Taxes done? Awesome! Take a tax break – everything’s 15% off!

Numerous articles in the last few days have suggested serious problems in either defining web accessibility or in the way it’s handled. Trenton Moss considers the future of accessibility. Alastair Campbell follows up with his own opinions. Gez Lemon and Mike Cherim co-published an article outlining two supposedly opposing views of accessibility at Accessites. Roger Johansson chimed in with his reasoning for universality. And, to cap if off, Mike Davies wrote an excellent (if possibly inflammatory) four-part series declaring Accessibility in Trouble.

All of these articles seem to revolve around two central points: whether web accessibility is about people with disabilities or whether it’s about universal access, and whether more advanced technologies (such as AJAX or Flash) are acceptable for use in accessible web design. These aren’t entirely separate issues: the whole universe of web accessibility is tightly entwined with the use of technology.

Who is Web Accessibility For?

First and foremost, web accessibility is about users with disabilities. It’s my firm opinion that the first goal of an accessible website is to ensure that users who, for whatever reason, are unable to make use of a website using standard user agents and settings, are able to use the website. This includes, amongst many other techniques:

  • Providing for screen readers through alt texts, image long descriptions, and appropriate labels
  • Using an acceptable default color contrast
  • Using acceptable typography and providing the ability to alter text size (through browser settings or website settings)
  • Providing appropriate link texts and explanatory information for acronyms and abbreviations.
  • Avoid the creation of any access barriers requiring specific knowledge or abilities.

These are the first priorities: they make a website usable (in the sense of “possible to use”) by disabled visitors. A second priority is in making the site easy to use. Is this accessibility? Web accessibility is commonly defined according to the principles espoused in the WCAG. However, this debate seems to reach out more broadly. From a policy perspective, web accessibility means following the WCAG guidelines. But from a logical perspective, some of these guidelines are actually about making a website easier to use for visitors with disabilities. Usability is not identical to accessibility: it supplements accessibility.

Take, for example, the provision of WCAG 2.0 calling for skiplinks:

Blocks of repeated material, such as navigation menus and document headers, are marked up so that they can be bypassed by people who use assistive technology or who navigate via keyboard or keyboard interface. [V]


WCAG 2.0 Guideline 2.4

Bypassing a menu is not precisely an issue of accessibility: it’s an issue of ease of use. I’d say that this is the challenge of making the experience of a disabled user better, rather than possible. Is it any less important? Absolutely not. On the same grounds, I’d argue that any use of technology which improves the user experience is an acceptable part of accessibility.

One key with accessibility is to add features without ever subtracting from the overall accessibility. Many, many accessibility experts will recommend consistently against the use of AJAX, JavaScript, and Flash because these technologies have accessibility problems. I won’t argue against this: these technologies DO have accessibility problems. Are they inherent? Not really. It’s entirely possible to construct highly usable, accessible websites using these technologies: it does, however, take a very high level of knowledge to do it. I won’t do it. It’s not because I am fundamentally opposed to the use of advanced technologies, I’m just opposed to my own use of them. It would be a massive disservice for me to build anybody a Flash or JavaScript heavy website. I don’t yet have the breadth of experience to work effectively with these technologies.

For me, I will continue to recommend against them while consulting, unless the client is also willing to support extensive user testing: the only truly effective way to guarantee accessibility.

Universal or Accessible?

In Part 3 of his article series, Mike Davies states:

The position of disallowing technologies such as Flash stands quite contrary to providing accessible content. Here the goals of universality are conflicting with web accessibility.

Web accessibility has always been about reaching out to disabled people – using what we have at our disposal: technology and technique. Starting with an accessible website, and ripping out the Flash (because there’s no Flash plugin for Lynx) is a step backwards for web accessibility. And yet, this is what zealots want you to do.

Its very reminiscent of the tools that create a text-only version of a website – by stripping out the images and multimedia. Both the concept and the process do more to hinder the accessibility of a website.

He’s got a great point: universality and accessibility are NOT the same thing. Universality, though an acceptable goal, is measurable only in device specific terms. Accessibility is only measurable in human specific terms. The challenge for an accessible web developer, however, is in finding an appropriate balance. Let’s be honest: how many of us really do extensive user testing? I don’t. My clients usually can’t afford it, or won’t spring for it if they can. I would love to be able to, but for now, it’s not a practical approach for me. That simple fact renders Flash an unsupportable candidate for my own development. And, I’ll opine brashly, it should also leave it unacceptable for anybody else who isn’t doing user testing.

I’m not speaking against Flash explicitly: I’m simply saying that accessible Flash is a relatively untested field. It’s not impossible, and for the knowledgeable it’s probably not even all that difficult. (For more about accessibility recommendations for Flash, you may want to read Bob Regan’s 2005 white paper on the subject.)

What Does Accessibility Need?

Well, obviously, more user testing is always called for. What I’d love to see, although I’m not capable of putting it together myself, would be a full scale accessibility study of Flash and AJAX websites which have been specifically designed with accessibility in mind. User testing, limitations, the whole banana. Accessibility needs better awareness of using Flash. AJAX has received a fair amount of attention: articles from Standards-Schmandards, WebAIM, WebStandards.org, and many others have given developers a fair shot at addressing the limitations and possibilities in AJAX accessibility. Flash has been almost entirely disregarded by the web standards and accessibility community. I’d like to see it given an equal chance.

Accessibility does not, however, need a particular agreement on who accessibility needs to serve. At least, not an agreement which refines between “disabled” and “everybody”. In my opinion, a lot of this trouble in defining web accessibility comes from petty bickering on terminology. Fine, some people define accessibility as providing for users with disabilities. Others call it providing for all users, regardless of abilities. Perhaps the second group is better defined as providing universal websites; but I can’t bring myself to be too concerned. Both camps agree without hesitation that they need to provide access for users with disabilities.

Universal web designers won’t use Flash under any circumstances, because it isn’t supportable in some rare browsers (Lynx, for example.). Fine. Does this reduce the accessibility (for disabled users) of their work? I don’t think so: it merely limits the tools they’ll work in. I find it hard to support Mike Davies’ claim that:

If zealots have their way, websites would only use HTML, with an optional CSS for presentation. And yet, this combination of technologies is inaccessible to certain groups of disabled people – certain groups that can be reached with Flash and JavaScript.

I can’t help but be curious exactly what groups of disabled people can be reached with Flash and JavaScript, but not with HTML and CSS. I’ve sat here and tried to imagine that situation; but have had only limited success. I’m imagining individuals with ADD not being capable of sitting still long enough to read a text document; but that’s a problem correctable through content changes. I would love to know what user group cannot be reached using standards-based HTML.