WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Screen readers, math symbols, and Word

for

From: David Farough
Date: Nov 18, 2010 1:48PM


Hi Jason:
I have been looking into this.

As far as I can see, the best and easiest way to handle this would be
to get the access technologies to handle these symbols.

This is a little more complicated than it should be.
These symbols are actually handled by the synthesizer, not the screen
reader per say. Then you need to provide the appropriate definitions
for each available language as well.

I added an entry in the eloq.sbl file for the greater than or equal
symbol (2265)

The entry looks like this.
symbol137=u+2265 11111111 greater than or equal
This entry is found at the end of the [American English] section of the
file.
Here is a description of the entry taken from the sbl file.

;keys starting with symbol have the following format:
;symbolN=char flags text
;where N is an incrementing number (as you add symbols to the table),
;char is the symbol being represented
;flags are four groups of two bits, from left to right, two for all,
two for most, two for some and two for none.
; These sets of flags correspond to the four punctuation levels
supported by JAWS.
; The two bits represent (from left to right) whether pronunciation
text at the end of the rule should be inserted and the
;second bit represents whether the symbol itself should be removed from
the stream
;The final field, text, is the text to be spoken when bit 1 of any
group of two bits is set, ie the text to be spoken for
;the symbol.
; Some symbols also have the actual symbol appended after the text to
ensure that specific synthesisers still honour the
;punctuation symbol when processing intonnation because a space would
otherwise be
;inserted after the text causing the inserted symbol to stand alone and
thus not necessarily be honoured by the synth.

I noticed that the less than or equal symbol and the not equal symbols
are not defined here either.


The best thing about this option is that these entries will be used
when reading all text regardless of the application.
Unfortunately it is really up to the access technologies to implement
this for the synthesizers they support. Then it is up to the user to
determine if any software synthesizers that they buy will handle these
symbols appropriately.

this file is stored in the following location in Windows XP.
C:Documents and SettingsAll UsersApplication DataFreedom
ScientificJAWS12.0Settingsenu
.

David Farough
Application Accessibility Coordinator/coordonateur de l'accessibilité
Information Technology Services Directorate /
Direction des services d'information technologiques
Public Service Commission / Commission de la fonction publique
Email / Courriel: <EMAIL REMOVED>
Tel. / Tél: (613) 992-2779

>>> Jason Kiss < <EMAIL REMOVED> > 04:47 PM Wednesday,
November 17, 2010 >>>
It's interesting that the "greater than or equal to" Unicode character

is read as "greater than" by JAWS when used in Word documents, while
the
equivalent named character entity reference (&ge;) or numeric reference

(&#8805;) is read by JAWS as "equals" when used in HTML.

I've done some comparisons of HTML character references as read by JAWS

and Window-Eyes, and both are pretty poor. For many of the character
references, where JAWS simply says nothing, Window-Eyes actually says
the word "question". You can find a comparison table of mathematical
operator character references as read by JAWS and Window-Eyes here:
http://www.accessibleculture.org/research/character-references/jaws-we-all/#mathOps.

The tests were performed using JAWS 8 and Window-Eyes 6.1, but some
quick reviews show that JAWS 9 and 11 behave the same. I don't know
about the most recent version of Window-Eyes, but expect it's also the

same.

For documents that present significant amounts of mathematical
equations
and the like, MathML is likely the most robust solution, but, to agree

with Cliff, it seems like overkill to me when we're talking about a few

symbols or equations here and there in what is otherwise a
straightforward text document.

If the user environment is known and relatively controlled, it may just

be easiest to go with customised pronunciation dictionaries, as Birkir

and Donald suggest, and allow content creators to continue using the
regular Unicode characters, whether they're doing it in Word or in
HTML.

I think that ideally, we could somehow convince screen readers to
properly read such characters and symbols by default and
out-of-the-box.
Is there a technical reason why they don't already, or is it just
something they've not considered or can't be bothered with? I would
love
to know more.

Jason





On 18/11/10 09:54, Cliff Tyllick wrote:
> I appreciate that MathML is the preferred solution, but I'm
concerned
> that there seems to be a pretty significant learning curve -- the
> page you pointed to is quite a bit to digest.
>
> And we will need an even more significant cultural change before we
> can adopt MathML as the standard for producing these documents.
After
> all:
>
> - The many authors who contribute to these documents do not know
> markup language, so training would be needed.
>
> - The people who review them during production are used to using
> Word's tools for reviewing, revising, and commenting. There is no
> ready solution I'm aware of for doing the same thing in markup
> language -- and even if there is, we're back to that need for
> training.
>
> - Some of the people who receive these documents after they are
> published want them in Word.
>
> - These documents are a relatively small part of a production scheme
> that involves Word and PDF -- in part because of relative ease,
> familiarity, and availability; in part because they meet our need
for
> all forms of the document to have a uniform format.
>
> - These documents are fairly lengthy and are heavy with text. The
> math is interspersed in various places -- in fact, in many cases,
the
> "math" is simply a character next to a value in a table. So are we
> supposed to have everyone learn a new technique of producing,
> distributing, and digesting documents, just so they can insert the
> occasional mathematical symbol?
>
> - And what if we have a series of 20 related documents, and only one
> of them needs mathematical symbols? Must we use MathML for the whole
> bunch? Or have a unique production method for just the one?
>
> I'm not saying it's impossible, but I'm not sure how we would get
> there from here.
>
> Cliff
>
> Cliff Tyllick Usability assessment coordinator Agency Communications
> Division Texas Commission on Environmental Quality 512-239-4516
> <EMAIL REMOVED>
>
>
>>>> On 11/17/2010 at 11:50 AM, in
>>>> message< <EMAIL REMOVED> >, Stephen L
>>>> Noble< <EMAIL REMOVED> > wrote:
> The preferred solution is to use web documents using MathML (i.e.,
> XHTML+MathML). At this juncture, native accessibility to
> mathematical content within a Word document has not been solved.
>
> For a broader discussion, see NCAM's Accessible Digital Media
> Guidelines:
>
http://ncam.wgbh.org/invent_build/web_multimedia/accessible-digital-media-guide/guideline-g-math

>
>
Technique G2.1 / Use MathML to provide access to scientific and
> mathematical expressions "MathML is the best choice for a markup
> language for expressing math. The advantage of MathML is it provides
> mathematical information in an open, standard format that can be
> exploited by a wide range of assistive technologies."
>
> Best regards, --Steve Noble
>
> ------------------------------------ -- Steve Noble Chair, National
> Technology Task Force Learning Disabilities Association of America
> <EMAIL REMOVED> 502-969-3088
>
> -------------- Disclaimer: The opinions and comments made in email
> are those of the author, and do not necessarily represent the
> official position of any organization unless explicitly stated.
>
>
>>>> Cliff Tyllick< <EMAIL REMOVED> > 11/17/2010 11:55
>>>> AM>>>
> One of our authors who has tested Word documents in JAWS 9 has
> doscovered that the "greater than or equal to" symbol (Unicode
> character 2265) is announced as "greater than."
>
> In some cases this might be a minor annoyance, but the difference is
> important in documents that tell people how to comply with
> environmental regulations. Is there a good solution to this problem?
>
> If not, we're thinking of just replacing the character with an
> inline graphic of the same size with appropriate alt text. Thoughts?
>
> And is this just a JAWS thing, or do other screen readers do the
> same?
>
> Cliff
>
>
> Cliff Tyllick Usability assessment coordinator Agency Communications
> Division Texas Commission on Environmental Quality 512-239-4516
> <EMAIL REMOVED>
>