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/
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
