Twenty Twelve: Menu not accessible in "mobile" size

[artychan]

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.

[lancewillett]

Hiya artychan! Thanks for the ticket.

Patches welcome. :)

[rclations]

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.

[artychan]

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]

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

[rclations]

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

[lancewillett]

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?

[DrewAPicture]

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.

[obenland]

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.

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

[lancewillett]

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.

[davidakennedy]

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.

[obenland]

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.

[davidakennedy]

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.