Keyboard test Gutenberg, a first try

How does Gutenberg 2.3 perform with keyboard only? I’ve set up a test and looked for issues. The test, the results and a YouTube with the test are included.

  • Gutenberg: Plugin version 2.3.0
  • Browser: Chrome Version 64.0.3282.186 (Official Build) (64-bit)
  • OS: MacOS High Sierra, 10:13:3
  • OS Settings: Keyboard shortcuts: full keyboard access set on all control
  • Test done with: keyboard and my eyes only, no screen reader or other assistive technology.

This test results are part of the large scale Gutenberg testing for Accessibility, organized by The WordPress Accessibility team.

The test is set up to do the most common tasks for a content manager (who is not a developer). Like add and modify text, headings, images, lists, tables, and embeds.

Goal of this test is to see where currently the problems are and collect data to write a manual for keyboard users. Also I want to learn and construct a standard test for other assistive technology.

I’ve recorded my test session, view it on YouTube. I haven’t looked at Gutenberg for a while and did not look at the code, so be as blank as possible for how things work.

The test

First: add a new post, using the Gutenberg editor

Set up some content

  • enter a title
  • add a paragraph with some texts
  • add an H3 heading with the text “this is a heading”
  • add an image
  • add a list of 5 items (cats, dogs, fish, birds, spiders)
  • add a table with 2 columns, 2 rows and add some data in the cells
  • add the YouTube embed

Actions at the top:

  • preview the post
  • publish the post
  • switch to draft
  • hide and display the settings (the wheel)
  • Open  “More” ( 3 dots) and switch from visual code editor to code editor and back again

Modify the paragraph

  • make a link to on one of the words
  • align the text to the left when you focus the paragraph
  • with the settings on the top, select Fix toolbar to Top, is this usable for you when you change the content of a paragraph?

Block options

Modify the paragraph with the Block options (you can see the blocks by selecting the settings wheel at the top).

  • switch of/off drop cap
  • change font size and reset it
  • change background colour red
  • change text colour light grey
  • clear text and background colour
  • align the block to the left
  • add an additional CSS class wp-caption

Modify a heading

  • change the H3 heading into an H2
  • make a part of the heading italic
  • remove the heading

Modify an image

  • add a link to the image
  • add a caption
  • align image to the right
  • change the size of the image using the Block options

Modify the list

  • add an item to the list
  • delete an item from the list

Modify the table

  • add a row
  • add a column
  • delete a row
  • delete a column

Manipulate the blocks

  • move the image above the H2 heading
  • turn the list into a paragraph
  • delete a block

Found issues and questions

  • How to reach the block options for a corresponding block? I could not find a way to reach the block options because the focus on the item you are working on is lost.
  • How to add a link to a paragraph or caption, the focus is lost before you can add the link to the selected test.
  • For the block type selection: if you tab twice, the focus drops out of the modal.
  • The preview button does not get focus, I can not preview the post.
  • After selecting Publish it’s confusing how to get to the update options. They are hard to reach with keyboard, I couldn’t figure out the tab order for this.
  • How to select a date of publishing, only the time gets visual focus. The date modal could not be closed by keyboard too.
  • What is the logic for showing/not showing the toolbar above for example a paragraph. Sometimes is shows, sometimes it doesn’t.
  • Not keyboard related, but anyhow: The table needs a <th> option.

Accessible custom styled form elements

HTML elements like check buttons, radio buttons or select options can be hard to style with CSS in a custom design. There are many workarounds for this, but are they accessible? Here’s my point of view.

The challenge

HTML elements like check buttons, radio buttons or select options can be hard to style with CSS in a custom design. There are many workarounds for this, based on two different approaches:

  1. Hide the form elements from sight and apply the styling on a container or related element
  2. Hide the form elements from sight and rewrite the functionality, using styleable elements like <div>s and JavaScript

Continue reading “Accessible custom styled form elements”

Looking back on 2015 and forward to 2016

Last year I changed the focus of my company. I wanted to do web accessibility related work only. The plan was to:

  • build and maintain accessible websites only
  • give accessibility training to web developers and graphic designers
  • help developers and companies fixing accessibility issues
  • give talks on WordCamps and Meetups
  • keep contributing to WordPress

Continue reading “Looking back on 2015 and forward to 2016”

Fix the accessibility of your Genesis responsive menu

The Genesis Framework is my favorite tool to build a WordPress website. And with the next update (version 2.2) a lot of accessibility features and fixes will be added. But a framework is no child theme.
The HTML5 themes you can purchase with StudioPress have a beautiful responsive menu for the primary navigation. And that menu is completely inaccessible for keyboard and screen reader users.

What’s wrong?

The HTML code to show the responsive menu is:

 <div class="responsive-menu-icon"></div>

A div is not focusable, if you tab though a page the menu is skipped and you have no way to open it, only by using a mouse. And also the div is an empty container, with no content.

What needs to be changed?

  1. Change the <div> to a <button>, a button is focusable and clickable
  2. Add some text inside the  <button></button> to tell a screen reader user what the button is about. You can make this visibly hidden by using the screen-reader-text class
  3. Tell a screen reader user if the menu is open or closed by adding dynamically aria-expanded=”false” or aria-expanded=”true”

How can you do that?

The Genesis child themes use js/responsive-menu.js (GitHub) to show the responsive menu.
Change this JavaScript into for example:

jQuery(function( $ ){

 $(".nav-primary .genesis-nav-menu").addClass("responsive-menu").before('<button class="responsive-menu-icon" aria-expanded="false"><span class="screen-reader-text">Menu</span></button>');

 var _this = $( this );
 _this.attr( 'aria-expanded', _this.attr( 'aria-expanded' ) === 'false' ? 'true' : 'false' );
 $(this).next("header .genesis-nav-menu, .nav-primary .genesis-nav-menu").slideToggle();

 if(window.innerWidth > 768) {
 $("header .genesis-nav-menu, .nav-primary .genesis-nav-menu, nav .sub-menu").removeAttr("style");
 $(".responsive-menu > .menu-item").removeClass("menu-open");

 $(".responsive-menu > .menu-item").click(function(event){
 if ( !== this)
 $(this).find(".sub-menu:first").slideToggle(function() {


See an other accessible example of an Accessible Genesis responsive-menu.js at GitHub. With the visual text “Menu” (I hate hamburgers) and a leading heading.

You have to add the screen-reader-text class and maybe change the CSS .responsive-menu-icon to style the button so it fits your theme.

So: by changing a few lines of JavaScript and adding a few lines of CSS you turn your responsive menu into a perfectly accessible awesome responsive menu.


Yes, this is a quick and dirty fix. There’s now untranslatable hardcoded text in the JavaScript, this could be done way better and cleaner. But you’ve got the picture of what needs to be changed. If you are a JavaScript pro: all help is welcome 🙂