Tables are designed to show collections of data such as numbers, schedules or statistics in a way that they can be read in a two dimensional form. By having rows and columns, it is easy to make references either by row or column. Visually it is faster to scan across a table of data then to constantly repeat references used throughout a list. For example a school time table, has the days of the week and times of the day. Placing this into a data table, with the times across the top and days down the left, all the lessons can be placed in each of the remaining spaces of the grid.
This concept of tabular data is used extensively in computing with things like spreadsheets and databases. However, for a blind person having this information converted to speech, they won’t get the visual reference and will either have to memorise all the references or have them repeated.
In HTML, the table element is used to mark-up tabular data into the two dimensional grid of rows and columns. Each row and column can be treated as a block of inter-related information. Individually these bits of data may not make any sense if read out of context, but within the table format their relationship to each other is clear.
Because tables are complex structures the opening tag should always have a summary attribute that can be read out by screen readers or other assistive technology to help explain the table.
The summary text is not displayed in regular browsers but is available to assistive technology like screen readers, so that it can be read out. This summary text 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. It becomes very important with more complex tables, offering additional information to help people understand the tabular data that follows.
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 printed page. This option might work on some browsers (but not all) so best to be avoided where possible by placing such data into documents such as PDF files.
Developers sometimes use columns of empty header and data cells to provide a space between the columns in a table. This doesn't follow correct semantic code and may cause problems to assistive technologies.
JAWS screen reader, 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. By using CSS padding or margins rather than empty cells to control the presentation, it follows correct semantic code and helps assistive technologies like screen readers.
When presenting tabular data, it is important to consider how people may be viewing it. Having large areas of white space between columns can give problems to people who use screen magnifiers as typically only a very small of the screen is visible at any one time. Also having things to close together may make it difficult for people with literacy related problems.
In some cases, having light shading on alternate rows can assist people in scanning across each row of data. This is most helpful when a table spans across a wide screen or has some rows with large areas of white space between columns.
The caption element is the most accessible and semantically correct 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 to understand visually as the column and row headings are at the top and far left of the table, and printed in bold.
|Breakfast||Boiled egg||Fried egg||Bacon||Poached egg|
|Lunch||Lamb Stew||Grilled fish||Roast Beef||Lamb Chops|
Blind people using screen readers, 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 assistive software such as screen readers to be able to understand the relationships within the table and present these effectively to the user it is important to use semantic code. So every table heading cell should be marked up with the TH element and every table data cell use the TD element. The software can then store these headings in memory and reference them to the relevant data cells 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).
Without these headings a blind person would have to remember the sequence of column headings and the title of the current row as they moved through the table. This becomes virtually impossible with larger tables.
Because we use the same heading element 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.
We have added scope="col" to the column headings so that the assistive 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 assistive software knows that these headings relate to the current row (horizontally).
Abbreviations for headings
Because we have included the "scope" attribute to the table headings, assistive software such as a screen reader may now automatically read out both the row and column headings for each table data cell as the user moves around the table. For example as a screen reader user reads across the second row of the previous table, they would hear something like:
"Heading row 2 Breakfast, Monday, boiled egg, Tuesday, Fried Egg, Wednesday, Bacon, Thursday, Poached egg".
Exactly what is read out and how it is done will vary from one assistive software to another but the point is by placing this information in the code it gives the best chance for the assistive technology to work effectively.
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
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).
The scope attribute really comes into its own when we have more complex tables as shown below.
|Breakfast||Normal||Boiled egg||Fried egg||Bacon|
|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|
|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 or other assistive technology works through the table.
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 element is given a unique "id", for example heading data