During the contributors day at WordCamp London we discussed Gutenberg with @afercia @aardrian @samikeijonen @grahamarmfield Claire Brotherton @moorscode and @rianrietveld.

This ticket is to bundle the recommendations and to be used as tracking ticket for accessibility issues with Gutenberg.

Recommendations by Adrian Roselli (@aardrian)

1. Each content area should be set as its own editable region, one at a time. Not the parent container. This means you may need to wrap content in arbitrary containers just to allow editing.

2. Focus management will be crucial, as once the content area gets focus, the corresponding toolbar will need to be keyboard accessible.

3. As I am thinking about this, it occurs to me that treating each content area as a modal once it has focus might be a good idea. The advantage is that it forces the context to be contained within the editable area.

4. Each control must have a an accessible name. The SVG now has <title> elements, which is good, but you will likely need to lean on aria-label or aria-labelledby (testing will be needed).

5. You will have to support Windows High Contrast Mode in your controls, including the SVGs for the buttons. Luckily, this may not be very hard for single-color SVGs as the fill can be defined via a media query.

6. You may want to explore a method for making the alt text for an image visible while editing, plus an easy way to edit it. While the alt text may come in from the media library, context means it might need to change on a per-use basis. Showing it is a good reminder.

7. The ability to add a heading is nice, but I am wary that this will make it easier for people to choose a heading based on how it looks, not what is the appropriate level. Auto-restricting to one <h1> would be a good start. Recommending levels would be swell, if you can parse the page content appropriately.

8. The icons (such as for headings and arrows and the like) will need some sort of visual explanation. I would not use a title attribute, but instead look at a programmatic tooltip that can be enabled/disabled as a user setting.

9. The Esc key should always get me out of whatever thing I am trapped within.

10. Make sure to undo all contenteditable attributes when done with a content area. Much like focus management.

11. Labeling the content areas will be important so a user knows what he or she is doing and where. Much like a modal needs a title (or any control needs an accessible name).

12. I am wary of allowing each paragraph to be editable as a stand-alone instead of within a larger editable block. I can offer no reason why off the top of my head, but my gut tells me this may be a problem for content authors.

13. Will there be a way to quickly jump into the full WP admin from any page to do more editing?

14. I am wary of using application-style roles, such as the aria menu role and its patterns as users do not typically know them and the context does not apply (most of those roles are informed by desktop applications).

Resources:

• Content areas and spell-checking https://www.paciellogroup.com/blog/2017/02/in-browser-spellchecking/
• Description of keyboard interaction for a modal https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal
• Description of the tooltip pattern, still in development https://www.w3.org/TR/wai-aria-practices-1.1/#tooltip
• Menu bar pattern https://www.w3.org/TR/wai-aria-practices-1.1/#menu

Other points the group came up with:

• Test with non tech users and users of AT, grab a sample text and let users try it and ask for expectations.
• Make the alt text visible (as a check what it is and if it makes sense in this context)
• Is there a way to flip back to the current editor
• How to expose HTML. The advantage of this block structure may be that you can edit only that HTML of that block. Editing by block would be a huge time saver for large texts.