Network admin can't be accessed via keyboard

[abletec]

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.

[afercia]

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:

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

[afercia]

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.

[Cheffheid]

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)

[Cheffheid]

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

[afercia]

@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.

​https://www.w3.org/TR/wai-aria/roles#menu

[Cheffheid]

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 :)).

[afercia]

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.
​https://www.w3.org/WAI/tutorials/menus/examples/appmenu/

[afercia]

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:
​http://w3c.github.io/aria-practices/examples/menubar/menubar-1/menubar-1.html

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

[afercia]

We're running out of time for the 4.8 release, so: punting.

[afercia]

Agreed during today's bug scrub to wait a bit to see how ARIA 1.1 evolves. Moving to 4.9.

[Cheffheid]

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:

Honestly, this is what makes sense to me. Simply because of the use of the word "presented", meaning that it'd apply when it looks like it not just acts like it. But I'm also aware that my interpretation is different from what seems to be the consensus on it. :)

Guess we'll need to wait and see what happens when 1.1's status finally changes, unless someone has a brilliant idea to fix this. :)

[afercia]

As per today's bug scrub: moving to future release, waiting for ARIA 1.1.

[sabernhardt]

This still is a problem in WordPress 5.7.

If all dropdown interactions are changed in #48894, though, then the sub-menus probably should expand properly with the Enter key or spacebar as well.

[sparklingrobots]

Hi, all! Hope this is useful information:

There are forum reports that this is still impacting users in 5.8, as well: ​https://wordpress.org/support/topic/wp-multi-site-network-admin-page-not-accessible-to-screen-readers-from-wp-admin/

I took a look at #48894 -- it looks like it's been indefinitely delayed.

[sabernhardt]

Moving to 5.9 to investigate an option based on the menubar role.

Also, I opened ticket:53888 for an additional link to Network Admin somewhere outside the toolbar.

[sabernhardt]

adding menuitem role only to top-level links and including aria-expanded attribute

[sabernhardt]

Using the menu, menubar or menuitem role is ​not appropriate for a navigation menu. However, I made 34668.2.patch​ to find out if adding the menuitem role to the top-level parent links might help anyway.

With NVDA and Firefox, the patch toggles those links when pressing the Enter key on its own. If people want to follow the My Sites link instead of toggling, though, they can use either Shift + Enter or Ctrl + Enter to open it in a new tab or window. The mouse/pointer interaction would remain the same as it has been.

We may also want to consider opening submenus on focus like in the side admin menu (comment:8).