The a11y Monthly: Get rid of your tables (or fix them)

While the original intended use of HTML tables was tabular data, tables are also used as aids for page layout. This was especially true some years ago when browsers hardly supported CSS. Tables were necessary to overcome limitations in visual presentation. Today, there is much more flexibility in controlling page layout using CSS. Does it still make sense to use layout tables? From an accessibility perspective, are layout tables good or bad? Any myths and misconceptions to debunk? At Yoast, we’ve decided to get rid of the few layout tables still used in our plugins.

We’re working hard on making the web and our products as accessible as possible for everyone. We believe every single individual on this planet has a right to accessible web content and we have to lead by example. Since so much of our work goes on behind the scenes, we’re publishing this monthly series of blog posts to keep you posted on this important part of our work.

What the rules say about tables

In the HTML5 specification, the table element is under a section named “Tabular data”. The specification doesn’t define what “tabular data” is, but one thing is very clear: HTML tables are meant to represent data. Besides that, there’s a separate W3C recommendation that defines an abstract tabular data model. Quoting from the specification:

The table element represents data with more than one dimension

That’s a pretty imperative statement and seems there are no exceptions. Yet, the specification introduces some ambiguity when it says:

Tables should not be used as layout aids

Thus implicitly admitting that tables may be used for layout purposes. Although the specification strongly encourages authors to not use layout tables, it also describes a series of indicators user agents should use to determine when a table is used for data or layout. It also suggests a few techniques, such as the use of the role=”presentation”, to help user agents and assistive technologies understand the table is used for layout purposes. Ambiguity increases.

Myths and misconceptions

It’s a common belief that layout tables are always bad for accessibility. That’s not necessarily true. Layout tables don’t create accessibility barriers as long as they’re designed with accessibility in mind. When following a few basic techniques, assistive technologies ignore the fact that the content is inside of a table. They read it in the order that it appears in the markup. If the order is logical, then there are no accessibility concerns.

What many authors and developers probably don’t know, is that browsers and screen readers try to make an educated guess to determine which tables contain data and which are used for layout. The HTML5 specification suggests some possible indicators for this heuristics. Browsers use them to expose the result of their “guess” to assistive technologies. Sometimes, this educated guess is based on the analysis of the table structure and markup; sometimes even CSS borders can make a difference. If you want to get an idea of how this works, I’ve prepared a simple test page.

Why it matters

When screen readers identify a table as a “data table”, they will announce the presence of the table including the number of columns and rows. They will also provide table navigation functionality, and repeat the row and column headers when navigating through the table cells. This behavior gives users contextual information about the cell’s data. Say, for example, the screen reader moves to a cell that says “10”: it’s essential that the screen reader also reads the column and row headers to communicate users what “10” actually means.

Yet, when a table identified as “data table” is used improperly for content that is not tabular data, all the information about the column and row numbers are completely redundant and unnecessary. A very common scenario is an HTML form where the fields labels are in a table left column and the form fields in the right column. When navigating through the form fields, the screen reader will announce both the association between form fields and their labels and the information related to the table. For example:

• First name, column 1 of 2
• First name, edit text, column 2 of 2

In this example, the semantics added by the data table is pointless and potentially confusing for users. The only relevant information to convey is the field label, and anything else should be removed. There are two options: get rid of your tables or fix them.

Fix your tables

Data tables should use all the elements and attributes to convey the logical relationships among content. Instead, if you have to use a table for layout purposes, then you should make sure to remove any element or attributes that assistive technologies could use to identify a table as “data table”. It’s of fundamental importance that elements such as caption, thead, th or headers and scope attributes, or even borders, are never used within layout tables.

Get rid of your layout tables

At Yoast, we’ve decided to get rid of the layout tables. There were still a few of them in our plugins, mostly for historical reasons. For example, all the content in the Yoast SEO metabox, including the content added by other Yoast plugins like Video SEO for WordPress and News SEO for WordPress, is now table-free.

In our view, today there’s no good reason to use layout tables. Modern browsers have a great support for different CSS layout models, and you can build any kind of layout by just using CSS, with the advantage of a greater flexibility.

Simpler, cleaner, and more maintainable code is always valuable, especially in the long run. It helps to increase the intrinsic quality of our products and at the same increases the accessibility of our content for everyone.

Want to help?

Accessibility is a process based on continuous improvements, testing, iteration, and development. You can help. We’re always open to feedback and contributions. Please do not hesitate to let us hear your voice and please do report any issues or potential improvements you notice in our products.

Read more: The a11y Monthly: web content accessibility at Yoast »