Tables are a great way to organize and share a lot of data and information. They help content creators and designers present facts and figures cleanly, when describing them in words and sentences may be difficult and tiresome. And, some types of information are natural fits for tables: rates, scores, standings, schedules, to name only a few.
A basic table is composed of individual cells, typically with the top row serving to categorize the data within each column and the left-most column serving to categorize the data within each row. Certainly, there are tables that appropriately have only one header and there are tables that have more complex header structures, but this information is for simple tables with row and column headers.
While there are many other factors for whether a table can be considered accessible, one of the most common accessibility issues with data tables is the lack of properly-coded headers.
Tables should have row and column headers
Here is a straight-forward table with fictional data. It shows how many friends, enemies, and acquaintances someone has in four states: New York, California, Florida, and Texas.
The information across the top makes up the column headers. The states make up the row headers.
| Friends | Enemies | Acquaintances | |
|---|---|---|---|
| New York | 35 | 12 | 17 |
| California | 7 | 11 | 3 |
| Florida | 18 | 3 | 18 |
| Texas | 27 | 9 | 7 |
If someone is reading this table visually, it is the intersection of those labels that makes the data within the table make sense. For example, it's because they know that the column is labeled "Enemies" and the row is labeled "California" that the number "11" means anything, in this case that the person has 11 enemies in California.
Commonly, developers will run into accessibility trouble when they consider tables as serving only a visual purpose, ignoring or not completely considering the semantic meaning of the table properties. After all, a table is presenting data, so that data needs to be coded carefully.
So, when focusing only on visuals, it is common for developers to miss coding headers altogether, or to code only one category (row or column) as headers.
Now, so far in the example, only visual presentation was mentioned; however, if someone is reading the table using assistive technology, like a screen reader or refreshable Braille display, the same principle is true: it is the intersection of the labels that makes the data make sense. Those labels provide the context needed for the numbers to mean anything, and without them, they're just numbers.
Sticking with the same table example above, here is how the scenarios of providing no headers or only one set of headers would play out, using a screen reader. Please note the user in this example is navigating cell-by-cell within the table to consume the information.
- With no headers, starting at the same number "11" cell, the user has no context. The row and column that the "11" belong to are not identified. If the user chooses to navigate, let's say, one cell to the right, they would hear something along the lines of "row 3, column 4, 3," (with the exact announcement varying based on software and device type). That number "3" means nothing on its own, and the row and column numbers provide little context either. The relationships between all of this information have not been made available to this user and the table information is not accessible.
- With only one set of headers applied, the column headers for example, let's pick back up at the same cell number "3." If the screen reader user navigates to the left one cell, they'll be told that focus has moved to the "Enemies" column and they'll hear the data, "11." That's great because now they know the value for this column is 11. Now, if they choose to move one row below, they'll hear something like "row 4, 3." This is where the experience breaks; they know they are in the "Enemies" column, but the row they're in doesn't have a label available, and so the context is lost. "Enemies" and the number "3" don't mean anything without knowing the state, too.
If the same screen reader user is navigating the same table, and both column and row headers have been correctly applied, they can move throughout the table always knowing exactly which column and row is receiving focus.
Picking up at the last number "3," which is the number of enemies in Florida, the screen reader user can move one cell to the right and be told the new column name and the value in the cell, and know for certain the person has 18 acquaintances in Florida. They can move one cell down, knowing they're in the "Acquaintances" column, and hear "Texas, 7," learning the person has seven acquaintances in Texas. They can move between each cell and always have the full context, thus having the same information that is apparent to some people visually.
If either or both of the table headers are not appropriately applied, that information is lost and the table is not accessible.
Like this content?
If you found this explanation helpful, be sure to subscribe to our blog and newsletter. We are always publishing new content designed to be of value as we work to make the internet accessible to everyone.
Looking for help with your accessibility initiatives? Contact us or get started with a free website accessibility scan.
