How to Create Accessible Tables

| page 1 | page 2 | page 3 |

Layout Tables

You will probably hear some accessibility adovcates say that layout tables are a bad idea, and that CSS layout techniques ought to be used instead. There is truth in what they say, but, to be honest, using tables for layout is not the worst thing that you could do in terms of accessibility. People with all kinds of disabilities can access tables without much difficulty, as long as the tables are designed with accessibility in mind.

The biggest concern has to do with those using screen readers. Early versions of screen readers could not read tables at all. The software would read from left to right across the table as if the table were not present. Here is a sample table:

If I were using an old screen reader on this table, it would read:

Famous Quotes
Person Quote
Bob "If it's not fun, you're
Basso not doing it right."
Helen "Life is either a
Keller daring adventure or
nothing at all."

(Note: the actual order of words may be slightly different on your computer, depending on your font size, browser, and platform.) As you can imagine, this can be totally unintelligible, especially in more complex tables. Luckily, screen readers have been able to read tables for quite some time now. The sort of problem described above is a thing of the past. There are other issues to worry about, though.

Ensure that the contents of the table make sense when linearized (i.e. when removed from the table).

Screen readers access information in a linear fashion. They can only read one thing at a time. This has a significant impact on the way that Web content is rendered. Users of screen readers cannot quickly glance at a Web page all at once. They must rely on their screen readers to give them the information one piece at a time.

Not only that, but there are instances in which the reading order is different for visual users and for users of screen readers. Remember this:

Screen readers read the content of Web pages as if there were no HTML tags at all. They read everything in the order that it appears in the source markup.

This is an important concept. Let's take a look at a circumstance in which this becomes an issue. Here is a table which was created for visual effect:

Basement			UP!
Toilets		Flush
	Must

The visual user will read: "Basement Toilets Must Flush UP!

The screen reader will hear (or feel via Braille): Basement UP! Toilets Flush Must

Why does this difference exist between the visual order and the screen reader order? To answer this question, we have to look at the table structure. Here is the same table with the border added back in. I have also added numbers to each cell to indicate the order in which the screen reader will read them:

1 - Basement	2	3	4 - UP!
5 - Toilets	6	7 - Flush	8
9	10 - Must	11	12

Here is the markup code for the original table. Notice the order of the text:

(Note: this table has some other issues too, like the fact that it uses deprecated--outdated--font and b tags, but that's another topic.)

Checking for Good Table Linearization

There are a couple of good ways to check to see if your tables linearize well. The first one is to use the online accessibility validator, the WAVE. I recommend using the 2.2 alpha version for the extra functionality that it offers.

Here is the same table, as seen through the WAVE:

Notice that the WAVE has added little blue arrows to show the reading order of the table cells in this table. The WAVE has also added an icon to show us the alt text for the image of the toilet.

Another way to check the reading order of table cells is to use the Opera browser (http://www.opera.com/).Opera allows the user to turn off tables completely. In Opera 6.0, go to File | Preferences | Page Style | User Mode then de-select the tables option.

Once you have done this, you can toggle the User Mode on and off with one click of the mouse. The User Mode icon is found in the upper left area of the browser window, right next to the address bar. It looks like a sheet of paper.

You'll also notice that the user mode turns off colors and styles. That's because it's using your style sheet, which, if you haven't specified one, is no style sheet at all. When you strip the page of tables and styles, you have a pretty good idea of what a page is like for users of screen readers.

Do not use table headers (<th> tags) for visual effect.

The table header (<th>) tag is meant to be used in data tables. Don't use it in layout tables because you may confuse screen reader users, making them think they're inside a data table when they are not.

Use proportional sizing, rather than absolute sizing.

Internet "documents" and Web "pages" are different then their ink-on-paper counterparts. Printed pages have an absolute, unchangeable size. Web pages do not. We can stretch our browser window up, down, right, left and achieve just about any size. Web layout should be fluid to fit the fluid nature of the Web browser.

A layout table with a fixed width does not change its size to match the viewing area of the browser window. If the viewing area is very small, users will be required to scroll back and forth too much. This can be quite a nuisance for people with low vision who must use special software to enlarge the viewing area. This software, often called "screen enlargers" can enlarge the contents of the screen much more than the operating system can. Some people have the magnification so high that only a word or two can be seen at a time. More commonly, users will set the magnification between 200% and 500%.

Developers can use the Opera browser to simulate the effect of using a screen reader. Opera can enlarge Web pages up to 1000%! The magnification option is found in the upper right of the document window. When you enlarge pages, you will notice that the amount of horizontal scrolling increases significantly. You can't avoid this, but you can reduce its impact by specifying relative table layout units, such as percentages, rather than fixed units, such as pixels.

Use the simplest table configuration possible.

Some designers go crazy with layout tables. They create all kinds of unnecessary rows and columns, using spanned rows and columns in every which way, until the table hardly looks like a table at all anymore. All of this may be invisible to sighted users if the table border is set to zero, but blind users will "see" it all. Their screen readers will inform them of the number of rows and columns in the table. When they try to navigate from one area to the other within the table, they may become disoriented. The rule of thumb here is, the simpler the better.

| page 1 | page 2 | page 3 |

Top of Page || Return to Tutorials List