Create Accessible Tables
Applies to the following areas:
|
|
Overview
Tables can sometimes be complex for assistive technologies to read. To make an accessible table, please use the Insert Table tool instead of the Draw tool. Tables should be used only for data or information that requires organization with rows and columns, not for layouts or lists. Often, complex tables can be simplified by breaking them into multiple simple tables with a heading above each.
General tips to keep tables simple, accessible, and easily understandable to assistive technologies:
- Make sure all columns have table headings and do not leave any heading row cells blank.
- Never leave the first table cell blank.
- Cells should all contain data (e.g., 0 or NA or “blank”).
- Refrain from merged or split cells.
- A heading or title should appear before the table.
- The best accessible tables are created using the Insert/Table functionality feature.
- Tables should be used to display truly tabular data and not for layout purposes.
Tables should not be used for layout or design of visual presentations. For example, a two-celled table in a syllabus should not be used to achieve a side-by-side instructor and teaching assistant contact information layout.
Bad example:
| Instructor | TA |
|---|---|
| Jane Doe, jane.doe@uagc.edu | John Smith, john.smith@uagc.edu |
Tables have additional functionality, which can cause accessibility issues if they are not created properly. So, a good rule is to use a list if extra functionality is unnecessary.
When to Choose a List Instead of a Table
- Small, temporary data sets: Lists offer fast and simple data entry for quick tasks or reference lists.
- Unstructured data: A list might be sufficient if your data doesn’t require analysis or sorting.
When to Choose a Table Instead of a List
- Large or complex data sets: Tables easily handle intricate data, enabling robust analysis and visualization.
- Frequent filtering and sorting: A table is the way to go if you need to filter or sort your data based on various criteria.
- Professional presentation: Tables offer a cleaner, more professional look for data sharing.
Tables vs. Lists
Structure and Organization
| Tables | Lists |
|---|---|
| Use rows and columns, which helps in organizing data with multiple attributes for each entry. Each column represents a specific attribute, and each row is a record. | Typically a single sequence of items without divisions into columns or rows. Good for organizing simple, single-dimensional data. |
Consistency and Automatic Formatting
| Tables | Lists |
|---|---|
| Often come with tools for automatic formatting, such as alignment, color coding, and cell formatting, which helps maintain consistency. | Formatting is generally limited, and they lack options for automatic alignment or cell-specific formatting. |
Flexibility
| Tables | Lists |
|---|---|
| Allow for more flexibility in handling complex data and multiple dimensions, including the ability to add or remove rows and columns easily. | More rigid, especially with larger datasets, since they’re limited to one dimension and don’t handle multiple attributes well. |
Limitations
| Tables | Lists |
|---|---|
| Can become cluttered or hard to read when dealing with a large amount of data, though they’re generally suitable for complex datasets. | Limited in terms of data complexity and best for smaller, straightforward collections without multiple attributes. |
Best Use for Data Size and Complexity
| Tables | Lists |
|---|---|
| Ideal for both large and small datasets with multiple attributes (e.g., customer data with name, email, and address fields). | More suited to small, simple datasets (e.g., a checklist or a sequence of names). |
Ease of Sorting and Filtering
| Tables | Lists |
|---|---|
| Columns allow for easy sorting and filtering by specific attributes, enhancing data organization. | Sorting can only be done on the entire list, limiting organization and making filtering challenging. Tables work best for multi-attribute, structured, or large datasets where consistency and organization are key. Lists are more efficient for smaller, single-attribute collections and simpler tasks. |
Tip
- Do not forget alternative text when creating a table. If the table contains information that cannot be deciphered from a screen reader or assistive technology, the entire table's meaning must be described in alternative text.
- Tables should have an identifying title or caption associated with them but outside of the table data. Generally, the best place is just before the table so that a screen reader can identify it before entering into the details.
- Text in the document's body should tell the author’s point for the end user to understand from the table if it is not merely a presentation of data. If the table is complex enough to need explanation, it likely is not very accessible and should be simplified.
- Column headings should be as simple and meaningful as possible to their intended audience. The first cell in each row should be a meaningful identifier of the row's content, not a row number.
Steps to add a table in a Word document
Steps to add a table in Google Docs
WCAG 2.1 Success Criteria
The issues described on this page map to the following success criteria in the W3C’s Web Content Accessibility Guidelines (WCAG) 2.1:
- 1.3.1 Info and Relationships (Level A)
- 1.3.2 Meaningful Sequence (Level A)
- 2.4.6 Headings and Labels (Level AA)