Hawai Finance

May 16 2018

WebAIM: Creating Accessible Tables – Data Tables, creating a content management system.#Creating #a #content #management


Creating Accessible Tables

  1. Page 1: Layout Tables
  2. Page 2: Data Tables
    1. Marking Up Data Tables
    2. Table Captions
    3. Identify Row and Column Headers
    4. Associate the Data Cells with the Appropriate Headers
    5. Use Proportional Sizing, Rather than Absolute Sizing
    6. Other table markup

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 table tag.

While it is not necessary for each table to have a caption, a caption is generally very helpful. If present, it should be associated to the table using the caption element.

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

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:

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.

All 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.

The headers and id attributes

Another way to associate data cells and headers is to use the headers and id attributes. This method is NOT generally recommended because scope is usually sufficient for most tables, even 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 headers and id may be used. In these cases, while headers and 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 id value 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


The 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 summary attribute 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

The thead and 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 tbody element 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.

Written by admin

Leave a Reply

Your email address will not be published. Required fields are marked *