If you’re not a screen reader user, let’s pretend that you are for just a moment. You’re going to a web site to find out where the biology 205 class is going to be held. You go to a web page that has this information, and this is what you hear:
Table with 10 columns and 7 rows. Department Code, Class Number, Section, Max Enrollment, Current Enrollment, Room Number, Days, Start Time, End Time, Instructor, BIO, 100, 1, 15, 13, 5, Mon,Wed,Fri, 10:00, 11:00, Magde, 100, 2, 15, 7, 5, Tue,Thu, 11:00, 12:30, Indge, 205, 1, 15, 9, 6, Tue,Thu, 09:00, 10:30, Magde, 315, 1, 12, 3, 6, Mon,Wed,Fri, 13:00, 14:00, Indge, BUS, 150, 1, 15, 15, 13, Mon,Wed,Fri, 09:00, 10:00, Roberts, 210, 1, 10, 9, 13, Mon,Wed,Fri, 08:00, 09:00, Rasid.
After listening to this information, do you have any idea where biology 205 is supposed to be held? Probably not. When you listen to tables straight through, without going into table reading mode in a screen reader, this type of information can be quite confusing. Even when you do go into table reading mode, it can still be confusing if the table is not marked up properly.
Layout Tables vs. Data Tables
There are two basic uses for tables on the web: data tables and layout tables. The original intended use of HTML tables was for tabular data. A table is a data table when row headers, column headers, or both are present. For example, here is a simple data table:
Tables are also commonly used for page layout. Layout tables do not have logical headers that can be mapped to information within the table cells. Layout tables were traditionally used to overcome limitations in visual presentation and layout using HTML. With CSS, however, there is much more flexibility in controlling page layout, so it is best to not use tables to do this. Using CSS results in cleaner and more simple HTML code, better end user adaptability, and few potential accessibility issues.
It is sometimes suggested, even by some accessibility advocates that layout tables are bad for accessibility. In reality, layout tables do not pose inherent accessibility issues. There are certainly many worse things that you could do in terms of accessibility. People with all kinds of disabilities can easily access layout tables, as long as the tables are designed with accessibility in mind – ensuring proper linearized reading order, content scaling, etc.
Layout Table Linearization
Content linearization refers to the order of the content when all formatting is removed. For both data and layout tables, the order in which content is presented can affect its meaning. Many web sites use tables for layout, and most of them use spanned rows and columns to achieve formatting effects. The end result is that the linearized reading order may not be the same as the visual reading order. This can lead to confusion on the part of people who access the linearized reading and navigation order, such as individuals who use screen readers or who navigate with keyboards.
Screen readers essentially ignore the fact that the content is inside of a table. The screen reader just reads the content in the literal order that it appears in the code. If the literal order of the content in the code is logical, then your linearized reading order is logical.
Screen readers treat layout tables and data tables very differently. For layout tables, they simple read the content of table based on the source code order. For data tables, however, they will identify the presence of the table including number of columns and row, provide table navigation functionality, read row and column headers, etc.
So how does a screen reader know if a table is a data table or a layout table?
They perform some analysis of the table markup and structure to ‘guess’. Because of this, it’s vital that data table markup, such as
<th>, etc. are NEVER used within layout tables, otherwise the screen reader may incorrectly present the table as a data table causing increased overhead and confusion.
When author’s use tables for layout, they are typically doing so to get more precise and (supposedly) flexible control over the positioning of elements within the page. When doing so, layout tables typically define pixel values to attempt to control exact positions. Because there is an immense range of end user browsers and devices, ranging from text-only mobile browsers to large-screen, high definition displays, defining pixel-based sizing is very limiting.
A primary concern of layout tables is their lack of flexibility for accommodating end-user content adjustments, primarily text sizing by users with low vision. If text within a pixel-sized table cell is enlarged by the end user, this can cause readability issues, especially if the text can no longer fit within the pixel dimensions defined. This may result in horizontal scrollbars, text bleeding out of the cell and overlapping other page components, etc. If using layout tables, ensure that the structure of the table allows end user customization and text scaling.
It is possible to create all kinds of nested tables and unnecessary rows and columns, using spanned rows and columns in every which way, until the table hardly looks like a table at all anymore. All of this may be invisible to sighted users if the table borders are set to zero, but blind users will “see” it all. Their screen readers may inform them of the number of rows and columns in the table. When they try to navigate from one area to the other within the table, they may become disoriented. The rule of thumb here is, the simpler the better.
Although WCAG 2 does not prohibit the use of layout tables, CSS-based layouts are recommended in order to retain the defined meaning of the HTML
table elements and to conform to the coding practice of separating presentation from content.
The purpose of data tables is to present tabular information in a grid, or matrix, and to have column or rows that show the meaning of the information in the grid. Sighted users can visually scan a table. They can quickly make visual associations between data in the table and their appropriate row and/or column headers. Someone that cannot see the table cannot make these visual associations, so proper markup must be used to make a programmatic association between elements within the table. When the proper HTML markup is in place, users of screen readers can navigate through data tables one cell at a time, and they will hear the column and row headers spoken to them.
Data tables very often have brief descriptive text before or after the table that indicates the content of that table. This text should be associated to its respective table using the
<caption> element. The
<caption> element must be the first thing after the opening
Identify Row and Column Headers
A critical step toward creating an accessible data table is to designate row and/or column headers. In the markup, the
<td> element is used for table data cells and the
<th> element is used for table header cells. Going back to our original data table example, the column headers for this table are Name, Age, and Birthday. The row headers are Jackie and Beth. Also note the associated caption.
Table headers should never be empty. This is particularly of concern for the top-left cell of some tables.
Associate the Data Cells with the Appropriate Headers
Now that we’ve created headers, we need to associate the data cells with the appropriate headers.
The scope attribute identifies whether a table header is a column header or a row header. Here is the markup for the table, using the
scope attribute tells the browser and screen reader that everything within a column that is associated to the header with
scope="col" in that column, and that a cell with
scope="row" is a header for all cells in that row.
<th> elements should generally always have a scope attribute. While screen readers may correctly guess whether a header is a column header or a row header based on the table layout, assigning a scope makes this unambiguous.
Scope will apply even if the table is complex with multiple levels of headers (such as in spanned cells). The scope of a table header will apply to all cells over which that header spans.
In this example, the “by birth” row header has a scope of row, as do the headers with the names. The cell showing the age for Jackie will have 3 headers – one column header (“Age”) and two row headers (“by birth” and “Jackie”). A screen reader would identify all of them, including the data cell content (e.g., it might read “by birth. Jackie. Age. 5.”).
Despite being standard markup for tables for many years, some screen readers still do not fully support complex tables with spanned or multiple levels of row and/or column headers. When possible, try to ‘flatten’ the table and avoid spanned cells and multiple levels of header cells.
Another way to associate data cells and headers is to use the
id attributes. This method is NOT generally recommended because
scope is usually sufficient for most tables, even if if the table is complex with multiple levels of headers.
In extremely complex tables where
scope may cause table headers to apply to (or have a scope for) cells that are not to be associated to that header, then
id may be used. In these cases, while
id might make the table technically accessible, if there are multiple levels of row and/or column headers being read, it will not likely be functionally accessible or understandable to a screen reader user.
With this approach, each
<th> is assigned a unique
id attribute value. Then, each and every
<td> cell within the table is given a
headers attribute with values that match each
<th> idvalue the cell is associated to. The values are separated by spaces and should be listed in the order in which a screen reader should read them. If using headers/id in the example above, the cell for Jackie’s age might be marked up as
<td headers="birth jackie age">5</td>).
Again, it should be emphasized that this method is more complex, uses much more markup (and potential to become broken), and is rarely necessary (use scope instead).
Use Proportional Sizing, Rather than Absolute Sizing
The rule that applies to layout tables also applies to data tables. Let the browser window determine the width of the table whenever possible, to reduce the horizontal scrolling required of those with low vision. If cell widths need to be defined, use relative values, such a percentages, rather than pixel values. Defined cell heights should generally be avoided so the cell can expand downward to accommodate its content – something especially useful for users with low vision that may enlarge text content.
Other table markup
summary attribute of the
<table> tag may be used to provide a summary of a data table structure (not content). Support for summary varies, but in general, it is screen reader specific (it’s not accessible to anyone else) and is not well supported. Additionally, the
summaryattribute is not part of the HTML5 specification. In general, if a table is so complex that it needs an explanation of how it is structured, it probably is not very accessible and should probably be simplified. For these reasons, we do not recommend the use of summary. If it is used, it must never be used for layout tables.
thead, tfoot, and tbody
tfoot elements define header and footer rows for tables. They provide no accessibility functionality and are generally only of use when a long table is printed – the head and/or foot rows will repeat at the top or bottom of each printed page. Similarly, the
tbodyelement defines the body content of a data table (meaning anything that’s not a thead or tfood). Again, this element does not provide any additional accessibility benefit, but there is no harm in using it for table styling or other reasons.