Insufficient keyboard accessibility of the main menu for mobile version Dashboard

[rianrietveld]

If the screen is enlarged by Ctrl+ the Dashboard layout jumps into mobile version.
For people who enlarge the screen and only use a keyboard, the menu of this mobile version is not easy accessible.
A screen reader user can't see the size of the screen, so when it's in mobile version, that's a problem for them too.

The menu button has no label and if selected, the focus stays on the menu button. So the menu can only be reached entering shift-tab. The user than can navigate though the menu from the bottom to the top backwards.

My recommendations
Add a label to the menu
Set the focus on the first menu-item after selecting the menu
For screen reader users: change the style hidden into the class screen-reader-text
And maybe add an option: disable mobile version with the user settings?

[bramd]

This patch adds an aria-expanded attribute to indicate if the menu is expanded. It also places focus on the first link in the menu if the user expands the menu. It also removes the title attribute and replaces this with a hidden span which is read by default by screenreaders, the title attribute is not.

[ceo]

FWIW, as far as I can tell through my own use on iOS, when on an actual mobile device there is no issue with navigation.

What I find when in the mobile view on my computer, however, is that while navigation itself isn't hindered (the focus moves through the screen as expected at least), there is no indication that the menu has been expanded and when in the menu, none of the items are spoken. This issue repeats into the sub-menu as well, where it can be expanded but nothing is spoken.

The really interesting thing is that if I switched the zoom and moved in and out of the mobile version I could get the menu to be spoken as normal (even though visually the menu wasn't expanded).

It is because of exactly that, that I strongly suggest a method for disabling the mobile view be added.

[bramd]

Replying to SergeyBiryukov:

Why did you move this to 3.9? This ticket is just to improve usability of the menu in mobile view for keyboard users. The suggestion that has been done in this ticket to add an option to disable the mobile view is interesting, but outside the scope of this ticket. So, the patch I proposed does not introducte new options or other user facing changes.

Also, the extension of the admin bar to handle the aria-expanded attribute is backwards compatible. If it is this code you have problems with, I would propose to add only the fixed menu label and focus handling and leave aria-expanded out for now, we can do that in 3.9.

[SergeyBiryukov]

I misread the ticket description and didn't think it was a regression from 3.7. Apparently it is. Moving to 3.8.1 for consideration.

[SergeyBiryukov]

26639.2.diff​ builds on 26639-1.diff​ with a few changes:

• Keeps the Menu label translatable.
• Uses #adminmenu a:first selector to set the focus on the first menu item (in case the Dashboard section is removed by a plugin).
• Minor formatting cleanup.

[SergeyBiryukov]

Setting the aria-expanded attribute doesn't work as expected for me in Firefox 25.

On page load, aria-expanded is added to the link, however, the JS adds it to the <span> element instead:

<a class="ab-item" href="#" aria-expanded="false">
	<span class="ab-icon" aria-hidden="true" aria-expanded="false"></span>
	<span class="screen-reader-text">Menu</span>
</a>

26639.3.diff​ uses $(this).find('a') to set the attribute, which seems to work as expected.

[SergeyBiryukov]

What's the purpose of the aria-hidden="true" attribute for the <span class="ab-icon"> element here? Looks like it's the first instance of using it in the toolbar.

[bramd]

Replying to SergeyBiryukov:

What's the purpose of the aria-hidden="true" attribute for the <span class="ab-icon"> element here? Looks like it's the first instance of using it in the toolbar.

Just did some more testing, aria-hidden can be safely omitted here. The icon is not inserted using a symbol font or other method that's visible to a screenreader, so no need to hide anything.

[SergeyBiryukov]

Seems like the changes in wp-includes/class-wp-admin-bar.php are not really necessary, we can set the initial state in JS as well: 26639.4.diff​.

[grahamarmfield]

Have tested this patch on Windows 7 laptop with IE10, FF26 and Chrome 31. I forced the mobile view by narrowing my browser windows.

The patch does improve the situation for getting into the menu having pressed enter when focus is on the menu button. Focus is now on the top link within the menu and I can move sensible through the items.

Should the keyboard user wish to hide the menu again however, that is not so easy since the menu icon is now not the previous item in the taborder. However, I think that's a small issue.

But surely the most significant issue with the mobile view is the fact that when arriving at a page with the menu hidden, you can still tab to all the menu links. Starting from the top of the screen the tab order is: Skip to Main Content, Skip to Toolbar, followed by the navigation menu link to the Dashboard, Posts, Media, etc, etc.

Since the menu is hidden at this stage the focus effectively disappears for some considerable time, until the user eventually reaches the 'open menu' link.

Surely when the menu is hidden, it should not be possible to tab into it. Suggest that when the menu is hidden that it is also set to display:none - this will effectively remove it from the tab order.

[SergeyBiryukov]

Replying to grahamarmfield:

Suggest that when the menu is hidden that it is also set to display:none - this will effectively remove it from the tab order.

Done in 26639.5.diff​.

We already use display: none for smartphones: tags/3.8/src/wp-admin/css/wp-admin.css#L13011​, so this should make it consistent.

The patch also moves width: 190px rule to the same selectors a few lines above to avoid unnecessary repeating.

[azaozz]

How about we disregard that button and show the menu on "focusin"? That makes it work almost exactly the same as in non-mobile mode. All sub-menu items are visible and accessible by tabbing and flow "naturally".

In 26639.6.diff: toggle the mobile menu on focusin/focusout.

[azaozz]

So, which approach makes this better, in 26639.5.diff or 26639.6.diff? Perhaps go with 26639.5.diff for 3.8.1 as we have some feedback for it and consider 26639.6.diff for 3.9?

[azaozz]

In [27010]:

Improve keyboard accessibility for the admin menu when in responsive mode, props SergeyBiryukov, fixes #26639 for 3.8.1.

[azaozz]

In 27011:

Improve keyboard accessibility for the admin menu when in responsive mode, props SergeyBiryukov, fixes #26639 for trunk.