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: Wed, 10 Dec 2003 23:07:53 +1100
Message-ID: <3FD70C99.3010603@acslink.net.au>
To: Charles McCathieNevile <charles@sidar.org>
Cc: WAI Interest Group <w3c-wai-ig@w3.org>

Hi Charles,

I do agree with some of your points, and many of the tests are not so 
easy to do, but the ones I mentioned are *darn right easy* too do.

To be able to parse a document and detect empty values in certain 
elements, or look for <NOSCRIPT> where there are <SCRIPT> elements is 
something a first year CS student should be able to do, so why after all 
this time, in a commercial product from a commercial company, why isn't 
the project manager knowledgeable enough to isolate these problems and 
have them corrected?  These particular checks are trivial and should 
only take a few days to implement them.  Why haven't these been 
identified and dealt with?

You say that most of these haven't been documented by WCAG for 
programmers to implement, but these points are well documented in these 
forums, they come up time and time again on these lists just falling on 
seemingly deaf ears.

Just say I was project manager of this product, I'd be watching this and 
a few other lists all the time for feedback on my product.  We have all 
been complaining about this for years.  You'd have to either have your 
head in the sand to be missing this, or be completely incompetent in 
your job not to be able to address the specific areas of concerns that 
I've pointed out.  If you have just the basic understanding of 
accessibility and programming these points would not have slipped by. 
They would have been fixed.  It's crap that it's too difficult.

It's absolutely true that to parse and validate web document for 
accessibility is not a trivial matter.  But, the specific items I point 
out are trivial matters for a even a basic parser or an average 
programmer (like myself).  They are not hard to implement, as obviously 
the W3C validator shows this.  So if there are checkpoints that are very 
easy to implement I cannot fathom, beyond sheer neglect and 
incompetence, why this has not been done.  These checks would not be 
overlooked by competent people.  Please enlighten me to what I am 
missing here?

Look, I'm no great programmer, but I have worked with some that are 
exceptionally talented, and I can assure you that I could sit down with 
one of these programmers and say “we have to parse to check for this and 
this and this, and I know for certain that we can do it, cause I have 
worked with these people on lots of great and successful projects.

This is a commercial product from a large commercial company, they are 
selling us mediocrity, that's their product, and if they keep peddling 
the line that an accessibility parser is too difficult, they have just 
been feeding crap to us, because just about all their products are based 
on parsing technology, they are specialists at precisely this type of 
product.  So why doesn't all this expertise show up in Bobby?  I'm 
flabbergasted.

If it was an open source project with little to no funding, I have no 
complaints, only encouragement, but for a commercial product in a large 
resourceful company making money from it and willingly promoting 
pseudo-accessibility, it's pathetic.  It's absolutely pathetic.

Do you know what it says to me?  Watchfire bought Bobby because it 
gained an early high industry profile, so they can sit back, put very 
little effort into it and it will still make them money.  And the 
accessibility community is so darn forgiving and amicable they won't 
complain too much about it's poor quality.  But if it was a tool for 
another sector of the development community it would be ridiculed and 
rejected until they fixed it.

So many commercial companies are down right slack in the area of 
accessibility because of the good nature of the accessibility community 
and the incredible effort and patience shown by it to the tools 
industry.  It is also what I love and learn from in this community, but 
I really feel at the same time the knowledge based and much of the good 
work in the community is just exploited for cheap commercial gain and in 
the long run the Accessibility movement and awareness will suffer 
because of the impact of ignorance these tools will have on the general 
web development industry.

Why do you need the expertise of the people on this list and others if 
you can easily generate HTML soup that does not even conform to a valid 
grammar which passes as WAI AAA.  Piece of cake, what's all the fuss 
about, you don't need any real skills or knowledge.

I really don't know what goes on in that company (Watchfire), but I do 
know they have developed some great products in the past and when they 
bought Bobby I originally thought "Great, now it will really be 
redeveloped into a fine product" (Cast initially did a good but flawed 
job I feel).  But the time and results speak for themselves and it is 
another sad tale of a product that showed so much promise, but to date, 
delivering so little, and now doing real damage because uncorrected it 
will create a cult or pseudo accessibility.

The source code to the W3C validator is open, maybe Watchfire need to 
take it, examine it and go back to the drawing board and start again, 
because, sadly, Bobby has become a Web Accessibility Joke, and this 
should never have happened.  It didn't deserve this, the web 
accessibility community doesn't deserve to be treated in this way.

I know that most of these companies have representatives involved in 
their relevant areas in the W3C, but I ask you, is this really a sign of 
active involvement, or just token representation.  Even if these people 
are genuine, often their managers just put them there to fulfil a public 
role, whether they like it or not.  The proof of the pudding is in the 
results, and I have seen little improvement in Bobby over this time.  It 
still has the same *basic* flaws that could have been fixed ages ago. 
Something is very wrong in Bobby's development lifecycle.

Come on Watchfire, lift your game.  If you can't fix it, give it to the 
open source community to do something decent with it, but stop selling 
and promoting a highly floored product.  It's doing more damage than 
good, but I guess it is providing cash flow, and that is the bottom line.

Geoff Deering

Charles McCathieNevile wrote:
> Hi Geoff,
> 
> Bobby is not alone in missing out various tests - in fact it is 
> difficult to know all the things that should be tested, so it is not 
> surprising that tool developers have different opinions even before the 
> problems faced in actually implementing them are taken into account.
> 
> There has been an interesting discussion in the last day or so on the 
> Accesoweb (spanish) list about Coca-Cola, who launched an "accessible" 
> version of their spanish website. Clearly they have tested it with TAW 
> and Bobby, and have not detected the problems that come up even at 
> level-A. To be fair, these are problems that are not really identified 
> in the tool tests, nor in the documentation, although they are fairly 
> serious ones. (On the other hand it is nice to see a company like 
> Coca-Cola España is making a serious effort...)
> 
> There is a forum - the Evaluation and Repair Tools group, where people 
> discuss precisely how to do testing and what tools should do, and 
> developers such as Bobby's Michael Cooper are active participants in 
> this area. (Chus Garcia, developer of TAW, speaks spanish and 
> participates in discussions through Sidar where we have people who 
> follow both groups).
> 
> But most important are the techniques themselves - the WCAG group has 
> not really been inundated with tests that can be applied, which means 
> they haven't published documents sufficiently complete to enable tool 
> developers to get really good guidance. And most of what they have has 
> come from a handful of developers. We the people can contribute this 
> material, which would make a big difference.
> 
> The EuroAccessibility Consortium's goal is to harmonise web 
> accessibility testing in Europe through consistent interpretation of 
> WCAG at a detailed level. It has therefore been working on a checklist 
> for WCAG where each aspect of each checkpoint is called out. Sidar has 
> been participating in that work, because we believe that it will provide 
> a great deal of valuable input to WCAG (and because we like the aspect 
> of EuroAccessibility's rules that specifically recognises WAI as the 
> technical authority where decisions should be made, rather than 
> promoting further fragmentation of standards and approaches). Sidar has 
> also been active chairing the EuroAccessibility group on testing tools, 
> and we expect to see some major improvements, although we recognise that 
> software development often takes some time.
> 
> I share the frustration of seeing people rely on poorly-used tools as a 
> substitute for thinking. Although from time to time I am scathing about 
> the cavalier attitude to people, and the clear lack of professionalism 
> that this shows, I am also aware that many people trying to develop 
> accessible content are not professional web developers but experts in a 
> particular field trying to do their best with limited tools. Worse, many 
> of them do not have the resources to use the good but not free tools 
> which are available.
> 
> It isn't a cult of pseudo-accessibility that concerns me, but a cult of 
> "accessibility only if it costs nothing and requires no effort or 
> thinking or learning". Often (but not always) accessibility is trivially 
> easy and has negligible cost when included by a professional. To avoid 
> even that minimal effort strikes me as reflecting badly on developers. 
> (In Australia it is also against the law, but we live in a special place 
> <grin/>).
> 
> And I hope that we do get better tools, and that people use them. It's 
> tough on the bleeding edge...
> 
> cheers
> 
> Chaals
Received on Wednesday, 10 December 2003 07:11:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:13 GMT