This chapter is from the book
This chapter is from the book
This chapter is from the book
E: Accessibility overview
I’ve already mentioned accessibility many times, usually coupled with some snide remarks about the general lack of it in JavaScript development. It’s time for a more formal overview, as well as an accessibility test of the example scripts.
What is accessibility?
Accessibility means that your pages remain accessible to anyone, under all circumstances, especially when the user suffers from a condition she cannot change, for instance diminished eyesight, or has a browser that does not support (sufficient) JavaScript.
What does “remain accessible” mean in a JavaScript context? It means that the user must be able to read the content of the site, use the navigation, and perform common operations like submitting a form. Nothing less, but also nothing more.
Making every site perfectly accessible in all situations is rather a tall order, and we’ll see that at the time of writing it is not yet possible because of some tricky technical issues with screen readers. Nonetheless, we should make a start, and since we are able to solve some accessibility problems, we should do so.
Noscript
The clearest accessibility problem, the one that everybody’s able to name, is that some browsers will not support (sufficient) JavaScript. Your carefully crafted scripts don’t work in these browsers, and their users will see an unscripted page.
Priority One of writing accessible scripts is, therefore, to make sure that the page functions without JavaScript. We’ll discuss the gory details later, but first I’d like to point out two less well-known but still serious accessibility problems.
No mouse
Some users don’t use a mouse, but instead navigate the Web through keystrokes. Some use the keyboard, but others might use widgets like on-screen keyboards, or devices that emulate a keyboard.
Their reasons for using keystrokes instead of mouse gestures may vary. I myself occasionally use the keyboard for some quick operations, and this is obviously my own choice. I could reach for the mouse, but sometimes I’m too lazy to do so.
Other users, though, may be forced to use the keyboard continuously for reasons they’re not able to change. The most likely scenario is that these users are (partially) disabled in their hands and cannot perform the rather subtle movements necessary to guide the mouse. Keystrokes offer a good alternative for these users—except when a JavaScript developer has forgotten to take them into account.
Usually these users’ browser is able to execute advanced scripts, and the user is able to see the results when they appear on the computer screen. Thus there’s really no problem, except that the scripts don’t react to keyboard input.
In order to make your scripts keyboard-compatible, you should define extra events in addition to normal mouse events. For instance, if you use a mouseover event you should also use a focus event, since without a mouse no mouseover event will ever take place. We’ll discuss this specialized area of accessibility in 7B when we treat the available JavaScript events.
Screen readers
Some people cannot use a normal browser. Typically, these are blind or severely sight-impaired people who simply cannot read anything from a computer screen. Instead, they need a program that reads the content of the page out loud. These programs are known as screen readers.
JavaScript developers used to think that screen readers were essentially noscript browsers, and therefore accessibility for screen-reader users was an extension of accessibility for noscript users. As long as the page works without JavaScript, blind users would not suffer from JavaScript-related problems (though plenty of other problems like missing alt attributes still remained).
Unfortunately, this is a myth. Most screen readers are programs that run on top of an existing browser—usually Explorer, sometimes Mozilla. Since they use a normal browser to get their data, they also support JavaScript. When the underlying browser encounters a script, it tries to execute it normally.
This seems to be good news. If screen readers also support JavaScript, there’s no problem, right? Unfortunately, there are two very serious ones: the linear nature of screen readers, and their chaotic events support.
A screen reader offers only linear access to a page. When a sighted user with a graphic browser visits a site, she gets a quick overview of all possibilities simply by looking at it. The bunch of odd-color bits on the left will probably be the main navigation, the text in the middle is obviously the main content, etc. Thus the user can quickly determine which parts of the page she needs, and interact only with those parts. In addition, as soon as a script changes the document structure or presentation, her eye is drawn to this change and she can evaluate its meaning.
Not so with screen-reader users. A screen reader reads the page from top to bottom, usually in source code order. This is a severe problem to modern JavaScript. Even if all screen readers supported JavaScript perfectly (which they don’t, not by a long shot), how would we alert their users to the fact that (parts of) the page have changed, especially when the screen reader has already read those parts?
Take Form Validation, in a hypothetical screen reader that supports perfect JavaScript. Screen readers allow their users to fill out forms and to submit them. Since JavaScript works fine, Form Validation runs when the user activates the Submit button, and if it finds errors, the script places error messages next to faulty form fields, alerts “Errors have been found,” and halts the form submission.
The problem is that a screen-reader user may (usually but not always!) hear the alert and get an inkling of the problem, but since the reader has already read past the form fields themselves, he won’t hear the error messages themselves.
To help screen-reader users, Form Validation scrolls back to the start of the form:
[Form Validation, lines 100-103]
<form id=”startOfForm”>
if (!validForm) {
alert(“Errors have been found”);
location.hash = ‘#startOfForm’;
}
This is useful to both sighted and blind users; both groups will appreciate being sent back to the start of the form so that they can mend the errors of their ways. Nonetheless, it’s important to note that this feature is a nice extra for a sighted user, but an absolute necessity for a screen-reader user.
Screen readers and events
Unfortunately, the events support of screen readers is extremely confused and chaotic. In theory you’d expect them to support interface events like focus and blur, but not mouse events like mouseover and mouseout, because screen-reader users use a keyboard (or an equivalent device) to give input.
Unfortunately, some (but not all) screen-reader vendors have seen fit to include mouse events anyway. The reason is, of course, that most sites use only mouse events because their creators never seriously considered keyboard accessibility. Screen-reader vendors want their programs to treat these pages correctly, too, and therefore added mouse event support. Of course this creates serious problems when an accessibility-aware Web developer wants to carefully separate screen readers from graphic browsers to give them special treatment.
I’m deliberately not going to give details; they’d just confuse you (and me), and screen-reader event support is likely to change when new versions are released. Suffice it to say that you cannot assume anything about screen-reader event support.
The situation is in fact so bad that I fear accessibility is just not possible in the generation of screen readers current at the time of writing. It was Derek Featherstone who drew the harsh but correct conclusion, “We can deal with JavaScript on or off, but we can’t deal with in between,” and therefore he feels it’s better to ask users of older screen readers to disable JavaScript entirely. If they do, they’ll fall back to a noscript page, and that’s a situation we can handle.
At the moment, and speaking from the scant knowledge we have about screen-reader JavaScript support, I’m forced to agree with him, albeit reluctantly. Noscript screen readers are far easier to cater to than script-enabled screen readers.
Accessibility and usability
This brings us back to our starting point: any Web page should remain accessible when a browser does not support (sufficient) JavaScript. Before treating the practical accessibility of the example scripts, we first have to discuss a few general rules.
We should carefully consider JavaScript’s purpose, which, as we saw in Chapter 1, is the addition of an extra layer of usability to a Web site. As soon as JavaScript is disabled, a Web site’s usability will suffer—after all, an entire layer disappears. But the absence of this layer should not hamper the page’s basic accessibility.
Take Usable Forms. When the script works, it makes sure that users will see certain form fields only when they actually indicate they need them. The “Date of divorce” field will remain hidden until the user indicates he is, in fact, divorced.
When the script does not work, the user sees all form fields he may possibly need. From a usability perspective, this is obviously undesirable: the more form fields the user sees, the more confused or irritated he becomes, and the more likely to decide not to bother with the form at all.
Nonetheless, the page remains perfectly accessible, and I’ve done my duty as a Web developer. The user is able to fill out the form and submit it to the server, even if without my nifty script the process will become more time-consuming and confusing. The user might be less willing to fill out the form because it’s so huge and confusing, but that’s something we can’t help. When JavaScript is not supported, usability suffers.
Don’t restrict usability
Accessibility should not restrict usability. If you have an excellent idea to increase your site’s usability that won’t work without JavaScript, use it—just make sure that it’s possible (not necessarily easy, just bare-bones possible) to use the page without it.
Perfect accessibility does not consist of offering exactly equal functionalities to script and noscript users. Sometimes that’s flat-out impossible, and at other times the attempt will backfire with a vengeance.
For instance, let’s try to create the Usable Forms effect without JavaScript. You could serve a form without the optional fields first, let the user submit it to the server, and send back an extended form with the “Date of divorce” field when your server-side scripts notices the user has checked the “Divorced” radio button. Technically, this could work.
However, from a user-experience point of view, it is far worse than the noscript form we just studied. Although that form may be confusing and is certainly less usable than the scripted version, at least it doesn’t confront the user with extra downloads and fields at the moment he thinks he’s successfully submitted the form.
In general, it’s far better to accept the diminished usability of a noscript page than to try to work around it.