Opened 8 years ago
Last modified 4 weeks ago
#34668 accepted defect (bug)
Network admin can't be accessed via keyboard
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 6.5 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Toolbar | Keywords: | has-patch 2nd-opinion needs-testing |
Focuses: | accessibility, javascript | Cc: |
Description
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 (3)
Change History (45)
This ticket was mentioned in Slack in #accessibility by cheffheid. View the logs.
8 years ago
#3
@
8 years ago
- Component changed from Networks and Sites to Toolbar
- Focuses javascript added; multisite removed
This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.
7 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
7 years ago
#7
@
7 years 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
@
7 years 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)
#10
@
7 years 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
@
7 years 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
@
7 years 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.
https://www.w3.org/WAI/tutorials/menus/examples/appmenu/
#13
@
7 years 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:
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).
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
7 years ago
#15
@
7 years ago
- Milestone changed from 4.8 to 4.8.1
We're running out of time for the 4.8 release, so: punting.
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
7 years ago
#17
@
7 years ago
- Milestone changed from 4.8.1 to 4.9
- Version 4.3.1 deleted
Agreed during today's bug scrub to wait a bit to see how ARIA 1.1 evolves. Moving to 4.9.
#18
@
6 years ago
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. :)
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
6 years ago
#20
@
6 years ago
- Milestone changed from 4.9 to Future Release
As per today's bug scrub: moving to future release, waiting for ARIA 1.1.
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
4 years ago
#22
@
2 years ago
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.
This ticket was mentioned in Slack in #accessibility by johnbillion. View the logs.
2 years ago
#24
@
2 years ago
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.
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
2 years ago
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
2 years ago
#27
@
2 years ago
- Keywords needs-refresh added; needs-testing removed
- Milestone changed from Future Release to 5.9
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.
#28
@
2 years ago
- Keywords needs-testing added; needs-refresh removed
- Owner set to sabernhardt
- Status changed from new to accepted
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).
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
2 years ago
#30
@
2 years ago
@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!
#31
@
2 years ago
@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).
#32
@
2 years ago
@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.
#33
@
2 years ago
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.
#34
@
2 years ago
@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.
This ticket was mentioned in Slack in #accessibility by sabernhardt. View the logs.
2 years ago
#36
@
2 years ago
- Milestone changed from 5.9 to Future Release
As @alexstine said on Slack:
More time might be good to re-consider options.
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
2 years ago
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
8 months ago
#39
@
7 weeks ago
- Milestone changed from Future Release to 6.5
I'd like to add this to the 6.5 release cycle. This is a fairly significant accessibility issue, and needs to get solved.
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:
keydown
event in the console, the link default action is prevented and the sub-menu opens: