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

[alexstine]

@sabernhardt Here's a modification. I think your patch is going in the right direction. I tried to make it a little better. I know this should not be an ARIA menu, but I ended up making it one. The biggest changes are I removed the aria-expanded false from JavaScript and allowed PHP to handle that directly. The other change was I allowed all items to have menuitem. Finally, I made an adjustment so that when sub menus open, they have the menu role and will announce the title of the menu via aria-label.

This patch is far from perfect, but maybe if the code is half way decent, it can be a keeper.

Can you work on the JavaScript some more? For some reason, if you click on About WordPress, the sub menu will only open if the screen reader is in focus mode first. Can you bind to the link and throw event.preventDefault(); unless Ctrl+Enter or Shift+Enter keys are used?

Thanks!

[sabernhardt]

@alexstine Thanks for testing and for the patch!

The goal with using the menuitem role was to put screen readers in focus mode automatically for these links, so it would need to work consistently for all of them. The problem might relate to how "About WordPress" is the first link after clicking the "Skip to Toolbar" link. If I tab forward and back, and then press Enter, the menu expands.

Because this is only a partial fix, I tried to avoid changing the behavior when using a pointing device. But perhaps disabling the "About WordPress" top-level link is fair.

If we add ARIA labels for submenus, I think the user account actions menu could have something better than the "Howdy, [name]" text. (Editing the labels might be more of an enhancement.)

34668.3.patch also removes the special log-out link for keyboard users. The link is probably unnecessary with the rest of these changes, though eliminating it would require people to search for the one within the submenu.

And if we remove the negative tabindex from the spare profile link, I would rather consider combining links so the user's display name and "Edit Profile" text are together (ticket:43633).

[alexstine]

@sabernhardt Agree with those observations completely.

Honestly, if this was to be refactored correctly, I would not allow top level submenus to have links. They would be rendered as buttons with the top level link being the first item in the menu. That way there is no problem with having to handle keyboard events differently with screen readers. I think this will greatly improve the UX, your latest idea, but this whole class needs to be refactored in the future. I'd like to do it now but I just don't think there's enough support in current class implementation to do what I want it to do. I could re-code the core links, but it's the custom admin menus that wouldn't have proper support. The only true way to achieve this would be to replicate the functionality in the class. That way, you would get this.

About WordPress button
Begin submenu:
About WordPress link
Other links...

Hope this makes sense.

[sabernhardt]

OK, disabling the click event on the "About WordPress" top-level link would not work. It may be fine with a mouse, but apparently that would make the entire About menu unusable with a touchscreen.

Maybe there is an event that can fire immediately after skipping to the toolbar.

[alexstine]

@sabernhardt Would it be possible to open the submenu on focus of the top level link? This way the submenu will open and the top level link will still be clickable. The submenu should still close on Escape press or once the container has focus loss. Will be harder to implement, that's why I held out on this suggestion.

Thanks.

[sabernhardt]

As @alexstine said on Slack:

More time might be good to re-consider options.

[joedolson]

I'd like to add this to the 6.5 release cycle. This is a fairly significant accessibility issue, and needs to get solved.

[alexstine]

Adding to my queue to work on again.