From an accessibility perspective, there is some question about whether to use or to avoid tables. As a general rule, tables are more useful to screen reader users with more skills who know how to use the screen reader tools that assist in navigating a table. Even more important though, is a web developer using tables appropriately and designing them correctly.
When to Use a Table
Tables display pieces of information that have some sort of relationship. For example, the dates on a calendar are organized horizontally by day of the week and vertically by week of the month. A list of books can be organized vertically by information such as the title, author (s), editor, publication year, or ISBN and horizontally by the book. Some data often times fits best into a table, rather than a paragraph. For example, month and year horizontally along the top and climate information such as highest/lowest temperature, precipitation, and humidity vertically along the left. Writing all of this information out in a single line of text would make it much more challenging to access, understand, and recognize patterns and relationships.
Tables are just as valuable to someone who is blind as to someone who is sighted. They provide information about relationships, simply explaining how one piece of information is oriented with respect to another, and how sets of information relate to one another. Tables also make it easier to sort through a lot of information more quickly. Users can sort horizontally and vertically to find what they want without having to go through every piece of information. Frequently when a developer eliminates tables for “accessibility,” they simply put all the information into linear form,potentially making it tedious to navigate.
When Not to Use a Table
The biggest problem is when a developer uses a table in order to format a page. The table provides extra information to a screen reader user and impacts the order in which they navigate through the content. When a screen reader user enters a table, the screen reader will say something along the lines of “Table with 54 rows and 4 columns.” Then, as the user navigates through the table, the screen reader will provide information about their location in the table such as “Row 2 check box unchecked.” If the table is meaningless, the information about location in the table winds up being burdensome and distracting. Here is a link to a video of a screen reader user navigating an email that uses tables for layout. For a screen reader user, it’s equivalent to having talk radio playing the background during a meeting - not impossible to work with, but it makes it difficult to concentrate. In addition, the use of a table suggests there is some sort of meaningful relationship about how the contents are organized. A screen reader user might spend time trying to find this relationship, and in the end waste time if there is no such use.
How to Make a Good Table
Here is a link to a screen reader user navigating an accessible and inaccessible table.
- Label column headers. As a screen reader user moves horizontally along a row, it reads the contents of the column header. This is helpful, because it allows a user to review the title of the column without having to navigate back up to the first row to remember which column they are on. It gives a screen reader user quick access to remember how the table is organized.
- Label row headers if it is appropriate. When a user navigates vertically up and down a column, the screen reader will read the row header, if it is appropriate to have one. In some cases, such as a bus schedule, a table is just columns of times below stop names and it would not make sense to read the contents of the first column every time if the first column is times the bus arrives at the first stop. However, if the table is a list of courses for the semester, the class name in the first column should be read each time, so a user knows what course they are looking at as they go over other information such as location and time. In this case, it is important to make sure the header column is meaningful and not just the first column; a check box could be the first column, but would not be helpful to have read each time a user changes rows. The headers provide orientation to where a user is in the table.
- Avoid merging cells. When cells are merged, it blocks a screen reader from navigating in a way that makes sense, increasing the likelihood a user will miss content or be unable to understand the overall layout.
- Be careful when nesting tables inside of tables. This increases the likelihood a screen reader will have problems navigating and get stuck inside a cell. It is also harder to follow the intention of the developer. Before nesting tables, consider if it is possible to create separate, simpler tables.
- Keep tables as simple and small as possible. All users, both with and without a screen reader or more likely to struggle with a table that is too large and contains too much information.
Conclusion
Tables are a useful way to present the types of information that belong in a table. When they are used appropriately, they do make content more accessible.