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

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.

Only if you have great faith in the wisdom of committees.

no I don’t, and no I don’t

.

Sorry if I misunderstood you.

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

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.

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

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

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

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?

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.

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?

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.

Do we ban people from using that [HTML5] because even in twenty years time some people will still have browsers that don’t support it?

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

hopefully that will demonstrate that the test case was adequately tested

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

To take part in [WCAG], you need the big money backing

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.

Adobe claims Flash is ‘accessible’. But its limited accessibility features work only with certain assistive software, only on Internet Explorer, and only on Windows…Benjamin Hawkes-Lewis

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?

We live in a world with severe income disparities that actively discriminates against the disabled. Benjamin Hawkes-Lewis

Sadly true. But it’s not just the disabled who are discriminated against. The poor as a whole are discriminated against…

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 reasonableBenjamin Hawkes-Lewis

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 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.Benjamin Hawkes-Lewis

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.

Web developers seem to make poor experimenters, so I am a little sceptical of such empirical claims.Benjamin Hawkes-Lewis

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.

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.Benjamin Hawkes-Lewis

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.

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.) Benjamin Hawkes-Lewis

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’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:

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.Benjamin Hawkes-Lewis

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…

…guideline-type standards such as OHSAS 18001 or WCAG offer no absolute guarantees. So language like ‘ensure’ and ‘necessarily proof’ is simply misplaced.Benjamin Hawkes-Lewis

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.

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’.Benjamin Hawkes-Lewis

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

This strawman argument …Benjamin Hawkes-Lewis

…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?

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

Benjamin Hawkes-Lewis

… 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:

The Web Accessibility Initiative (WAI) develops strategies, guidelines, and resources to help make the Web accessible to people with disabilities.Web Accessibility Initiative

… 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?

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.

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:

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

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!