Planning for keyboard navigation

The theme review team is requiring all themes to implement keyboard navigation in two months time, around the third of september 2019.

Because this may be a complex task for many authors, we encourage you to start planning for and working on this as soon as possible.

We want to point out that this requirement does not only include menus. All functionality should work using a keyboard only. Any action you can complete with a mouse must also be performable via keyboard.

Theme authors must provide visual keyboard focus highlighting in navigation menus and for form fields, submit buttons and text links. All controls and links must be reachable using the keyboard.

First, please read the requirement found here:

As well as the background for this requirement: Techniques for WCAG 2.0
G202: Ensuring keyboard control for all functionality

We would like to collect examples for the keyboard navigation, including menus. If you know of a good resource that is not already included, please add a comment and link.

Navigation menus and controls

Drop down menus and controls must be available when tabbing, using keyboard only.

Both forward and backwards tabbing must work. To test backwards tabbing, hold down Tab and Shift at the same time.

Controls also include open and close buttons for modals such as off canvas sidebars or search forms.

Form fields

Don’t break the browsers default focus by removing the outline. Other kinds of decorative changes are also allowed. Only showing the marker inside the field is not enough.

Submit buttons

Submit buttons may be hidden during it’s normal state but visible on focus.

A high contrast color change, an outline, a border, or a text decoration change will assure that visible submit buttons pass the requirements.

Text links

Make sure you can see visually which link is focused. Focus should either incorporate a visual change that is not based on color (background change, underline, shape) or a color change where the difference between the two colors meets the WCAG 2.0 level AA contrast ratio (4.5:1) .

Basically, don’t break or remove the browsers default focus by removing the outline.


For those interested in AMP:

Example menus: ( )

Musik 2.0 and 2.1

In the past weeks I have made two updates to Musik. Most of the changes where made to make sure that the theme is more accessible, and there has been some color changes. The theme now passes the accessibility-ready review.

There has also been some bug fixes. Thank you for continuing to report bugs!

Version: 2.1 2019-02-12

  • Added the flex height parameter to the custom logo option so that the logo can be shown in any size again.
  • Added the accessibility-ready and block-styles tags to style.css.
  • The header images have been further compressed to reduce the size.

Version: 2.0 2019-02-05

  • Made sure that the social menu, if used, shows next to the main menu by default.
  • Made sure that the page footer is only used if there is actual footer content such as footer widgets and footer credit text.
  • Removed a redundant headline from the author archive.
  • A minor style change for the “Read more” link, moving it to new line.
  • Accessibility improvements:
    • Added underlines to links in the widget areas.
    • Changed the text color and background image of the comments to increase the contrast.
  • Added a new screenshot to reflect the changes of the widget areas.

Random thoughts about Gutenizer Phase 2

Some early (and early morning 🙂 ) thoughts about Phase 2.

I’m still a bit confused about what will go into earlier updates, and what will go into phase two. I mean there was a ton of block ideas that got postponed, will these blocks or some of them be added in phase 2?

Simplicity is important. Having a lot of visible elements (and in different colors) on the same page editor can be stressful.

I’m finding it difficult to picture if -or what part of, the current customizer sidebar will be visible at the same time as the new editor toolbar/inspector.

I think that having both the customizer sidebar with the panels and settings visible, and also have visible toolbars for selected blocks; and on top of that, the customizer shortcuts, could be too distracting. The visible panels and settings has to be carefully selected.

How will the customizer shortcuts be used, when many but probably not all elements will be editable directly? If we don’t use the customizer shortcuts, how do we show the user which elements that are editable?

This might not work…

Would the customizer only be used to edit the front page, or would we be able to edit the search results page, 404, archives, single pages, shop pages etc?

Because when we talk about layouts and in an extension, block page templates, all these inner pages are likely to look different from the front page and from each other. For example, a header image and large site title and tagline might be a visible editable area for a front page, but might not be visible in a single post view.

Currently, the customizer panels can have unlimited options. It would not make much sense, to have a panel with a setting that selects the sidebar position for my single posts, if I am currently viewing and editing blocks for the front page.

Perhaps the theme would declare support for different views which can be edited?

It would be nice to have a simple option where we can choose whether we want to show the full content, excerpts, or even just the titles on the blog, archives and search result pages.

I sometimes receive support requests from users who are asking why the full content is showing, even when they set the feed to only display the summary.

No, this setting is not for the blog.

I want to be able to create reusable block templates, and not only for custom post types.

We might need several different kind of templates:

  • Layouts where we select the position of our widget areas, header images, adverts, menus etc.
  • Layouts for individual content blocks, recommending a specific order of blocks for individual content.

In phase 2, will we really need both pages and posts? If we are able to change the visibility of the meta information like the post date etc, the difference between the two types will continue to be blurred out.

If I want a front page of ten posts, then I don’t want to manually have to drag and drop ten individual post blocks and order them in the customizer.

I want to be able to add the latest ten posts in one go, but maybe I don’t want to use the current latest posts widget either. That block has a different purpose.

Then again, if I added post block(s) to my front page that I am editing in the customizer, and I spotted a typo, then I would want to be able to edit it directly in the customizer and save it, instead of having to leave my view and open the individual post.

I want to be able to edit everything in the post. Like title, permalink, images…

I want to be able to add a simple one page menu. A menu that checks what posts or pages that I have added to the current page view, and automatically creates the links for me.

I think adverts is something that have been forgotten. Today you might install a plugin, or a few plugins, or add a code to a theme setting (!) in order to include your ad code, but displaying the adverts correctly on the page is still not that easy. We could greatly improve this and help users optimize their adverts.

Social media links with icons is something that nearly every theme adds, either as link options in the customizer, or as a menu. There should be one simple, recognizable way to include social media links. If a menu system is used, I still think it needs to be a lot simpler than it is now.

It should not be more difficult than adding any other type of link, and the visual feedback must be better. The icon should be visible immediately, not only on the front.