Re: Brainstorming - abbreviations

>Robert Brodrecht wrote:
>> An optional "pronounce" attribute wouldn't be bad.  However, I don't
>> know how screen readers would behave.  As of now, do they simply read
>> the title attribute or do they read the abbreviated text in the element
>> with the option of reading the title?  If the former, how would it
>> decide whether to read the "pronounce" or the "title"?
>
>JAWS defaults to reading the abbreviated text, but can be configured to
>look at the title attribute.
>
>Window-Eyes has similar options, but I do not know offhand what the
>default is.

I'd like to point out that while it's easy to say "Jaws can be configured", this is not a standard configuration. The equivalent is Windows XP home users with everything set to be as secure as possible - sure, some do, but it's not default and it's very few.

JAWS default behavior is to read the text content of the element, so if I have <abbr title="What you see is what you get">WYSIWYG</abbr>, unless I have the "read abbr and acronym title attributes" checkbox set (and it's buried in setting dialogs, btw), JAWS will pass 'WYSIWYG' to the logic the decides if it tries to speak it as a word or as initials. Sometimes it makes good calls on those, sometimes not.

Someone suggested "screen readers should have complete lookup dictionaries." for expanding things like Mr. and Sr. When I'm home this evening, I'll run some quick tests to see just how complete these are in JAWS 8.

My question is, how much control should authors have here, and how much of the task is given to the makers of screen readers? What about abbreviations like 'ph' for phone? "Contact us: ph: 111 222 333, fax: 111 333 222" for example. What about ambiguities like <span lang="es">Sr.</span> versus <span lang="en">Sr.</span>, which have differnt meanings and different pronounciations? Or ambiguities like nm, which can be nautical miles or nano meters?

When we think about this question, we need to decide *why* this markup exists in the first place.

Among other uses, I think one of the main points is so that everybody can approach the text on equal footing: When sighted readers come accross abbreviations in context, we don't think about the meaning. Why should a user of a screen reader have to take the time to figure out what's written just because his software didn't have a certain letter combination in its lookup tables?

I think if the markup could have the ability to make text flow better for screen reader users, it should.

Colin Lieberman

Received on Thursday, 15 March 2007 20:40:24 UTC