Accessibility recommendations and discussion

[rianrietveld]

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.

[jasmussen]

Great list of recommendations, thank you for taking the time to put this together. Lots of specific and actionable recommendations too 👏

It's also heartening to see that a lot of the issues put forward, like focus and modality, can go very well hand in hand with the block-specific approach at the heart of our efforts.

A few questions:

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.

Is this an accessibility issue, or a semantic issue? Note that by asking this question I'm specifically not taking sides, nor do I have a strong opinion. But if it isn't an accessibility issue, it should probably be raised as a separate ticket.

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

Is this a regression in the block first approach compared to the current editor where the contents of a blog post aren't labelled at all? Was this recommendation surfaced from specific accessibility issues surfaced by the idea of treating sections of contents as disparate blocks, compared to the current editor behavior? Edit: And can such a label be an attribute, or otherwise hidden visually?

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

The prototypes have been shown without the surrounding WP-admin. And this will not be the final form. Here's an early mockup of the editor shown in WP-admin context: https://wpcoredesign.mystagingwebsite.com/gutenberg/#admin

Is there a way to flip back to the current editor

Do you mean if the Gutenberg editor focus is a success and gets merged into WordPress? Then no, there probably won't be a way to switch to the editor that comes with WordPress today without installing a plugin.

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.

That's an interesting idea, which would potentially be possible in the future. However it's likely the textarea editor that exists in WordPress now will stay mostly as is, though the method for switching to HTML mode might change.

[aardrian]

Regarding the heading bit:

Is this an accessibility issue, or a semantic issue? Note that by asking this question I'm specifically not taking sides, nor do I have a strong opinion. But if it isn't an accessibility issue, it should probably be raised as a separate ticket.

It is a structural and accessibility issue. If an author is too cavalier in choosing headings (such as based on how they look, not which is appropriate for the content structure) then it can inadvertently make it easy for an author to fail WCAG sections 1.3.1, 2.4.1, and 2.4.6. Preventing an author from using an <h1> at least reduces some of that risk.

Regarding the labeling of content areas:

Is this a regression in the block first approach compared to the current editor where the contents of a blog post aren't labelled at all? Was this recommendation surfaced from specific accessibility issues surfaced by the idea of treating sections of contents as disparate blocks, compared to the current editor behavior?

This recommendation came from no comparison to the current editor. I raised it based on the notion of treating each content block as a modal when it comes to editing. It may be difficult for a user to quickly understand in which content block he or she is about to start editing, and reading the entire block to understand that can be verbose (especially if that is the accessible name). Since each block must have an accessible name, I am simply raising it as something to be addressed. How you name them, which technique you use to provide that name, is something that would require more research and time with your prototypes.

[rianrietveld]

There may be an argument agains leaving out the <h1>.
Some page builders and themes strip out the title on a page/post, so the <h1> must be added in the content.

[ellatrix]

Regarding the headings, I've been thinking for a while that it might be good to auto-set heading levels and only allow to go one level up or down (effectively ending a sub-section or starting a new sub-section). This could be quite similar to lists in terms of UI.

I'm not sure what the arguments would be against this. One could be less freedom and not being able to use it for random bigger text, but that's something it shouldn't be used for anyway. To resolve this issue, we could create a new "Big Text" block which we can do semantically correct and can be styled differently by the theme. We could also allow some variation in bigness of course, but even without it's a good start I think.

<p class="stand-out">...</p>

On the other hand, I'm not sure if it's a good idea to just add a very general purpose block. It could be misused as well for text that should be a heading, or should be strongly emphasised. It would be good to go over some examples in real posts/texts and learn what is needed. Maybe the author just wanted a different quotation style, or a warning box, or something like that.

[joyously]

The editor should not be the "content police". It has no knowledge of context. What if your blog was about HTML and how to write it? The content would be full of examples, so the user could see how they are rendered. Limiting what the user writes is dangerous territory --- censorship!
And don't be thinking that the editor is doing any styling of the content. That should be entirely the theme's job. Adding classes to blocks for styling is the main reason why I want to be able to edit the raw HTML.

[ellatrix]

The editor should not be the "content police". It has no knowledge of context. What if your blog was about HTML and how to write it? The content would be full of examples, so the user could see how they are rendered.

You can use pre for examples or use section/aside/figure containers to display the HTML. Heading hierarchy is per sectioning root.

Limiting what the user writes is dangerous territory --- censorship!

There are always limitations in a visual editor. For more complex things, you can always use the HTML editor. I wouldn't call this censorship. :)

And don't be thinking that the editor is doing any styling of the content. That should be entirely the theme's job.

I'm not suggesting that.

[BE-Webdesign]

@joyously,

I had the same worries at first, but after mulling things over a bit, I am confident that things are going to work out well for everyone. I think the new block editor and the HTML editor are going to be two separate things essentially, that won't conflict (or won't conflict if used properly). Probably within the block editor there will also be an HTML block, so if you wanted to, in theory, you could edit the same way you do now, all in one huge HTML block (pretty much what the current WordPress editor is). For people who do not understand HTML, nor care to learn about it ( a lot of people ), I think it will be amazing to give them tools to build a really engaging experience on their website/blog. Those tools that will empower many to more easily build a website is what the focus of this effort is, or at least that is my take. I believe one of the goals is to always have the HTML editor available for those who want/need it.

Limiting what the user writes is dangerous territory --- censorship!

The block editor on its current path, will be lifting the censorship of expression for many users, who will now more easily be able to create compelling content and share their stories. I personally do not see any limiting only expanding.

[jasmussen]

Regarding the headings, I've been thinking for a while that it might be good to auto-set heading levels and only allow to go one level up or down (effectively ending a sub-section or starting a new sub-section). This could be quite similar to lists in terms of UI.

Recent discussions around SEO and accessibility on the core Trac seems to suggest this may be a good way to go (which surprised me a bit to be honest). I like it!

And in that vein, it seems only fair to refer back to the vision that @shaunandrews put forth 25 days ago:

I think with a few tweaks there could be something there!

[ellatrix]

Yeah not displaying all options at once could help too. What about displaying a button for one level higher and lower? As you click on the button, the number still change, so in this example, clicking on H3 would replace the numbers with 2-3-4, where 3 is active.

And when inserting a new heading, we take the heading level of the previous heading as the default.

[joyously]

Wow, I obviously need to work on communicating ideas.

You can use pre for examples or use section/aside/figure containers to display the HTML. Heading hierarchy is per sectioning root.

What part of "how examples are rendered" works with pre or figures? If the site is about seeing how your choice of browser renders the HTML, the examples need to be in the content, not necessarily in accessibility order or hierarchy.

There are always limitations in a visual editor. For more complex things, you can always use the HTML editor. I wouldn't call this censorship.

The limitations of the editor are fine by me. Just don't limit what the user can write with it. Suppose I have a heading already, in the editor. It's the right hierarchy. Now I decide to move it. Will the editor let me move it to a wrong place in the hierarchy? Do I have to change it before I move it? (editor won't let me) Do I have to delete it and add a new one in the other place? Censorship of any kind is problematic. If you want to have an accessibility check on Save, that would a better way to handle it. Trying to do it as the user edits is a mess. It's all about context, which the editor doesn't know.

[ellatrix]

What part of "how examples are rendered" works with pre or figures? If the site is about seeing how your choice of browser renders the HTML, the examples need to be in the content, not necessarily in accessibility order or hierarchy.

<p>Main article...</p>

<figure>
  <h1>Main heading</h1>
  <p>Some text.</p>
  <h2>Second-level heading</h2>
  <p>Some text.</p>
  <figcaption>Example of HTML headings</figcaption>
</figure>

[joyously]

only allow to go one level up or down

So I couldn't write
h1. high level
h2. sublevel
h2. sublevel again
h3. subsublevel
h1. second high level

[ellatrix]

Yes, you could. I meant that you can close any level, but only jump down by one level, much like indenting lists.

I made a mistake by saying "only allow to go one level up or down". It should be "only allow to go one level down from the last heading". You should be able to go as many levels up as you want.

[grahamarmfield]

Whilst I believe that a good heading structure is important in a web page or post, I'd be uncomfortable about the editor enforcing levels.

Either through a plugin or in a custom built theme, a shortcode could add headings into the page at a certain level. Unless it's going to get into interpreting shortcodes, the editor is not going to know this. So the editor may inadvertently mess up heading order for the page, or make it hard for the content author to get it right.

I do think it would be a good idea for the editor page to contain some basic guidance for content authors as to why a sensible heading structure is good for accessibility as well as SEO. Maybe this should go in the dropdown Help section along with a bit of advice about adding alternate text for images etc.

[afercia]

Worth mentioning TinyMCE has an accessibility checker plugin that checks for headings hierarchy:

Enabled and testable on the demo https://www.tinymce.com/

[jasmussen]

Worth mentioning TinyMCE has an accessibility checker plugin that checks for headings hierarchy

I like that heading size best practices are surfaced in an advisory manner, rather than enforced.

[karmatosed]

I 'think' most of these things have now been done or have issues for. I am going to close this issue but if we haven't caught any, please make an issue so we can.

[afercia]

I'll take care of splitting the issues that aren't fully addressed or not addressed at all in separate issues or mention them in existing issues.

There is one big item that hasn't been addressed so much, though:

Test with non tech users and users of AT

Note: AT = Assistive Technologies 🙂