[META] improve accessibility of toolbar

Toolbar module has a number of accessibility issues. Some of these may be addressed individually in child issues, but it will be a good idea to consider them holistically.

Known problems

Visual design

• #3097907: Active toolbar tray has weak affordance and fails WCAG color criteria
• #3097905: Add visual indicator to show which toolbar buttons have trays associated with them
• Confusing visual focus order. MAJOR. Visually, the top level toolbar has some buttons which appear on the right hand side (e.g. edit, tour). The DOM order differs from the visual presentation, so focus order jumps around in a way that's confusing for sighted users. Effectively a failure of WCAG success criterion 2.4.3 Focus Order (level A). Aim to find an order which is usable by screen reader users and sighted users. #3167438: Presentation of some toolbar buttons differs from DOM order
• Missing icons in Windows high-contrast mode. #3269420: Toolbar icons may not meet contrast when in forced colors mode The icons are CSS background images, which don't work when a Windows' high-contrast theme is enabled. Internet Explorer and Firefox both strip CSS background images out, but Edge displays them. (Other browsers don't respect Windows high-contrast mode at all, which is something beyond our control). This issue can be addressed by using an alternative technique such as inline <img>/ <svg>, or the CSS content property.

  However some buttons are badly broken, because visually they are just an icon. When the icon is missing users can't perceive or understand the button:

  • Many cases are OK, because the icon is accompanied by a visible text label. When the icon is missing, the link or button is still perceivable because the text label remains. It would be better if the icons weren't missing.
  • Switch toolbar orientation. Visually this is just an icon. In high-contrast mode, when the icon is missing, users may be completely unaware that the toolbar orientation can be changed, or can't find how to do it. MAJOR, fails WCAG SC 1.1.1 Non-text Content (level A) for the high-contrast scenario.
  • Sub-menu buttons in vertically-orientated trays. Visually this is just an icon. In high-contrast mode, when the icon is missing, users may not understand the hierarchy of an open menu, and may be completely unaware that more links can be disclosed. MAJOR, fails WCAG SC 1.1.1 Non-text Content (level A) for the high-contrast scenario.

Assisitive technology and Semantics

• #3066954: Admin toolbar not usable with latest versions of JAWS due to mis-use of aria-owns. CRITICAL. Fixed in 8.7.9.
• #3085781: aria-pressed attribute isn't updated correctly.. MAJOR.
• #3085811: Toolbar buttons should respond to spacebar key. These are <a href="" role="button"> which only responds to the return key. It needs an extra keyboard handler. Spotted in #3066954: Admin toolbar not usable with latest versions of JAWS due to mis-use of aria-owns.
• #3090120: Improve accessibility semantics for Toolbar buttons with trays
• #3093378: Use ARIA disclosure pattern for submenu buttons in vertical toolbar orientation
• Too many ARIA group/landmark roles. #3509700: Accessibility of landmark regions in toolbar The toolbar uses lots of ARIA navigation landmarks. In general, it's a good idea to avoid using to many landmark regions because it reduces their usefulness. They are used to quickly navigate between major regions of the page, and too many of them can make it tedious to cycle among them.
  • Consider just using a single navigation landmark for the entire toolbar, and eliminate the nested ones. Possibly use another non-landmark grouping role inside the toolbar. The nested menus already have
  • The toolbar is wrapped by an ARIA group (not a landmark) and a navigation role, each with their own label. This double wrapper doesn't serve much purpose, it merely increases verbosity.
• Navigation landmark regions without accessible names. #3509700: Accessibility of landmark regions in toolbar When a page has multiple landmark regions of the same kind, they should be distinguishable by name.
  • Toolbar has some navigation landmarks with accessible names. For example, in the second-level toolbar "trays" with menus: manage, shortcuts, and user.
  • However is also has unlabelled navigation landmarks too. For example there the home, "back to site", tour, and edit items.
• Empty navigation regions. #3509700: Accessibility of landmark regions in toolbar Some navigation landmark regions are present, but are empty. This is pointless, and may be confusing because they appear in a screen reader's list of landmarks. They are associated with top-level toolbar items which don't have a second-level tray.