In this lesson
Data tables
Tables were originally designed purely to show collections of data such as numbers or statistics so that they could be read by computers using applications such as databases and spreadsheets. The data could then be manipulated for research purposes and the relationship between different bits of information would be easy to identify.
Table element
The table element <table> groups together numbers, words and phrases in a reference-able format. Each column and row can be treated as a block of inter-related information. Individually these words and phrases make no sense if read out of context, but within the table format their relationship to each other is clear. An added benefit is that tables can be imported into a database or spreadsheet and manipulated for further analysis.
The basic HTML data table consists of three parts
1. The <table> element itself.
2. The table heading <th> that defines row and column headings
3. The table data <td> that defines each data cell within the table.
Summary attribute
Because tables are complex structures the opening <table> tag always has a summary attribute that can be read out by screen readers to explain the table. This is written as :-
<table summary=“Some text to explain the table”>
Visual users will not see the summary but blind people will hear it read out before the table is rendered.
Summary should be used to describe the primary purpose of the table and give an indication of its overall structure. Most assistive output technologies will read the summary first to provide the user with information to help them interpret and use the table. With more complex tables, the summary is very important.
<CAPTION> for the Table Title
The title for data tables you see on the web today are often presented outside the table in a separate heading <h> or paragraph <p> element. In some cases they are presented within the table in the top row <tr> or data cell <td>. All of these approaches may cause problems for users of assistive technologies.
The <caption> element is the most accessible way of providing a table with an identifying title. By default, 'caption' will place the title in the centre immediately above the table. However, CSS can be used to change the style and on screen position of the 'caption' element. For example, the title (caption) can be put underneath the table as is commonly done in scientific and academic publications.
When coding a table, the <caption> element should come immediately after the opening table element and before anything else.
Example of a data table
The table below shows the meals available at certain times on certain days. If we look at the Wednesday column and the Lunch row we can tell that we will have roast beef for lunch on Wednesday. This is easy for a sighted user to understand as the column and row headings are at the top and far left of the table, and printed in bold.
| Meal | Monday | Tuesday | Wednesday | Thursday |
|---|---|---|---|---|
| Breakfast | Boiled egg | Fried egg | Bacon | Poached egg |
| Lunch | Lamb Stew | Grilled fish | Roast Beef | Lamb Chops |
| Supper | Pasta | Pizza | Hamburgers | Spaghetti |
Blind users do not get the benefit of seeing the whole table, they only hear a string of text read from left to right, one row at a time. For automated software such as screen readers to be able to understand the relationships within the table and present these to the user it is important to code the column and row headings using the <th> element to define them as “heading” cells. The software can then store these headings in memory and reference them to the relevant data cells <td> within the table. A blind person using a screen reader is thus able to pause in the Roast Beef cell and check the column heading (Wednesday) and the row heading (Lunch). In this case the user would press the up arrow to hear “column heading four Wednesday”, and press the left arrow to hear “row heading three Lunch”.
Without these headings a blind user would have to remember the sequence of column headings and the title of the current row as they tabbed through the table. This becomes virtually impossible with larger tables.
Scoping the headings
Because we use the same heading element <th> for both column and row headings it is advisable to add the scope attribute in order to clarify if the heading is a column or row heading. Thus we would write the code for the above table as
<table summary=”Meals delivered Monday to Thursday”>
<caption>Weekly menus for residents </caption>
<tr> <th scope=”col”>Meal</th>
<th scope=”col”>Monday</th>
<th scope=”col”>Tuesday</th>
<th scope=”col”>Wednesday</th>
<th scope=”col”>Thursday</th></tr>
<tr> <th scope=”row”>Breakfast</th>
<td>Boiled egg<</td>
<td>Fried egg</td>
<td>Bacon</td>
<td>Poached Egg</td> </tr>
<tr> <th scope=”row>Lunch</th>
<td>Lamb Stew</td>
<td>Grilled Fish</td>
<td>Roast Beef</td>
<td>Lamb Chops</td> </tr>
<tr> <th scope=”row”>supper</th>
<td>Pasta</td>
<td>Pizza</td>
<td>Hamburgers</td>
<td>Spaghetti</td> </tr>
</table>
We have added scope=”col” to the column headings so that the users software knows that these headings relate to the data in the cells directly beneath. We have also added scope=”row” to the row headings so that the user's software knows that these headings relate to the current row (horizontally).
Abbreviations for headings
Another function blind users can set up is to have the headings repeated automatically as they tab across the table. Because we have now included the “scope” attribute the user could now hear the following as they tabbed across the second row of the above table.
“Heading row 2 Breakfast, Monday, boiled egg, Tuesday, Fried Egg, Wednesday, Bacon, Thursday, Poached egg”. The screen reader stores the heading in a cache so that they can be repeated each time a relevant data cell is focused.
It can get a bit tedious for blind people to hear the full title of long column or row headings, so HTML provides an abbreviation attribute for the <th> element. In our case above we might use the abbreviations "mon", "tue", and "wed" for the days of the week. When deciding on an abbreviation for a heading please bear in mind what it will sound like when processed by a screen reader. These abbreviations are not seen by sighted users, so it is good practice to write them phonetically (i.e. spelling is not as important as what it sounds like).
Complex data tables
The scope attribute really comes into its own when we have more complex tables as shown below.
| Meal | Monday | Tuesday | Wednesday | |
|---|---|---|---|---|
| Breakfast | Normal | Boiled egg | Fried egg | Bacon |
| Vegetarian | Cereal | Cereal | Cereal | |
| Nut Free | Boiled egg | Fried egg | Bacon | |
| Lunch | Normal | Lamb Stew | Grilled fish | Roast Beef |
| Vegetarian | Lentil Chili | Fennel Bake | Tofu Paella | |
| Nut Free | Lamb Stew | Grilled fish | Roast Beef | |
| Supper | Normal | Pasta | Pizza | Hamburgers |
| Vegetarian | Couscous | Savoury Crumble | Tofu Burgers | |
| Nut Free | Pasta | Pasta | Fish cakes |
Each row has two headings, the mealtime and the type of meal. The mealtime (breakfast, lunch, supper) is only written once, but they each span three separate rows so they need to be repeated for each of the meal types as the screen reader works through the table.
<table summary="Optional meals available from Monday to Wednesday">
<tr>
<th scope="col">Meal</th>
<th scope="col">Type</th>
<th scope="col">Monday</th>
<th scope="col">Tuesday</th>
<th scope="col">Wednesday</th>
</tr>
<tr>
<th rowspan="3" scope="rowgroup">Breakfast</th>
<th scope="row">Normal</th>
<td>Boiled Egg </td>
<td>Fried Egg </td>
<td>Bacon</td>
</tr>
<tr>
<th scope="row" abbr=”vejjy”>Vegetarian</th>
<td>Cereal</td>
<td>Cereal</td>
<td>Cereal</td>
</tr>
…..etcetera……..
</table>
Note that we have added the abbreviation (abbr) attribute to the vegetarian heading so that screen readers do not read out the full “vegetarian” title as they scroll across the page – we have also spelt the abbreviation phonetically to get the “jee” sound rather than the guttural “ggee” sound.
For really complex tables – where the relationship between the column headings and the data is not clear – it is possible to tie individual cells to individual headings using the “id” and “headers” attributes. Here each <th> element is given a unique “id”, for example <th id=”unq1”>heading</th>. Then any data cells that require that particular header are written as <td headers=”uniq1”>data</td>. An example of this is available on the W3C website at http://www.w3.org/TR/html401/struct/tables.html#h-11.4.1
Long Data Tables
For long tables, ie tables that might, when printed, go over one or more pages it is possible to set the table heading and footer rows so that they repeat on the top and bottom of each new page. This option might work on some browsers (but not all) so should only be used when you have a very long table that you think people will want to print out, and would extend beyond a single page of paper.
Example of code used for a long table
<table >
<thead>
<tr> <th scope="col">first head</th><th scope="col">second</th> <th scope="col">third</th> <th scope="col">fourth</th> <th scope="col"> Fifth</th> </tr>
</thead>
<tfoot>
<tr><td>first foot</td> <td> </td> <td> </td>
<td> </td> <td> </td> </tr>
</tfoot>
<tbody>
<tr> <td>body 1</td> <td> </td> <td> </td>
<td> </td> <td> </td> </tr>
</tbody>
</table>
Note that the table heading and footer rows are coded before the table body rows. This can cause problems for text only browsers so please avoid this method of table construction if at all possible. A good solution is to offer the table as a downloadable file (Excel, Word or PDF document) for the visitor to print out separately. This means that you don’t need to use the <thead> and <tfoot> elements within your HTML.
Avoid Columns of Empty Table Cells
Developers sometimes use columns of empty header and data cells to provide a space between the columns in a table.
JAWS, for example, voices the word "blank" every time it encounters an empty cell and this can reduce both the usability and accessibility of data tables for people who rely on screen readers. Use CSS padding or margins rather than empty cells to control the presentation of data tables.
The following guidelines are relevant to this session
Principle 1: Perceivable - Information and user interface components must be presentable to users in ways they can perceive
1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)