Make WordPress Core

Opened 18 months ago

Last modified 10 days ago

#34668 new defect (bug)

Network admin can't be accessed via keyboard

Reported by: abletec Owned by:
Milestone: 4.8 Priority: normal
Severity: normal Version: 4.3.1
Component: Toolbar Keywords: has-patch 2nd-opinion needs-testing
Focuses: accessibility, javascript Cc:


In order to *reliably* see the network admin dashboard, one has to hover over the 'My Sites' icon. Violates accessibility guidelines & makes it very difficult to access the network admin dashboard for screenreader users, & I would think many mobile users as well. I've tried example.com/wp-admin/network but this does not reliably bring up the network admin dashboard. Actually pressing the enter key while on the icon does nothing either. To reproduce, simply try accessing the network admin dashboard via keyboard. Sometimes I actually can, but that doesn't seem to happen consistently.

Attachments (1)

34668.patch (462 bytes) - added by Cheffheid 6 weeks ago.
Appends role="menuitem" to toolbar menu item parent ARIA attributes

Download all attachments as: .zip

Change History (14)

This ticket was mentioned in Slack in #accessibility by cheffheid. View the logs.

18 months ago

#2 @joedolson
18 months ago

  • Focuses accessibility added

#3 @afercia
18 months ago

  • Component changed from Networks and Sites to Toolbar
  • Focuses javascript added; multisite removed

As far as I can tell, this is not specific to Network installations and happens in single installations too, for all the menu items in the admin bar and just when a screen reader is running. Putting it simply, JavaScript keyboard events don't work as many developers would expect when a screen reader is running.

Screen readers intercept key strokes (with a few exceptions) for their own needs. Browsers are simply unaware a keydown event occurred.

This kind of non-native interactions would need some serious ARIA to actually work with screen readers. I'm not even sure it can be done without an admin bar major refactoring. I'd propose to discuss this in the next accessibility team weekly chat in order to plan some action and verify available resources.

In the screenshots below:

  1. dumping the top menu item keydown event in the console, the link default action is prevented and the sub-menu opens:


  1. doing the same thing with NVDA running, no event and the link gets activated:


This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.

10 months ago

#5 @rianrietveld
10 months ago

  • Milestone changed from Awaiting Review to Future Release

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

3 months ago

#7 @afercia
3 months ago

  • Milestone changed from Future Release to 4.8

This is very noticeable with screen readers on Windows (JAWS, NVDA). Less noticeable with VoiceOver but still an issue if using Control-Option-Space to activate the menu. Moving to 4.8 to, at least, start a discussion and investigate on best options to fix it.

#8 @Cheffheid
6 weeks ago

It probably doesn't help here that the items with a submenu are also legitimate links. Because I think what NVDA does is pass the keydown through as a click event instead.

So, there seems to be a way to force NVDA and JAWS to pass keydown events. I've found this (old) list of the impact of the role attribute and its value on anchor tags (the first table): https://unobfuscated.blogspot.com/2013/05/event-handlers-and-screen-readers.html

As it turns out, setting a role of "menuitem" will restore the keydown event and allow the submenus to function.

I was going to ask if making these menus function the same way as the ones in the left sidebar (that is, make the submenus appear once there is focus on the parent) is acceptable, but I think this will do as a quick fix for this issue. We can always discuss a larger overhaul later.

(Added the 2nd opinion tag, just to make sure we're on the same page for this fix)

Last edited 6 weeks ago by Cheffheid (previous) (diff)

6 weeks ago

Appends role="menuitem" to toolbar menu item parent ARIA attributes

#9 @Cheffheid
6 weeks ago

  • Keywords has-patch 2nd-opinion needs-testing added

#10 @afercia
6 weeks ago

@Cheffheid yep using role="menu" (or role="menubar") and role="menuitem" would make screen readers let browsers know of the event and so it would work. However, role="menu" and role="menuitem" are suited for menus like the ones of an application, not for navigation menus 😞

The menu role is appropriate when a list of menu items is presented in a manner similar to a menu on a desktop application.


#11 @Cheffheid
6 weeks ago

I have legitimately no idea what that actually means. Menu on a desktop application? Doesn't that refer to menus like the image below? In which case, since the keyword in that statement is "presented", wouldn't that mean it's appropriate? Or am I missing some other kind of menu in a desktop application that it's actually referring to?

(Sorry, lots of questions :)).


#12 @afercia
6 weeks ago

There's an example of "application" menu on the WAI tutorials, it's basically a menu with items that are "actions" or commands rather then navigation. Note: the example is sligthly broken :) So yes, like in the image you posted.

#13 @afercia
10 days ago

Seems there's some ambiguity: the new ARIA 1.1 spec (still a Candidate Recommendation at the time of writing) still refers to menus similar to the ones on desktop application but then in the authoring practices demos (still not official) the role=menu is used for site navigation:

If this kind of usage is legit, that's exactly what would fix the toolbar (plus some aria-expanded magic).

Note: See TracTickets for help on using tickets.