AccessibilityTables

Tables are used to present data in rows and columns. It allows a user to make quick connections between different data.

You must create tables in a way that assistive technology can understand. This means making tables available to screen reader, screen magnification and speech-to-text software users.

Where possible, you should use semantic HTML to indicate different table cells. Tables should not be used to position elements on a web page - for this you should use other CSS layout techniques.

See the impact that accessible tables have on people who use text to speech software.

Helping everyone

All users will benefit from well-structured and simple tables.

The basics

Do:

• Present tabular data using semantic HTML markup

Do not:

• use tables to position text or lay out elements on a page
• create overly complex tables or nest tables within each other
• use ARIA roles to replicate the structure of a table unless absolutely necessary

Examples of users with access needs

User	Access need	May find helpful
Blind	Uses screen reader to understand the structure of the table	Correctly marked up table cells
Blind or partially sighted	Using custom style sheets to adjust how a table looks	Correctly marked up table cells that are responsive
Cognitive impairment	Understanding table layout – associations between data	Less complex tables

Creating good tables

A correctly implemented table with structural markup means that screen readers will correctly read out the content of cells and users will be able to apply alternative rendering to suit their needs. You should use the tables component in the GOV.UK design system for simple tables.

You should consider whether the information you’re presenting needs a table or whether a different presentation method would be more suitable.

Table structure

Tabular data needs to be presented using proper HTML markup.

• Tables should be implemented using <table>
• Table rows should be marked up with <tr>, header cells should be marked up with <th> and data cells should be marked up with <td>
• For tables with headers in the top row and first column use the scope attribute to denote the direction

It is worth noting that <thead>, <tfoot>, and <tbody> are not semantic HTML and do not make the table more accessible - they are only used for styling.

Table caption

Tables should include a <caption> element which summarises the overall purpose of the table. This is particularly useful for people navigating from table to table.

The <caption> element should be nested within the <table> element, before any other html elements.

You should not use <summary> as this is no longer recommended in HTML5.

Complex tables

You should avoid creating complex tables with multiple rows or columns of headings. Creating complex tables impacts navigation and understanding for all users.

For more complex tables, use the scope attribute in the <th> element to associate each header cell with the relevant data cells. The scope attribute can have a number of values, including row and col, and rowgroup and colgroup for header cells spanning multiple rows.

You can also associate <th> elements by assigning an id attribute and referencing this using a headers attribute in a <td> table cell.

For more guidance on more complex tables, such as tables with irregular headers and multi-level headers, see Tables concepts.

If you cannot use semantic tables (for instance, if yre working with a complex, highly custom component), ARIA roles can be used to replicate the structure of a table. However, you should avoid this as it adds complexity. If you need to use ARIA, please see the Table Design Pattern in WAI-ARIA Authoring Practices 1.1.

Table text

Ensure that text within tables can be resized up to 200% and the text spacing adjusted without it being clipped, truncated or obscured.