Tables: accessibility for content authors

  • Author: Access iQ ®
  • Date: 28 Nov 2012
  • Access: Premium

Quick facts

Information can be presented online in a number of visual ways. Tables offer a way of displaying data in a format that allows users to clarify relationships visually.


Their biggest advantage is in allowing users to cross reference two pieces of information to perceive a third piece of information, while ignoring everything else in the table.

That advantage is lost to users of screen readers, as they process content according to marked up instructions, not visually. Without specific markup, screen readers will read and voice all the table content left to right, top to bottom, thereby defeating the purpose of using a table at all.

HTML can be used to provide instructions for screen readers to follow, such as how to voice information presented in a table, and in what order information should be read. This way, markup helps preserve meaning and provides context for people using screen readers to access tabular data.

As an example, online bus schedules published as data tables can be marked up appropriately so that a person who uses a screen reader can match their bus route with time and place.

Most web professionals are aware that tables should be used only for the presentation of tabular data. They will be equally aware that tables have been used for many years now — and continue to be used — purely to assist in managing and controlling elements in a webpage layout.

The reality, as the WCAG 1.0 Note on Tables acknowledges, is that we need to know how to make all tables accessible, whether used for tabular data presentation or to manage page layout.

Data tables

Making tables of data accessible to users of assistive technology requires the use of markup to provide instructions for the proper processing of the information presented.

There are several techniques that make this possible.

Specifying row and column headings

The main objective is to preserve logical relationships between sets of data that would otherwise be obviously perceivable. Using the table element with the child elements <tr>, <th>, and <td> makes these relationships perceivable to screen readers.

The th element tells the screen reader that the area it is pointing to is the 'table header'. If the table is marked up appropriately, any data in the cells underneath the <th> attribute will be associated with that header. This means that the relationship between data in the table is preserved.

In Example 1 below, the use of the <th> element in the first row defines the days of the weeks as column headers, while the use of the <th> element in the second and third rows of the table define the time intervals as row headers.

Example 1:

<table>

  <tr>

    <td> </td>

    <th>Monday</th>

    <th>Tuesday</th>

    <th>Wednesday</th>

    <th>Thursday</th>

    <th>Friday</th>

  </tr>

  <tr>

    <th>8:00-9:00</th>

    <td>Meet with Sam</td>

    <td> </td>

    <td> </td>

    <td> </td>

    <td> </td>

  </tr>

  <tr>

    <th>9:00-10:00</th>

    <td> </td>

    <td> </td>

    <td>Doctor Williams</td>

    <td>Sam again</td>

    <td>Leave for San Antonio</td>

  </tr>

</table>

A screen reader will announce the column heading then the cell information, so the relationship between the cell and its column header is preserved. For example, "Row 2, Monday, Meet with Sam".

For those not using a screen reader, the visual presentation of the data in tabular format is maintained.

Using complex tables

So far we’ve given examples of simple data tables with no merged cells and only a single row or column of headers. When you merge cells within a table or have multiple header rows or columns, then it is necessary to manually associate cells with their corresponding headers. If this isn’t done, then screen readers will not correctly convey the relationship between cells and their respective headers to the user.

Both header cells and data cells can be associated with more than one table header column or row.

To indicate that a cell relates to more than one header which is marked up with the th element, all header cells are given unique identifiers so that the screen reader knows which header the data belongs to.

This is a two-step process:

  1. Give the header cell a unique identifier.
  2. Associate other cells (remembering these can be header cells or data cells) with their corresponding header or headers.

If the cells are not manually associated with their related headers, then the screen reader will not read out all the associated information.

Example 2:

Table comparing homework, exams and project results.
 

Homework

Exams

Projects

15%

1

2

Final

1

2

Final

15%

15%

20%

10%

10%

15%

<table>

   <tr>

     <th rowspan="2" id="h">Homework</th>

     <th colspan="3" id="e">Exams</th>

     <th colspan="3" id="p">Projects</th>

   </tr>

   <tr>

     <th id="e1" headers="e">1</th>

     <th id="e2" headers="e">2</th>

     <th id="ef" headers="e">Final</th>

     <th id="p1" headers="p">1</th>

     <th id="p2" headers="p">2</th>

     <th id="pf" headers="p">Final</th>

   </tr>

   <tr>

    <td headers="h">15%</td>

    <td headers="e e1">15%</td>

    <td headers="e e2">15%</td>

    <td headers="e ef">20%</td>

    <td headers="p p1">10%</td>

    <td headers="p p2">10%</td>

    <td headers="p pf">15%</td>

   </tr>

  </table>

In Example 2 above, the unique identifier for the 'Exams' header is 'e', marked up as id="e". Directly underneath the 'Exams' header is another row of headers marked up as:

Example 3:

<th id="e1" headers="e">1</th>

     <th id="e2" headers="e">2</th>

     <th id="ef" headers="e">Final</th>

By tagging the above table headers with the unique identifier id="e" you are associating them with the 'Exams' table header. This is important for screen readers so that users can associate information with the right headers, rows or columns so meaning is preserved.

Using captions to describe information in a table

The <caption></caption> element identifies or explains the information expected in a table. It is displayed above the table when viewed in a browser.

A screen reader will read out the caption to identify the table and its contents.

Because of this, while a caption can be placed anywhere in the table markup and still be displayed visually above the table, it is good practice to place the caption just after the opening <table> element, so that screen readers voices it first.

When thinking about how to caption a table, remember that a caption should not rely on implied visual knowledge.

If a bus timetable that cross references stops with estimated arrival times is given the caption "Bus Route 373 timetable", it requires the user to know which stops that route covers. A sighted user could tell at a glance, but a blind or vision impaired user relies on the caption in the first instance.

A caption such as "Bus Route 373 timetable, Coogee to City" at least tells the user the route's start and finish points, and in which direction the bus is travelling.

We can apply this technique to our earlier example of a table of appointments.

Example 4:

<table>

  <caption>Appointments by day of the week and time of day</caption>

  <tr>

    <td> </td>

    <th>Monday</th>

    <th>Tuesday</th>

 

...</table>

Using summary to describe how a table is organised

The summary attribute can be applied to the <table> element to give screen reader users an overview of the table, providing a description that will specifically assist blind and vision impaired users to understand the layout of the table and how to navigate it so they can get the information they need.

The caption and the summary serve two distinct purposes. A caption identifies a table whereas the summary describes how the table is organised and how the information is presented. It is important that the caption and the summary information are different — do not simply duplicate the content, or copy and paste one into the other.

Our appointments table might have the following summary:

Example 5:

<table summary="This table cross references days of the week across the top with time intervals down the left to identify appointments.">

The full code for that table is now:

Example 6:

<table summary="This table cross references days of the week across the top with time intervals down the left to identify appointments.">

  <caption>Appointments by day of the week and time of day</caption>

  <tr>

    <td> </td>

    <th>Monday</th>

    <th>Tuesday</th>

    <th>Wednesday</th>

    <th>Thursday</th>

    <th>Friday</th>

  </tr>

  <tr>

    <th>8:00-9:00</th>

    <td>Meet with Sam</td>

    <td> </td>

    <td> </td>

    <td> </td>

    <td> </td>

  </tr>

  <tr>

    <th>9:00-10:00</th>

    <td> </td>

    <td> </td>

    <td>Doctor Williams</td>

    <td>Sam again</td>

    <td>Leave for San Antonio</td>

  </tr>

</table>

Source: WCAG 2.0

A good summary will help screen reader users find the information they need from data tables.

Our bus timetable will greatly benefit from a detailed summary.

Example 7:

<table summary="Timetable for bus route 373 going from Coogee to the City. Service begins at 9:55am and ends at 10:45am. The bus route number is listed on the top row. Intersections are listed on the first column on the left. Find the intersection closest to your starting point or destination, then read across the row to find out what time the bus leaves that intersection.">

<caption>Bus Route 373 Coogee to City timetable</caption>

  <tr>

    <th>Stop</th>

    <th>373</th>

    <th>373</th>

    <th>373</th>

    <th>373</th>

    <th>373</th>

    <th>373</th>

  </tr>

  <tr>

    <td>Arden St Nr Coogee Beach (203741)</td>

    <td>9:55am</td>

    <td>10:05am</td>

    <td>10:15am</td>

    <td>10:25am</td>

    <td>10:35am</td>

    <td>10:45am</td>

  </tr>

  …

</table> 

Source: WCAG 2.0

Note: The summary specified the start time and finish time on the timetable in Example 7. This will not be required for every table, but this particular one becomes much friendlier to screen reader users as a result.

Tables used for layout

We should emphasise again that using tables to manage page layout is not best practice. We must also acknowledge again that there are many existing websites that do use tables for content positioning and layout.

A common example is using a table to give the appearance that content is laid out in two or more columns in the style of a newspaper or magazine.

Example 8:

<table>

  <tr>

    <td width="250" valign="top">Road workers have become sick after finding suspected radioactive material during an upgrade to the Pacific Highway south of Port Macquarie on the NSW mid north coast.</td>

    <td width="15"></td>

    <td width="250" valign="top">A truck believed to be carrying radioactive waste from Sydney's Lucas Heights nuclear reactor was involved in a crash on that stretch of highway in 1980 and the waste was subsequently buried near the crash site.</td>

</tr>

</table>

A screen reader will read across the rows of content, ignoring the column effect, "Road workers have become sick A truck believed to be carrying after finding suspected radioactive radioactive waste …"

The key to making this content accessible to screen readers users is to make sure it can be linearised, which means that the text would make sense read out if the table code was stripped out.

Note: Browsers are continually developing better ways of rendering side-by-side text correctly, and screen readers are also getting better at processing tables and at rendering side-by-side text without using tables at all. However, it will be a while before this becomes commonplace. Until such time, it is necessary to provide a linear text alternative to a table used for layout that can be processed in the proper order by a screen reader.

WCAG 2.0 references

Related Techniques for WCAG 2.0