On 22 May 2008, at 17:06, Alasdair King wrote:
From the BBC page linked:
"We've looked at quite a few screen readers out of the box and by
default they don't expand abbreviation elements so the user still
hears 19:30 not 2008-05-15T19:30:00+01:00."
I infer that they've tested the screenreaders, they're just worried
there are lots of blind people who have turned on ABBR, and the BBC is
a big, sensitive target. I know blind people are more annoyed about
the lack of audio descriptions in iPlayer, but there'll be some
uber-geek screenreader user in a well-off advocacy group who'll
complain.
People who have problems will be the subset of users who (use a
screenreader) AND (have a screenreader that supports ABBR) AND (have
turned on abbreviation elements) AND (come across hCalendar ABBR
elements) AND (find this one thing the biggest headache in using the
site.) Why not just offer to buy both those people a beer to make up?
I don't think the ‘what's the default‘ argument is an absolute decider
either way with this. The behaviour is supported and used; we've not
been able to get numbers on how many assistive technology users do
turn it on, but I don't think it's right to dismiss an option of a
browser which is acting legitimately with the semantics of the HTML it
is parsing.
Reading aloud abbreviations is a perfectly reasonable thing to do,
whether it's a default, on-demand or whatever. As far as I can judge,
assistive technology offering the ability to expand abbreviations is
entirely in line with the intentions of the HTML4 specification,
whereas stuffing illegible data into it is not. This is less an issue
of accessibility as it is semantics. Where ABBR is being used
incorrectly, there's no right to complain about a consuming tool
treating your code in an undesired way.
Recently, we've been discussing the issue of embedding machine-data as
part of microformats on uf-dev, and debating possible alternative
methods from a parser perspective (namely an empty element with a
title attribute).
Of interest here is the document now on the wiki covering all the uses
of machine data in microformats, and covering all the currently
supported means of including that alongside the publishers preferred
formatting.
http://microformats.org/wiki/machine-data
At the moment, the data embedding solution proposed there is being
discussed on -dev: (http://microformats.org/discuss/mail/microformats-dev/2008-May/000519.html
). It will move over to discuss once we're confident in it being
reliably parsable.
B
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
