Make MathJax contextual menu properly accessible

[jcsteh]

The MathJax contextual menu inserts clickable divs at the end of the document, but it does not focus them in any way or expose semantic information. For screen reader users (and perhaps users of other assistive technology products), these are difficult to locate. Most users wouldn't even realise this menu had appeared, let alone know how to use it. This can all be fixed with ARIA and keyboard handling.

Things that need to be done:

• The menu items need to be focused. Either set tabindex="-1" for all menu items and focus the item or set tabindex="-1" on the root of the menu, focus that and set aria-activedescendant on it to indicate the active item.
• Menus need to be given an ARIA role of menu. Menu items need to be given appropriate menu item roles (menuitem, menuitemcheckbox, menuitemradio).
• There needs to be an appropriate hierarchical relationship between submenu items and their submenu. Either the DOM positioning needs to be changed or aria-owns needs to be used.
• Appropriate keyboard navigation needs to be implemented; e.g. up/down arrows to move between items, left/right arrows to enter/exit submenus, enter to activate an item.

/cc @pkra

[pkra]

Thanks of the feedback -- that's extremely helpful!

I'm wondering how the menu should be triggered, e.g., for users using keyboard navigation. Should it be permanently in the DOM? If yes, any particular position / markup to make it apparent?

Also, would you say http://adobe-accessibility.github.io/Accessible-Mega-Menu/ is a good resource?

[jcsteh]

I'm wondering how the menu should be triggered, e.g., for users using keyboard navigation.

Screen reader users can right click it easily enough. However, that's not true for keyboard users who aren't screen reader users. Perhaps the expression could be in the tab order and the context menu key (e.g. the Applications key/shift+f10 in Windows) could be intercepted to open it, just as right click does.

Should it be permanently in the DOM?

I don't think it should be, since it's meant to be a contextual menu and contextual menus aren't generally available until they're activated.

Also, would you say http://adobe-accessibility.github.io/Accessible-Mega-Menu/ is a good resource?

The problem with their solution is that they intentionally don't use the menuitem* roles. They want the items to be treated as links, but this causes screen reader to treat the content as a document instead of a menu. I'd probably recommend that you stick to the ARIA authoring practices for menus, which Adobe do reference.

[pkra]

Thanks for the additional info, @jcsteh, much appreciated!

[pkra]

Just some notes from other discussions.

• we probably need to disable outlines caused by adding equations to the tabindex (since browser do not honor clipping, making the outlines look extremely messy/irritating).
• so we need to provide a visual cue (maybe along the lines of the unfinished discvoerability UI).

[pkra]

Just to update this thread.

From #1242.

TODO

• I've introduced an abstract class with default methods of keyboard navigatable objects as a superclass of menu and item but reattached it as a field to MathJax.Menu, which is slightly awkward.
• Opening menu by keyevent (Space) enables left right navigation through Math element similar to a menu bar. Not sure if we want that. Maybe with a modifier key?
• On Chrome focusing seems to also cause scroll events if the menu is too large, which can cause awkward interactions with the mouse pointer. Not sure yet how to avoid this.
• I currently use the standard right-open/left-close paradigm for submenus. This can be visually confusing when the submenu opens to the left, but seems to be natural given that the pointer is announced as right pointer.
• I still need to deal with the case of rtl menus.
• Focus on popups is not yet correct. This is particularly not straight forward for windows showing code.
• Aria elements might still need refinement.

[pkra]

I believe we can close this as fixed by #1242

[pkra]

Or not?

[pkra]

In any case, I've updated the example from the #938 . Feedback would be welcome.

[dpvc]

I am not sure of the current state of affairs at this point. The accessible menu work that Volker did was about keyboard access to the menus. That certainly helps people who have difficulty with the mouse, and similarly helps the mobile users who don't have mice. My question is, does this help the screen reader folks, too, or is there still more to be done for that? My recollection was that there were aria tags specifically for menus (role="menu", aria-owns, aria-haspopup, etc.), and I don't recall that being part of what is included here.

Is there more to do, or are screen readers OK with what we have now?

[pkra]

Is there more to do, or are screen readers OK with what we have now?

We did not receive much feedback but I think we have accomplished what we set out so any remaining issues should be filed as a bug.

[dpvc]

So do we close this now or not? The OP discusses the attributes role, aria-activedescendent, aria-owns, etc., so that part of this issue hasn't been addressed.

[pkra]

@zorkow will know best. But IIRC, he followed http://www.w3.org/TR/wai-aria-practices/#menu (the roles are "may" but they might be nice).

In a quick test with NVDA and JAWS just now (IE9, 11 and FF40) I ran into trouble navigating the menu by keyboard. It worked fine without them so it might simply be my inexperience using screenreaders. E.g., NVDA uses the space bar so opening the menu obviously can't work with space. But I couldn't figure out how to enter the sub-menus in either of them.

[dpvc]

I agree that the keyboard part of the document you cite has been accomplished, but it seems to me that not all of the WAI-ARIA Roles, States, and Properties box is implemented. In particular, I don't think bullet points 3, 4, and 8 are. I'm not sure that 3 is necessary since our submenus pop-up automatically, but I'm pretty sure 4 and 8 are needed.

[zorkow]

There are multiple ways to achieve the same effect. E.g., I went the menuitem**** route. The role menu would need to go on the actual math element. Not sure if we want that, as it might be announced at every element, depending on the screen reader. And I tried to avoid properties like aria-owns as they are computationally expensive. But that is not to say that I am certain that it is complete. To add has-popup is certainly a good idea.

I will have another go over the aria attributes on Sunday.

Best,
Volker

[dpvc]

OK. I'm certainly no expert on this, so I wasn't sure which parts are needed and which are redundant. If I recall correctly, the submenus are not children of the parent menu item, so I thought the aria-owns property might be necessary. But if it is not needed, or if we want to wait with that for the next release and see how what we have now is received by the community, I'm OK with that.

I agree that we probably don't want rule="menu" on the math element. I was thinking more of the items in the menu themselves to make sure they had what was needed.

[dpvc]

OK, everything is merged, so is this ready to close?

[pkra]

👍

[zorkow]

+1

[kensgists]

If you are interested in an accessible context menu implementation (for purposes of reverse engineering, etc.), see Dojo's menu system test.

In the Dojo example, for keyboard-only users, any keyboard focusable element on the page has attached to it a right-click/contextual menu. For screen reader users, any browseable or focusable element has the context menu. The context menu can be entered via right-click, application key, or Shift + F10. It is fully keyboard and screen reader navigable.

Apropos of MathJax accessibility, as @jcsteh and others have pointed out here and in other accessibility related issue threads, there needs to be a way for AT users to turn on native MathML rendering or the benefits of MathJax are limited, esp. for screen reader and literacy software (Read&Write Gold, etc.) users. While it is great that MathJax "remembers" settings per domain once they are selected in the context menus, keyboard and screen reader users may never discover how to enable the native rendering, unless the context menu can be made accessible.

Note: as others have pointed out, a screen reader user hears "clickable" when encountering a MathJax island in browse mode. But all forms of clicking fail to do anything. In addition to an accessible context menu, there needs to be some announcement to the screen reader user that he is on a math equation -- he knows that now only if MathML rendering is already enabled -- and he'll need to know that he can use shift + F10 to enter the math settings menu. For keyboard users, obviously, there would need to be a way to first focus a math island to be able to spawn the context menu. (Setting tabindex="0" I suppose would be one, for the most part inelegant, way to do that -- instead, maybe MathJax creates a page-global context menu that is discoverable on tabbing into a page??)

[pkra]

@kensgists I don't quite follow your comments. In particular, it's not clear if you are referring to the changes that were implemented to resolves this issue (and are part of MathJax v2.6) or if you are referring to the behavior of previous versions. If you see an issue with the behavior of 2.6, please file a new bug report. Please note that other new accessibility features were introduced in 2.6, in particular the AssistiveMML extension.

[kensgists]

@pkra OK I see. You are absolutely right. I was referring to a previous version. Was looking at places where the older version was being used and I should have checked the latest. I see that v2.6 now allows for keyboard focusable equations via tab key navigating and keyboard-only use of the contextual menu (with space bar instead of application key, but that's OK). I'm also hearing correct reporting of the MathML in all renderers using JAWS and NVDA. This is terrific work.