WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: JWAS and special characters pronunciation

for

From: Chagnon | PubCom
Date: Jan 1, 2014 5:44PM

Birkir wrote:
" What all screen readers should uniformly support is to announce a character differently when put inside a span, it should not take a Block level element to get that done. "

Whatever solution is developed by the industry, it needs to also work for non-HTML documents, such as MS Word, PowerPoint, and Acrobat PDFs.

Right now, putting a span tag requires hand-tooling in the resulting PDF file, not a very efficient method for the millions (and probably billions) of ordinary documents created every day. The native Word and PowerPoint files need to be just as accessible as the PDF exported from them, as well as their HTML counterparts.

1) We need to broaden our focus: all information should be accessible, not just HTML websites, and we need to encourage the key players (which are the AT manufacturers, Microsoft, and Adobe) to develop solutions that will work for HTML, Word, PDF, ePUBs and forthcoming technologies. Hand-coding a span tag around these elements won't get done by ordinary workers who create the majority of documents.

2) We also need to use Unicode to its full capabilities for these characters.

There are different Unicode characters for the Greek letter pi used in written material (Unicode 03C0) versus the mathematical symbol pi used in formulae (Unicode 03D6), although both appear visually the same to the human eye.

Similar for all sorts of dashes; the hyphen has about 12 variations but the normal hyphen is Unicode 2010, the mathematical minus sign Unicode 2212, the en-dash is Unicode 2013, and the em-dash is Unicode 2014. Each of these glyphs has a different purpose in language and technical documents.

It would help if we and the industry could develop standards for how these variations will be voiced and treated by AT. One solution is for screen readers to pick up the Unicode name from the character when they encounter it.

In a series of technical documents we just completed for a client, plus and minus signs peppered the narrative, as in "adults 21+" and "a co-efficient of −.125". Our screen reader testers didn't even know that the characters were there and so they misread a great deal of the information in the documents. AT users shouldn't have to play mindreader and figure out that they have to force their technology to voice individual characters: instead, we the document creators, need a way to signal all technologies to voice the character with its Unicode name.

And that has to be done in the source document, such as MS Word, Adobe InDesign, and an HTML editor.

—Bevi Chagnon

— PubCom.com — Trainers, Consultants, Designers, and Developers.
— Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508 Accessibility.

-----Original Message-----
From: <EMAIL REMOVED> [mailto: <EMAIL REMOVED> ] On Behalf Of Birkir R. Gunnarsson

I totally agree that we cannot always shift all responsibility to the content developer.The problem with this particular conundrum is that the screen readers have one set of rules but TTS voices used often have their own independent rules (painful lesson learnt from working with developer to design a TTS engine for Icelandic).
What all screen readers should uniformally support is to announce a character differently when put inside a span, it should not take a Blockk level element to get that done.
Btw. if you have a copy of an online example, I would happily file a bug both with Freedom Scientific, makers of Jaws, and NVDA.
What we need to do more of is to alert assistive technology vendors of issues for end users and content developers, so they are aware of the problems and have a chance to react to them.
It does not solve the problem for you today, but it could ensure that next year you and everybody else does not have to invent hacks to get around them.
Cheers
-B


On 12/31/13, Olaf Drümmer < <EMAIL REMOVED> > wrote:
> Wouldn't inserting a zero width space do the trick? Though strictly
> speaking it is breaking the one word into two words though they still
> look like one to the sighted user (but be also aware that searching
> for the one word might begin to fail...).
>
> In general I would like to add that it is more important to fix less
> than well working tools instead of hacking around in content to avoid
> limitations of one out of many tools. But that's just my personal
> point of view…
>
> Olaf
>
> Am 1 Jan 2014 um 00:17 schrieb "Birkir R. Gunnarsson"
> < <EMAIL REMOVED> >:
>
>> A crude way to do this is to wrap the character in a <div>.
>> In very quick testing span does not do the trick (though this is very
>> brief testing).
>> This also will require some repositioning with CSS, but this forces
>> the screen reader (at least Jaws) to read the character by itself.
>> I would also like to suggest that you add screen reader instructions
>> to the page, informing the user this article uses a lot of special
>> charaacters so user needs to make sure the screen reader is set to
>> pronounce these (for instance, NVDA, ignores most non-alphabet
>> characters in its default pronounciation setting).
>> Hope this helps.
>> Happy 2014
>> -B
>>
>> On 12/31/13, Druckman,Geri < <EMAIL REMOVED> > wrote:
>>> Hi,
>>>
>>> I am testing a medically related site about gene mutations. Some of
>>> the text contains special charters in Greek (e.g., the character
>>> Alpha).
>>> I have added the symbol and the proper pronunciation to the JAWS
>>> dictionary, I tested it with both character encoding &alpha; and
>>> &#945; both work very well as an individual character, and JAWS will
>>> indeed read "alpha", but when it is part of a word it will read it
>>> as "ah".
>>>
>>> So a gene named p110(enter here a symbol for alpha) will be read as
>>> "pe one hundred ten ah", though when arrowed through the word it
>>> will read "pe one one zero alpha".
>>>
>>> Any ideas how to encode the page (HTML) in such a way, or make JAWS
>>> properly read "pe one hundred ten alpha"?
>>> This will help with other scientific paper (encoded in HTML for
>>> online
>>> reading) that have other special characters.
>>>
>>> Thank you, and a Happy New Year!
>>>
>>> Geri Druckman
>>> Web Development Specialist - Accessibility Department of Internet
>>> Services MD Anderson Cancer Center T 713-792-6293 | F 713-745-8134
>>> >>> >>> list messages to <EMAIL REMOVED>
>> --
>> Work hard. Have fun. Make history.
>> >> >> list messages to <EMAIL REMOVED>
>
> ---
> Olaf Drümmer
> Florastraße 37
> 13187 Berlin
> Tel 030.42022239
> Fax 030.42022240
> <EMAIL REMOVED>