Tables
Use a table to let users compare and navigate to information in rows and columns. Out of the box, html almost makes tables accessible. In our experience, adding these further help:
Use the <caption> element to describe a table in the same way you would use a heading. A caption helps users find, navigate and understand tables.
<caption> is visible to sighted users as well, so use CSS to make them screen reader only if needed.
The <summary> element was deprecated in HTML5, so it should be avoided.
Use table headers to tell users what the rows and columns represent. Use the scope attribute to help users of assistive technology distinguish between row and column headers. For example,<th scope=”col”> or <th scope=”row”>.
If the table uses semantic tags for table headers, rows, and cells, there is no need to add role attributes to these tags.
Use aria-sort to communicate the sorting method to screen reader users. This works most reliably with an explicit 'role=”columnHeader”'
Not all screen readers support aria-sort, but a sorting button label of "sort by [column label] in [‘ascending’ | ‘descending’] order" makes things clear enough to those who do not have the sorting state reported.
If you are using icons to represent sorting status, use an SVG. SVGs scale without degradation for users who use zoom in. They also respect native contrast settings.
Don't use tables just for layout or presentation. To be more clear, don't use tables for anything but tabular data.
Semantically, use table markup when you need users to navigate rows and columns. If you were to use a list, that would severely limit anyone who may be using assistive technology.
Consider the context of your users. If most of them will be accessing your service/website via a mobile device, your table will need to be accessible even when responsive.
It is best practice to shift from a table layout to a stacked card layout. Adrian Roselli has an in-depth post on how to make responsive tables accessible.
Avoid nested tables if you can. Whilst they help present information in a contained manner, they are not entirely accessible. Screen readers are often thrown off and don’t convey context correctly.
For example, for a screenreader to read ‘BIS 3330’, it would convey all the nesting rows and columns before reaching the actual cell value.
Consider splitting them into multiple tables. Alternatively, if you must do the nested table, test with your users who use assistive technology to ensure that it is usable and conveys context effectively.
There can be situations where you may have form elements within a table. For example, a combo box with mutli-select.
Making these accessible is hard because you need to convey that it’s a form element within a cell, convey any state change (going from read view to edit view) involved when interacting with it and provide feedback based on the user interaction. Consider if you can start with two separate views - The table and an edit view for the information you are looking to add/edit.
https://tink.uk/how-screen-readers-navigate-data-tables/ https://inclusive-components.design/data-tables/ https://brucelawson.co.uk/2020/accessible-data-tables/ https://www.w3.org/WAI/tutorials/tables/
Managed Care Review, EASi