W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: Reality Check: Bi-polar Accessibility Disorder (BAD)

From: Dave Singer <singer@apple.com>
Date: Wed, 1 Aug 2007 09:09:56 -0700
Message-Id: <p06240836c2d65ee21fc9@[]>
To: public-html WG <public-html@w3.org>

At 8:22  +0100 1/08/07, Philip Taylor (Webmaster) wrote:
>Dave Singer wrote:
>>I cannot tell you the number of times I have seen something like 
>>"Frobotz 2" as an optional install, and wondered if I needed it or 
>>not, clicked on it to find out what it was, and been given the 
>>explanatory string "This installs the Frobotz 2 option".  Which is 
>>useless to me.
>>Requiring (this is an example only) a text description of elements 
>>may be counterproductive.  Authoring tools or authors might, for 
>>example, insert "this is an image" as the default description of 
>>all images.  Now browsers, crawlers, analyzers etc. cannot tell 
>>easily whether an element has a real (useful) text description or 
>>not. Indeed, a browser that tries to "say something useful" about 
>>un-described elements now is "blocked" by these apparent (but 
>>useless) descriptions.
>All good points (said he, as one proud to wear the
>"I care about accessibility" badge).  But if the author
>of "Frobotz 2" had /not/ written "This installs
>Frobotz 2", what more useful information might the
>installer have been able to adduce ?

Actually, in this case, it could say "this installs a background 
process that launches at boot and has root privileges" or "this adds 
the frobotz extension to Microsoft Office", and so on.  The installer 
can work out what pieces it is putting where.

Similarly the filename is probably more informative than "this is an 
image", and maybe where it comes from, how large it is, and so on. 
You don't even have to do image analysis.

I'm not saying this is the right way to go, mind you.  I'm just 
arguing that the work of accessibility is NOT done when the spec. 
permits, or has features that would support, good accessibility; 
it's done when good accessibility actually happens in practice.  And 
writing a spec. that achieves that is quite tricky and involves 
subtleties about the way people think and behave.

My perception is that some of the push-back to proposals is not 
because people don't support accessibility, but because people fear 
that proposals are too complex to be widely supported, or would end 
up (as in the example above) possibly even worsening the position, in 

Our goal is a web that has good accessibility, not just a 
specification which supported something which didn't end up happening.

David Singer
Received on Wednesday, 1 August 2007 16:11:04 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:25 UTC