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.
>
>