[uf-discuss] Request for help from screen reader users from the BBC

Ben Ward lists at ben-ward.co.uk
Thu May 22 10:17:00 PDT 2008


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


More information about the microformats-discuss mailing list