DES 3.4 – Design and implement accessible tables and graphs
Why is this important?
Data should appear in the simplest form possible. Doing so makes understanding the content easy for everyone to understand, particularly those using assistive technology, such as screen readers.
Whether you are designing tables for web pages or office documents, there are options to specify row and column headers. Screen readers can use this information to give context to the table cell that they are announcing.
Avoid using tables for layout purposes
Tables are intended for conveying tabular data. Avoid using tables to provide a column-based layout for your pages. CSS is able to produce layouts that replicate table layouts, without the semantics that tables imply.
Use the simplest data table possible
- If you have a large, fairly complex table, split it into multiple, smaller, simple ones;
- Design your content so that the table reads out logically – row by row;
- Avoid merging columns or rows using rowspan and colspan – some screen readers have problems conveying their nature to users. If you find you are having to merge rows or columns, ask yourself, could I change my table design, or split this into two tables, to make it easier to navigate?
- Avoid leaving any table cells empty as these can cause confusion for screen reader users.
If your table is beginning to look complex, look at the data and ask yourself, ‘does this need to be in a table?’ This can be a good opportunity to consider a more appropriate format, for example, a narrative description with relevant data points and generalisations.
Use headings and table captions to convey the nature of the table
- The heading should appear directly above the table;
- If your template or content management system support the use of table captions, you can use this to describe the nature of the table.
Communicate important attributes to anyone implementing your data table
If someone else is implementing your table for you, make sure you:
- Differentiate header rows and columns <th> from data cells <td> through design;
- Provide designs for the table <caption> element, to summarise the nature of the table. Ideally, this text should be visible (rather than hidden to all but screen reader users) so that everyone has a similar experience, and so there is less chance of the text becoming out of date (as it will be easier to review if visible)
Do not use the table’s “summary” attribute
You used to be able to summarise the nature of the table in a <summary> attribute that sat inside the table. Since the latest version of the language web pages use (HTML 5), the <summary> attribute is no longer supported. Some screen readers will still announce it but you should not rely on that. Instead, you can use the <caption> attribute to convey the nature of the table, as that will make it available to all users. If necessary, you can use CSS to hide the <caption> from non-screen reader users.
For charts, provide a description in text and a data table of the chart data
- Do not rely on colour alone to convey information in the chart.
- If you are using a line chart, use different line styles (solid; dotted; dashed) and thicknesses;
- If you are using a bar chart, apply patterns to each bar (horizontal, vertical, diagonal lines) and border thicknesses.
Example of good practice
There is a caption above the table; column and row headers have been specified and are distinctive in appearance; there is an indication of the unit of measurement for age in the column header; the initial column is left-aligned, making it easy to scan; there is a comfortable amount of cell margin, making it easier to read.
Table 1 – Birthdays for class eleven
Example of bad practice
There is no caption above the table; column and row headers have not been specified and are not distinctive in appearance; there is no indication of the unit of measurement for age; the initial column is right-aligned, making it less easy to scan; there is no cell margin so the text is pinned to the cell borders, making it harder to read.
EN 301 549 v 2.1.2
- 1.1.1 Non-text Content
- 1.3.1 Info and Relationships
- 1.4.1 Use of Colour