Techniques

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. If your templates or content management system does not provide the layout you require, liaise with your design team who will be able to produce an appropriate layout for you.

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:

  • identify header rows and columns so that they can be coded correctly (developers will code header cells as <th>, to differentiate them from data cells <td>
  • explicitly state the text you wish to use to summarise the nature of the table – this will go inside a <caption> attribute, at the top of the table. Specify whether or not you want this text to be visible to everyone – it is usually a good idea to allow that 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

NameAge (years)Birthday
Emily83rd September
Francois1228th April

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.

NameAgeBirthday
Emily83rd September
Francois1228th April

References

WCAG 2.1

  • 1.1.1 Non-text Content (A)
  • 1.3.1 Info and Relationships (A)
  • 1.4.1 Use of Colour (A)

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

Further reading