WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: JWAS and special characters pronunciation

for

From: Birkir R. Gunnarsson
Date: Jan 1, 2014 7:10PM

I agree.
I, myself, stumbled into the accessibility arena because I could not
obtain accessible CFA/FRM certification study materials, though it was
probably a blessing in disguise.
http://www.daisy.org/stories/birkir-gunnarsson-part-2

I think access to STEM materials (and we are talking STEM content
here, even if the format is not that of STEM instructional material
per se) is a huge problem and prevents millions of people with
disabilities from pursuing exciting, innovative and profitable
careers.
Having dabbled in math accessibility as well, I can attest to the fact
that A.T. vendors generally do not treat math/STEM accessibility it as
a high priority, because so few users request it.
The reason so few users do that is that many are discouraged and never
try to pursue a STEM degree/career, so we have a classic chicken and
egg problem (which I wish we could turn into a bacon and egg problem).
Partially I am still pinning my hopes on increased adoption of the
MathML standard for pure math, but you are right in that document
authors really need a way to tell screen readers what content should
be read, leaving it entirely to the user and the user default setting
is a dangerous game.
I know CSS3 has some sort of speech control, but I do not claim nearly
sufficient expertese to understand that, or to what degree it is
applicable (though it is on my wishlist of topics to master in 2014,
along with a lot of other things). PDF/Word/other formats require
their own standards, and screen readers need to converge on a standard
as well, and the whole interface needs to be supported by authoring
applications, rendering apps, possibly the O.S. as well as the screen
reader, not to mention that the TTS used by the user may have its own
pronounciation rules which can override the screen reader default. so
we are facing a gigantic mess of standards and technologies, and STEM
definitely pushes the limit.
I am hoping ePub3 along with MathML may start pushing the envelope in
this area, but I honestly am at aloss as to seeing the big picture of
how this could realistically be achieved.
My initial answer was supposed to be limited in scope to how this
particular problem could be addressed for this particular situation,,
but it is hard not to turn it into a long rant about how important it
is that we fix the bigger picture I admit. Reading your post was
refreshing and I found myself grinning inanely and even saying the
words "heck yeah" out loud.
If you have some ideas and info or relevant links on how to address
the bigger picture, feel free to contact me on or off-list with links
to such. I am always curious to keep abreast of the latest and
greatest in document accessibility.
All that being said, I have to be careful not to stray too far into
how to fix the world discussion on this list, so I will stop here.
*grin*
Happy ew year everyone!





On 1/1/14, Chagnon | PubCom < <EMAIL REMOVED> > wrote:
> 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>
>
> > > >


--
Work hard. Have fun. Make history.