Major accessibility regression in V3

[NSoiffer]

The accessibility features in V2 worked really well. I recently had the need to refresh my memory about some math content and found maybe 80% of the pages or more that I clicked on had accessible math thanks to MathJax. Images and PDFs are rapidly becoming a thing of the past. That great success is greatly endangered by V3. To be blunt, V3 is an accessibility disaster. Let me walk through why:

1. Out of the box, V3 is not accessible. Requiring people to turn on accessibility is a big no-no. First off, most people won’t know they need to do that, let alone how to do it. And without that knowledge, the page is not accessible.

2. If they somehow know they need to turn it on by using the context menu for math, doing so is difficult for screen reader users. I’m told that bringing up a context menu is something that only advanced screen reader users know how to do, so for a large number of screen reader users, they will require help from sighted users anytime they encounter a new site (assuming someone told them they need to turn on accessibility). The menu itself is accessible, but getting that menu to come up is the problem.

3. Once those barriers are crossed, the math still doesn’t read. You get a notification “clickable: <first char of math>”. No indication this is math and no smooth reading. Imagine if you had a page that had images in it and you had to click on the image to see it. That’s the experience screen reader users face in V3.

4. With NVDA and JAWS, I only occasionally got the math to read. Mostly (>90% of the time), I just heard the characters in the math. I tired both ‘enter’ and ‘space’ in both Chrome and Firefox. Maybe the focus wasn’t really on the math (despite it reading the characters), maybe it was some other mistake I made. If I made the mistake most of the time, I suspect others will make it also (some experts I consulted concurred that they had problems hearing the expression as math). That’s another accessibility barrier.

5. Even when it does read, it is an inferior experience to what V2 users had with NVDA. There is no prosody and the “a” sound is at the mercy of the speech engine, which will usually use the short “a” sound (e.g, “ah squared”). JAWS has this same (lower quality) reading experience, but for NVDA users, this is yet another regression.

I want to be clear that I am not criticizing SRE. The problem is the way in which accessibility is exposed by V3 -- it is not on by default, not easy to turn on, somewhat inconvenient to use, and flaky once turned on. Taken together, all the accessibility experts I consulted consider this to be a major regression compared to V2.

My suggestion is to do two things:

1. By default, put the hidden MathML back into the document as in V2. This gives out of the box accessibility to NVDA, JAWS, and VoiceOver users. That accessibility is in most ways superior to V3 for the reasons given above.

2. Add a ‘use Native speech’ option to the accessibility menu. If a screen reader user figures out how to activate the MathJax’s native speech (which should remove the MathML) and didn’t like the MathJax solution, the new menu item would give them a way to revert to V2 behavior.

I have a third suggestion that is somewhat independent of the above and was (I think) true for V2: make sure all the example configurations on mathjax.org and in the documentation are ones that result in accessible math out of the box unless specifically noting that they are not. Because V3 is not currently accessible, authors making use of V3 won't know that the pages they produce are not accessible.

[zorkow]

Could you please clarify what you mean by:

The accessibility features in V2 worked really well.
[...]
Requiring people to turn on accessibility is a big no-no.

I assume you are not referring to MathJax v2's Accessibility Extension, as that always had to be switched on explicitly, via the context menu, which apparently is a "no-no".
Are you therefore referring to how some of the screenreaders were accessing information from v2?

In that case I am confused about how you are raising the matter here. For two years we have been very open about the fact that v3 is a full re-implementation and that the API will change, which might break how other systems use MathJax. In fact, I was very vocal at all the relevant meetings (CSUN, AIM, etc.) about the need to for screenreaders to adapt. We have put out multiple beta version, for over a year now.
So frankly I am quite surprised that nothing had been done about adapting the interfaces or that no-one has even bothered to test until now.

We are certainly willing to discuss with all the stakeholders what can be done. But I am afraid we do not have the resources to support legacy tricks of other systems.

[NSoiffer]

The issue is that hiding MathML in output was on by default in V2 and is no longer on by default in V3. The hidden MathML is how JAWS, NVDA, and VoiceOver made the math accessible. They never interacted with MathJax via any MathJax configuration, so I'm baffled what you expected that they will change.

Because the MathML is not present in V3, there is no out of the box accessibility. Having to turn on accessibility is not acceptable, and even if you thought it was, it is not easily discoverable nor easy to do in V3.

Putting hidden MathML into the document is hardly a major resource issue.

[sinabahram]

I think this is pretty critical. This is the fundamental difference. When V2 was/is used, I can go to a page, and the math is accessible with NVDA, Jaws, and VoiceOver. With V3, not only is the math completely inaccessible and a jumbled together mess of characters in the DOM, but the menu affordence is completely not surfaced what-so-ever in any way, shape, or form. There's zero notification on any AT we tested over here, as far as screen readers go, and I would wager magnification and speech input software as well, that a menu is even available. Even if that was surfaced, how to actuate said menu becomes a concern (for example, I repeatedly have to make sure it gets into forms mode), and the lack of having access to the MathML in the DOM means that the most successful way of accessing the math is completely unavailable to screen reader users.

In short, this makes math on the web less, not more, accessible out of the box, at least in my and others' testing with the popular combinations of screen readers and browsers.

Now, as for enabling accessibility. This is a matter of equity, inclusion, fairness, and appropriateness. As a community, I would hope we all agree that forcing someone to turn on accessibility when it could be surfaced by default is a major issue, especially if this needs to be done on a repeated basis. That's not fair nor inclusive.

Lastly, there's a privacy concern here because forcing enabling of accessibility, by definition, forces mandatory disclosure of disability, which again is not right nor fair; whereas, if the MathML is in the DOM, hidden or otherwise, then the AT usage status of the visitor cannot be determined, as far as I know.

[zorkow]

But the AssistiveMML.js was always a temporary measure and it does not exist as such in v3.
Please see the documentation here for details.

Due to the modular nature we can't really guarantee that a MathML output jax is even in the page.
So this legacy model is not a robust solution.

[zorkow]

@sinabahram you are absolutely right. Currently the announcement re content menu did get lost from v2 to v3. This is addressed in the next point release.

But again a robust solution for all would be good. Having an attribute with a hidden MathML was never ideal, even if it can be generated, and we should come up with an alternative.

[sinabahram]

Maybe we should come up with an alternative (happy to discuss/explore), but can we please restore that functionality while this happens? Otherwise, this is substantially, and I really do mean substantially worse, in every single way. I’ve come across several websites using V2, and I’ve been blown away that I can just read and understand the mathematics. That is game-changing. It is actually impossible to exaggerate how useful, effective, and amazing that is. Not perfect, perhaps, but orders of magnitude better than some jumbled characters in the DOM. Losing that access would be heart-breaking.

[jasonjgw]

If I test the live demonstration at mathjax.org using JAWS 2020, I find that the SRE rendering of the expression is present in the document - at the end of the page, presumably in DOM order - but it is not spoken automatically. So, I concur with @sinabahram that this is a regression from the end user's perspective - and I stress the need for a viable solution that doesn't require the user to access a context menu just to read the content.

[zorkow]

Maybe we should come up with an alternative (happy to discuss/explore), but can we please restore that functionality while this happens? Otherwise, this is substantially, and I really do mean substantially worse, in every single way.

We can probably include a temporary solution for tex-mml-chtml. That should help in the majority of cases, but if authors use something else it might not. Or we can just switch on accessibility by default.

@jasonjgw What you are probably seeing is the live region after switching on the a11y extension.

[sinabahram]

if this is enabled by default, then that sounds like a step in the right direction. Happy to help test/verify.

[jasonjgw]

Moving focus to a mathematical expression with tab navigation didn't present the live region. This may be a browser or screen reader-specific issue, of course. Also, users won't typically move focus to each expression - even if it's in the navigation order. They'll expect customary screen reader reading and navigation commands to work correctly.

[NSoiffer]

@zorkow: adding hidden MathML to tex-mml-chtml is a very good start. The other thing that has to happen is the documentation needs to warn authors that other solutions are not currently accessible and to make their pages accessible, they need to add the code in http://docs.mathjax.org/en/latest/output/mathml.html#assistivemml (or a better method if you have one).

[sinabahram]

Yes, I completely agree with this. In addition to there being essentially junk in the DOM, moving focus to it does not seem to achieve anything useful, and it’s technically a violation of expectations and best practices and WCAG, because there’s nothing actuated there. It’s not a link, nor a button, nor a form element of any kind, at least not reported as such with NVDA, Jaws, etc., so it being focusable is a technical violation, IMHO.

[zorkow]

It's not junk. It's effectively the math and the aria label should be read. So you will get at least the math text even if there is no MathML. There's a bug, which means it is not exposed correctly on some elements, which is fixed in PR mathjax/MathJax-src#355
Space opens the content menu and return the live region, hence it's focusable.

... I still wish some people would have tested the beta ...

[NSoiffer]

I know you went to lots of conferences and talked about accessibility, but I don't know how many people realized how major a change V3 was. I thought perhaps I just spaced out about those changes, but I just did a search through my email and on google groups (both mathjax-dev and mathjax users) and I don't see a discussion of the changes or a call for accessibility testing. That's something that could be improved. I certainly would have tried it out sooner had I seen a request or realized the major change -- I only tested it now and reached out to others to verify the problems after someone told me last week that V3 had dropped MathML and might not be accessible.

[jscholes]

Space opens the content menu and return the live region, hence it's focusable.

I don't understand why opening a menu would have anything to do with a live region. Could you clarify the meaning of the word "return" in this context?

The math is focusable, but it only has an accessible role of "section". That is not an interactive role, meaning that users will not expect interacting with it to do anything. No instructions are available, programmatically connected to the element or otherwise, to indicate anything to the contrary. This is a WCAG violation, failing at least SC 4.1.2 and SC 3.3.2.

The fact that the math is rendered in some form or another doesn't change any of the above. A screen reader announcing a bunch of numbers and symbols doesn't in any way flag the availability of a menu, nor is the current rendering in speech particularly understandable. If users navigate using a screen reader's virtual cursor, which is by far the most common paradigm, in Chrome and Firefox they will encounter each character of the math on its own line. This will only serve to drive the idea that this is a single focusable element further from users' minds.

[NSoiffer]

@zorkow: In addition to adding hidden MathML to tex-mml-chtml, I think you should add it to tex-chtml.html also. Sites like stackexchange have users type input, so they only need to process TeX input. Currently, stackexchange uses TeX-AMS_HTML-full. I think that the V3 equivalent would be tex-chtml.html. Please correct me if I'm wrong/if you feel a different package is appropriate.

[sinabahram]

I have to say, I also don’t have any emails asking me to test this. It’s completely possible that I missed something, but I assure you that realizing no more math is imbedded in the page was startling enough that I absolutely know I would have dropped everything to talk about it, and I just don’t remember ever knowing/realizing/understanding that.

[zorkow]

@jscholes Usually nodes should have role=presentation. Only if the a11y extension is switched on, you get role=application and can browse the expression. That's where the live region exposes speech. But the correct root node somehow got lost during rendering (including most embarrassingly the aria-hidden). This corresponds to the v2 behaviour.
But that will be restored in the next point release.

[NSoiffer]

Will hidden MathML make it into tex-mml-chtml and tex-chtml.html so the math will be accessible out of the box in the next point release?

[avneeshsingh]

As @NSoiffer described, I found that behaviour of JAWS with MathJax 2 much better. The hidden MathML is read fluently by JAWS. While in MathJax 3.0 JAWS does not read MathML because this feature is no longer available and it is not straight forward to activate the accessibility menu and use MathJax accessibility features with screen readers. It would be much better to activate the hidden MathML in MathJax 3 till the issues discussed in this thread are fixed.

[dpvc]

@NSoiffer, we are looking into adding it back in the next release. It can be included in all the combined components (like tex-chtml.js and mml-svg.js) and as a separate component that be loaded as part of a custom configuration.

[sinabahram]

Sorry if I’m misunderstanding, but does this mean that authors will need to explicitly do something to make this happen?

[dpvc]

@sinabahram, no, it will be part of the usual configuration files that people will load, but will also be available for those who are loading individual components separately rather than one of the all-in-one combined components.

[NSoiffer]

@davide P. Cervone <dpvc@union.edu> : Great to hear. Hopefully anyone using V3 now will update so sites go back to being accessible. At least for the sites I encountered, no one had made the switch to V3 yet, but I suspect many places are internally considering it/working on the switch. I'm sure you know much more than I do about major site plans though. Again, thanks for the quick action once the problem was raised.

…

On Thu, Dec 12, 2019 at 9:09 AM Davide P. Cervone ***@***.***> wrote: @sinabahram <https://github.com/sinabahram>, no, it will be part of the usual configuration files that people will load, but will also be available for those who are loading individual components separately rather than one of the all-in-one combined components. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2260?email_source=notifications&email_token=AALZM3CUXUCGXMAUD4N4IPDQYJV3XA5CNFSM4JYN54MKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGXLIVA#issuecomment-565097556>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALZM3G7XWAC7O7M3THJC3LQYJV3XANCNFSM4JYN54MA> .

[sinabahram]

This is great news. Can’t wait to test.

[dpvc]

@NSoiffer, the examples our documentation for v3 all use the "latests v3 version" URL of cdn.jsdelivr.net/npm/mathjax@3/es5/..., so if they are using that, it will get the most up-to-date version automatically when it is released.

I'm currently at an AIM conference, so have been pretty booked up all day, and haven't been able to be involved in the conversation (or on making changes until I get back next week).

[RichCaloggero]

I think that IMO, MathJax native accessibility has improved greatly in this version of MathJax. There are issues, but I believe they are easy to fix as explained below. I'll be happy to do additional testing, or help in any way I can.

I believe the main issues here are these:

1. accessibility is not turned on by default
2. expression speech is not surfaced by default

Number 1 above has been discussed at length here already. I'll try to explain what I mean by number 2 above...

Each expression is exposed as a tree of custom elements: the outermost is mjx-container, and the next level down is mjx-math. The mjx-container elements have a tabindex of 0 and the mjx-math elements are effectively the top level of the expression tree. Each tree node contains a data-semantic-speech attribute which contains a string of text which present speech based on that element's position in the tree. The mjx-math elements contain the entire speech of the expression; and leaf nodes, such as the identifiers, contain only the text which represents their name (i.e. "b" or "x", etc).

The issue for screen readers is that when you tab to an mjx-container element, you do not hear the speech for the expression, and with NVDA at least, you need to forceibly turn off virtual / document reading mode in order to interact with the tree.

However, I think a fix is fairly straightforward:

• add a role which automatically disables document mode to the mjx-container elements (a role of "tree" does this)
• add an aria-label attribute to each container element whose value is the value of the wrapped mjx-math element's data-semantic-speech attribute (i.e. the speech for the full expression)
• add aria-hidden="true" to the wrapped mjx-math elements
• possibly add a aria-roledescription to the container whose value indicates that this is a math (or possibly mathjax) expression

You can see this working here:
https://RichCaloggero.github.io/test/mathjax-test.html

Notes

• you need to turn on accessibility by tabbing to an expression, opening context menu, and choosing accessibility / activate
• I needed to add a substantial delay via setTimeout to the script that modifies the MathJax output. If this were being implemented natively via MathJax itself, this would not be necessary.
• I also needed to remove the async attribute from the mathjax script element

There is a chance that the delay isn't long enough, in which case you'll need to download the file and play with it locally.

I hope this helps push this forward. I think the native accessibility in MathJax is well done; just needs to be polished a bit and enabled by default.

[zorkow]

Thanks @RichCaloggero, in particular for preparing the example.
The aria-hidden and role attributes will be back in v3.0.1.

We had decided against switching on accessibility by default, as there is considerable extra code that needs to be loaded over the network. And since speech can only be generated once accessibility is switched on it, it is currently not surfaced by default.

For v3.0.1, we have solved the main performance issue for starting speech. But I am currently still working on minimising what needs to be sent for SRE to work and generate speech. This will probably only make it into v3.0.2 the earliest.

[jscholes]

@dpvc I'm not convinced this can be closed and marked as fixed. The most recent comment from @zorkow seems to suggest that accessibility is still not enabled by default, which is not an appropriate way forward. In addition, @NSoiffer and @sinabahram have not been give a chance to weigh in on the current state of accessibility.

[dpvc]

Sorry, was making global changes to the issues and didn't look carefully enough at them.

Volker's comment was about the v3.0.0 accessibility features, not the new assistive MathML extension that is in v3.0.1, and that is enabled by default. His comment refers to the SRE-based extensions, which are too expensive to have on by default, not the hidden MathML that we just added.

My understanding is that Neil's main complaint was about the missing hidden MathML. That is now back, and there is a menu item to turn that on and off (on by default). So the original complaint should be resolved. If there are additional issues with the new implementation, we should open a new issue to track that.

[sinabahram]

To clarify, the hidden MathML is on by default with the menu to turn it off, or is it off by default?

[dpvc]

@sinabahram, the menu item is "Include hidden MathML" and it is on by default. So the (visually) hidden MathML is in the document by default, but can be turned off by de-selecting that menu item. Sorry if I was not clear originally.

The MathJax web demos should show this. For example, this CommonHTML demo or this SVG demo.

[sinabahram]

The math does work with a screen reader on that page. I do notice that the math’s container has a tabindex of 0 and seemingly hard-coded style attributes, though?

[dpvc]

I do notice that the math’s container has a tabindex of 0

Yes, it has tabindex set to 0 because it needs to be able to accept focus to handle the MathJax menu. This was also present in the v2 output.

and seemingly hard-coded style attributes, though?

The style attribute includes the font scaling needed to match the math to the surrounding text, and position: relative that is added by the assistive MathML extension so that the hidden MathML can be positioned relative to the math container (this allows readers like VoiceOver that highlight the MathML that is being read to have the highlighting that is (roughly) where the MathJax output is). The position:relative could probably be added to the main stylesheet, but not the font-size, which is dependent on the surrounding text. Both of these styles were present in the CommonHTML output of v2.

[sinabahram]

Thanks for the additional information. Please note, I have no general assertions about V2, so indicating that something was present then as well, doesn’t make it good or bad. It just makes it true that it was in V2, which is appreciated, as it helps provide context. The thing that caught my ear was that it was something with a presentation role, but with a tabindex of 0, which felt quite odd. If that is not causing focus or naming issues in browsers, then wonderful.

[dpvc]

@sinabahram, OK, thanks for the clarification. Since the original complaint was about changes from the v2 results and a request to return to the previous behavior, I was just trying to make it clear that these were the previous behavior.

I am not an AIRA expert, so a presentation role and tabindent of 0 don't strike me as odd, but that is how it has been in v2 for a long time, and it doesn't seem to have interfered with the focus in browsers, so I think that should be OK. I'm not sure what the naming issues are that you refer to.