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

I think one of the tricky things about accessibility is coming up 
with a specification that is not only effective when used properly, 
but naturally leads people to using it properly.

I'll give an example from another field.  The installer used on Mac 
OS X requires that if you choose "custom install", the user is shown 
the various pieces that might get installed, with a check-box for the 
optional pieces.  Selecting an optional piece shows an explanatory 
string for what you get if you install that option.

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.

So, I actually think, despite the heat on the mailing list, we are 
somewhat on the same page.  We're looking for a specification in 
which people "naturally" do the right thing, where at least 
reasonable accessibility is normal, good is possible, and poor is 

This isn't easy;  it's a subtle trade-off of designs, mandates, 
recommendations, and examples.
David Singer

Received on Tuesday, 31 July 2007 23:58:44 UTC