(g) Row and column headers shall be identified for data tables.

(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers. 

Why are these two provisions necessary?
Paragraphs (g) and (h) permit the use of tables, but require that the tables be coded according to the rules of the markup language being used for creating tables. Large tables of data can be difficult to interpret if a person is using a non-visual means of accessing the web. Users of screen readers can easily get "lost" inside a table because it may be impossible to associate a particular cell that a screen reader is reading with the corresponding column headings and row names. For instance, assume that a salary table includes the salaries for federal employees by grade and step. Each row in the table may represent a grade scale and each column may represent a step. Thus, finding the salary corresponding to a grade 9, step 5 may involve finding the cell in the ninth row and the fifth column. For a salary chart of 15 grade scales and 10 steps, the table will have at least 150 cells. Without a method to associate the headings with each cell, it is easy to imagine the difficulty a user of assistive technology may encounter with the table.

Section 1194.22 (g) and (h) state that when information is displayed in a table format, the information shall be laid out using appropriate table tags as opposed to using a preformatted table in association with the "<pre>" tag. Web authors are also required to use one of several methods to provide an association between a header and its related information.

How can HTML tables be made readable with assistive technology?
Using the "Scope" Attribute in Tables – Using the "scope" attribute is one of the most effective ways of making HTML compliant with these requirements. It is also the simplest method to implement. The scope attribute also works with some (but not all) assistive technology in tables that use "colspan" or "rowspan" attributes in table header or data cells.
Using the Scope Attribute – The first row of each table should include column headings. Typically, these column headings are inserted in <TH> tags, although <TD> tags can also be used. These tags at the top of each column should include the following attribute:

scope="col"

By doing this simple step, the text in that cell becomes associated with every cell in that column. Unlike using other approaches (notably "id" and "headers") there is no need to include special attributes in each cell of the table. Similarly, the first column of every table should include information identifying information about each row in the table. Each of the cells in that first column are created by either <TH> or <TD> tags. Include the following attribute in these cells:

scope="row"

By simply adding this attribute, the text in that cell becomes associated with every cell in that row. While this technique dramatically improves the usability of a web page, using the scope attribute does not appear to interfere in any way with browsers that do not support the attribute.
Example of source code – the following simple table summarizes the work schedule of three employees and demonstrates these principles.

<table>
<tr>
<th>&nbsp;</th>
<th scope="col" >Spring</th> <th scope="col" >Summer</th> <th scope="col" >Autumn</th> <th scope="col" >Winter</th> </tr>
<tr> <td scope="row" >Betty</td> <td>9-5</td> <td>10-6</td> <td>8-4</td><td>7-3</td>
</tr>
<tr> <td scope="row" >Wilma</td> <td>10-6</td> <td>10-6</td> <td>9-5</td> <td>9-5</td>
</tr>
<tr> <td scope="row" >Fred</td> <td>10-6</td> <td>10-6</td> <td>10-6</td> <td>10-6</td>
</tr>
</table>

This table would be displayed as follows:

  Spring Summer Autumn Winter
Betty 9-5 10-6 8-4 7-3
Wilma 10-6 10-6 9-5 9-5
Fred 10-6 10-6 10-6 10-6

The efficiency of using the scope attribute becomes more apparent in much larger tables. For instance, if an agency used a table with 20 rows and 20 columns, there would be 400 data cells in the table. To make this table comply with this provision without using the scope attribute would require special coding in all 400 data cells, plus the 40 header and row cells. By contrast, using the scope attribute would only require special
attributes in the 40 header and row cells.

Using the "ID" and "Headers" Attributes in Tables
Unlike using the "scope" attribute, using the "id" and "headers" attributes requires that every data cell in a table include special attributes for association. Although its usefulness for accessibility may have been diminished as browsers provide support for the "scope" attribute, the "id" and "headers" attributes are still very useful and provide a practical means of providing access in smaller tables.

The following table is much more complicated than the previous example and demonstrates the use of the "id" and "headers" attributes and then the scope attribute. Both methods provide a means of complying with the requirements for data tables in web pages. The table in this example includes the work schedules for two employees. Each employee has a morning and afternoon work schedule that varies depending on whether the employee is working in the winter or summer months. The "summer" and "winter" columns each span two columns labeled "morning" and "afternoon." Therefore, in each cell identifying the work schedule, the user needs to be told the employee's name (Fred or Wilma), the season (Summer or Winter), and the shift (morning or afternoon).

<table>
<tr>
<th>&nbsp;</th>
<th colspan="2" id="winter" >Winter</th>
<th colspan="2" id="summer" >Summer</th>
</tr>
<tr>
<th>&nbsp;</th>
<th id="am1" >Morning</th>
<th id="pm1" >Afternoon</th>
<th id="am2" >Morning</th>
<th id="pm2" >Afternoon</th>
</tr>
<tr>
<td id="wilma" >Wilma</td>
<td headers="wilma am1 winter" >9-11</td>
<td headers="wilma pm1 winter" >12-6</td>
<td headers="wilma am2 summer" >7-11</td>
<td headers="wilma pm2 summer" >12-3</td>
</tr>
<tr>
<td id="fred" >Fred</td>
<td headers="fred am1 winter" >10-11</td>
<td headers="fred pm1 winter" >12-6</td>
<td headers="fred am2 summer" >9-11</td>
<td headers="fred pm2 summer" >12-5</td>
</tr>
</table>

This table would be displayed as follows:

  Winter Summer
  Morning Afternoon Morning Afternoon
Wilma 9-11 12-6 7-11 12-3
Fred 10-11 12-6 9-11 12-5


Coding each cell of this table with "id" and "headers" attributes is much more complicated than using the "scope" attribute shown below:

<table>
<tr>
<th>&nbsp;</th>
<th colspan="2" scope="col" >Winter</th>
<th colspan="2" scope="col" >Summer</th>
</tr>
<tr>
<th>&nbsp;</th>
<th scope="col" >Morning</th>
<th scope="col" >Afternoon</th>
<th scope="col" >Morning</th>
<th scope="col" >Afternoon</th>
</tr>
<tr>
<td scope="row" >Wilma</td>
<td>9-11</td>
<td>12-6</td>
<td>7-11</td>
<td>12-3</td>
</tr>
<tr>
<td scope="row" >Fred</td>
<td>10-11</td>
<td>12-6</td>
<td>9-11</td>
<td>12-5</td>
</tr>
</table>

This table would be displayed as follows:

  Winter Summer
  Morning Afternoon Morning Afternoon
Wilma 9-11 12-6 7-11 12-3
Fred 10-11 12-6 9-11 12-5

Is the summary attribute an option?
Although highly recommended by some webpage designers as a way of summarizing the contents of a table, the "summary" attribute of the TABLE tag is not sufficiently supported by major assistive technology manufacturers to warrant recommendation. Therefore, web developers who are interested in summarizing their tables should consider placing their descriptions either adjacent to their tables or in the body of the table, using such tags as the CAPTION tag. In no event should web developers use summarizing tables as an alternative to making the contents of their tables compliant as described above.

up arrowBack

Tables and Table Markup

Relevance to Accessibility
Paragraphs (g) and (h) permit the use of tables, but require that the tables be coded according to the rules of the markup language being used for creating tables. Large tables of data can be difficult to interpret if a person is using a non-visual means of accessing the web. Users of screen readers can easily get "lost" inside a table because it may be impossible to associate a particular cell that a screen reader is reading with the corresponding column headings and row names. For instance, assume that a salary table includes the salaries for federal employees by grade and step. Each row in the table may represent a grade scale and each column may represent a step. Thus, finding the salary corresponding to a grade 9, step 5 may involve finding the cell in the ninth row and the fifth column. For a salary chart of 15 grade scales and 10 steps, the table will have at least 150 cells. Without a method to associate the headings with each cell, it is easy to imagine the difficulty a user of assistive technology may encounter with the table. Section 1194.22 (g) and (h) state that when information is displayed in a table format, the information shall be laid out using appropriate table tags as opposed to using a preformatted table in association with the "<pre>" tag. Web authors are also required to use one of several methods to provide an association between a header and its related information.

 
508 Software (Subpart B)(1194.21)

 
508 Web (Subpart B)(1194.22)
(g)
Row and column headers shall be identified for data tables.
(h)
Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.
508 Functional Performance (Subpart C)
(a)
At least one mode of operation and information retrieval that does not require user vision shall be provided, or support for assistive technology used by people who are blind or visually impaired shall be provided.
(b)
At least one mode of operation and information retrieval that does not require visual acuity greater than 20/70 (when corrected with glasses) must be provided in audio and enlarged print output that works together or independently. In the alternative, support for assistive technology used by people who are blind or who have low vision must be provided.
508 Information, Documentation, and Support (Subpart D)
None or In Progress of Mapping

 
Comparison
In Progress

 
UAAG 1.0 Requirements & Priority

 
2.1 Render content according to specification (Both (g) and (h))
 
  1. Render content according to format specification (e.g., for a markup language or style sheet).
  2. When a rendering requirement of another specification contradicts a requirement of the current document, the user agent may disregard the rendering requirement of the other specification and still satisfy this checkpoint.
  3. Rendering requirements include format-defined interactions between author preferences and user preferences/capabilities (e.g., when to render the "alt" attribute in HTML, the rendering order of nested OBJECT elements in HTML, test attributes in SMIL, and the cascade in CSS2).
Who benefits: Users with disabilities when specifications include features that promote accessibility (e.g., scalable graphics benefit users with low vision, style sheets allow users to override author and user style sheets).
[Priority 1]

 
10.1 Table orientation   (Both (g) and (h))
Make available to the user the purpose of each rendered table (e.g., as expressed in a summary or table caption) and the relationships among the table cells and headers
Who benefits: Users for whom summaries are important (e.g., some users with a cognitive or memory disability), and for whom two-dimensional relationships may be difficult to process (e.g., users with blindness who have serial access to the content, or some users with a cognitive disability). Renderings that provide easy access to cell header information will also help some users with low vision or a physical disability, for whom it may be time-consuming to scroll in order to locate relevant headers.
[Priority 1]

 
 
10.5 Outline view
 
  1. Make available to the user an "outline" view of content, composed of labels for important structural elements (e.g., heading text, table titles, form titles, @@ frame titles, @@ etc.).
  2. What constitutes a label is defined by each markup language specification. A label is not required to be text only.
Who benefits: The outline view is a type of summary view, and will benefit some users with a memory or cognitive disability, as well as users for whom serial access is time consuming (e.g., some users with blindness or a physical disability, or some users with low vision). A navigable outline view will add further benefits for these users.
[Priority 2]