|
|
|||||||||||||||||||||
|
|
|||||||||||||||||||||
|
Main Menu: Tables:
Page 1 2 3 4
5 6 Tabula Rosey
. . . or not so rosey, as the case may be with accessibility concerns. Tables are in a sort of no-mans-land of accessibility, an odd sort of space that belongs to neither side of the line. Tables can be perfectly accessible or horribly inaccessible. They tend to be a blind person's online nightmare, but they can be the designer's dream and totally invisible (or inaudible) to the blind user if they are used effectively and sometimes creatively. The main problem with tables lies in how screen readers read page content. They read in a line from left to right (recall the examples at the very beginning of this tutorial). Most data presented in a tabular format would get chopped to bits if it were read in single lines from left to right (tables are often used to present content that doesn't fit left-right reading so neatly). However, these problems are further complicated by designers who use tables to layout an entire page, not just present tabular data. As in the example you heard at the beginning of this tutorial, content layed out in a table gets chopped to bits, too, by a screen reader. Let's start with the nastiest example of how a table is horribly inaccessible. Give the following table a listen [sound clip of table read by JAWS].
Audio transcription is also available. Tables like this one are common on websites, especially in course websites where instructors or professors post rubrics or other assessment methods. Listen specifically for the order in which different blocks of text get read. Let's look at how you can deal effectively with tables for both content and layout. |
|||||||||||||||||||||