Accessibility: Changing Camps?
I’ve always described myself as being in the camp that defines accessibility as making things accessible to all, as this feels like the best fit for what I believe to be correct. The other camp being of course that accessibility is about making things accessible to people with disabilities (For further discussion about the deciding which form of camp suits you best, take a look at The Great Accessibility Camp-Out).
Unfortunately, I now find myself caught squarely between two camps, which no doubt means I’ll have people on both sides of the debate chipping in to criticise me (feel free, I’m a big boy and I can take it).
Actually, I’m not sure that was the best phrasing: it might have sounded like I was attempting to come out of the closet there, particularly given the very camp feeling to the article so far, but I’m sure you know what I meant…
On the whole, I believe it’s important, and it is good practice for web designers to design sites that work whether or not you have javascript enabled, that work at different screen resolutions, that work whether or not you can see images, whether or not your monitor supports more than a monochromatic display and whether or not css is supported. These features to me are used to build the bells and whistles that make a site more interesting or more attractive but they do not provide the basic content.
The idea being therefore that someone with a stripped-down browser that is capable of rendering HTML and very little else should still be able to get useful information from the site. Furthermore the site should be usable regardless of how you’re trying to access it — whether you’re using a keyboard and a mouse, a keyboard only or even a sip-and-puff device.
And yet when it comes to the practicalities of a situation, I sometimes find myself making different judgement calls…
Then, one of the leading lights of the “accessibility for all” world, Roger Johansson wrote an excellent and very thought provoking article You cannot rely on JavaScript being available. Period.
Roger is entirely correct. You can’t. You could however choose only to support those users who come to your site with a javascript enabled browser. Now before you all start yelling at me, I’ll come back to this point later in more detail, so wait to see what I actually have to say.
Secondly, December 5th was the International Day of the Disabled Person, and Nomensa carried out some research to see how various leading websites held up against WCAG. Not surprisingly, not everyone held up particularly well.
Unfortunately, simply complying to WCAG does not in any way ensure that your site is accessible to people with disabilities any more than failing WCAG is necessarily proof that your site fails people with disabilities. (Incidentally, WCAG is clearly in the “access for people with disabilities” camp, so that’s the meaning I will use when discussing WCAG).
Sadly, the reporting of this report fails to take account of this, because it doesn’t make for a good soundbite:
- 93% failed to provide adequate text descriptions for graphics
- 73% relied on JavaScript for important functionality
- 78% used colours with poor contrast, causing issues for those with colour blindness
- 98% did not follow industry web standards for the programming code
- 97% did not allow people to alter or resize pages
- 89% offered poor page navigation
- 87% used pop-ups causing problems for those using screen magnification software
The whole issue of why reporting is carried out by soundbites is a different matter entirely: is it that popular culture demands a dripfeed of soundbites rather than meatier news items, or is it that the media are so used to presenting soundbites to us that they forget how to give an in-depth story most of the time? Either way, that’s a debate for another time methinks …
Of course, part of the problem here is that we don’t know exactly what’s been tested, or what has been defined as a minimum.
It looks to me as though WCAG at level Double-A has been set as the minimum — i.e. that level to which web developers should comply, rather than level A which is defined as the level to which they must comply. Surely the “must” level should be the minimum requirement?
And of course, as I’ve demonstrated before, it’s perfectly possible to fail some of the Priority Level 1 and 2 checkpoints with a negligible impact upon the accessibility of the relevant document…
But it does look as though they’ve used the second priority level, because a number of these failings don’t appear anywhere in the first. Indeed, one of them “poor navigation” doesn’t appear anywhere at all — the closest is:
13.4 Use navigation mechanisms in a consistent mannerWCAG 1.0 Checklist
Similarly, no checkpoint requires people to be able to resize pages: if you’re using screen magnification software, or the Opera or Internet Explorer 7 browsers, you can resize pages irrespective of what the web designer has done.
Just as the web designer is responsible for ensuring that images have appropriate alt texts to be read out by screen readers, the web designer can’t be held responsible if the user has chosen to access the website with an inferior technology — or would it again be the developer’s fault if a blind person found that they couldn’t access your website because they weren’t prepared to use a screenreader or other assistive technology?
No. If you’re not using the appropriate technology then it’s your fault not the developer’s.
Now all of the checkpoints that were listed can cause problems to disabled people. However, many of them can be addressed at least partially either by changing the user’s browser or by tinkering with their settings. I fully accept that web developers need to take certain steps to make their websites accessible — but the users also have a responsibility.
But rather than railing about a series of soundbites from a press release, wouldn’t it be better to look at the actual report? Indeed it would, but as that’s not been released yet, I’ll have to make to with the executive summary of the UN report into web accessibility that one of the nice chaps at Nomensa was kind enough to send me when I asked, along with the list of sites surveyed.
Okay, I don’t agree with all of their findings, but at least the “poor navigation” thing is properly explained. The actual statistic given was:
89% failed to use the correct technique for conveying document structure through the use of headings, making page navigation awkward for many visually impaired people; Executive Summary
Ah, right! It’s a reference to this:
3.5 Use header elements to convey document structure and use them according to specification. WCAG 1.0 Checklist
If you’re going to be comparing sites, you obviously need some method of comparison, so I’m not criticising Nomensa for choosing WCAG — it’s the best standard currently available. A site that passes more of the checkpoints is more likely to be more accessible than a site which doesn’t. Nor do I have a problem with the survey findings — disappointing but unsurprising, perhaps.
What I do object to is the continuing assumption that WCAG is some kind of accessibility “Holy Grail” and that by complying with all of it your site is accessible to people with disabilities, and by failing to do so, your site isn’t. It just isn’t that simple.. What particularly annoys me here is that I know the people at Nomensa know that too, but you’d not get that impression from reading the document.
Of course, sound-bite simplification is nothing new, but it’s doing accessibility a disservice by not accepting that there are parts that are contentious, that just because WCAG 1.0 is the de facto international standard for accessibility, doesn’t mean it couldn’t do with being improved, and it most certainly doesn’t mean that it is infallible.
And this brings me back to the Great JavaScript Question, and the question of which base camp I’m going to be taking up on Mount Accessibility.
For example, I produced a test case for the use of JavaScript with assistive technology. I’ve yet to find anyone who has tested it (with the exception of when it was throwing an application error, but that’s a different matter) with assistive technology when it hasn’t worked. I am therefore confident that those particular pieces of JavaScript can be used without discriminating against disabled users.
I am fully aware that to rely on that would be in breach of the WCAG checkpoint:
6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible pageWCAG 1.0 Checklist
…but, and this is my point, it would most certainly not be “failing the disabled”. If someone chooses to switch off javascript for reasons of security, that’s not my problem. Admittedly, I may also be excluding some mobile devices (although plenty of mobile devices do support some javascript, so it might work with those also).
Now, you may have a situation where someone has javascript disabled or partially disabled and they can’t adjust their settings — for example, security policies at work. In this case I would suggest that if you need to access the site for work business, have a word with your support guys. If you don’t need to access the site for work, then stop your whinging and get back to work!
So what am I saying? Part of the responsibility is with the web developer, but part of the responsibility is also with the user to ensure that they are coming to my site with the appropriate kit/setup.
On the one hand, I’ll do my best to ensure that my sites are accessible to everyone. On the other hand, if I want to use a feature — and it has been tested with a wide range of assistive technologies — then I’ll use it without a second thought, even if that means a user would need javascript switched on, or a flash plug-in, or a more modern browser, or whatever…
*wince*. I just know that’s gonna upset Tommy…
So which camp does this put me in?
Hello. I am 
Please remember, Jack, that Camp 1 is supposed to include everything that Camp 2 stands for, we just take it further. Based on what you’ve written in this article I’d say you’re more Camp 1 than ever.
You’ve been criticized?! Who the hell is criticizing you? Nobody has the right to criticize you from either camp because it’s obvious you care about accessibility and ensuring that everyone has access to your content. People who criticize you need to be a bit more introspective.
The whole point of that article Gez and I put together was to not put a divider between the two ways of thinking about web accessibility — the so-called camps. It was meant to send a message of grow the $@*# up and stop bitching about the meaning of a word. It’s all about intent.
Last time I looked we were all trying to make the web a better, friendlier, more accessible place. Not just for disabled users but for everyone, regardless of their particular barrier(s) or disabilities.
My advice: Don’t mire yourself in the semantics of it. It’s a trap. Just keep doing what you’re doing, which happens to be the best you can. You care, you’re trying, what more could a critic possibly want from you? Sheesh!
For some reason my postbacks don’t appear to be working, but there is a response from Al:
http://alastairc.ac/2006/12/reporting-on-accessibility-issues/
I think this rhetoric misses the point. Let’s see how the same logic would apply in another sphere of life. Unfortunately, the argument would run, simply complying to OHSAS 18001 [the British Standard for ocupational health and safety] does not in any way ensure your offices are safe for employees any more than failing OHSAS 18001 is necessarily proof that your offices are a death trap that will kill your employees. So should we dismiss attempts to promote OHSAS 18001 because it’s not some kind of safety ‘holy grail’?
The metre rule is an absolute standard, but guideline-type standards such as OHSAS 18001 or WCAG offer no absolute guarantees. So language like ‘ensure’ and ‘necessarily proof’ is simply misplaced. The important question is not, if sites attempted to comply with WCAG, would they be guaranteed to be accessible, but rather, would they be generally more accessible? And as you yourself admit, ‘A site that passes more of the checkpoints is more likely to be more accessible than a site which doesn’t.’
Nothing in the BBC report implies that WCAG ‘couldn’t do with being improved’. The report doesn’t talk of WCAG absolutely ensuring accessibility but in terms of websites failing to meet ‘minimum levels of accessibility’.
This strawman argument only confuses discussion of what appears to be your real beef with the standards, namely that you:
1) Dispute the accessibility benefits of certain WCAG guidelines.
2) Reject WCAG’s animating principle of supporting alternative and older user agents, especially when an improved user agent is not ‘readily available’.
You imply that anybody surfing without JavaScript, Flash, or a modern user agent does so by choice, or by their employer’s choice, so it is not discriminatory to require them. But the realities are not nearly so simple.
Consider the problem of JavaScript accessibility. How would you suggest blind free software users access JavaScript content? Most Linux distributions do not include a recent Edbrowse or ELinks compiled with (limited) JavaScript support. Compiling is not newbie-friendly; and I’ve so far failed to compile Edbrowse successfully. But let’s assume that all blind users somehow succeed. When you require JavaScript functionality, do you test that functionality in ELinks and Edbrowse? And what about the many users of older versions of Windows screen readers, or minority Windows screen readers, with poor JavaScript support?
Adobe claims Flash is ‘accessible’. But its limited accessibility features work only with certain assistive software, only on Internet Explorer, and only on Windows. That’s Adobe’s and Gnash’s choice. You want to use Flash without a fallback? I suggest you go talk to Adobe and Gnash about exposing Flash content to all the various accessibility frameworks on which assistive technology relies. Here’s the relevant Gnash feature request:
http://savannah.gnu.org/support/?105660
We live in a world with severe income disparities that actively discriminates against the disabled. Expecting disabled users to waste hundreds of pounds for the privilege of using expensive, closed-source, technically inferior systems to access your content is not reasonable, unless you are intending to foot the bill for them to switch to the latest, top-of-the-range Windows or Mac hardware and software. Because if you don’t, that’s your choice. (See how slippery this ‘choice’ rhetoric is?)
You mention:
I suspect it’s possible to construct test-cases to show that you can break individual guidelines in particular ways and your site can still be accessible with current user agents. But such test-cases might still not be sufficient to demonstrate that breaking the guideline in question never results in accessibility costs. And they cannot hope to prove that breaking the guideline will not result in accessibility costs in the future, especially as user agent developers interested in accessibility are likely to bear the guidelines in mind.
Web developers seem to make poor experimenters, so I am a little sceptical of such empirical claims. For example, RNIB (Royal National Institute for the Blind) recently complained about sites not meeting WCAG standards, but confusingly pointed to http://www.jkrowling.com as a flagship example of accessible Flash. I pointed out that despite claiming double-A compliance, Rowling’s homepage did not validate (which means it flunks priority 2). One of the Lightmaker developers popped up to explain that they had deliberated inserted errors into their client’s page to make the point that you can write broken markup that is still accessible. But in fact, it was trivial to demonstrate that their decision not to validate their markup had resulted in some current browsers dumping technobabble gibberish into the text content of the page.
It is a lot easier to prove that something causes an accessibility problem that to prove that it never will. So I think test cases demontrating that particular guidelines, or at least particular interpretations of guidelines, can actually create new accessibility problems would be more useful. Ideally, such test-cases should be submitted to W3C’s Web Accessibility Initiative for possible inclusion or discussion in the guidelines’ errata. (There doesn’t seem to be much alternative to continuing to deal with the Initative, given that WCAG Samurai is a closed process.)
Gargh, sorry about the broken link: RNIB (Royal National Institute for the Blind) recently complained about sites not meeting WCAG standards.
Ben,
I’m not entirely sure I agree with you. I see where you’re coming from, but I disagree with the conclusions you have arrived at. You say:
I’d agree with where your argument is going: accidents can, and do happen at sites which have passed the standard. They are similarly more likely to happen at a place which hasn’t passed the standard. But, like accessibility, it boils down to individual circumstances in each case.
For me, WCAG (or ideally an improved version of it, but it’s the best we’ve got) should be used as the best yardstick we have. However it should not be used in such a way that we say a site that meets it is automatically “helping the disabled” any more than a site that fails a particular checkpoint is automatically “failing” the disabled.
For me, it’s an educational thing: there are too many people out there who focus on checkpoint-passing and box-ticking, in comparison to those actually wanting to make accessible, usable sites…
I completely agree. Unfortunately, my experience is that this isn’t a widely held belief, and therefore I believe it needs reinforcing from time to time.
The report doesn’t state that the standards are absolutely perfect. But it does refer to them as international standards, and it doesn’t so much as imply that they are out of date or that newer standards or in development. It is not unreasonable to infer from this that these standards are perceived as the best that could be assembled from current knowledge — which is emphatically not the case.
I’m not sure I read a difference in tone between ‘minimum levels of accessibilty’ or ’sites being accessible’. I certainly didn’t find anything in the BBC report to suggest that these weren’t seen as one and the same thing (which as we both know is not the case).
…hang on a minute. I’d dispute that. Can we just say “this argument”? I believe I’ve given a reasonable indication as to why I think you could make the argument I have, you have disagreed. That’s fair enough. But can we just look at the argument itself?
… um, no I don’t, and no I don’t. I object to the fact that guidelines are painted as black and white. I object to the fact that if I were to say:
<p>Arnie said "Hasta la vista baby"<p>… that I’d be in this case making my site inaccessible. It would fail a level one checkpoint (change in natural language) and a level two checkpoint (not marking up a quotation properly). The only benefit assistive technology would gain from fulfilling the critieria in this case is that a screen reader might offer a different pronounciation for “Hasta la vista“.
That’s not to say under other circumstances, these checkpoints might offer significantly greater benefits, which is precisely why I argue that it is more important to understand the user requirements and the uses of assistive technology than simply to try and tick off a checklist.
Secondly, I’d dispute what you regard as WCAG’s animating principle. For me, it’s this:
… and even then, I would encourage graceful degradation. If a browser doesn’t support css, they wouldn’t get my styles. They would still get my content however. But it gets a lot trickier when you come to web applications as many applications — mapping systems for example — require things that are virtually or completely impossible to create a genuinely accessible equivalent.
I would reject any assertion that because we can’t make these fully accessible, or because we can’t do them without javascript we shouldn’t do them at all, and would instead argue that we should do the best we can reasonably be expected to do to provide an alternative (even if it is not an equivalent) for those people who can’t access that content (for reasons of old browsers, security being switched off and so on).
*deep breath*. Right, I’m going to start a second comment to reply to the second half of what you were saying, ‘cos this is going on a bit, isn’t it?
Right, where were we?
Fair enough then. In that case I wouldn’t use it. I’m not a flash developer. Can you take my flash reference therefore to instead mean “a free, freely available and accessible plugin that is supported across a wide range of browsers and platforms”. Would you settle for that?
Sadly true. But it’s not just the disabled who are discriminated against. The poor as a whole are discriminated against…
Now you’re using perjorative terms to criticise something you don’t like. “Waste”, “expensive”, “technically inferior”, “closed-source”. For a start, how is closed-source inherently worse? Opera is closed source. Firefox is open source. Should we tell everyone to move away from the Opera browser?
But again, you seem to be missing what I’m saying. All I’m saying is that you do your damndest to make stuff as accessible in as wide a range of platforms, browsers and assistive technologies as possible but it is not possible to always support everything. What happens if people want to start using HTML 5? Do we ban people from using that because even in twenty years time some people will still have browsers that don’t support it?
I never, ever, said that it did. The whole point of that was to test one specific piece of Javascript, and one specific piece of javascript alone..
It would have obviously been easier for you to check this out if I’d provided the link to my javascript testcase but I didn’t, and I do apologise for that. I’ve mentioned it several times before during other rants, and I made the stupid assumption that someone reading this post would have been likely to have seen it before. Consider me suitably chastised.
Grant Broome from the company CDSM, who carry out pan-accessibility testing with the charity the Shaw Trust, tested this for me with JAWS. Robin Christopherson from the disability charity AbilityNet — himself blind — also tested this for me. Of course, you weren’t to know that, since I didn’t link to my test case in the first place, but hopefully that will demonstrate that the test case was adequately tested. Note that the comment from Gavin occurred when there was a .NET failure with the application, and not with the testcase itself.
Oh, I’m with you on this one. I’m a firm believer in validity for purpose of future-proofing even though I will concede the point that an invalid site is not necessarily inaccessible.
The problem here is that there simply isn’t an open standard for accessibility that anyone can contribute to. To take part in WACG, you need the big money backing; to take part in the samurai, you need to be invited by Joe. There’s nothing for the rest of us. Unless you want to look at starting an open standard Ben?
That wasn’t meant to be flippant by the way, if someone is interested in developing an open standard, I’d be happy to help to contribute. But I’m not prepared to take it on myself…
I think this conflates four related issues:
1) Need for checkpoints that better reflect the needs of people who are disabled;
2) Too much faith in automated checkers, not enough testing;
3) Lack of genuine interest in accessibility;
4) Risk of service providers hiding behind formal standards despite real inaccessibility to actual people with disabilities.
You cannot expect people people to not only do the right thing (make an accessible site) but also do it for the right reason (because they want to). Many people who commission web development projects don’t have the benevolence, interest, or time required to investigate accessibility seriously. Try though we should to raise consciousness about accessibility issues, all we can rely on is persuading them to meet checkbox requirements.
I haven’t yet seen evidence that the WCAG double-A is so imperfect that even if service providers were to implement conformance then turn around and try to use it as a shield against criticism that wouldn’t still be an improvement over the inaccessible services we have today.
However, if there are serious gaps between the checkboxes and accessibility, then we need better checkboxes. Note that checkboxes needn’t be as crude as ‘such-and-such element must always include such-and-such an attribute’. They might well mandate testing with range of users and user agents, and setting up a process for providing opportunities for user feedback and solving the accessibility problems raised by that feedback.
Only if you have great faith in the wisdom of committees.
.
Sorry if I misunderstood you.
Presumably you’d agree that you’d be making your site more inaccessible, however? Just how inaccessible does a site have to be before you would consider it inaccessible? Having a minimal standard does not conflict with the idea of a continuum between total inaccessibility and universal accessibility.
As an aside, your example, which touches on a minor obsession of mine, is problematic in four ways:
1) Even if you don’t use Q, you could should still use SPAN to trigger the correct pronunciation.
2) You write ‘only benefit’ as if correct pronunciation was a minor benefit; I’d say it’s a particularly crucial one.
3) Pronunciation is not the only benefit of Q. Irrespective of punctuation settings, assistive technology can use Q to distinguish quotations from surrounding text unambiguously. (Ordinary punctuation used to demarcate quotations is inherently ambiguous, since it can serve many purposes other than quotation, as with scare quotes.) Users of browsers that expose the CITE attribute, such as Firefox, can use the distinction between Q and surrounding text to know to check the element’s properties for a source URI. (The interface for CITE currently sucks, but I’m writing an extension to make it easier to use.)
4) I assume you’re primarily avoiding Q because a bug in JAWS 7.1 means it cannot distinguish Q from surrounding text by using a different voice or announcing its beginning and end. But by doing so, you reduce accessibility in current assistive technology that does support Q, including the Window-Eyes screen reader and Thunder with WebbIE, as well as future assistive technology that will support Q. It’s generally assumed that using in-text punctuation to demarcate quotations instead of Q because screen readers will always read it, but this isn’t the case at all. Many screen reader users turn off punctuation because it slows down reading. JAWS defaults to reading some in-text punctuation; Window-Eyes defaults to ignoring most of it, including ” (straight double quotation marks). And once you move beyond the simplest of quotation punctuation, you may begin to run into difficulties with how screen readers read it. For example, Thunder with WebbIE cannot read the single curly quotation marks in this message due to a bug in their handling of punctuation. So we can’t win really. However we demarcate quotations it won’t suit all current UAs and AT, so we might as well demarcate them the right way. If you’re concerned that this leaves the largest group (users of JAWS with Internet Explorer) high and dry, I suggest using conditional comments to change the markup processed by Internet Explorer. For example, you might use conditional comments to replace Q with quotation punctuation around span followed by an anchor link for the CITE URI in square brackets, but an alternative would be to simply add in superfluous quotation punctuation around Q. I keep changing my mind about which would be best. Either way, if quotations are important, you should explain how assistive technology should be configured in your site help. Because conditional comments are actually just comments, I’d say either would comply with HTML4 and WCAG.
I’m a bit sceptical about the claim that mapping tools can’t be made accessible but: if something can’t be made accessible, then there’s no point diluting general web content accessibility standards in order to accomodate such content.
That’s very close to what WCAG 1.0 says to do anyway. (See Checkpoint 1.1 and Checkpoint 6.3.) Exactly how close depends on how we choose to interpret ‘equivalent’.
Probably, but I’d have to evaluate such plugins on a case-by-case basis. I don’t think I’ve come across any plugin which fits this description. At an absolute minimum, I’d want content for the plugin to be usable with Emacspeak.
Sorry, I wasn’t being clear. I was primarily thinking of Internet Explorer being required in order to access Flash content. IE is obviously closed-source, but it is also expensive because it requires modern hardware and Windows, and I think it can be objectively demonstrated to be ‘technically inferior’ as a web browser (generally poorer support for HTML, ECMAScript, W3C DOM, and CSS than rival implementations; broken MIME handling; highly deceptive HTTP request headers; no XHTML parsing; impoverished exposure of web content to MSAA (Microsoft Active Accessibility) compared to Gecko). I didn’t mean to imply that ‘closed-source’, ‘expensive’, and ‘technically inferior’ inevitably go together.
The raison d’être of HTML5 is to move the web forward while being backwards compatible with existing user agents. If we need to wait for actual support, then HTML5 will have failed. But to answer the logic behind your argument, we do not need to wait for widespread browser support before using a technology. In fact, as far as I’m concerned we don’t even need to wait for the first implementation to appear. What we need, instead, is for content to transform gracefully for user agents that do not support the technology. In the case of XHTML2 (which is a better example than HTML5), we need to be able to transform to HTML. I don’t think one should start relying on new technologies until software that does support the technology is ‘readily available’, to adopt WCAG’s phrase. How one should define ‘readily available’ is a good question. As far as I can see, that means it must be cross-platform, free, and meet the users’ other needs roughly as well as their existing software. For example, a free technology only implemented in Opera wouldn’t be much use to braille users, so I wouldn’t consider that to be ‘readily available’.
Not really.
What I was hoping to see was testing with a wide variety of software (both browsers and assistive technology) and disabilities. But instead I read Grant Broome saying ‘I cannot vouch for any other screenreaders’ than JAWS 7.0. Because upgrading JAWS is both troublesome and potentially very expensive, many users are still stuck with JAWS 6.0. Screen readers are all very different, and their levels of support for JavaScript vary considerably, so I certainly wouldn’t assume what works in JAWS will work in other screen readers. And this still ignores the problem of screen readers whose users typically fall back on browsers distributed without JavaScript support (Emacspeak, Orca, LSR, and SpeakUp in particular).
FYI, there appears to be an error in your test JavaScript at line 72 reported by both Internet Explorer and Firebug: ‘WebForm_Autofocus is not defined’.
Depends. I’d say I’ve ‘taken part’ in a small way in XHTML2’s development by submitting issues to www-html-editor. But could W3C processes be more open? Of course.