[uf-discuss] proposed title-design-pattern is not backwards compatible, too big of a change

[Jeremy Keith]

James said, in replying to Brian:
>> A while ago there was a whole
>> report about who screen readers fail with AJAX apps, then someone
>> actually ASKED some blind folks if they could navigate the site...
>> they managed to do so just fine.
>>
>
> To what report and response are you referring? Do you have a link?

That would probably be Joe Clark's testing of Basecamp for the Iceweb  
conference:
http://joeclark.org/access/research/ice/iceweb2006-test-results.html

To say that the results show that blind users managed just fine would  
be stretching the truth. The Ajax parts of the application *did* put  
stumbling blocks in the way of screen readers but using learned  
behaviour, users were able to get around the Ajax. But that's a long  
way from saying that Ajax is accessible. Most of the larger Ajax apps  
aren't accessible to screen readers to any usable degree. For the  
small to mid scale Ajax applications, the question of whether or not  
they're accessible is questionable and varies on a case by case basis.

I think it's great that we're now gathering data on exactly how  
screen readers handle the title attribute of the abbr element but I  
would caution against expecting a clear "yay" or "nay" answer.  
Accessibility and checklists rarely make good bedfellows. Even after  
all the research, the final question of "is this accessible?" will  
still be a judgement call.

There are a number of truths here are that are Kenobi-esque in nature:

For the existing abbr-design-pattern, the English text "May first" is  
an abbreviation of the ISO date "2007-05-01"... from a certain point  
of view.

Because a screen reader doesn't convert an ISO date in the title  
attribute of the abbr element into words, the abbr-design-pattern is  
inaccessible... from a certain point of view.

And really, placing any machine-readable data in the body of an HTML  
document (rather than the head) is semantically questionable... from  
a certain point of view.

So we compromise. The abbr-design-pattern was a compromise to begin  
with. It was a very good and clever solution but it has its limits.  
Those limits are now being reached (research pending). The proposed  
expansion, the title-design-pattern, is also a compromise. It's far  
from ideal but it will help to mitigate the problems that are  
inherent in encoding machine-readable data in markup.

My point is this: the decision of how to encode this kind of data  
should come down to human judgement. The publisher of the data should  
have an option to encode datetime or geo data in a way that they feel  
makes most sense from a semantic point of view, a practical point of  
view, or a mixture of both.

For example, should the title-design-pattern be adopted (and I  
sincerely hope it will), I will--in certain cases--still use the abbr- 
design-pattern to encode some machine-readable data. I think that an  
ISO date that doesn't include the time and uses dashes to separate  
its components is acceptable to present to screen readers. Others,  
like James, would no doubt disagree. It's a judgement call but I  
don't intend to stop using the abbr-design-pattern on this page, for  
instance:
http://adactio.com/about/speaking.php

But in other situations, where I want to encode complete datetimes  
and timezones, I really don't want to present that information to  
screen reader users and I would like to have the choice of encoding  
in an other element, even if it is slightly less semantic... from a  
certain point of view.

My point is that even with plenty of empirical data on screen reader  
behaviour, and even with the rules laid down in the HTML spec, there  
are some situations--like this one--where the human factor needs to  
be given more weight. Or at least, publishers need to have the option  
to weigh the human/machine benefits at their own discretion. I  
believe that the title-design-pattern offers publishers that option  
while still allowing the abbr-design-pattern to be used at the  
discretion of the publisher.

In short, sometimes the needs of the few outweigh the needs of the  
many*. In matters of accessibility, I don't think the 80/20 rule can  
or should be applied and I don't think we should any crystal clear  
answers to emerge from testing assistive technology (though I  
wholeheartedly agree that the testing should happen).

Please forgive that long ramble when I could have just summarised it  
by saying "accessibility isn't binary":
http://adactio.com/journal/1224/

Bye,

Jeremy

* well, I had to throw a Star Trek reference in there to balance out  
the Star Wars.

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/