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

Sun Apr 29 17:57:22 PDT 2007

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/