Accessible Design: Best Practices

Layout and Data Tables.

Types of Tables.

There are two types of tables used in web pages: layout tables and data tables. In general, data tables require more careful design and coding to insure accessibility. However, layout tables should be used sparingly and designed for quick access to key content on a given page.

Summaries for Tables.

The W.C.A.G. Priority 3 standards state that regardless of whether it is a layout or data table, you should provide summaries for all tables via the "summary" attribute. However, the WAC recommends only providing summaries for data tables. When layout tables have summaries, screen readers are more likely to read the other attributes of the table, instead of moving directly to the content.

For layout tables, the summary can describe the layout.

Layout table with detailed summary --

<table id="sample" summary="Layout table with two rows and three columns. First row contains a link to the home page and contact information. Second row: the left cell contains the site menu, the middle cell contains the page content, and the right cell contains suggested external links for more help.">

Since many screen-readers are now able to distinguish layout tables from data tables, it is also permissible to simply identify a table as "layout table" in the summary. But, remember, the Best Practice is to provide no summary for layout tables.

return to top

Summaries for data tables should clarify the relationships among cells.

Keep in mind that summaries will be read each time the screen reader detects the table, regardless of if the user wants to explore the table data. Thus, if a user tries to "pass by" the table on the way to information before or after the table, she has to wait until the summary is read before continuing on. For this reason, summaries should be as short as possible.

In this example, a table caption would identify the subject matter and the summary gives a brief overview of the data:

Data table with simple summary --

<table id="data" summary="For each category, displays total investment required, actual dollars spent, planned spending, and percent change." caption="Total required by pollution control standards as of January 1, 1971">

It would be a good idea to include a more detailed description of the table data in either the introductory or explanatory paragraph before or following the table. For example:

The table below identifies the total investment required to meet the pollution control standards as of January 1, 1971. For each industry category: stores, insurance, companies, and banks, the table shows the total investment required in billions of dollars as well as, in millions of dollars, the actual spending for 1970, the planned spending for 1971 and the percent change.

If a description of the table contents, like the one above, is used instead of embedding the information in the TABLE tag, more users have access to the information and users of screen readers can choose to "skip over" the description at any time. Screen reader users cannot "skip over" a table summary embedded in the TABLE tag (as shown below).

Data table with extended summary --

Extended summaries put all the relevant information in the summary attribute of the TABLE tag (as shown below). However, only users of screen readers can access this information, which may be valuable to other users as well, and the summary must be read in entirety every time the table is detected on the page.

<table id="data" summary="Total required by pollution control standards as of January 1, 1971. Commercial category includes stores, insurance companies and banks. The table is divided into two columns. The left-hand column is 'Total investment required in billions of dollars'. The right--hand column is 'Spending' and is divided into three sub-columns. The first sub-column is titled '1970 actual in millions of dollars', the second is '1971 planned in millions of dollars', and the third is 'Percent change, 1970 versus 1971.' The rows are industries.">

return to top

Relative Sizing.

The tables with absolute sizes do not transform gracefully for users with smaller screens and lower resolutions.  A table set to 800 pixel-width will require a user with 640 resolution to scroll left-right to see all the content.  This also affects a user who does not have the browser window maximized to take-up the whole screen.  Tables with absolute sizes also tend to cut-off important information when the page is printed. 

Sample HTML code:

Absolute table: <table width="780" border="0" cellspacing="0" cellpadding="0" align="center">
Relative table: <table width="95%" cellspacing=0 cellpadding=20 align="center">.

Guidelines for Layout Tables.

When to Use Layout Tables.

The WCAG recommends using style sheets for layout and positioning, rather than layout tables. As browser support for CSS2 develops, it will soon no longer be necessary to use layout tables to position content on a web page.  However, most designers still use layout tables to insure wide-spread compatibility with various browser technology.

When using layout tables, keep in mind that screen-readers typically read tables left-to-right and top-to-bottom. For example, consider this page layout:

Before the screen-reader gets to the primary information (the content), the logo, contact information, and menu will be read. The submenu will not be read until after all of the content. A Skip Navigation Link will help users reach the content faster, but may not be the only or best solution. Be sure to carefully consider the arrangement of tables, including layout tables.

return to top

Marking-up Layout Tables.

In most cases, it will not be necessary to use table column and row header attributes for layout tables. If they are used, they should accurately represent the table and not be used for formatting. For instance, column headers frequently appear centered and bold. If the data is not a header, CSS should be used to achieve the same formatting rather than using the <TH> tag.

Guidelines for Data 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.

return to top

Simple Data Tables .

To get an idea of how data tables are made accessible using the <TH> element, consider this table with both row and column headers:

Here is the code used to define this table, including headers:

<table width="90%" border="2" id="datatable" summary="This table contains information on student programs. Each row lists the student name, academic level completed to date, and current program enrolled.">
<tr>
<th scope="col"><p>Student</p></th>
<th scope="col"><p>Academic Level</p></th>
<th scope="col"><p>Current Program</p></th>
</tr>
<tr class="smallertxt">
<th scope="row"><p>Lori Badia</p></th>
<td><p>M.A. completed</p></td>
<td><p>Ph.D. English</p></td>
</tr>
<tr class="smallertxt">
<th scope="row"><p>Susan Bailey</p></th>
<td><p>B.S. completed</p></td>
<td><p>M.B.A.</p></td>
</tr>
<tr class="smallertxt">
<th scope="row"><p>Alicia Baker</p></th>
<td><p>B.A., in progress</p></td>
<td><p>Dept. of Education</p></td>
</tr>
</table>

As a screen-reader, like JAWS, reads this table, each data cell can be identified by either row or column header. For instance, when reading across row two, JAWS reads the row header:

"Student Lori Badia, academic level, M.A. completed; current program, Ph.D. English."

When reading down, JAWS reads the row header for each cell. For instance, when reading column three:

"Lori Badia, Ph.D. English; Susan Bailey, M.B.A., Alicia Baker, Dept. of English."

Row and column headers help insure that data tables can be understood regardless of how the user accesses the cells. Row and column headers are required for any data table of two or more rows.

return to contents

Complex Data Tables

As the complexity of the table increases, more deliberate methods of associating the data with it's identifying header are required. For instance, consider this data table used in a biology lab:

Assume this table of resting heart rates may include 20 different subjects, each recording 3 measurements of resting beats per minute, with a calculated average across all 3 for each subject. Each row in the table represents a subject and each column represents either a resting heart rate or the calculated average. The table would have at least 100 data cells. Finding the 3rd measurement for the 11th subject may involve navigating as many as 14 rows and 4 columns. 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.

Here is more simple example to consider:

<TABLE border="1" summary="This table charts the number of cups of coffee consumed by each senator, the type of coffee (decaf or regular), and whether taken with sugar.">
< CAPTION>Cups of coffee consumed by each senator</CAPTION>
<TR>
< TH id="header1">Name</TH>
<TH id="header2">Cups</TH>
<TH id="header3" abbr="Type">Type of Coffee</TH>
< TH id="header4">Sugar?</TH>
< TR>
< TD headers="header1">T. Sexton</TD>
<TD headers="header2">10</TD>
<TD headers="header3">Espresso</TD>
< TD headers="header4">No</TD>
< TR>
< TD headers="header1">J. Dinnen</TD>
< TD headers="header2">5</TD>
< TD headers="header4">Yes</TD>
</TABLE>

This example shows how to associate data cells (created with TD) with their corresponding headers by means of the "headers" attribute. The "headers" attribute specifies a list of header cells (row and column labels) associated with the current data cell. This requires each header cell to have an "id" attribute.

More complicated tables, in which two or more headers may apply to the same data cell, require the use of the ID and HEADERS attributes. Consider this complex table, for example:

Each data cell in the table may be associated with either the San Jose or Seattle location; may be either a meal, hotel, or transportation expense; or may be a subtotal or total of other data. For a user to understand the data of a given cell, she must know the location, date, and category which the data belongs to. The ID and HEADERS attributes solve this problem. To see how, view the HTML for this table.

return to top

Abbreviated Headers

Designers can further support table accessibility by providing abbreviations for long headers. Consider the Student Academic Level and Program table again. When reading across a row, each time a cell is read by JAWS, the data is prefaced with either "student," "academic level," or "current program." We can assign abbreviated terms for these headers to reduce the repetition. In this code example, we would change "academic level" to "level" and "current program" to "program":

<tr>
<th scope="col"><p>Student</p></th>
<th scope="col" abbr="level"><p>Academic Level</p></th>
<th scope="col" abbr="program"><p>Current Program</p></th>
</tr>

The abbreviated header still distinguishes the cell information, but results in quicker navigation through the table.

return to top

Next