W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2003

Re: The Cult of Pseudo Accessibility

From: Geoff Deering <gdeering@acslink.net.au>
Date: Thu, 11 Dec 2003 06:59:54 +1100
Message-ID: <3FD77B3A.2000508@acslink.net.au>
To: James Craig <work@cookiecrook.com>
Cc: Charles McCathieNevile <charles@sidar.org>, WAI Interest Group <w3c-wai-ig@w3.org>

James Craig wrote:
> I think you are confusing the "letter of the law" and the "spirit of the 
> law." The plain and simple truth is that not every <script> element 
> requires a <noscript> element to be accessible; hence the concept of 
> user-checks.

For sure, but when a whole page is dependant upon scripts executing and 
you get a page that is unusable and inaccessible when scripts are turned 
of, and these parsers still continue on their merry way without the 
slightest suggestion there could be a problem, you have a real problem.

As a programmer you should know that all they have to do is at least in 
this situation parse the functions calls and match them in a DOM tree 
table to see if they meet critical or none critical criteria and flag 
them as such?

Now why hasn't anyone done this?

> If I have a script that provides some *non-essential* functionality, do 
> I really need to explain that to a user with scripting disabled in order 
> to provide that person with a usable experience? No. WCAG understands 
> this and doesn't require it. Section 508 suggests the explanation but, 
> IMHO, it's extraneous in most cases and rarely helpful.

Sure, you know that.  You know how to use these tools wisely, you 
understand the issues.  Most of us here do understand how to use these 
tools within their limitations.  But the vast majority do not, and there 
are heaps of companies out there that use such tools without this 
knowledge.  Bobby has been in production long enough for some of these 
things to be addressed, and Watchfire have not addressed them, so my 
concern is that there is a developing cult of pseudo accessibility.

> I agree with you that there are some fundamental flaws. The main one is 
> that it stills displays the "Bobby Approved" graphic without verifying 
> even one user check. If they continue to use this logo, the validation 
> process should go throhugh a series of Yes/No questions such as "Have 
> you verified that the <script> element on line 53 of file...blah blah?" 
> Once those have past, the logo could be displayed. Granted, this 
> provides no more verification of accessibility than the current version, 
> but it is less likely to be misunderstood by a novice user.


> I'd like to reference two clichés:
>   1. "Guns don't kill people, people do."
>   2. "Guns just make it a lot easier for people to kill people."
> These could also be interpreted as "Bobby doesn't misrepresent sites as 
> accessible, people do." and "Bobby just makes it a lot easier for people 
> to misrepresent sites as accessible." However, in the right hands at the 
> right time, both Bobby and guns can be used for good, too. ;)

As I said, tools like Bobby, because Watchfire has done bugger all to 
fix, are killing real accessibility.  The test of accessibility in a lot 
of large to medium companies is Bobby.  To all those developers out 
there, they are happy that they have mastered accessibility in 24 hours, 
as Bobby tells them.  And as for those of us who frequent these 
discussions, well... what are we on about????

> PS. I just know that last sentence is gonna come back to haunt me.

Well I do definitely know Bobby CAN be used for good.  I use it and it 
is helpful.  I also use it because it is built into TopStylePro.  I know 
it's limitations, but with my toolset it is very handy and helpful.

But if I was involved in that project at Watchfire I'd be ashamed.  I'm 
not directly blaming the project manager or the developer because I have 
been involved in many projects for large companies where the politics 
absolutely killed the prospect of unfettered development and a 
successful product, so it's not easy to lay blame on anyone, but I am 
comfortable in saying, that as a company, their performance is very poor 
  in regards to the development of this project.

Received on Wednesday, 10 December 2003 15:00:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:26 UTC