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 (Web Content Accessibility Guidelines). 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 (HyperText Markup Language), with an optional CSS (Cascading Style Sheets) 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.
Joe Dolson
Thanks a lot for your comments, Mike – it’s interesting how much quieter conversation on these issues has been recently. Partially, at least, I think it’s because of cases such as the rather infamous Jeff Croft post: that post spawned such vitriol on every sides that many people may now be treading very cautiously.
People are passionate about the issue. I think that’s great. It makes for a much richer discussion. However, when passions run high, sometimes tempers flare. Acknowledging the limitations of understanding accessibility is crucial to keeping an even keel, for me.
For me, the biggest acknowledgement to make in accessibility is that you (speaking abstractly) just never know everything: who is (or will be) accessing your site, with what tools, with what goals – so it’s inevitably a Sisyphean battle. We will never get to the top: all we can do is try.
Isofarro
Joe, good post – its great to see some thought, and some research of evidence, offered into the discussion.
John, interesting and insightful response, and a couple of comments in reply:
* Some people won’t consider themselves disabled, even if they have vision, dexterity or hearing difficulties – yet a disability it still is, regardless. Its a reduced or lack of a sensory perception or skill. We deal with vision impairments regardles of whether someone is legally certified as being vision impaired or not. The legality or acknowledgement of a disability is irrelevant. Its the act of not discriminating against someone on the basis of their disability – whether they acknowledge that disability is not important, and does not change the approach.
* Regarding the battle against “adding accessibility almost always has a trade off of some kind” – it sounds like you are saying there’s no trade off in making content accessible? Am I reading that right?
* I understand, and agree with your point on relying on enhancements being a barrier. Although I point out Flash isn’t always an enhancement. When it is used to enhance content – fine, then there should be a fallback. When it is used as a means of making content accessible, then no fallback is necessary – unless your audience is of people with disabilities that cannot, because of their disability, access the content, or use the technologies needed to access the content.
* “the same blog article where I was called a troll” – that was deserved (and I don’t mean that as an insult – just a fair reflection of that particular thread). I was surprised it was you that got snagged on that hook.
* In Jeff Croft’s case – accessibility wasn’t just an additional feature. He’d already catered for accessibility up to a certain level. What he pushed back on was the overly crude reaction he got from accessibility people when he rejected the idea of implementing a reverse-colours option. He made a reasonable decision based on time, cost and benefit, and opted not to do it. (And his grounds for doing so were sound – why replicate something in an inferior way on one website when it can and should be done in the browser in a way that can be used on all websites? – its the same rationale as the font-resizer widgets and print buttons that clutter up many pages)
I also note with great interest that the real problem zealots and “experts” have been remarkably quiet and well behaved in the last two weeks. Perhaps that’s a good sign.
Mike.
Joe Dolson
Thanks for your extensive comments, John! I certainly agree with you – “accessibility” is first about “access”. I do feel, however, that there’s a progression to developing an accessible site: first preparing for those users who have no choice but to use a device with limited access capabilities, and second to prepare for those who have other options, but have chosen to access your site on, for example, their Palm pilot.
But graceful degradation is an utterly critical portion of web accessibility, regardless of any difference in terminology: having a “Plan B”, like you mention, is too important to be left behind. I hadn’t seen Robert Nyman’s article: that was very interesting! Yet another reason to be cautious when using client-side scripting!
Thanks for your comments!
John Foliot
As one of those who has been accused of being both a “zealot” and a pedant (and even a troll) over the years, I am confused by this “division” between Universal and Accessible. To me, they *should* be the same thing. Here’s my position:
When it comes to online accessibility, it is important to remember that is not just about “disabled” users, it’s about all users – “disabled” is a label that many people do not want or feel applies to them. However, a study by Microsoft in 2004 showed that among adult computer users in the United States:
* 1 in 4 has a vision difficulty
* 1 in 4 has a dexterity difficulty
* 1 in 5 has a hearing difficulty
The Microsoft Survey also found that 16% of users have a cognitive difficulty or impairment, and few (3%) have a speech difficulty or impairment.
Today’s multitude of web-enabled devices relies on online content that has been optimized, not for a specific browser, but rather for Universal Accessibility. As developers, we have many tools at our disposal today, many more than we had even 5 years ago. But as a “web accessibility advocate”, the real problem is that the notion of graceful degradation apparently has gone missing. Flash and AJAX (to name just two of the “hot spot” debating points) *can* aid in the goal of improved access and improved user experience for some users. But too often what I see is an all or nothing approach – positions are polarized and many developers refuse to accept that there must be a “Plan B”.
“Plan B” acknowledges that there are a myriad of possible approaches to our web content, and we need to be cognizant of these differences and be prepared to deal with them. The foundation of all web based, human consumable content (and even interaction) is the exchange of ideas or knowledge, and so at its base, that knowledge exchange *should* (nay, *must*) stand on its own. We can layer on enhancements and designs which may improve some user’s ability to deal with this exchange, and this is a positive thing – it improves accessibility. If these enhancements improve the user experience then I’m all for it. But when you sacrifice the access to the basic exchange by relying on these layers of enhancement, then you are creating inaccessible content – and it is here that I become a zealot. Use the enhancements, but always be sure that there is a Plan B – what happens when your enhancement is not accessible (to any user, for any reason)?
Recently I was researching information on AJAX for my new position, and one of my favorite “warnings” on AJAX was from Robert Nyman, who wrote:
http://www.robertnyman.com/2006/04/25/an-important-lesson-learned-about-ajax-and-accessibility/
(Note that he used the word “access” when connecting to his web application…)
Finally, the bigger battle is (should be?) against those “zealots” who are starting to think aloud “Has accessibility been taken too far?” and “…adding accessibility almost always has a trade off of some kind.” (
www2.jeffcroft.com/2006/aug/21/has-accessibility-been-taken-too-far/
– the same blog article where I was called a troll). Continuing to think of accessibility as an enhancement or add-on misses the point entirely, and here both “Camps” still have much work ahead of us.
JF
Mike Cherim
Great article Joe. As you know, I’m a Camp 1 subscriber, but my first definition of an “accessible” site is that it meets the needs of disabled users — that’s rule one. If it fails that the rest doesn’t matter; I’ve failed. This may surprise some people, but I did note that in the article I wrote with Gez that making a site for disabled users is all part of it. I just choose to kick it up a notch in terms of how I define the word.