Problem/bug report: Using MathJax plus MathPlayer with Read & Write Gold

[Noble,Stephen L.]

I am trying to resolve an issue when attempting to read math content served by MathJax with a synthetic speech application called Read & Write Gold by TextHelp. Information about this assistive technology can be found at http://www.texthelp.com/North-America/our-products/readwrite

 

I have not found an example of a MathJax page which will work correctly with Read & Write. To document the problem, I used the page

http://www.mathjax.org/demos/tex-samples/ and created a video showing what happens. The video is loaded at http://screencast.com/t/VR7tlrYUud

 

The problem is that the visual highlighting goes away when a math equation is encountered, and the math is not read correctly by the synthetic speech.

 

I am using IE 8 and MathPlayer 3 on a Vista computer, along with RWG 9.

 

After consulting with Neil Soiffer at Design Science he stated:

"I thought Davide worked on this.  I remember both Robert and I came up with web pages where MathJax hid the math.  Perhaps there is some MathJax setting that needs to be done."

 

Let me know what further information is needed, or if I should try something on my end.

 

Thanks much,

 

--Steve Noble

 

------------------------------------

-- Steve Noble

Chair, National Technology Task Force

Learning Disabilities Association of America

steve...@louisville.edu

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.

 

 

[Davide P. Cervone]

I will have to check into it, but don't know that I will be of much help.  It looks like RWG is supposed to know how to talk to MathPlayer to read the math, but that isn't happening.  Do you know if this works for you if MathJax is not involved (i.e., on a page with MathML that doesn't load MathJax)?  I'm wondering if RWG doesn't interface properly with MathPlayer3; have you tried it with MathPlayer2.2?

As for highlighting, since MathPlayer is displaying the mathematics in this case, RWG would have to communicate with it about highlighting what is being spoken.  I'm not sure what MathPlayer is capable of in this respect, but since it doesn't seem RWG is talking to MathPlayer, that clearly isn't happening.

I'm not sure what Neil has in mind by "hiding the math"; MathJax does not do anything special to mark the math in its NativeMML output is used (though it does mark the output of its HTML-CSS output so that an alttext is used, if there is one, but most ages don't include this).

If you are able to create your own pages for testing purposes, you might want to try using the Accessible configuration and see if that helps.  This will prevent MathJax from using part of its user interface that is known to confuse some screen readers.  That might be interfering with RWG.

Davide

[Noble,Stephen L.]

RWG has supported MathPlayer for many years now, and works just fine with web pages containing math (e.g., XHTML+MathML). RWG works fine with either MP 2.2 or MP 3. I have been working closely with Neil Soiffer and the developers of RWG on testing and feedback for several years. The developers of RWG (TextHelp) have also tested MathJax pages with the standard shipping version of MathPlayer (2.2) and have confirmed the same "broken" behavior.

 

I went through my email and found this from Robert Miner. Perhaps this will give you more of a lead?

---

When I last tried to figure this out, it looked to me like it was something about the mathjax.org page template that was screwing things up. The way I remember it was that if I had a plain black on white HTML test page it worked fine.  Thus, I don't think it was anything to do with MathJax configuration per se.  But Neil remembers it differently.

 

A slightly more technical answer is that when there is an invisible layer in the HTML over a MathJax equation, clicks and AT software go to that layer (since it is on top) and don't see the math.  MathJax's own menu is such a layer, and so the configuration setting in question is to disable that so that clicks and AT software see right through to the MathPlayer equation. 

 

But no one has ever really gotten to the bottom of whether it is some interaction between MJ and the mathjax.org template that causes a layer to obscure the math, a MJ bug, or just something pathological about the mathjax.org template. I suppose it is on me to either debug it or find someone who can, and empower them to do so by lining up access to all the bits and pieces.

---

 

Does this help?

 

Can you point me to a site using the "accessible configuration" you mention. Why wouldn't the mathjax.org website be created with an accessible configuration? How can I persuade vendors to use MathJax for accessibility if the MathJax website itself in not accessible??

 

--Steve Noble

[Davide P.Cervone]

On Nov 18, 2011, at 9:33 AM, Noble,Stephen L. wrote:

RWG has supported MathPlayer for many years now, and works just fine with web pages containing math (e.g., XHTML+MathML). RWG works fine with either MP 2.2 or MP 3. I have been working closely with Neil Soiffer and the developers of RWG on testing and feedback for several years. The developers of RWG (TextHelp) have also tested MathJax pages with the standard shipping version of MathPlayer (2.2) and have confirmed the same "broken" behavior.

 

I went through my email and found this from Robert Miner. Perhaps this will give you more of a lead?

---

When I last tried to figure this out, it looked to me like it was something about the mathjax.org page template that was screwing things up. The way I remember it was that if I had a plain black on white HTML test page it worked fine.  Thus, I don't think it was anything to do with MathJax configuration per se.  But Neil remembers it differently.

 

A slightly more technical answer is that when there is an invisible layer in the HTML over a MathJax equation, clicks and AT software go to that layer (since it is on top) and don't see the math.  MathJax's own menu is such a layer, and so the configuration setting in question is to disable that so that clicks and AT software see right through to the MathPlayer equation. 

 

But no one has ever really gotten to the bottom of whether it is some interaction between MJ and the mathjax.org template that causes a layer to obscure the math, a MJ bug, or just something pathological about the mathjax.org template. I suppose it is on me to either debug it or find someone who can, and empower them to do so by lining up access to all the bits and pieces.

---

 

Does this help?

I don't think it is the mathjax.org configuration.  Robert's second paragraph is more likely the issue.  The "configuration setting" that Robert mentions is the showMathMenuMSIE parameter in the NativeMML block of the configuration, which prevents MathJax from using its overlay, and so should expose MathPlayer to the screen reader.  The Accessible configuration has showMathMenuMSIE:false for this reason (and that is pretty much the only difference between it an the TeX-AMS-MML_HMTLorMML configuration.

Can you point me to a site using the "accessible configuration" you mention.

Use "config=Accessible" on the script that loads MathJax.js.  For example:

<script type="text/javascript" src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=Accessible"></script>

Why wouldn't the mathjax.org website be created with an accessible configuration? How can I persuade vendors to use MathJax for accessibility if the MathJax website itself in not accessible??

The problem is that MathPlayer does not handle user interface events in the same way that normal DOM elements do.  That is, for a regular DOM element, you can attach event handlers that will fire when those events occur, and can override the default actions of the events.  While MathPlayer does allow you to add event handlers to the <math> element, unfortunately it does not respect the settings that prevent the default action or cancel the bubbling of the event.  For example, MathJax has its own contextual menu for all mathematics it processes, and while you can attach a handler for the contextmenu event, MathPlayer will post its own menu regardless of whether the event handler does any of the htings that should prevent the default action.  Similarly, you can't override MathPlayer's click action, so MathPlayer will produce a zoomed version even if MathJax's zoom trigger is turned off.

in order to overcome this, MathJax is forced to use an invisible element over top of the MathPlayer output in order to trap the events before MathPlayer sees them, and pass through the ones that MathJax doesn't care about.  This allows MathJax to have its contextual menu, and to handle zooming and other settings in a way that is consistent across browsers and regardless of the renderer used.  Unfortunately, this also has the consequence of confusing some screen readers, which apparently check what element would be clicked on at a certain location in order to decide what to read.  Personally, I think that's a bad idea, but I'm sure I don't know all the issues underlying that approach.  So what that means is that having MathJax's normal user interface is incompatible with some screen readers when MathPlayer is in use.  Because of this, the showMathMenuMSIE flag is available, but that turns off the MathJax interface, which is not something we want to do by default.  Unfortunately, there is no easy way for the user to set this flag at the moment, and so it is not easy to make things accessible if they aren't set up that way initially.

There is a second issue as well, which is that there is a bug either in IE or MathPlayer itself (I can't tell which) that causes MathPlayer to malfunction and IE to crash if the information needed to set up MathPlayer is added to the page dynamically rather than being a part of the page initially.  Since MathJax sets up MathPlayer, it does so dynamically, and that triggers the conditions for the bug.  It turns out that if MathPlayer is set up this way, then any user input (clicking on the math, using the MathPlayer contextual menu) will cause IE to crash when you close the window or move to another page.  But if there is no user interaction, everything is OK.  This is the other reason that MathJax traps mouse events and doesn't pass them on to MathPlayer.  Without this, IE will crash too often when MathPlayer is used.  

I haven't tested this with IE10, but some things I've seen on the network suggests that it might be resolved in IE10.  I also haven't tested it with MathPlayer 3, which uses a different mechanism for inserting itself into the page, so perhaps this will not be a problem with the new MathPlayer.  

So for these reasons, www.mathjax.org does not disable the contextual menu overlay in IE.  This does have a negative impact on screen readers, but I don't really see a viable alternative at the moment.  I had asked you to check it with the Accessible configuration in order to verify that it really is the overlay that is causing the problem for RWG, since I don't have the software to test with myself.

I hope that helps clarify the situation.

Davide

[Noble,Stephen L.]

Hi Davide,

 

Thanks for taking the time to look into this. A few follow-up questions:

 

1) It sounds like no one knows of a single web site which uses the "accessible configuration" for MathJax which you mention. Since the MathJax.Org website makes a selling point about the accessibility of MathJax, why don't we have at least one example of such an "accessible configuration"? I strongly urge that one such example page is added to the "Demos" menu.

 

When you say…"So for these reasons, www.mathjax.org does not disable the contextual menu overlay in IE.  This does have a negative impact on screen readers, but I don't really see a viable alternative at the moment"...it almost sounds like you are saying that it is impossible for *any* site to use an accessible configuration (without encountering major instability and performance issues) because of the problems you cite. If that is true, then the ramifications of this problem are much bigger than I had initially thought.

 

2) You suggested that I…" Use "config=Accessible" on the script that loads MathJax.js.  For example:

 

            <script type="text/javascript" src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=Accessible"></script>

 

I am not sure that I understand what you are telling me to do. Are you saying I should make a local copy of one of the MathJax demo pages on my PC, and then substitute the line in your example and try viewing the revised page locally?

 

--Steve

 

 

From: Davide P.Cervone [mailto:dp...@union.edu]
Sent: Thursday, November 24, 2011 1:13 PM
To: mathja...@googlegroups.com; Noble,Stephen L.
Subject: Re: Problem/bug report: Using MathJax plus MathPlayer with Read & Write Gold

 

On Nov 18, 2011, at 9:33 AM, Noble,Stephen L. wrote:

[Davide P. Cervone]

1) It sounds like no one knows of a single web site which uses the "accessible configuration" for MathJax which you mention. Since the MathJax.Org website makes a selling point about the accessibility of MathJax, why don't we have at least one example of such an "accessible configuration"? I strongly urge that one such example page is added to the "Demos" menu.

That is a good idea.  I'm also considering an "Accessibility" setting in the MathJax contextual menu so that users can switch the configuration on their own, so that they don't have to rely on the page author to set things up properly for them.

When you say…"So for these reasons, www.mathjax.org does not disable the contextual menu overlay in IE.  This does have a negative impact on screen readers, but I don't really see a viable alternative at the moment"...it almost sounds like you are saying that it is impossible for *any* site to use an accessible configuration (without encountering major instability and performance issues) because of the problems you cite. If that is true, then the ramifications of this problem are much bigger than I had initially thought.

It looks like IE10 may have resolved the problem (more work needed to test this).  I am also looking into using a different approach to setting up the MathPlayer associations that should avoid the problem for pages that include MathJax in the standard way (but will not work for those that load MathJax after the onload handler).  So perhaps the situation is not so dire, but yes, it is currently a serious issue.

2) You suggested that I…" Use "config=Accessible" on the script that loads MathJax.js.  For example:

 

            <script type="text/javascript" src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=Accessible"></script>

 

I am not sure that I understand what you are telling me to do. Are you saying I should make a local copy of one of the MathJax demo pages on my PC, and then substitute the line in your example and try viewing the revised page locally?

Yes, that should work, but it would be better to put it on a test website rather than a local file, if possible, since IE has some issues with cross-browser same-origin policy when the HTML file is a local one.  I don't think it will affect your test, but if there are problems, switching to a web site rather than a file:// URL might resolve them.

Davide

[Davide P. Cervone]

Steve:

I have been working on these issues for the MathJax v2.0 release.  It turns out that the problem with R&WG is not the overlay as I had originally suspected.  The problem in this case seems to be that R&WG requires the namespace used for MathML to be "m" and MathJax was using a different one.  I have switched it to m and it now works for me (even with the MathJax menu in place).  I have also added some menu items to that control the interaction of MathJax with MathPlayer, so a special Accessible configuration is no longer needed for that purpose (individual users can change the way MathJax interacts with MathPlayer if that interferes with their screen reader).  Finally, I have made changes that avoid the crashes that we were seeing after a user clicks on MathPlayer directly, without MathJax intercepting the events (the cost is that MathPlayer will be started when MathJax is loaded even if it is not actually used).  

So I think these issues should work more smoothly with MathJax v2.0.  I have tested this with JAWS and R&WG and it seems to work out of the box with both of those (no menu settings need to be changed).  The public beta of version 2.0 will be made available soon (perhaps as soon as this afternoon).  But there is a copy at

http://devel.mathjax.org/mathjax/dpvc/v2.0-candidate/Mathjax.js

that you could try out if you want to see if this works with your setup (using one of the standard configurations).  If you do, I'd appreciate hearing if this works better for you.

Davide

[Noble,Stephen L.]

Hi Davide,

This news is very encouraging! It sounds like there is hope to having this problem solved very soon.

I do not have access to a server for loading the beta version. But if you could point to a test page where the beta is being used I can certainly try it out with some AT.

I will pass the information about the public beta on to the publishers with whom I have been working.

Best regards,

--Steve Noble

---

From: mathja...@googlegroups.com [mathja...@googlegroups.com] on behalf of Davide P. Cervone [dp...@union.edu]
Sent: Friday, February 10, 2012 9:43 AM
To: mathja...@googlegroups.com
Subject: [mathjax-users] Re: Problem/bug report: Using MathJax plus MathPlayer with Read & Write Gold

[Peter Krautzberger]

Steve,

You could try

http://devel.mathjax.org/mathjax/dpvc/v2.0-candidate/test/sample.html

also the usual index.html, index-images.html, sample-mml.html, sample-dynamic.html sample-signals.html sample-dynamic-steps.html sample-tex.html are there.

Regards,

Peter.

[Noble,Stephen L.]

Thanks, Peter, for pointing me to the test examples.

Davide: My observations are that we are "almost there." I was able to get a degree of usability by using the MathJax context menu to serve the content as MathML (using IE8 plus MathPlayer), and then selecting the setting to let MathPlayer handle mouse events (or whatever the exact wording is). The problem I notice, though, is that Read & Write Gold will speak all the TeX code first before reading the MathPlayer text string, unless one moves the mouse directly onto the math equation. That is especially problematic with inline equations, since the literary text is interrupted with a string of TeX code before one hears the math.

Is there something I am missing...or maybe the changes you recently made are not yet reflected in the version of MathJax now running at http://devel.mathjax.org/mathjax/dpvc/v2.0-candidate/test/sample.html?

Thanks for your continuing progress on this matter.

--Steve Noble

---

From: mathja...@googlegroups.com [mathja...@googlegroups.com] on behalf of Peter Krautzberger [p.kraut...@googlemail.com]
Sent: Friday, February 10, 2012 3:35 PM
To: mathja...@googlegroups.com
Subject: Re: [mathjax-users] Re: Problem/bug report: Using MathJax plus MathPlayer with Read & Write Gold

[Davide P. Cervone]

My observations are that we are "almost there."

OK, good.

I was able to get a degree of usability by using the MathJax context menu to serve the content as MathML (using IE8 plus MathPlayer),

Yes, the test page forces HTML-CSS (but most sites will use a configuration that has IE/MathPlayer default to MathML output).

and then selecting the setting to let MathPlayer handle mouse events (or whatever the exact wording is).

With my demo copy of R&WG10 I didn't need to do that, but I don't know much about screen readers, so perhaps I was using it in a different way.  (I think I highlighted text and pressed a button to make it read the text.)  It sounds like you are having it read what you point at, so it makes sense that you would need to pass the mouse events to MathPlayer for that.  Can you tell me how you are using R&WG so I can test it the same way here?  Thanks.

The problem I notice, though, is that Read & Write Gold will speak all the TeX code first before reading the MathPlayer text string, unless one moves the mouse directly onto the math equation. That is especially problematic with inline equations, since the literary text is interrupted with a string of TeX code before one hears the math.

During preprocessing, MathJax usually sets up a preview that is the TeX code so that it is visible until the math is typeset.  After it is typeset, the preview is hidden by setting its CSS to include display:none; visibility:hidden (this is what the AT sites I looked at recommended, and this is what seemed to work for R&WG for me).  It sounds like R&WG is reading those previews despite their being hidden.

I have set up a new test page that doesn't generate the previews at

http://devel.mathjax.org/mathjax/dpvc/v2.0-candidate/test/sample-2.html

Can you try that out and see if that avoids the problem?

Davide

Is there something I am missing...or maybe the changes you recently made are not yet reflected in the version of MathJax now running at http://devel.mathjax.org/mathjax/dpvc/v2.0-candidate/test/sample.html?

No, you are using the correct version.  Let's see if the new sample helps.

Davide

[Noble,Stephen L.]

Davide,

First off...THANK YOU!!!

The test page now seems to be completely accessible with RWG. Getting rid of the TeX preview took care of the problem of the invisible TeX code being read.

I am using RWG 9 because our school test sites in Shelby County Kentucky are using that version. These days, schools rarely have the funds to update software as they should, and they simply could not afford the fees to update their site license this year. I don't know if RWG 10 performs better in this respect, but I'll also let TextHelp (the makers of RWG) know about the test page and have them give it a try.

RWG will only read math correctly using the "web highlighting" setting. Highlighting the text and pressing a button would probably only work with simple expressions containing common qwerty characters without superscripts, fractions, roots, etc. If you found it to work with RWG 10 without using the web highlighting setting, that would be interesting to know, because I wasn't aware that TextHelp actually addressed that issue.

When I tried out the page you had up first (before you took out the TeX preview)--without setting the MathJax context menu to let MathPlayer handle mouse and menu events--it would not read the expressions correctly. But I went back and turned the mouse and menu events setting off just now with the new page, it now reads correctly that way as well.

Actually, the only problem I can mention now is that the for some reason after RWG reads the inline equation example, the space between the previous word and the equation begins to grow at a regular rate and will over time expand to an extreme length. Here's a video example of what I am seeing on my end: http://screencast.com/t/gqw8JqReM9
I suspect that may be a quirk due to how RWG redraws the page to get highlighting. I wonder if you get the same results on your end?

Anyway...this is nothing short of fantastic.

I would be happy to garner further input on the accessibility improvements of the beta by asking the assistive technology community to try out this test page, if you think this is a useful juncture for that.
 
Thanks so much!

--Steve Noble

---

From: mathja...@googlegroups.com [mathja...@googlegroups.com] on behalf of Davide P. Cervone [dp...@union.edu]

Sent: Friday, February 10, 2012 4:36 PM

To: mathja...@googlegroups.com
Subject: Re: [mathjax-users] Re: Problem/bug report: Using MathJax plus MathPlayer with Read & Write Gold

[Davide P.Cervone]

First off...THANK YOU!!!

You're welcome.  I'm glad this is working better for you.

The test page now seems to be completely accessible with RWG. Getting rid of the TeX preview took care of the problem of the invisible TeX code being read.

This is an author-level change (so you can set up your owen pages to prevent previews), but it is not something that can be controlled by the user, and most pages on the web that use MathJax will have them.  I personally consider this a bug in R&WG, since they should NOT be reading elements that have display:none or visibility:hidden (and certainly not both).

RWG will only read math correctly using the "web highlighting" setting. Highlighting the text and pressing a button would probably only work with simple expressions containing common qwerty characters without superscripts, fractions, roots, etc.

It is not the version that it based on a screen image analysis, but I think the same thing you are talking about (the words are highlighted as it reads, even in the mathematics).  That seems to work fine for me in R&WG10 without having to change the MathPlayer settings in MathJax.  But I just tested it again, and even version 10 reads the preview (despite being display:none and visibility:hidden).  I could have sworn that adding visibility:hidden had made that work, but I must had the previews off during my tests, though I didn't think I had.  I have not been able to find a way to prevent R&WG from reading hidden text, so it appears that the only way to get R&WG to work with MathJax would be to remove (or not create) the previews, rather than just hide them as is the case now.

If you found it to work with RWG 10 without using the web highlighting setting, that would be interesting to know, because I wasn't aware that TextHelp actually addressed that issue.

Well, here is the setting that I used:

so web highlighting is not checked (but it appears to be working that way anyway, as I do see a yellow highlighting by sentence, and blue highlighting on the word being read).

What I do i highlight where I want the reading to begin, then press the green button, and it reads from there.  This seems to work (other than reading the previews).

When I tried out the page you had up first (before you took out the TeX preview)--without setting the MathJax context menu to let MathPlayer handle mouse and menu events--it would not read the expressions correctly.

It does for me in R&WG10.

But I went back and turned the mouse and menu events setting off just now with the new page, it now reads correctly that way as well.

OK great.

Actually, the only problem I can mention now is that the for some reason after RWG reads the inline equation example, the space between the previous word and the equation begins to grow at a regular rate and will over time expand to an extreme length. Here's a video example of what I am seeing on my end: http://screencast.com/t/gqw8JqReM9 
I suspect that may be a quirk due to how RWG redraws the page to get highlighting. I wonder if you get the same results on your end?

I tried the same example as you and do not see any extra spaces appearing, so it seems that this must be a R&WG9 issue that is fixed in version 10.

Anyway...this is nothing short of fantastic.

I'm glad you are happy with it.  I am still concerned about the previews, but don't yet know what the right solution is.  It is a R&WG bug in my opinion, but I don't know if MathJax should have a built-in option of removing the previews that the user can control.  Certainly we could make a bookmarklet that does that, but that would be an extra step for people.  I hate to start to add menu options to work around bugs in other software, as that could get out of hand quickly.  Let me think about what might be done.  But certainly for your OWN pages, you could prevent previews through the tex2jax{ preview: "none" } configuration setting.

I would be happy to garner further input on the accessibility improvements of the beta by asking the assistive technology community to try out this test page, if you think this is a useful juncture for that.

Sure, it would be great if other screen readers could test these two pages and see how they perform.  We have very little time to affect MathJax v2.0, however.  I am shooting for an official release next week or at latest the week after.

Davide

[Noble,Stephen L.]

Thanks, Davide.

I'll bring up the issues directly with TextHelp and see what they think. There are quite a number of AT applications now that can handle MathML content via IE+MathPlayer, so it would be good for me to have them take a look as well.

My primary concern is accessibility for publishers of educational content, not my own content, per se. If the tendency to read the hidden preview code is more widespread than just RWG, then it would be good to mention this problem on the MathJax pages which mention accessibility...but let me work on confirming if this is only a RWG problem (which they could fix on their end) or if it is something systemic about the way AT interacts with MathJax pages.

--Steve

---

From: mathja...@googlegroups.com [mathja...@googlegroups.com] on behalf of Davide P.Cervone [dp...@union.edu]

Sent: Saturday, February 11, 2012 12:20 PM

To: mathja...@googlegroups.com
Subject: Re: [mathjax-users] Re: Problem/bug report: Using MathJax plus MathPlayer with Read & Write Gold

[Davide P. Cervone]

It would also be nice if they honored the aria-hidden="true" attribute on a DOM element.  That would work just as well.

All the AT pages that I found indicated that display:none; visibility:hidden is the standard for telling screen readers not to read something.  I have tested with JAWS, and it does properly handle that, but that is the only other screen reader I've used.

I only have 10 days left on my R&WG demo copy.  If they want to give me a developer copy, I'd be happy to continue to work on testing it with MathJax.  :-)

Davide

On Feb 11, 2012, at 6:33 PM, Noble,Stephen L. wrote:

Thanks, Davide.

I'll bring up the issues directly with TextHelp and see what they think. There are quite a number of AT applications now that can handle MathML content via IE+MathPlayer, so it would be good for me to have them take a look as well.

My primary concern is accessibility for publishers of educational content, not my own content, per se. If the tendency to read the hidden preview code is more widespread than just RWG, then it would be good to mention this problem on the MathJax pages which mention accessibility...but let me work on confirming if this is only a RWG problem (which they could fix on their end) or if it is something systemic about the way AT interacts with MathJax pages. 

--Steve

---

From: mathja...@googlegroups.com [mathja...@googlegroups.com] on behalf of Davide P.Cervone [dp...@union.edu]
Sent: Saturday, February 11, 2012 12:20 PM
To: mathja...@googlegroups.com
Subject: Re: [mathjax-users] Re: Problem/bug report: Using MathJax plus MathPlayer with Read & Write Gold

First off...THANK YOU!!!

You're welcome.  I'm glad this is working better for you.

The test page now seems to be completely accessible with RWG. Getting rid of the TeX preview took care of the problem of the invisible TeX code being read.

This is an author-level change (so you can set up your owen pages to prevent previews), but it is not something that can be controlled by the user, and most pages on the web that use MathJax will have them.  I personally consider this a bug in R&WG, since they should NOT be reading elements that have display:none or visibility:hidden (and certainly not both).

RWG will only read math correctly using the "web highlighting" setting. Highlighting the text and pressing a button would probably only work with simple expressions containing common qwerty characters without superscripts, fractions, roots, etc.

It is not the version that it based on a screen image analysis, but I think the same thing you are talking about (the words are highlighted as it reads, even in the mathematics).  That seems to work fine for me in R&WG10 without having to change the MathPlayer settings in MathJax.  But I just tested it again, and even version 10 reads the preview (despite being display:none and visibility:hidden).  I could have sworn that adding visibility:hidden had made that work, but I must had the previews off during my tests, though I didn't think I had.  I have not been able to find a way to prevent R&WG from reading hidden text, so it appears that the only way to get R&WG to work with MathJax would be to remove (or not create) the previews, rather than just hide them as is the case now.

If you found it to work with RWG 10 without using the web highlighting setting, that would be interesting to know, because I wasn't aware that TextHelp actually addressed that issue.

Well, here is the setting that I used:

<R&WG.png>

so web highlighting is not checked (but it appears to be working that way anyway, as I do see a yellow highlighting by sentence, and blue highlighting on the word being read).

What I do i highlight where I want the reading to begin, then press the green button, and it reads from there.  This seems to work (other than reading the previews).

When I tried out the page you had up first (before you took out the TeX preview)--without setting the MathJax context menu to let MathPlayer handle mouse and menu events--it would not read the expressions correctly.

It does for me in R&WG10.

But I went back and turned the mouse and menu events setting off just now with the new page, it now reads correctly that way as well.

OK great.

Actually, the only problem I can mention now is that the for some reason after RWG reads the inline equation example, the space between the previous word and the equation begins to grow at a regular rate and will over time expand to an extreme length. Here's a video example of what I am seeing on my end: http://screencast.com/t/gqw8JqReM9 
I suspect that may be a quirk due to how RWG redraws the page to get highlighting. I wonder if you get the same results on your end?

I tried the same example as you and do not see any extra spaces appearing, so it seems that this must be a R&WG9 issue that is fixed in version 10.