Make WordPress Core

Opened 11 years ago

Closed 11 years ago

#26639 closed defect (bug) (fixed)

Insufficient keyboard accessibility of the main menu for mobile version Dashboard

Reported by: rianrietveld's profile rianrietveld Owned by: azaozz's profile azaozz
Milestone: 3.8.1 Priority: normal
Severity: normal Version: 3.8
Component: Accessibility Keywords: has-patch
Focuses: Cc:

Description

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?

Attachments (6)

26639-1.diff (1.8 KB) - added by bramd 11 years ago.
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.
26639.2.diff (1.9 KB) - added by SergeyBiryukov 11 years ago.
26639.3.diff (1.9 KB) - added by SergeyBiryukov 11 years ago.
26639.4.diff (1.3 KB) - added by SergeyBiryukov 11 years ago.
26639.5.diff (2.2 KB) - added by SergeyBiryukov 11 years ago.
26639.6.diff (1.5 KB) - added by azaozz 11 years ago.

Download all attachments as: .zip

Change History (26)

@bramd
11 years ago

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.

#1 @bramd
11 years ago

  • Cc bramd added
  • Keywords has-patch added

#2 follow-up: @SergeyBiryukov
11 years ago

  • Milestone changed from Awaiting Review to 3.9

#3 @ceo
11 years ago

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.

Last edited 11 years ago by ceo (previous) (diff)

#4 @ceo
11 years ago

  • Cc ceo@… added

#5 @toscho
11 years ago

  • Cc info@… added

#6 in reply to: ↑ 2 @bramd
11 years ago

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

Last edited 11 years ago by bramd (previous) (diff)

#7 @SergeyBiryukov
11 years ago

  • Milestone changed from 3.9 to 3.8.1

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.

#8 @SergeyBiryukov
11 years ago

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.

#9 @SergeyBiryukov
11 years ago

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.

#10 follow-up: @SergeyBiryukov
11 years ago

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.

#11 in reply to: ↑ 10 @bramd
11 years ago

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.

#12 @SergeyBiryukov
11 years ago

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.

Last edited 11 years ago by SergeyBiryukov (previous) (diff)

#13 @grahamarmfield
11 years ago

  • Cc graham.armfield@… added

#14 follow-up: @grahamarmfield
11 years ago

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.

#15 in reply to: ↑ 14 @SergeyBiryukov
11 years ago

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.

Last edited 11 years ago by SergeyBiryukov (previous) (diff)

@azaozz
11 years ago

#16 @azaozz
11 years ago

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.

This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.


11 years ago

#18 @azaozz
11 years ago

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?

#19 @azaozz
11 years ago

In [27010]:

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

#20 @azaozz
11 years ago

  • Owner set to azaozz
  • Resolution set to fixed
  • Status changed from new to closed

In 27011:

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

Note: See TracTickets for help on using tickets.