Site Map



Data Tables

As a general rule, use tables for representing the relationships between data, not for providing visual layout. In designing course content, we want to prevent any possible ambiguity in what we are presenting. The goal should be to relay information in as direct a method possible. Thus it makes sense to use the table element for the purposes a student expects—representing the relationships between data in a grid-like format.

While it is true that many screen reading programs are “smart” enough to discern when a table is being used for laying out a page—creating column, header, and footer sections, for instance—we should not be relying on the screen reader to “figure out” the page, to guess about content, since inevitably there will be instances were a screen reader is not up to the task or where there are variations in how different screen readers read content. Instead, we ought to strive for clarity and avoid ambiguity.

Use the table for its intended purposes. For purely visual layout, use CSS, not a table.

1. Provide descriptive information about your data table's organization and content in the SUMMARY attribute

Discussion

When a student who can see the screen scans a table quickly, he/she immediately gets a sense of what sort of information is presented, how it relates in columns and rows, and a general impression of the “point” the data is supposed to be relating. The “summary” attribute attempts to do the same for someone who cannot see the screen or who may have a literacy or reading disability that makes such a scan difficult.

The “summary” attribute of the “table” tag provides descriptive information about a table's organization—how its rows and columns relate—and the content of the table indicating the data the table provides. Like the “alt” attribute of the image tag, the “summary” is readable by specialized access technologies. All major screen readers read the value of the “summary,” and some screen magnification and literacy software do too.

The “summary” works to orient the student before he/she encounters the data in the table first hand. It provides and introduction to what the table will present and how it will present.

For examples of table summaries, see the Examples under BP 4 and BP 6 on this page.

2. Use the caption element to provide a title for a data table

Discussion

The first element in a data table is the caption. It should contain the title and/or a very brief description of the table.

Using CSS, it is possible in most browsers to position the caption visually either at the top or bottom of a data table and that choice is up to the designer. But a screen reader will read the caption back to the student upon entering the table. He/She can also use specialized keystrokes in her screen reading program to call up the caption at any point in browsing a table.

For examples of table summaries, see the Examples under BP 4 and BP 6 on this page.

3. Provide column and row headers using the table header element

Discussion

Like in an Excel spreadsheet, an HTML table has columns and row header cells that provide descriptive categories for the data that line up in each column and row. Not only is it semantically correct to mark up headers using the table header (“th”) tag, doing so has special meaning for access technologies, such as screen readers. When an access technology reads the content of a table data cell, it also can read the table header associated with that cell, thereby helping the student better understand the significance of the data content.

4. For simple data tables, specify row and column scope

Discussion

How do access technologies know which table header helps describe any given data cell? In the case of very simple tables, the access technology can just “figure it out.” But as we know, the goal is not to leave it up the (potentially “dumb”) access technology. Our task as content authors and designers is to take away ambiguity and present information in a way that ensures maximum clarity for the student.

The “scope” attribute of a table header tells the access technology that the header applies to the data in the either the row or the column, and thereby helps minimize the chance that the student will misinterpret the data.

Examples

Screen Shot: Using scope attribute to make proper associations between data and header cells:

2-dimensional table with scope set on rows and columns

Figure BP-Data Tables-1. Click image to enlarge.

Screen Shot: Using scope attribute to make proper associations between data and header cells:

<table border="1"
  summary="Correlates car color preference to age and sex. 
  Left column lists ages in ascending order. 
  Top row is sex of surveyed population. 
  Data cells contain car colors.">
  <caption>Car Color Preferences by Age and Sex</caption>
  <tr>
    <td></td>
    <th scope="col">Male</th>
    <th scope="col">Female</th>
  </tr>
  <tr>
    <th scope="row">16 to 20 years old</th>
    <td>Red</td>
    <td>Pink</td>
  </tr>
  <tr>
    <th scope="row">21 to 36 years old</th>
    <td>Black</td>
    <td>Silver</td>
  </tr>
  <tr>
    <th scope="row">37 to 50 years old</th>
    <td>Brown</td>
    <td>Blue</td>
  </tr>
</table>

5. For complex data tables provide unique “id” attributes for all column and row headings and use the “headers” attribute to define the association between data cells and their corresponding column and row headings

Discussion

In the case of tables where we have multiple headers on columns and rows, it is necessary to provide extra information so that access technologies, especially screen readers, can make sense of the data in the cells.

We can assign “id's” to all of the table headers and then use the “headers” attribute in each data cell to tie the data to one or more table header cells. A modern screen reader will then read the contents of the associated header cells when it reads the current cell contents.

If we do this, modern screen readers will have no problem figuring out what header belongs with what data cell and can relay that information back to the student.

For an example and more elaboration, see the discussion and example in BP 6.

6. Use the “axis” attribute in table header and data cells to clarify the conceptual category the cell belongs to

Discussion

Think of the axis attribute as a means to provide extra information about the category of things to which a table cell belongs. It is an attribute that is not used very frequently. However, in complex tables with lots of numbers or raw figures, an “axis” attribute can provide verbal help, a little extra clue as to what the table cell is and what it means in relation to the rest of the data in the table.

When a screen reader encounters a table cell that has the “headers” attribute, it will use that attribute to perform a look up of the appropriate associated headers and cells that help provide context for the cell. It will read aloud both the contents of the current cell and the contents of all of the headers-associated cells. If one or more of those associated cells has an “axis” attribute on it, the axis value will be voiced.

So, to take the example below, when the screen reader using student encounters the expense amount 37.74, the screen reader will read that amount and the associated headers, along with their axis attributes, read in the order listed in the “headers” attribute. Thus, he/she will hear something like: “Location, San Jose. Date, 25-Aug-97. Expenses, Meals. 37.74”.

It should be noted that not all screen reader programs handle headers and axis attributes identically. But most of the major screen readers will be able to use most or all of these attributes to disambiguate table cell contents. And though it takes more time to carefully code tables with these attributes, your students will appreciate the extra labor.

Examples

Screen Shot: Complex table showing summary, headers and ids, and axis attributes:

Complex table normal view and linearized

Figure BP-Data Tables-2. Click image to enlarge.

Screen Shot: Complex table showing summary, headers and ids, and axis attributes:

Table with accessibility attributes visualized

Figure BP-Data Tables-3. Click image to enlarge.

Code Example: Complex table with summary, headers and ids, and axis attributes

<table summary="Summarizes expenses for August 1997 trips to 
  San Jose and Seattle. Left column lists locations and dates. 
  Meal, hotel, and transportation costs are in columns
  two, three, and four. Cumulative subtotals are in column five. 
  Grand totals are in bottom row.">
<caption>Travel Expense Report</caption>
<tr>
  <th></th>
  <th id="a2" axis="expenses">Meals</th>
  <th id="a3" axis="expenses">Hotels</th>
  <th id="a4" axis="expenses">Transport</th>
  <td>Subtotals</td>
</tr>
<tr>
  <th id="a6" axis="location">Jan Jose</th>
  <th></th>
  <th></th>
  <th></th>
  <td></td>
</tr>
<tr>
  <td id="a7" axis="date">25 Aug. 97</td>
  <td headers="a6 a7 a2">37.74</td>
  <td headers="a6 a7 a3">112.00</td>
  <td headers="a6 a7 a4">45.00</td>
  <td></td>
</tr>
<tr>
  <td id="a8" axis="date">26 Aug. 97</td>
  <td headers="a6 a8 a2">27.28</td>
  <td headers="a6 a8 a3">112.00</td>
  <td headers="a6 a8 a4">45.00</td>
  <td></td>
</tr>
<tr>
  <td>Subtotals</td>
  <td>65.02</td>
  <td>224.00</td>
  <td>90.00</td>
  <td>379.02</td>
</tr>
<tr>
  <th id="a10" axis="location">Seattle</th>
  <th></th>
  <th></th>
  <th></th>
  <td></td>
</tr>
<tr>
  <td id="a11" axis="date">27 Aug. 97</td>
  <td headers="a10 a11 a2">96.25</td>
  <td headers="a10 a11 a3">109.00</td>
  <td headers="a10 a11 a4">36.00</td>
  <td></td>
</tr>
<tr>
  <td id="a12" axis="date">28 Aug. 97</td>
  <td headers="a10 a12 a2">35.00</td>
  <td headers="a10 a12 a3">109.00</td>
  <td headers="a10 a12 a4">36.00</td>
  <td></td>
</tr>
<tr>
  <td>Subtotals</td>
  <td>131.25</td>
  <td>218.00</td>
  <td>72.00</td>
  <td>421.25</td>
</tr>
<tr>
  <th>Totals</th>
  <td>196.27</td>
  <td>442.00</td>
  <td>162.00</td>
  <td>800.27</td>
</tr>
</table>

Resources

7. Avoid large data tables by dividing them into smaller, individual data tables

Discussion

Using the “headings” and “id” attributes to clarify how data relates in a table can be very effective. As tables get very large and complex, however, it may make sense to break large and complex tables into smaller, individual tables.

It can be difficult to determine when to make the decision to break up large and complex tables. Try to decide if the relations between the data you are presenting might be broken up into multiple separate instances of correlations. Always be cognizant of ways you might present your data more simply. All students, not only those with disabilities, will benefit from the increased clarity.