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
<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.