Layout Using Tables

A screen reader reads table rows and cells in a particular order from left to right. Look at the following table.

If a screen reader were to read this table, it would read in the following order:

Row 1, Column 1; Row 1, Column 2; Row 2, Column 1; Row 2, Column 2

The reader would read left to right across the first row and columns, and then across the second row and columns.

A lot of Web designers use tables to position text, images and other elements on a Web page. Tables were never intended for layout, but Web developers discovered early on that they could achieve a better look on their sites if they bent the rules a little and used tables to position elements on a page. By using tables, you can create a page that is laid out like a newspaper with columns. Look at CNN's page, and notice how the information is in columns.

This is achieved by using an invisible table with columns. The problem associated with this type of layout is that older screen readers would read a Web page from left to right through all the columns making nonsense out of the text as shown in the example that follows.

Here is an example of text in two columns:

This is how the text would sound in older screen readers:

"There is a 30% chance of Classes at the University of Wisconsin rain showers this morning, but they will resume on September 3rd. should stop before the weekend."

Ideally, a screen reader would read all the information in each column from top to bottom in order, i.e., column 1 then column 2. Newer screen readers can be made to read a columned page, but the older ones cannot.

This is NOT to say that you cannot use columns to organize your page, but to make you aware of the accessibility issues involved when presenting information in tables. If you use tables, try to keep them simple, and avoid using nested tables. To a blind user using a screen reader, a complex table used for layout is like a maze, and it's easy to get lost on the page if you cannot SEE where you are going. Test you pages in Lynx in the Tools section to see how the information on the page will be read by a screen reader.

The recommendation from the W3C is:

"Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version)."

For example, the information in the table above would be laid out in logical paragraph format (linear), one on top of the other:

"There is a 30% chance of rain showers this morning, but should stop before the weekend."

"Classes at the University of Wisconsin will resume on September 3rd."

Let me reiterate here that you CAN use tables with rows and columns on your pages, but keep them simple.

Tablin - A table Linearizer

In the Tools section of this site, there is an online service offered by the W3C called "Tablin". This tool will linearize content from tables and display it in a logical, linear format so that screen readers can read it in the correct order. The linear format can be placed on an alternate page, or used in lieu of tables on the original page.

Summary Attribute

A table can have a summary=" " attribute that can be added to the <table> tag. The summary attribute is a message that only a screen reader can read; it is not seen by visual users. In the summary attribute, you can indicate what the table is used for, and how it is laid out so that a blind visitor will have a sense of how to navigate the table.

Although some resources suggest that the summary attribute does not work with all screen reading devices, it wouldn't hurt to add it to your tables. Here is an example of how the summary attribute would look in your code:

<table summary="This table has two columns and three rows. Navigation is located in the left column.">

Data Tables

Simple Data Tables

If you are using a table to present information that is easy to recognize, it is not always necessary to use special markup in the table code. Consider the following table and information it presents:

Each row has easy-to-recognize information, e.g., Jane Doe, her phone number and her email address. The same goes for Bob. Someone using a screen reader would recognize that everything after Jane Doe's name relates to her. It would not hurt to use the special HTML code to markup the table, but it might not be necessary for simple tables with recognizable information. The basic HTML for the table is as follows:

<table>
<tr>
<td >Name</td>
<td >Phone</td>
<td >Email</td>
</tr>
<tr>
<td >Jane Doe</td>
<td >912-123-4321</td>
<td >jdoe@anywhere.com</td>
</tr>
<tr>
<td >Bob Smith</td>
<td >912-456-7894</td>
<td >bsmith@anywhere.com</td>
</tr>
</table>

There is no special code in this table to make the screen reader correlate header information (name, phone, email) with data cell information. A screen reader would read across each row and simply read the contents of each cell. If the table presented a lot more information (lots of columns and rows) , and the information were not easy to recognize, the listener might become disoriented because it would be hard to remember all the column and row headers. By using special markup, a screen reader can associate the content of any cell with the column and row headers. This will be addressed below.

Data Table with Header and Id Tags

This example shows how to associate information being presented in the data cells with the column and row headers. The <th id="..."> allows a screen reader to speak the header information before each piece of information in the <td headers="..."> data cells. Note also that a summary tag is used to describe the contents of the table. The summary information will not be seen by visual users, but screen readers will speak it. The markup for this table follows.

<table summary="This table gives the name, phone and email of specific people.">
<tr>
<th id="name">Name</th>
<th id="phone">Phone</th>
<th id="email">Email</th>
</tr>
<tr>
<td headers="name">Jane Doe</td>
<td headers="phone">912-123-4321</td>
<td headers="email">jdoe@anywhere.com</td>
</tr>
<tr>
<td headers="name">Bob Smith</td>
<td headers="phone">912-456-7894</td>
<td headers="email">bsmith@anywhere.com</td>
</tr>
</table>

A screen reader would render (speak) this table as follows:

Summary: This table gives the name, phone and email of specific people.
Name: Jane Doe, Phone: 912-123-4321, email: jdoe@anywhere.com
Name: Bob Smith, Phone: 912-456-7894, email: bsmith@anywhere.com

Complex Data Tables with Axis, Id and Header Tags

In more complex tables, it is necessary to add the "axis" attribute. This attribute will allow the user to pause in any cell, and make the screen reader speak the column and row headers.

Consider the following table from the W3C's site:

This table has column headers and row headers. Column headers are listed across the top of the table: Meals, Hotels, Transport; and row headers are listed down the first column: San Jose, 25-Aug-97, 26-Aug-97, etc. If you want to know how much someone paid for a hotel (column header) on 28-Aug-97 (row header), you would have to find where the column and row header intersect, which a sighted person can do simply by scanning the header information. Screen reading software can be made to triangulate information in the data cells (td) using the row and column headers. By using special HTML markup, a screen reader can speak column and row headers to help the user find the information they seek within the table.The summary information will not be seen by visual users, but screen readers will speak it. The markup for this table follows:

<table>
<caption>Travel Expense Report</caption>
<tr>
<th></th>
<th id="Meals" axis="expenses">Meals</th>
<th id="Hotels" axis="expenses">Hotels</th>
<th id="Transport" axis="expenses">Transport</th>
<th id="Subtotals" axis="expenses">Subtotals</th>
</tr>
<tr>
<th id="SanJose" axis="location">San Jose</th>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th id="25-Aug-97" axis="date">25-Aug-97</th>
<td headers="SanJose 25-Aug-97 Meals">37.74</td>
<td headers="SanJose 25-Aug-97 Hotels">112.00</td>
<td headers="SanJose 25-Aug-97 Transport">45.00</td>
<td></td>
</tr>
<tr>
<th id="26-Aug-97" axis="date">26-Aug-97</th>
<td headers="SanJose 26-Aug-97 Meals">27.28</td>
<td headers="SanJose 26-Aug-97 Hotels">112.00</td>
<td headers="SanJose 26-Aug-97 Transport">45.00</td>
<td></td>
</tr>
<tr>
<td>subtotal</td>
<td headers="Meals SanJose">65.02</td>
<td headers="Hotels SanJose">224.00</td>
<td headers="Transport SanJose">90.00</td>
<td headers="Subtotals SanJose">379.02</td>
</tr>
<tr>
<th id="Seattle" axis="location">Seattle</th>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th id="27-Aug-97 axis="date">27-Aug-97</th>
<td headers="Seattle 27-Aug-97 Meals">96.25</td>
<td headers="Seattle 27-Aug-97 Hotels">109.00</td>
<td headers="Seattle 27-Aug-97 Transport">36.00</td>
<td></td>
</tr>
<tr>
<th id="28-Aug-97" axis="date">28-Aug-97</th>
<td headers="Seattle 28-Aug-97 Meals">35.00</td>
<td headers="Seattle 28-Aug-97 Hotels">109.00</td>
<td headers="Seattle 28-Aug-97 Transport">36.00</td>
<td></td>
</tr>
<tr>
<td>subtotals</td>
<td headers="Seattle Meals>131.25</td>
<td headers="Seattle Hotels">218</td>
<td headers="Seattle Transport">72.00</td>
<td headers="Seattle Subtotals">421.25</td>
</tr>
<tr>
<th id="Totals" axis="Totals">Totals</th>
<td headers="Meals Totals">196.27</td>
<td headers="Hotels Totals">442.00</td>
<td headers="Tranport Totals">162.00</td>
<td headers="Totals">800.27</td>
</tr>
</table>

As you can see, the code for this table is quite complex. To help you understand the organization of the table code, we have replaced the headers with header code:

Definitions of the code:

Table Header: th

The table header creates the space where the header information will be placed, whether it is the top of a column or the beginning of a row.

Header identification: id

Header id identifies (or names) the header of a column or row header. The id is "called" by the "headers" attribute (see below) to make the screen reader read the headers of the column and row of any data cell within the table.

Axis

The axis attribute allows for relational groupings of header information.

Headers

The "headers" attribute calls the information from the column and row headers: <td headers="meals totals">. Notice that the two words "meals and totals" are space-delimited.

Image of Data Table

There are times when you find images of charts on the Web. This technique was already explained in the How To section under Images. We are using a modification of the "D" link to explain the contents of the table to a screen reader; instead of a "D" link, a descriptive phrase was used for the link text.

Description of Table for number of cups of coffee consumed by senators

Relative Sizing vs. Fixed Sizing for Fonts and Tables

Typically in a word processor, we have to decide what size we want our text to be. For the main header of a page, we might decide on a 32-point font, and for the body of the document, we might choose an 11 or 12-point font. Many Web designers practice the same when designing their pages. In Web editors, though, you have more options for sizing; you can use points, pixels, percent or nothing! Points, pixels and other units of measurement are considered "fixed" sizes. Percent and nothing are considered "relative" sizes.

One of the disabilities is low vision. A person with low vision might have to increase the font size on their screen in order to read the text. If the fonts and tables are set with fixed sizes, the the low vision user might not be able to increase the font size on their screen. If the fonts and tables are set to relative sizes (either percent or none), the user will have control over the sizing on their screen.

Each browser (Internet Explorer, Netscape) has a control panel in it that allows any user to set the font size on their screen. If you do not specify a fixed font size on a page, that page will look for the font size set in the users' browsers. In other words, if you don't control the font size in your Web pages, the users' browsers will.

The same is true for tables; you can use fixed or relative sizing. Some Web designers might set their tables to "600 pixels", which means that the table would be 600 pixels on all monitors. You can also set your tables to percent. You could set your table to 50%, which would fill up half of the users' monitors, or you could set the table to 100%, which would fill up the entire screen.

To recap, using relative sizing for fonts and tables allows the end users to have more control over the visual presentation of your pages.

Back to top

Navigate to other How To pages with the links below.