Planning for keyboard navigation

The theme review team is requiring all themes to implement keyboard navigation in five weeks 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: https://make.wordpress.org/themes/handbook/review/accessibility/required/#keyboard-navigation

As well as the background for this requirement: Techniques for WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/. 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.

If you need help, you can also use the Accessibility Support Forum.

As always, communication is key, if you know that you will need extra time to solve this, contact the team or add a note in your ticket so that we know that you are working on it.

Navigation menus and controls

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

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

Visible Focus

As a general rule, do not remove the browsers native outline from the focusable elements without replacing it with an accessible alternative.

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

Do not remove the browsers native outline without replacing it with an accessible alternative.

Make sure that you can see 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) .

Focus order

Focus order should match the visual order. Make sure that focus doesn’t move in unexpected ways around the page.

Both forward and backwards tabbing must work. To test backwards tabbing, hold down Tab and Shift at the same time.
Please also note that use of tabindex is discouraged.

Recommended reading regarding focus order:

https://www.w3.org/TR/WCAG20/#navigation-mechanisms-focus-order

CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. grid and focus order: https://www.matuzo.at/blog/the-dark-side-of-the-grid-part-2/#visual-order

Resources

https://make.wordpress.org/accessibility/handbook/test-for-web-accessibility/test-for-web-accessibility-frontend-code/#keyboard-navigation

Example menus:

https://www.w3.org/TR/wai-aria-practices/#menu

https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/menubar-1.html

https://github.com/wpaccessibility/a11ythemepatterns

-Some concerns were voiced during our previous meeting about the above examples not being updated for 4 years, so if people would try these out and help keep the code up to date that would be very helpful.

@acalfieri Is working on an example menu here, please help her test it and leave feedback: https://github.com/anace/keyboard-navigation

https://wordpress.org/themes/twentynineteen/

https://wordpress.org/themes/twentyseventeen/

https://github.com/Automattic/_s ( https://underscores.me/ )

https://github.com/wprig/wprig/

For those interested in AMP:
https://amp-wp.org/documentation/playbooks/keyboard-accessible-navigation-menus/

WebMan Design | Oliver Juhas 5:25 pm on August 3, 2019

Hi @poena,

Great to see this bold move with accessible navigation in themes 😉

I’ve actually put together a vanilla JS script dealing with this and released it just a while ago. Please check https://github.com/webmandesign/a11y-menu Hope it helps too.

Best regards,

Oliver
Martin Stehle 3:20 pm on August 4, 2019

I’m glad that WordPress keeps sensilizing for accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility).
Guido 2:39 pm on August 6, 2019

The theme review team is requiring all themes to implement keyboard navigation

What will happen to existing themes without (proper) keyboard navigation that aren’t updated on time?
- poena 4:41 am on August 7, 2019
  
  If we have to keep reminding authors to fix it and we do not hear from them or they can not show that they are working on fixing it, then themes can be suspended.
  - Guido 5:54 pm on August 8, 2019
    
    Just to be clear, this applies to all themes in repository, including themes that have not been updated in a long time? If that’s the case, many abandoned themes will be suspended, I guess.
    - poena 6:14 pm on August 8, 2019
      
      All requirements always apply to all themes unless it’s otherwise stated.
      But we don’t look for themes that break requirements unless its a security issue or it gets reported. We don’t have the number of volunteers, time or tools to do something like that. Its hard enough to try to keep up with doing a first review of all submitted themes.
      The important thing here is that theme authors start to think about and learn about accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility).
      The theme directory could do without the abandoned themes but that is another issue.
      - Guido 11:07 pm on August 9, 2019
        
        Understood, thanks for the clarification.
      - dingdang 6:46 pm on August 17, 2019
        
        All requirements always apply to all themes unless it’s otherwise stated.
        But we don’t look for themes that break requirements unless its a security issue or it gets reported.
        
        Do you mean by this that in practice the new rules would apply only for new themes? What if you get a list of all the themes currently in repository which don’t comply with the new rules, would you suspend them all?
        
        poena 2:29 am on August 22, 2019
        
        No. Authors still need to have a chance to update their themes first. But if you really want to make a list that would be very helpful.
        
        dingdang 12:37 pm on March 6, 2020
        
        Thank you for the clarification. Here is an example, let me know if this is the correct way to report it:
        https://themes.trac.wordpress.org/ticket/79496#comment:3
        
        Carolina Nymark 11:19 am on March 8, 2020
        
        Hi, the correct way to report it is to use the report button on theme’s page.

Welcome to the Themes team!

Handbooks and review requirements

Coding standards and plugins

Code Packages

Communication

Planning for keyboard navigation

Navigation menus and controls

Visible Focus

Form fields

Submit buttons

Text links

Focus order

Resources

Welcome to the Themes team!

Handbooks and review requirements

Coding standards and plugins

Code Packages

Communication

Navigation menus and controls

Visible Focus

Form fields

Submit buttons

Text links

Focus order

Resources

Share this: