Presenter: Hans Hillen
Watch the recording of “Responsible Responsive Tables: Where Are We Now?”.
Ever since responsive web design gained traction, accessible responsive data tables have remained somewhat of a holy grail. How do you reflow a structure that by its very nature has two or more dimensions? This presentation showcases different approaches to the problem, as well as the advantages and drawbacks that come with each of them.
When it comes to accessible responsive tables, it should be understood that there is no single approach that perfectly addresses the problem for every form of tabular content. This is because, at their core, data tables and responsive web design are not compatible. Each approach discussed in this presentation therefore has a case that can be made against it, and it’s up to the developer to decide which method is the best fit for their content.
The first decision to make is whether the table structure should remain intact across all responsive breakpoints. If so, the table can be squashed, made scrollable, or utilize collapsible columns in order to adapt to the available horizontal space. A combination of those methods may be used as well. The advantage of this approach is that the table’s semantic and accessibility benefits remain available to assistive technology users as well, even on smaller screens. The obvious downside is that it will only work for small tables with relatively little content in it. In addition, collapsing columns or scrollable tables may not be feasible for the content being displayed in the table.
An alternative and more likely scenario is a relatively large data table, containing more than a few columns that cannot be collapsed. Such a table would likely need to reflow to a different type of layout structure on smaller screens. For example, the data could be rendered as an accordion-style list of expandable sections, where each section represents a single table row. In this scenario, it would be beneficial if there was a match between the visual layout and the semantic structure exposed to assistive technology. In other words, we want to avoid a situation where a screen reader is announcing a tabular structure when there isn’t one visually.
One way to achieve this is to simply have two separate versions of the data, of which only one is visible at a time: one structured as a data table on desktop layouts, and one structured as collapsible sections on mobile ones. The reason this is not ideal is the redundancy involved. Having the content exist twice on the same page goes against the principles of responsive design, and makes the content harder to manage. This means that the next decision to be made is how this single source of content can be transformed from a tabular structure to a mobile friendly layout as part of a responsive breakpoint switch.
From a development perspective, the easiest approach would be if table markup was not used to begin with: having the content structured as a CSS flexbox layout makes it much easier to reflow than a regular data table would be. The problem is that this approach discards the benefits that data tables provide for assistive technology users, such having row and / or column headers be announced automatically. With this constraint in mind, we are left with the following options:
- Override the table’s display styles in responsive layouts, so that it’s no longer rendered as a data table or announced as one by screen readers.
- Use a flexbox layout after all, but give it table semantics trough the table specific roles that were added in ARIA 1.1.
The result is a table has the correct tabular semantics when it needs to, but the flexibility to be presented in a mobile friendly layout without requiring duplication of data. Having said that, these approaches will still require some scripting in order to provide the ideal accessible user experience across all responsive breakpoints. This is because in the responsive layouts, the table’s native roles will no longer be available to screen reader users. Other markup will have to be used to make up for this lack of semantics, such as headings, lists and ARIA markup.
All these examples demonstrate that there still is no perfect solution when it comes to having data tables adapt to all screen sizes in an accessible way. Instead, we have to consider the type of data being displayed and choose the least unsuitable method for making it responsive.