WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Screen readers, math symbols, and Word

for

From: Stephen L Noble
Date: Nov 18, 2010 3:12PM

By the way, here's a list of MathML enabled AT:
http://www.dessci.com/en/solutions/access/atsupport.htm

Using MathML and IE+MathPlayer could be a useful time saver over everyone having to map their own set of customized speech files for each AT product. Then there's the whole question of how each expression should be read. For instance, "a superscript 2" "a squared" and "a to the power of 2" are different ways to speak the same expression. So, on a global level, this can become quite a headache if one decides to write everything from scratch.

--Steve Noble

>>> Jason Kiss < <EMAIL REMOVED> > 11/18/2010 4:24 PM >>>
Hi David,

Thanks very much for this explanation! This is great info. It's quite
interesting to note the speech synthesiser's role in the problems with
these symbols, and the benefits of addressing them at this level,
something I had no idea about.

While sharing, for example, a custom pronunciation dictionary for JAWS
may be problematic since, when installed, it would overwrite any
customisations a user may have already made, I'm wondering if the
synthesiser's sbl file is something that normally gets modified in any
way by JAWS users or by way of any changes a user makes to their JAWS
preferences? If not, then perhaps sharing a customised sbl file for a
common synthesiser like eloquence, with definitions added for all of the
relevant symbols, might be feasible?


On 19/11/10 09:44, David Farough wrote:
> 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>
>>