WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#28224 closed defect (bug) (fixed)

Twenty Twelve: Menu not accessible in "mobile" size

Reported by: artychan Owned by:
Milestone: 4.0 Priority: normal
Severity: normal Version: 3.5
Component: Bundled Theme Keywords:
Focuses: accessibility Cc:

Description (last modified by SergeyBiryukov)

This is basically the same issue as #27147 except for Twenty Twelve.

When the screen gets narrow enough that the menu is just a button-looking "Menu", the keyboard and screen readers cannot access the links inside the menu.

There are different ways to approach this, but might just be easiest to adapt the solution from #27147.

Not sure how it was implemented in Twenty Fourteen, but ideally, the menu "button" would also change colour (much like it does on hover) when it gets focus.

Attachments (2)

28224.diff (1.2 KB) - added by rclations 4 years ago.
28224.2.diff (1.6 KB) - added by rclations 4 years ago.

Download all attachments as: .zip

Change History (19)

#1 @SergeyBiryukov
4 years ago

  • Description modified (diff)
  • Summary changed from TwentyTwelve: Menu not accessible in "mobile" size to Twenty Twelve: Menu not accessible in "mobile" size

#2 @lancewillett
4 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 4.0

Hiya artychan! Thanks for the ticket.

Patches welcome. :)

@rclations
4 years ago

#3 @rclations
4 years ago

Added a patch that integrates the fix from Twenty Fourteen in #27147

Tested on Chrome w/ the built-in screen reader on Mac OS X 10.9.2.

Looks like there were some styles added in the other ticket's patch (https://core.trac.wordpress.org/attachment/ticket/27147/27147.2.2.diff) but I didn't see a need for these here. Might need cross-browser testing to confirm I didn't miss anything.

#4 @rclations
4 years ago

  • Keywords has-patch added; needs-patch removed

#5 @artychan
4 years ago

re: CSS additions

right now, there are styles for:

  • .menu-toggle:hover
  • .menu-toggle:active

but none for .menu-toggle:focus (at least none that I can find, using https://themes.trac.wordpress.org/browser/twentytwelve/1.4/style.css as reference)

I would suggest adding focus to the same rule as hover. That way people will know when they have focus on the menu button

@rclations
4 years ago

#6 @rclations
4 years ago

Thanks for the feedback @artychan - I think this should be all set now.

#7 @rclations
4 years ago

fyi - tested Twenty Thirteen for the same issue and opened #28293 w/ a patch to resolve there also

#8 @lancewillett
4 years ago

  • Keywords 2nd-opinion needs-testing added

Anyone have thoughts on how this could break child themes or older Twenty Twelve installs that rely on the specific markup? Or is it worth the minor breakage for a nice accessibility enhancement?

#9 @DrewAPicture
3 years ago

28224.2.diff seems to be a pretty nice improvement, though the gradient is a little dark when toggled on. Perhaps make the darker of the shades a little lighter with something like #flflfl instead of #elelel.

#10 @obenland
3 years ago

  • Keywords 2nd-opinion removed
  • Version set to 3.5

We have a class name there, which makes me less hesitant concerning a tag change. Although we've not been as good in Twenty Twelve with not using tag names in our CSS selectors as in following default themes, in this case we're using the class throughout style.css.

I don't think we should change the colors though, that time has passed. We've been fairly strict with not doing visual changes retrospectively, and I think we should stick to it here too.

#11 follow-up: @obenland
3 years ago

Testing the patch, I noticed that after toggling the menu, the next tab leads to the "Skip to content" links and only after that to the actual menu items. This is due to how we have structured the menu. This happens in Twenty Thirteen and Fourteen as well.

I wonder if switching position with the menu toggle would a) make sense and b) wouldn't blow up in terms of back compat.

This ticket was mentioned in IRC in #wordpress-themes by obenland. View the logs.


3 years ago

#13 @lancewillett
3 years ago

  • Keywords has-patch needs-testing removed
  • Resolution set to fixed
  • Status changed from new to closed

In [29095] Twenty Twelve: make small-screen menu accessible to keyboard commands and voice-driven software by using a focusable button element rather than h3 for the toggle element. Fixes #28224, props rclations.

#14 in reply to: ↑ 11 ; follow-up: @davidakennedy
3 years ago

Replying to obenland:

Testing the patch, I noticed that after toggling the menu, the next tab leads to the "Skip to content" links and only after that to the actual menu items. This is due to how we have structured the menu. This happens in Twenty Thirteen and Fourteen as well.

I wonder if switching position with the menu toggle would a) make sense and b) wouldn't blow up in terms of back compat.

Where would you move the menu toggle and/or skip link?

Ideally, from an accessibility standpoint, we'd do something like to Underscores: https://github.com/Automattic/_s/blob/master/header.php#L23-L34

The issue here is similar to what obenland described. If you're on a touch device and moving around, listening for feedback, it's pretty easy for that Skip to Content link to get in the way of getting to the menu items because of source order.

However, I would hate to break themes for people. That's not cool. The skip link/toggle position isn't perfect, but not bad either. The skip link does come before the actual menu items. I'd say leave it, but make the effort to improve change things in default themes from here on out.

A big bug was fixed here and that's the important part.

This ticket was mentioned in IRC in #wordpress-ui by davidakennedy. View the logs.


3 years ago

#16 in reply to: ↑ 14 ; follow-up: @obenland
3 years ago

Replying to davidakennedy:

Where would you move the menu toggle and/or skip link?

Not sure moving it out of the nav element is a good idea (back compat). But maybe we could switch their position.

#17 in reply to: ↑ 16 @davidakennedy
3 years ago

Replying to obenland:

Not sure moving it out of the nav element is a good idea (back compat). But maybe we could switch their position.

I think switching their positions would be a good idea, so long as back compat doesn't blow up. It would alleviate the issue on the skip link getting in the way of the menu items in some assistive technology cases.

Note: See TracTickets for help on using tickets.