Wednesday 18 December 2002

Conversation with Joe Clark: 02

In the Slashdot interview you say that the two most significant accessibility features a Web developer can implement would be to make “all your images accessible including, crucially, adding alt="" to every spacer GIF and every other meaningless graphic” and to place visible “skip-navigation links on top of every navbar with, say, ten or more links.”

Let’s assume that we’re already doing that. What other (three? eight?) accessibility features will make a substantial impact, in order of importance?

Corollary of Point 2: Make sure your site makes sense when “linearized,” to use the buzzword. It is easiest to understand linearization in the case of table-based layouts. Turn borders on in your table, print out your page, and then cut out each table cell in strict left-to-right order based on your <tr> elements. (You kind of have to understand the underlying HTML to linearize properly, with with cellspan and rowspan values.)

Now place these in a single column in that strict order. Voilà: You have just linearized your site. For certain adaptive technologies like screen readers, linearized reading is *one possible* reading order. Visitors can override the reading order (as by skipping table cells), but if you just sit there and let the thing read, it does so in a linear or sequential manner.

For CSS-based layouts, the advice is not clear-cut. It is not widely understood that screen readers do not directly interpret underlying HTML. (There may be specific technical exceptions, but that is the thrust.) The order of inheritance is HTML → browser → screen reader → speech and/or Braille. The browser in nearly all cases is IE for Windows for various historical reasons, though Netscape 6 and 7 are said to work passably well with screen readers. Ordinarily the advice I’d give for CSS layouts is to make sure the page makes sense if the <div>s on the page are read in the order encountered in source code, but in practice the browser interprets and renders the page, which the screen reader then reads. I do not have firsthand knowledge of how linearization applies to such layouts, if at all.

Forms: Correct form markup is a bother but is quite necessary. The HTML elements for accessible forms, including <label>, <fieldset>, and <optgroup>, and the ubiquitous title attribute, are not conceptually difficult but are a tad tedious to add ot every single form element of every single page. Unfortunately, there’s no way around it. For the screen-reader user, it is rather difficult to conceptualize where one is located in a form without these elements. I would also add that screen-reader support for forms isn’t as good as it should be. For various technical reasons that may or may not be surmountable, putting yourself in forms mode in a screen reader turns off certain other modes. It’s difficult to get around, but not by any means impossible if the form is coded correctly. <optgroup> is pretty nifty, though its limitation of a single level of grouping is a pain. Adding a title to every single form element is helpful, even in graphical browsers.

You may have to fiddle with stylesheets for an acceptable visual appearance—for <fieldset> especially—and keyboard access could use some attention in complex forms, which are the next problem. Don’t put forms in tables unless you absolutely have no choice whatsoever. Suddenly the screen-reader user must deal with simultaneous forms mode *and* tables mode. Placing a label for a field (like “Name”) in a cell adjacent to that field is unnecessary and leads to a great deal of confusion.

People use tables for forms so that online forms look like printed forms—that is, they use as much of the “paper” as possible, because “paper” is expensive. But online we have unlimited screen real estate, at least in the vertical dimension. HTML forms, at root, yearn to be vertical, not horizontal. Do not flout their natural desires. Do not attempt to overlay the design of printed forms onto online forms.

Next, don’t be posting Flash or PDF without using those formats’ built-in accessibility features. That’s my advice. But it is difficult to heed because there is so little documentation of those features; they’re a bit limited at present; and the software interfaces, especially for PDF, are tremendously inconvenient (and essentially unavailable on any platform other than Windows).

Mark Pilgrim linked to a First Monday article called Users with Disability Need Not Apply? Web Accessibility in Ireland, 2002, describing it as “not encouraging.” What was your reaction to this article by Barry McMullin?

This seems like a reasonable way to use an automated checker tool (in this case Bobby, which I have described as “dumb as a mule,” but any such software is going to be that dumb) to quickly gauge the spread of obvious and indisputable accessibility errors, which are pretty much the only kind that a software tool can even spot, let alone fix.

It would be interesting to carry out a further qualitative study of the small number of sites that passed Bobby tests and a number that did not, this time using qualified accessibility experts (not necessarily me, of course). A longer and more ruminative explanation of what’s right and wrong with those sites would make it clearer to people new to the field, and to nonbelievers, that accessibility may be relatively simple but it is not always obvious and requires human interpretation. The downside, of course, is that people tend to want issues like this cleaned up by computers themselves without human intervention (like publishing a file using a content-management system), but that is simply unrealistic.

A study like this is useful in pointing out the scale of the problem, even with its limitations.



Another good reason to make your Flash accessible is to offer its content to those using browsers with Flash disabled on them. Many large companies have disabled Flash (thinking that it would cut down on online games and other bandwidth expensive operations). That leaves much dynamic content on the web unaccessible for these users who don't fit the traditional construct of "the disabled online reader".

Posted by: Lou on 18 December 2002 at 11:50 PM

And some of us just plain loathe Flash.

Posted by: Dorothea Salo on 19 December 2002 at 12:12 AM

Comment on screen readers and all-CSS layouts. I believe that the order of the DIV tags is the order in which screen readers will read things. On my site ( ) I have a breadcrumb trail on inner pages which is listed at the bottom of the page but displayed at the top (via absolute positioning). Screen readers read the entire page, then the breadcrumb trail (which is the order they are listed in the HTML source).

Posted by: Mark on 19 December 2002 at 02:22 AM

That's my experience too: IBM Home Page Reader reads my pages in the order of the DIV tags: banner, content, then links.

Posted by: Jonathon Delacour on 19 December 2002 at 09:41 AM

One should be able to approximate the "paper version" of tabled forms with some CSS (using display: inline) I would imagine. Saying that one should kowtow to the "web way of doing things" is a bit of a stretch. If users are accustomed to seeing Fieldnamme: field horizontally instead of vertically adept designers should accomodate the users when possible.

Posted by: Lou on 19 December 2002 at 12:49 PM

Lou, the issue is the use of *tables* to lay out forms. You can use CSS all you want, but the use of a screen reader's forms mode simultaneously with tables mode is a nightmare.

Posted by: Joe Clark on 20 December 2002 at 12:14 AM

There seems to be a common idea that when using CSS for layout, putting the content first makes a page more accessible (such a thing happens on this site and on's text-only option).

This makes absolutely no sense at all to me. It's based upon the assumtion that users only want to use the navigation after they've read the entire page.

What if they find they're on the wrong page? Have heard enough after the first paragraph? They'd have to go through all the content before being able to go elsewhere (unless, that is, they're lucky enough to be able to skip through it all using their screen reader - but not everything has this feature).

It also goes against the convention on pretty much every other page, so I believe text-only users will presume the navigation is at the top.

I really think the best solution is putting the navigation first and providing skip links, but I consider those a bit of a hack really - I really think there should be some way within HTML to label certain content as navigation, it would allow screen readers to skip through it automatically on first reading of a page, and jump to the navigation at any point, no matter where the user is in the page.

Posted by: Tom Gilder on 20 December 2002 at 09:21 PM

Heh. The Open eBook people invented such a navigation language. Not coincidentally in response to accessibility concerns.

Wouldn't work on web pages, though, as it's a linkbase kind o' dealie -- the links live in a file external to the marked-up text.

Posted by: Dorothea Salo on 25 December 2002 at 02:11 PM

This discussion is now closed. My thanks to everyone who contributed.

© Copyright 2002-2003 Jonathon Delacour