WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: JWAS and special characters pronunciation

for

From: Chagnon | PubCom
Date: Jan 1, 2014 11:01PM

Great comments, Birkir.
I think the world is ripe for pressing for accessible STEM materials. This
could easily be a successful campaign that would benefit all AT users and
open the doors for many students to enter higher-paying tech and science
jobs. What a revolution that would be for the community!

<< PDF/Word/other formats require their own standards >>
I'm not going to assume that.
In fact, I think Word, PowerPoint, InDesign, and Acrobat PDF should have the
same accessibility tags and standards as HTML.

Example: I have never been able to find a good reason why the PDF
accessibility tag for lists is the generic <L>, while HTML defines 2 list
tags, <UL> and <OL>. It's as if Adobe invented its own wheel rather than
using HTML's perfectly good wheel. No additional value was added by
switching to <L>, and the consequence to AT developers is that they now must
write code to recognize all three variations of list tags.

The accessible STEM issue is large, but I believe if we break it down into
logical segments, that is identify the accessibility feature that would have
the greatest impact with the least cost or retooling, it can be done, one
step at a time.

To me, accurate voicing and recognition of Unicode characters is the first
step because 1) almost everything else hinges on it, including Math ML, and
2) the identifiers are already defined by the Unicode standard itself.
Example: the 2 pi characters, one for Greek language and the other for math.
We just need the AT manufacturers to pick up that info from the Unicode
font. It would also help to get this concept of using the correct Unicode
character as a standard in WCAG.

And then we have to teach those who create documents how to use the correct
character in their documents. Not difficult, but it does require some
training to understand why they have to choose the correct pi and how to
choose the correct pi.

There are hundreds more characters like the 2 pi characters in Unicode.

—Bevi Chagnon

PS: Birkir, have you had bacon and egg cups? Had them this morning for New
Year's brunch. It's a muffin-shaped bacon cup (also called a bacon bowl)
filled with egg, cheese, guacamole, etc. My apologies to the vegans and
vegetarians on the list. And to the dieters, too.
http://www.instructables.com/id/Mini-Bacon-Cups/ and
https://www.buyperfectbacon.com/

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com — Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
New Sec. 508 Workshop & EPUBs Tour in 2013 — www.Workshop.Pubcom.com


-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Birkir R.
Gunnarsson
Sent: Wednesday, January 01, 2014 9:10 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] JWAS and special characters pronunciation

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>
>
> > > list messages to <EMAIL REMOVED>
>


--
Work hard. Have fun. Make history.
messages to <EMAIL REMOVED>