HTML Tables: how fashion affects Assistive Technology

“I like web pages with frames” a screenreader user told me in 2003. “They make it easy to differentiate the navigation bar and the content pages.” Back then, frames were well into their decline as a popular HTML technique, replaced by single-file HTML pages using TABLE elements. Everything was wrong with frames, including problems for blind people – confusing back and forwards, problems of positioning the focus and so on. The new TABLE layouts were much better, right?

Well, frames are pretty much dead as a design tool, and no self-respecting web developer would be seen dead using them. In fact, we are now going through the process of ditching the successor to the frame, using the TABLE element to lay out web pages. We’re moving to CSS-based pages. And arguments about accessibility for blind and screenreader users are being made in support of this shift (e.g. “Tables make life hell for those using screen readers” or “Tables Aren’t as Accessible” or “make your sites more accessible to all viewers and user agents” to give you the top three Google results for “layout tables are bad”.) There’s even a Web Content Accessibility Guideline, mandating what an “accessible” website should do, that says “5.3 Do not use tables for layout unless the table makes sense when linearized.

Is this true? What impact will the change to CSS have on blind and screenreader users compared to the current TABLE-based world? And what does it mean in terms of how we use arguments about accessibility to make decisions about technology?

Tables versus CSS: the technical details

Here’s why the use of TABLE elements is irrelevant to screenreader users and possibly even better than the CSS future.

Reason 1: Screenreaders handle layout tables just fine.

Tables for layout are the de facto standard, used on literally billions of web pages for over a decade. Screenreaders therefore handle them just fine. They’re a solved problem. Screenreader manufacturers do not generally insist that, for the sake of semantic purity, their users are inconvenienced by hearing extraneous and incorrect table formatting information as they browse the web.

Reason 2: Tables restrict designers to simpler layouts

Using tables means you have to segregate your page into relatively static and simple rectangles. The order of the content as it is encountered by the screenreader user has to reflect the order in which you code it, which means that navigation bars – usually left and top – generally come first. This is helpful for blind users because they can become used to “all the rubbish at the top” and come up with their own techniques for handling it, and the content when they do find it tends to be strictly linear and thus easier to use.

Compare this to PDF, where a page can hop about in terms of layout and floating text boxes and other things that confuse the all-important reading order. This kind of visually-effective design is much easier in CSS, and so will increase the complexity of web pages and hence decrease their usability for screenreader users.

CSS also permits much more variation in web page appearance during the page’s lifecycle, so suddenly you can do complex things like pop-up messages in CSS. Very Ajax, very hard for screenreaders.

Reason 3: CSS doesn’t give you any more semantics than layout TABLES.

It’s not like using CSS suddenly lets a screenreader user spot a search box, navigation bar or main content. CSS elements are arbitrarily named with non-standard tags. HTML5 might fix things – it has extra elements like NAV for navigation bar, which might actually be useful – but that’s going to be a long way off.

CSS3, of course, has a layout table anyway, so the Next Big Thing may well be – scrapping CSS for tables!

Reason 4: The implicit alternatives are “broken TABLE use” versus “utopian semantic web use”.

The latter isn’t going to happen. Most data is in PDFs or CVS. Everything else is in the tag soup of web pages. Maybe Wolfram Alpha will pull it out, but that gives one central point of reference – not arbitrary tables. Google gets information from links, not from page semantics – page semantics are too easy to game, as you’ll know if you tried using Alta Vista in 1999.

5 It should be easy to use heuristics to detect real data tables. They’ll need the extra semantics anyway.

The fact that content is laid out in a grid doesn’t really tell us that much. What do the columns mean? What’s the relationship between each item in each cell? Well, HTML gives us some extra elements which are actually useful – CAPTION, TH, SUMMARY. So a real data table is almost certainly going to use them.

Which gives us a convenient heuristic to differentiate data tables from layout tables: if it has the additional semantic elements then it’s a data table, otherwise it’s a layout table. So are we really missing semantics from the mis-use of the TABLE tag, or are we just missing actual non-layout TABLE elements from the Web?

7 TABLEs are relatively consistently and widely supported.

This means that people with alternative browsers are more likely to make sense of your layout, and the DOM for your access technology is simpler to parse and use. Known, older technology has better support from AT vendors, who always lag a few years behind, and from trainers and users and experts who need to build up techniques and approaches for new ways of doing things.

8 TABLEs scale better when you zoom the text.

CSS coders make assumptions: TABLE coders make assumptions. CSS assumptions don’t include people needing to zoom pages 400%, 1000% to read them. TABLE assumptions don’t include that either. However, because of how they are implemented in every major browser, and because they are simpler and lay out more simply, tables work much better when you zoom them up. Sure, you get a side-ways scrolling bar, but you don’t get overlapping text and columns squeezed to one character and rendered entirely unreadable.  Try it yourself with a table page and a CSS page.

6 Finally, CSS is harder than TABLEs: it’s a status symbol. The wasted time producing the same visual effect could have been used for accessibility.

First there were FRAME elements, then TABLE elements, now CSS. Professionals need a way to argue to their clients that their work is better than others: the ability to use hard-to-implement CSS is a form of display, a status symbol like a peacock’s tail. “Choose me, I can do this really hard thing! That means I’ll do a really good job of your site!”

What this all means for screenreader users and AT practitioners

If TABLEs are better than CSS, then what’s going to happen next? Can we fight it?

No. Let’s be honest: CSS is in, and layout tables are out. There is no way we’ll go back to TABLE use. The lesson to learn, therefore, is not that tables are better or worse. The lesson is that fashions and politics apply to coding and technology as much as they do anything else. Don’t believe the hype.

What we have to do is try, this time, to not drop the ball. CSS is part of making the browser environment a fully-fledged operating system, which means vastly increased complexity for the web page over the static text-based document of a decade ago. There will be decisions made about technology and support for screenreader users of these pages a-plenty: don’t leave them until the application is finished, because it never will be. The web moves too fast. Investigate HTML5 and WEB-ARIA and using your site without a screen or a mouse or the ability to click-and-drag.

Finally, coming full-circle back to our layout TABLES: if you want to help screenreader users, don’t waste your time replacing TABLE layouts with CSS. Wait until HTML5, and add the existing useful page semantics in HTML4, especially for your data tables. And make you funky AJAX sites work somehow if you turn off Javascript and pull out your mouse, and you’ll be doing the Right Thing.