Tables can be an incredibly useful tool in the content creator's toolbox, allowing for the organization of information in fixed, predictable ways. For the consumer, tables often lend themselves to information that is easy to find, scan, compare, and interpret — but they can also cause major usability headaches when used without accessibility in mind, sometimes making content extremely hard to understand and navigate. In addition to proper use of column and row headers, ensuring table accessibility sometimes has more to do with knowing when not to use them at all. In fact, tables should only be used for presenting tabulated data, not for layout or formatting.
It's a common practice, unfortunately, to display all or part of a web page inside a table. Developers may choose to do this so that the formatting of the content matches the design, essentially relying on the inherent structure of table rows, columns, and cells to place content where it seems to physically belong, visually. For example, if content was created to be displayed in two rows of three columns, a developer might place the information in a table so it displays as such. They might use a table for more of the page, or the whole page even, to help make sure elements like the header and footer are always fixed in their expected positions.
By removing visible table borders or using border colors that match the background color, can developers really tap into the formatting benefits of a table without anybody realizing it? Unfortunately, no.
Tables are structural elements. They have semantic value in the code. Blending cell borders into the background doesn't change that. They remain a series of cells organized by rows and columns, and those properties remain. This means that web browsers will continue to treat them as tables and, further, that assistive technology will continue to treat them as tables.
These user agents rely on the meaning of the elements being used, and tables have inherent meaning built in. Browsers and assistive technology have to assume those elements are used as they're intended, and tables are intended to show data that belongs in a table.
Using a screen reader as the example, it won't know that a developer has made the decision to use a table in another way. It will try to read the table as though it is presenting tabulated data, even if it is not. This means it will announce table properties and will continue to announce them as the reader moves through the content. The experience to the screen reader user then becomes a series of row and column announcements that don't make sense for the contained content. As a result, otherwise-straightforward information is complicated by the unintelligible application of table properties. Out-of-place announcements like "row two, column four" can range from an annoyance that can be overcome to complete confusion about the correct way to read the information.
Coming across improper tables also tells users that the website owners either don't know or don't care about accessibility best practices, the wrong message to send and one that can be avoided easily.
If there are instances in which tables have to be used for formatting or layout purposes — temporarily or perhaps in emails where the practice is fairly common — developers should add role="presentation" to the table elements. This instructs assistive technology to ignore the table properties and read the content as if it were not in a table. While this isn't likely to work across the board for all screen readers and devices, it will provide enough coverage to make it a worthwhile and important patch.
Was this content helpful?
Subscribe to our blog and newsletter.
