Using Tables for Layout
I am confused about the use of tables for data
and layout. We are designing new Web sites.
We are trying to incorporate the guidelines
of Usability.gov
and, of course, we want to be 508 compliant.
We are currently using tables for the layout
of the page in the same way that they do on
Usability.gov. Is this an appropriate use of
tables? The W3C
WAI (World Wide Web Consortium Web Accessibility
Initiative) Web site seems to say that we should
be using style sheets and not tables for this
purpose. If we do use tables in the same way
that they are used on Usability.gov, what methods
must be used to make the table accessible? How
do we provide the specific cues for the screen
readers?
This is an excellent question. First,
let's clarify the difference between tables for
data and tables for layout. The following is an
example of a data table with two matrices, Time
(horizontal) and Network (vertical):
click on IE Menu- View--Source- to see code for this table
Television Schedule
Television Schedule
|
9:00 PM
|
9:30 PM
|
10:00 PM
|
10:30 PM
|
11:00 PM
|
11:30 PM
|
|
FOX
|
COPS
|
COPS
|
COPS
|
When Pets Attack
|
COPS
|
|
CBS
|
60 Minutes IV
|
Matlock
|
Retirement Today
|
|
A&E
|
Biography: Patrick Duffy
|
Law & Order
|
|
HIST
|
The Luftwaffe Part IX
|
In Search of Hitler
|
|
LIFE
|
My Left Breast (cont'd)
|
Oh God Please Don't Take My Daughter
|
|
PBS
|
Pledge Drive
|
Irish Jigs and Dirges
|
Pledge Drive
|
Donny Osmond and Eminem in Concert
|
Pledge Drive
|
|
COM
|
The Man Show
|
South Park
|
That's My Bush
|
Cooking With Ben Stein
|
SNL Best of 1983
|
We'll deal with data tables on another day. Far
more common are tables used for layout
purposes. These tables are less obvious to the
viewer because their borders are typically set
at zero, making the divisions between rows and
columns invisible. Using tables for layout is
fine, for now, as long as they make sense when
linearized.
to see how they read in linearized
form. Or download Opera,
launch it, open your Preferences (located under
the File pulldown menu in Windows, the Edit menu
on Mac), select "Document," and uncheck the boxes
next to "Tables" (see figure below).
Here's a little bit of background on the layout-tables
issue: The TABLE tag was originally intended strictly
for data tables. However, the use of tables for
layout purposes developed quite naturally and
universally as designers took advantage of this
HTML feature to control the way their pages appeared
in a graphical browser. Most Web pages you see
today use tables to create multiple columns of
side-by-side content and to position page elements
(as you can see if you View:Source in your browser).
The people who write the standards (W3C)
would very much like everyone to move to CSS
(Cascading Style Sheets) for positioning, and
in many cases this is quite convenient to do.
For instance, there's no reason to use tables
with an empty left-hand column to create white
space and make text appear indented--it's now
easier to do that with CSS positioning.
However, absolute or fixed positioning
(the kind you'd need for two- or three-column
page layout) is still quite tricky in CSS. It's
not that CSS isn't powerful enough. It is; you
can do wonderful, elegant things with fixed positioning
of text and pictures using CSS1 and CSS2, and
your pages would be accessible. The problem is
that your pages would likely appear correctly
only in Opera
and certain versions of Internet Explorer. It's
those pesky "user agents" -- particularly the
widely-used Netscape -- that don't fully or correctly
support CSS. We have to wait for the user agents
to catch up with the standards.
Therefore, in the real world, as opposed
to the utopia envisioned by theW3C,
Web developers still use a combination
of CSS and tables to achieve the layout
effects they want. This is the way to go if you
want to ensure access for the most people, regardless
of the type of browser they're using. Even the
W3C occasionally uses tables for layout, though
they officially frown on this practice as a misuse
of structural formatting to achieve visual presentation
effects. When more browsers properly support CSS
and CSS2 positioning, tables for layout purposes
can be abandoned. Until then, we should use CSS
wherever possible and tables when unavoidable.
Some things to be aware of when using tables
for layout:
-
Screen sizes: In general, relative
values (table width="90%") for table
widths are preferable to absolute values (td
width="300"). Relative values allow your tables
to resize gracefully to fit browser windows
of various widths. Not everyone's screen is
the same size, and you don't want people to
have to scroll off to the right to see your
entire page. In particular, partially sighted
users are likely to set their monitors to
low-resolution so that text appears bigger.
-
Nested tables (tables within
tables): The more nested tables you use, the
more potential problems you create for users
of assistive technologies, and the slower
your pages will load for everyone. Instead,
use a series of simple tables one after another
if possible.
-
Never use structural markup,
such as the TH tag, to make your text bold
and centered in layout tables--it will confuse
screen readers. Use style sheets instead to
control the appearance of your text.
-
Ensure that users can skip
repetitive navigation menus, especially
if those menus appear before the main body
of the page (as in a horizontal nav bar at
the top, or a vertical menu on the left).
This is one reason that many developers prefer
right-hand navigation columns.
-
Use style sheets to control
your table elements (padding, colors, alignment,
etc.) rather than loading up each TD tag with
multiple attributes. This keeps your HTML
clean and makes your tables more portable
and updatable.
-
WYSIWYG ("what you see is what you get")
Web-authoring tools don't always give you
enough control over your tables, and they
often insert a lot of junk HTML automatically
if you're not careful. It's easier to write
the HTML for tables yourself and maintain
full control over the code than to go in and
clean it up later.
-
Always check your pages
in Lynx
to see whether your tables make sense when
linearized.
-
Always, always test your pages on multiple
browsers and platforms prior to launch,
especially if you are using CSS. At a minimum,
check on Internet Explorer for Mac, Internet
Explorer for Windows, Netscape for Mac, and
Netscape for Windows (versions 4 and later).
There's another issue that pertains to older
screen readers: Some of these screen
readers can't linearize tables correctly, so that
if there are two columns of parallel, wrapped
text, they'll won't read "cell 1, cell 2" across
a row; instead, they'll just read the text across
in a straight line, so that it sounds like nonsense.
The W3C guidelines warn
about this in a Level 3 checkpoint (in other
words, a fairly low-priority checkpoint), and
provide an example.
However, it's up to individual developers to
decide whether to worry about accommodating these
outdated technologies. The W3C's warnings were
written in the late 1990s, and those primitive
screen readers are extremely old at this point.
Since they would make nonsense out of more than
half the sites on the Web, most if not all users
will have upgraded to more recent versions. One
of the goals of 508, after all, is to push software
developers to improve their assistive technologies.
Web authors will have to use their own
best judgment, just as they do when deciding
when to stop making sites backwards-compatible
with very old browsers such as Netscape 2.0.
You may choose to offer a "linearized" version
of pages that use layout tables, either by coming
up with a script to do it on the fly, or by removing
the table tags manually, or by using the W3C's
Table
Linearizer. See W3C
WAI for an example (the icon
switches that page to a linearized version). Note
that if you are planning to offer two versions
of a page (with and without layout tables) rather
than generating a linearized version on the fly,
you will have to make sure that the content of
both pages is identical, and that they are updated
at the same time.
Because of these considerations, you may decide
that offering separate, linearized versions of
your pages is not worth the effort. Our
advice: if your pages with layout tables make
sense when viewed in Lynx, they will probably
make sense to the screen readers currently on
the market.
Tip: If you don't have Lynx or Opera (both are
free downloads), here's an alternate way to test
how your tables will look when linearized: Select
all text on your Web page (Control+A for Windows,
Apple+A for Mac), copy, and paste it into your
text editor or word processor.
Accessibility
Tutorials for Webmasters