# Revisit the aria values used for HTML-CSS and SVG output #893

Closed
opened this issue Aug 20, 2014 · 18 comments

Projects
None yet
6 participants
Member

### dpvc commented Aug 20, 2014

 We should re-evaluate the aria role and other aria attributes used in HTML-CSS and CVG output. Screen readers have improved in the years since we used those initial values, and they are really not the right ones.

Member

### pkra commented Aug 20, 2014

 cf. also #502
Member Author

### dpvc commented Sep 14, 2014

 I've removed the out-dated role="text box" and aria-readonly attributes, and instead added role="math". But I don't really have a good way to test any of this. The accessibility pages that I read also suggested using tabindex="0" so that screen readers can focus on the math, and I've added that, but I don't know if that is really a good idea or not. We really need to get some accessibility experts to advise us on this. The changes are in the issue860 branch of my fork of MathJax.

Member Author

### dpvc commented Nov 13, 2014

 ==> Merged (Nov. 2)

Closed

Member

### pkra commented Jan 7, 2015

 It looks like the CommonHTML output does not get these improvements.

### laurencedorman commented Jan 19, 2016

 Is there any way I could easily remove the tabindex=0 attribute? We use MathJax in multiple choice questionnaire forms and the fact that there is a tabindex=0 completely breaks the ability to keyboard navigate through the form.
Member

### pkra commented Jan 20, 2016

 @ld0rman There's no easy way. Could you share a live sample that exhibits the navigation problem?

### Alex-Just commented Jan 20, 2016

 Got the same problem. Example screenshot: I just don't want to confuse users with tab navigation through equations. Right now users are pressing TAB key to navigate through multiple input fields and it confuses them when focus stops on math text instead of the next input.

### laurencedorman commented Jan 20, 2016

 @pkra Here's an example : https://jsfiddle.net/aaLgznap/2/ I'm unable to show my exact problem, as it is in some unpublished code. In my situation the problem is more serious, but the example demonstrates the basic problem. I don't think that MathJax should be defining its level in the tabindex order, or if it does this should be optional as it is a global attribute.
Contributor

### christianp commented Jan 20, 2016

 I've noticed this as well. Numbas also has multiple choice questions which often have maths in labels. I'm not sure if it's as detrimental for me as @ld0rman says, but it's unexpected. There has to be a more precise way of saying "this element is something you should read in a certain way" without giving it a tabindex.
Contributor

### christianp commented Jan 20, 2016

 Looking at @dpvc's comment above, it seems the tabindex is just there so screenreaders can focus on maths. I suppose this might make sense for an equation on its own line, but for inline maths it's unhelpful. Maybe only display mode maths should get a tabindex? I'd prefer to let the page author decide, by wrapping maths in an element with tabindex.
Member Author

### dpvc commented Jan 20, 2016

 My comment above is quite old, and was before we added the assistive technology support. For keyboard users (those with motor limitations, for example), it is crucial that the math be focusable so that they can access the MathJax menu (for things like show source), and for the visually impaired so that screen readers are aware that there is a menu available and can access it. Page authors are, by and large, unaware of the needs of the disabled, and putting it in their hands means that most pages containing math will not be accessible to those who need assistance. No one is going to spend time adding ... around each inline equation. And for sites that use CMS that don't allow entering HTML directly, the authors may not be able to wrap the math in a tag with tabindex. This will only work for assistive technology if MathJax does it automatically. There has to be a more precise way of saying "this element is something you should read in a certain way" without giving it a tabindex. One would think, but since the math is both clickable and uses shift-space to activate its menu (that is accepts keyboard input), that means it must be focusable. And that means it must be in the tab sequence. Anything that gets keyboard input is supposed to be. One should note that there are things other than input fields that are in the tab sequence, like links and buttons. Anything that can be activated by keyboard is supposed to be. Since the math now can be "activated" by keyboard, it should be in the tab sequence. The best I can suggest is to allow an opt-out in the MathJax menu. An opt-in is not acceptable to the disabled community, as making such a choice indicates to the website that they are disabled, and they are very concerned about doing so.

### laurencedorman commented Jan 20, 2016

 @dpvc you obviously care a lot about the issue of accessibility, and as a collaborator you want to make sure that MathJax is as accessible as possible. I imagine it is must also be one of your wider aims to promote an accessible web in general. In my company, and on the new iteration of the website that I am currently helping to put into place, I am trying to achieve the same goals. This is in an environment where it is not necessarily easy to give accessibility the priority it merits. The current implementation of MathJax has been a hindrance and not a help to the realisation of these goals. Your comment gives me the impression that you are proposing solutions to end users, I am asking for a solution for developers, ideally something that I can pass to MathJax.Hub.Config() to disable this behaviour. I will of course, poke my nose into the code myself to propose something, when I have a moment.
Member

### pkra commented Jan 20, 2016

 @ld0rman thanks for the example. I can see how this navigation might be odd for casual users, especially since browsers differ in handling the tab order; Blink, WebKit, and Gecko seem to have a different (though consistent) strategy for it. @lDg5ixb thanks for the screenshot. As @dpvc already explained, the tab index is necessary for the accessibility of the menu. Removing it is therefore a really (really!) bad idea and we would strongly discourage anyone from doing so. However, we're always trying to be pragmatic; see #1352.

### laurencedorman commented Jan 20, 2016

 @pkra thanks, just to be perfectly clear, it's not that I want to remove it necessarily, it's more to be able to manage it myself. If I have a list with tabindex 1,2,3,4 and MathJax comes in the middle and places a 0 giving 1,0,2,3,4 - it is very difficult to manage this
Member Author

### dpvc commented Jan 20, 2016

 @ld0rman, thanks for your kind comments. Accessibility certainly is important to us, and we are trying to make it possible for those with special needs to have the same ability to interact with the math as everyone else. Of course, we want that experience to be as good as possible for everyone. The case where you are already setting tabindex for your own purposes is not one that I think we had in mind, and I can see where that could be a problem. Do you have any suggestions about how to resolve that? One possibility would be to include a function that specifies the tabindex value. The default would be to use 0 for everything, but you could override it to provide you own number, or number sequence. If you were to disable the tabindex as you suggest, how will your keyboard and screen-reader users be able to access the MathJax menu?
Member

### pkra commented Jan 20, 2016

 @ld0rman ah, that's a good use case. Can we move this discussion to the new issue?

Closed

Member

### pkra commented Feb 3, 2016

 We're close to wrapping this up, please comment on #1352 if you can.

### pwiegers commented Mar 27, 2016

 I also had trouble with this issue. For the moment, I "solved" it with a hack: MathJax.Hub.Queue ["Typeset", MathJax.Hub,"content"],-> \$('.MathJax').removeAttr('tabindex') As soon as MathJax signals it is done rendering, the code removes the tabindex attribute. Might nog be nice, but it works :-)