This pull request includes:
-
a few adjustments to the CSS to make the look for mouse (as opposed to keyboard) users more consistent with the current MathJax menu without interfering with the keyboard usage (I hope).
- The focus outline is not shown if the menu is opened by mouse (but focus is still set).
- The focus outline is not shown for dialog boxes opened by mouse (but focus is still set).
- The focus outline is not shown for close buttons when clicked by mouse
- The focus is not shown on the math element after a menu or dialog is closed by mouse click (but is if it is closed by keyboard action).
So the only significant difference for mouse users from the current UI is that clicking on a math element focuses it and shows the focus outline. (Note that we probably need to implement something for
<maction>elements so that they can get the focus and be activated by keyboard and screen reader users. I also haven't checked href's within the math to see if they are accessible.) -
Localization of the "Close Window" string that is used on the close buttons (though I'm wondering if this would be better as "Close Dialog" or "Close Pop-up" since it is not actually the window that is being closed).
-
A fix that makes sure
aria-androleattributes show up as actual attributes in the DOM. -
A fix to HTML-CSS so that the focus highlighting will be full width when the math is full width (e.g., when there is a
\tag, or with percentage-width tables, or with themultlineenvironment). -
Fixes for handling of keyboard and menus in IE < 9.
-
Fix so that SVG elements won't be focusable in IE.
-
Fix Error jax so that [Math Processing Error] elements work with keyboard menus.
Activity
mentioned in merge request !1264 (closed)
mentioned in merge request !1265 (merged)
I think WCAG requests that focus should be visible.
Note that the focus will be visible when the keyboard is used. It is just if the menu or dialog is opened with the mouse that the focus is not visible. This is is consistent with the example linked from the aria practices documentation. When the mouse is used to open and select the menu items, the focus doesn't show, but when keyboard is used, it does. This seems consistent with normal practice. I've never seen menus that show focus outlines for mouse actions, or buttons that focus when you click them. Perhaps it differs by operating system, but it seems very strange to me to see the focus outlines during mouse activity.
- Localization of the "Close Window" string that is used on the close buttons (though I'm wondering if this would be better as "Close Dialog" or "Close Pop-up" since it is not actually the window that is being closed).
I also would prefer close dialog (or close alert). However, I am we should keep in mind that the Aria label is what the AT will read out in lieu of a button label. So what is more natural for people: window or dialog? Does your casual user even know what a dialog is?
So what is more natural for people: window or dialog? Does your casual user even know what a dialog is?
I really don't know. But I was worried that "close window" might suggest that it is the browser window that is being closed, not that a pseudo-window is being closed within the browser window. A visually impaired user might not really know that a window-like item is open. Do we need to use the aria dialog attributes and techniques (see making dialogs modal, alert dialogs, and modal dialogs for instance)?
Good point. So maybe close dialog is the right way to go. Or, since we are not using a generic close button we might as well be more specific and say "close help dialog" and "close about mathjax dialog".
I believe we pretty much do everything re dialog/alert with the exception of using the document role for the message. And I am not sure that is really necessary given the tabbing order.
changed milestone to %MathJax v2.6
changed milestone to %MathJax v2.6
added v2.6 label
