E-mail List Archives
Thread: Screen readers, math symbols, and Word
Number of posts in this thread: 20 (In chronological order)
From: Cliff Tyllick
Date: Wed, Nov 17 2010 9:57AM
Subject: Screen readers, math symbols, and Word
No previous message | Next message →
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 ADDRESS REMOVED =
From: Ro
Date: Wed, Nov 17 2010 10:36AM
Subject: Re: Screen readers, math symbols, and Word
← Previous message | Next message →
Do you mean that the < and > and = signs are announced as such? And if
so, why is that an annoyance? Or is it because the symbols are used
for something else? Voiceover announces them as greater than or less
than if I'm reading code, but in other instances they aren't announced
at all as in this email, but that's because of my preferred
pronunciation settings. Guess I don't understand the problem?
~Randi and Guide Dog Jayden
http://raynaadi.blogspot.com/
On Nov 17, 2010, at 9:55 AM, Cliff Tyllick wrote:
> 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 ADDRESS REMOVED =
>
From: Stephen L Noble
Date: Wed, Nov 17 2010 10:51AM
Subject: Re: Screen readers, math symbols, and Word
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
From: Terrill Bennett
Date: Wed, Nov 17 2010 10:57AM
Subject: Re: Screen readers, math symbols, and Word
← Previous message | Next message →
Cliff,
In Word 2003 with NVDA 2010.2, the line "If a [unicode 2265] b then
do something" is read as "If a b then do something"
I used Word's menu options Insert -> Symbol and typed 2265 in the
"Character code" text field and chose "Unicode (hex)" in the "From"
drop-down, and in the document I do see the singe-character
"greater-than-or-equal-to" symbol.
-- tb --
At 11:55 AM 11/17/2010, you wrote:
>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 ADDRESS REMOVED =
>
From: Andrew Kirkpatrick
Date: Wed, Nov 17 2010 11:24AM
Subject: Re: Screen readers, math symbols, and Word
← Previous message | Next message →
Steve,
Even with MathML the assistive technologies are going to need to know what Unicode characters to support. I have no idea if there is a listing of important Unicode characters and their proper names, but I imagine that a listing for Math (and music, and other disciplines) would be helpful - I wonder if that exists.
Thanks,
AWK
Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe Systems
= EMAIL ADDRESS REMOVED =
http://twitter.com/awkawk
http://blogs.adobe.com/accessibility
From: Andrew Kirkpatrick
Date: Wed, Nov 17 2010 11:33AM
Subject: Re: Screen readers, math symbols, and Word
← Previous message | Next message →
I'll answer my own question. There are lots of tables of symbols (e.g. http://www.w3.org/TR/MathML2/isoamsr.html). I guess my question is whether there is a prioritized listing - I assume "almost equal to" being more important than "geometrically equal to" (I'm not doing much geometry), but I imagine that most every one is important to some discipline. It's hard to imagine that all of these and other symbols will be supported widely anytime soon. There must be a better way than each assistive technology or TTS voice needing to recognize these...
Thanks,
AWK
Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe Systems
= EMAIL ADDRESS REMOVED =
http://twitter.com/awkawk
http://blogs.adobe.com/accessibility
From: Terrill Bennett
Date: Wed, Nov 17 2010 11:39AM
Subject: Re: Screen readers, math symbols, and Word
← Previous message | Next message →
Would this be that which ye seek:
http://www.w3.org/Math/characters/mathml/mmlalias.html
http://www.w3.org/Math/characters/mathml/mmlextra.html
-- tb --
At 01:20 PM 11/17/2010, you wrote:
>Steve,
>Even with MathML the assistive technologies are going to need to
>know what Unicode characters to support. I have no idea if there is
>a listing of important Unicode characters and their proper names,
>but I imagine that a listing for Math (and music, and other
>disciplines) would be helpful - I wonder if that exists.
>
>Thanks,
>AWK
>
>Andrew Kirkpatrick
>Group Product Manager, Accessibility
>Adobe Systems
>
> = EMAIL ADDRESS REMOVED =
>http://twitter.com/awkawk
>http://blogs.adobe.com/accessibility
>
>
>
From: Birkir Rúnar Gunnarsson
Date: Wed, Nov 17 2010 11:45AM
Subject: Re: Screen readers, math symbols, and Word
← Previous message | Next message →
I know there are mapping files, between symbols and spoken words, in
most screen readers.
I can't recall specifically what the Jaws one is called, or if it is
editable, I believe it is, the braille mapping one has been (at least
until v12.0).
I would recommend contacting FS specifically and have them confirm
what the mapping is in this file for Jaws 9, and if this has been
corrected in subsequent versions of Jaws.
Thanks
-Birkir
On 11/17/10, Terrill Bennett < = EMAIL ADDRESS REMOVED = > wrote:
> Would this be that which ye seek:
>
> http://www.w3.org/Math/characters/mathml/mmlalias.html
> http://www.w3.org/Math/characters/mathml/mmlextra.html
>
> -- tb --
>
> At 01:20 PM 11/17/2010, you wrote:
>>Steve,
>>Even with MathML the assistive technologies are going to need to
>>know what Unicode characters to support. I have no idea if there is
>>a listing of important Unicode characters and their proper names,
>>but I imagine that a listing for Math (and music, and other
>>disciplines) would be helpful - I wonder if that exists.
>>
>>Thanks,
>>AWK
>>
>>Andrew Kirkpatrick
>>Group Product Manager, Accessibility
>>Adobe Systems
>>
>> = EMAIL ADDRESS REMOVED =
>>http://twitter.com/awkawk
>>http://blogs.adobe.com/accessibility
>>
>>
>>
From: Donald Evans
Date: Wed, Nov 17 2010 11:51AM
Subject: Re: Screen readers, math symbols, and Word
← Previous message | Next message →
I've run into a similiar situation using Jaws 11 and an online algebra
course. Here are a few changes I have made to make it more readable. You
can change or set the mapping of symbols to words by using:
JAWS > Utilities > Dictionary Manager > Add
- Actual Word = * Replacement word = times
- Actual Word = - Replacement word = minus
- Actual Word = ≠ Replacement word = not equal to. (requires a UTF-8
content type declaration on page: <meta http-equiv="Content-Type"
content="text/html;charset=utf-8" >
- Actual Word = Replacement Word = divided by
2010/11/17 Birkir Rúnar Gunnarsson < = EMAIL ADDRESS REMOVED = >
> I know there are mapping files, between symbols and spoken words, in
> most screen readers.
> I can't recall specifically what the Jaws one is called, or if it is
> editable, I believe it is, the braille mapping one has been (at least
> until v12.0).
> I would recommend contacting FS specifically and have them confirm
> what the mapping is in this file for Jaws 9, and if this has been
> corrected in subsequent versions of Jaws.
>
> Thanks
> -Birkir
>
>
> On 11/17/10, Terrill Bennett < = EMAIL ADDRESS REMOVED = > wrote:
> > Would this be that which ye seek:
> >
> > http://www.w3.org/Math/characters/mathml/mmlalias.html
> > http://www.w3.org/Math/characters/mathml/mmlextra.html
> >
> > -- tb --
> >
> > At 01:20 PM 11/17/2010, you wrote:
> >>Steve,
> >>Even with MathML the assistive technologies are going to need to
> >>know what Unicode characters to support. I have no idea if there is
> >>a listing of important Unicode characters and their proper names,
> >>but I imagine that a listing for Math (and music, and other
> >>disciplines) would be helpful - I wonder if that exists.
> >>
> >>Thanks,
> >>AWK
> >>
> >>Andrew Kirkpatrick
> >>Group Product Manager, Accessibility
> >>Adobe Systems
> >>
> >> = EMAIL ADDRESS REMOVED =
> >>http://twitter.com/awkawk
> >>http://blogs.adobe.com/accessibility
> >>
> >>
> >>
From: Stephen L Noble
Date: Wed, Nov 17 2010 12:12PM
Subject: Re: Screen readers, math symbols, and Word
← Previous message | Next message →
One easy way for developers is to simply write the calls to let
MathPlayer handle the MathML. MathPlayer includes speech rules for any
commonly used symbol. The nice thing about using MathML is that the
software would be able to change the speech string associated with a
given symbol by simply modifying the speech rules. That is exactly what
I am doing in my research project using MathML content in the classroom.
Here's a link to a past Education Week article on the SMART Project:
http://r.smartbrief.com/resp/mNxMhMrCCAbpzhoCQV
I have a speech rule which has been tweaked for middle school students
with learning disabilities. For blind students, who need much more
information verbalized, there are other speech rules available. One
could also easily develop discipline-specific speech rules for
chemistry, trigonometry, statistics, etc.
--Steve
------------------------------------
-- Steve Noble
Chair, National Technology Task Force
Learning Disabilities Association of America
= EMAIL ADDRESS 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.
>>> Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = > 11/17/2010 1:27 PM >>>
I'll answer my own question. There are lots of tables of symbols (e.g.
http://www.w3.org/TR/MathML2/isoamsr.html). I guess my question is
whether there is a prioritized listing - I assume "almost equal to"
being more important than "geometrically equal to" (I'm not doing much
geometry), but I imagine that most every one is important to some
discipline. It's hard to imagine that all of these and other symbols
will be supported widely anytime soon. There must be a better way than
each assistive technology or TTS voice needing to recognize these...
Thanks,
AWK
Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe Systems
= EMAIL ADDRESS REMOVED =
http://twitter.com/awkawk
http://blogs.adobe.com/accessibility
From: Ro
Date: Wed, Nov 17 2010 12:39PM
Subject: Re: Screen readers, math symbols, and Word
← Previous message | Next message →
Ooooh gotcha. I was thinking the equals sign, not the equal to sign.
Totally forgot about that one. I have no idea how that's rendered. I
see the problem now. Thanks!
~Randi and Guide Dog Jayden
In the Center of the Roof
http://raynaadi.blogspot.com/
On Nov 17, 2010, at 10:41 AM, Robin Maiorisi wrote:
> Randi,
>
> The problem is that if we use the symbol "Greater Than Or Equal To"
> which would be a left or right arrow with a line under it, when we
> test the Word document in JAWS, only "Greater Than" or "Less Than"
> is read. The "Equal To" portion is left out and this can be a
> problem for us.
>
> The alternative would be to create an object using the Equation
> editor and then adding alt text to that object, but since these
> mathematical symbols reside in a table, we are unsure of proper
> procedure.
>
> Does this help?
>
> Thanks in advance,
>
> Robin A. Maiorisi
> Web Administrator
> Texas Commission on Environmental Quality
> Office of Compliance and Enforcement
> Remediation Division
> Technical Support Section
> <mime-attachment>
>
>
> >>> Ro < = EMAIL ADDRESS REMOVED = > 11/17/2010 11:35 AM >>>
> Do you mean that the < and > and = signs are announced as such? And if
> so, why is that an annoyance? Or is it because the symbols are used
> for something else? Voiceover announces them as greater than or less
> than if I'm reading code, but in other instances they aren't announced
> at all as in this email, but that's because of my preferred
> pronunciation settings. Guess I don't understand the problem?
>
> ~Randi and Guide Dog Jayden
>
> http://raynaadi.blogspot.com/
>
> On Nov 17, 2010, at 9:55 AM, Cliff Tyllick wrote:
>
> > 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 ADDRESS REMOVED =
> >
From: Cliff Tyllick
Date: Wed, Nov 17 2010 2:00PM
Subject: Re: Screen readers, math symbols, and Word
← Previous message | Next message →
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 ADDRESS REMOVED =
>>> On 11/17/2010 at 11:50 AM, in message < = EMAIL ADDRESS REMOVED = >, Stephen L Noble < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
From: Andrew Kirkpatrick
Date: Wed, Nov 17 2010 2:06PM
Subject: Re: Screen readers, math symbols, and Word
← Previous message | Next message →
Cliff,
It will take some training, but maybe not as much as you think. The Word math feature is already creating MathML and you can copy and paste the mathml from a word equation really easily. The time may come when web page producing tools easily import or create the MathML from the tools that people use to create the mathematical expressions.
Thanks,
AWK
Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe Systems
= EMAIL ADDRESS REMOVED =
http://twitter.com/awkawk
http://blogs.adobe.com/accessibility
From: Stephen L Noble
Date: Wed, Nov 17 2010 3:06PM
Subject: Re: Screen readers, math symbols, and Word
← Previous message | Next message →
For all the documents I create with math, including all the content I
create for students with disabilities in my research projects, I simply
use Word plus the MathType add-on. It is a WYSIWYG editor and one can
use a graphical UI with a mouse, or if one is fluent in TeX you can type
that directly into the doc and use MathType's TeX toggle function
(that's also a useful method for a blind user producing content). Then
one simply exports the page as XHTML+MathML, which takes all of two or
three extra clicks. So, not a big deal really.
In California they even train folks in the prisons to create content
this way:
http://www.washington.edu/doit/articles?400
You can also get MathML "into" and "out of" PDF documents. MathPlayer
can read it, but Adobe needs to work on the authoring end to make this
easier. I am sure Andrew can address that issue...
Best regards,
--Steve
------------------------------------
-- Steve Noble
Chair, National Technology Task Force
Learning Disabilities Association of America
= EMAIL ADDRESS 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 ADDRESS REMOVED = > 11/17/2010 3:54 PM >>>
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 ADDRESS REMOVED =
>>> On 11/17/2010 at 11:50 AM, in message
< = EMAIL ADDRESS REMOVED = >, Stephen L Noble
< = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
From: Jason Kiss
Date: Wed, Nov 17 2010 3:21PM
Subject: Re: Screen readers, math symbols, and Word
← Previous message | Next message →
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 (≥) or numeric reference
(≥) 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 ADDRESS REMOVED =
>
>
>>>> On 11/17/2010 at 11:50 AM, in
>>>> message< = EMAIL ADDRESS REMOVED = >, Stephen L
>>>> Noble< = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>
From: Cliff Tyllick
Date: Wed, Nov 17 2010 4:27PM
Subject: Re: Screen readers, math symbols, and Word
← Previous message | Next message →
Jason, I noticed unusual behavior in Acrobat Reader's Read Out Loud, too: It skipped over the Unicode character when reading the page, but when I selected the Unicode character (remember, this is "is greater than or equal to" we're talking about), Read Out Loud announced "equals."
So it seems Adobe has two problems:
- Get the right meaning, which, as we've discussed, will take outside cooperation.
- Get the right behavior. I guess I could learn to follow along and quickly select each mathematical symbol just before it's announced, but it would be somewhat more challenging for most people who actually need the screen reader. ;-)
Also, inserting a graphic with "is greater than or equal to" as its alt text didn't work as smoothly as I had hoped. Even though we inserted it inline with text in Word, in the reading order in the PDF it comes *after* the text. So, for example, "2 [>= symbol] 1" was read by Read Out Loud as "2 [pause] 1 [pause] is greater than or equal to."
I've sent the same files to someone who volunteered to check them with JAWS, NVDA, and one or two other screen readers, so we'll see what happens there.
Cliff
Cliff Tyllick
Usability assessment coordinator
Agency Communications Division
Texas Commission on Environmental Quality
512-239-4516
= EMAIL ADDRESS REMOVED =
>>> On 11/17/2010 at 3:47 PM, in message < = EMAIL ADDRESS REMOVED = >, Jason Kiss < = EMAIL ADDRESS REMOVED = > wrote:
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 (≥) or numeric reference
(≥) 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 ADDRESS REMOVED =
>
>
>>>> On 11/17/2010 at 11:50 AM, in
>>>> message< = EMAIL ADDRESS REMOVED = >, Stephen L
>>>> Noble< = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>
From: David Farough
Date: Thu, Nov 18 2010 1:48PM
Subject: Re: Screen readers, math symbols, and Word
← Previous message | Next message →
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 ADDRESS REMOVED =
Tel. / Tél: (613) 992-2779
>>> Jason Kiss < = EMAIL ADDRESS 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 (≥) or numeric reference
(≥) 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 ADDRESS REMOVED =
>
>
>>>> On 11/17/2010 at 11:50 AM, in
>>>> message< = EMAIL ADDRESS REMOVED = >, Stephen L
>>>> Noble< = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>
From: Jason Kiss
Date: Thu, Nov 18 2010 2:27PM
Subject: Re: Screen readers, math symbols, and Word
← Previous message | Next message →
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 ADDRESS REMOVED =
> Tel. / Tél: (613) 992-2779
>
>>>> Jason Kiss< = EMAIL ADDRESS 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 (≥) or numeric reference
>
> (≥) 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 ADDRESS REMOVED =
>>
>>
>>>>> On 11/17/2010 at 11:50 AM, in
>>>>> message< = EMAIL ADDRESS REMOVED = >, Stephen L
>>>>> Noble< = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>>
From: David Farough
Date: Thu, Nov 18 2010 2:48PM
Subject: Re: Screen readers, math symbols, and Word
← Previous message | Next message →
There is a help topic on this in Jaws. If you want I can copy it to the
list. I believe I found it by searching for symbols in the search tab
of the file.
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 ADDRESS REMOVED =
Tel. / Tél: (613) 992-2779
>>> Jason Kiss < = EMAIL ADDRESS REMOVED = > 04:24 PM Thursday,
November 18, 2010 >>>
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 ADDRESS REMOVED =
> Tel. / Tél: (613) 992-2779
>
>>>> Jason Kiss< = EMAIL ADDRESS 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 (≥) or numeric
reference
>
> (≥) 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 ADDRESS REMOVED =
>>
>>
>>>>> On 11/17/2010 at 11:50 AM, in
>>>>> message< = EMAIL ADDRESS REMOVED = >, Stephen L
>>>>> Noble< = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>>
From: Stephen L Noble
Date: Thu, Nov 18 2010 3:12PM
Subject: Re: Screen readers, math symbols, and Word
← Previous message | No next message
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 ADDRESS 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 ADDRESS REMOVED =
> Tel. / Tél: (613) 992-2779
>
>>>> Jason Kiss< = EMAIL ADDRESS 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 (≥) or numeric reference
>
> (≥) 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 ADDRESS REMOVED =
>>
>>
>>>>> On 11/17/2010 at 11:50 AM, in
>>>>> message< = EMAIL ADDRESS REMOVED = >, Stephen L
>>>>> Noble< = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>>