Test results accessibility Gutenberg, July 6, 2017

In this post we gathered testing results for the new text editor Gutenberg.
As the functionality is work in progress, we will use these test results to create issues and add to the discussion on GitHub.
If you wrote a blogpost about this or published test results in another way, please add this as comment to this post, or tweet it to WPAccessibility. Then we’ll add it to the list of blog posts with testdata.

In this post:

  • Results WPa11y test team
  • Blogposts with test data and research
  • Call to action

Results WPa11y test team July 6th 2017

Thanks to: Janki Moradiya, Riddhi Mehta, Shah Rishi, Geof Collis, Gabriela Nino de Rivera, Reagan Lynch, Shaun Everiss

We asked the accessibility test team to look at the plugin. Below are the reported a11y related experiences and issues:

General opinion:

Reagan: My first and initial impression, and yes I understand this is early testing, is that Gutenberg is a major change and major step backward in WP accessibility. I strongly encourage the WordPress development team to NOT put this as the default editor. If you want to force it then do so on wordpress.com, but give us a choice with the .org (self-hosted) version. Gutenberg as it currently stands will force me to consider other platforms. In fact, after giving up on the second blog post I opened a Ghost account for the first time ever and began learning how their system works. If Gutenberg becomes the default Ghost will be the more accessible platform. (Using Windows 10 with Firefox and JAWS for Windows.)

Geof: To put it mildly, I don’t like it, it is too complicated and busy. I found it easier to add an image and move it around with in the main body if necessary, using a screen reader there are too many actions to deal with, I hope they drop the idea. (Using IE 11.096, JAWS 11 with latest updates, Windows 7.)

Shaun: I think in general, as long as you never need to change styles, add lists of media or ever interact with the button panels, then you should be fine. So what if you have to? You just can’t [Editor: mild translation of the original text]. (Using Win7 Pro, NVDA, Firefox)

What is a better experience

Without assistive technology:

  • Block arrangement and easily adding blocks on the post
  • Embedded any video or clip is too easy.So, now add media it’s not tedious anymore
  • The main part is code option is we can add the shortcodes and other PHP code directly. It’s so cool
  • Display latest post via Widgets is too easy
  • Add all HTML element easily and mainly add and other tags which are very interesting.
  • Easily move blocks with the up-down errors is too useful
  • The look and feel of the visual editor are good and it is very easy to manage content and I think it’s time-saving for development.

What is worse

Without assistive technology:

  • Aligning blocks and makes clicking into content areas are problematic.
  • Having a whole section for Embeds of only tangential use seems clumsy.
  • When I publish the post there is not a “VIEW” button available for that post edit screen of Gutenberg.
  • If writing something in the text block and click on undo button it was removing the whole section instead of new word or sentence.

If I select any text from the content block then it’s selected the whole block for delete so, it’s considered my selection as deleting a block. For batter understanding, I have captured a video for the same.

With VoiceOver + Safari:
It was very difficult to navigate between blocks and options for formatting. If I have more than 2 blocks moving from one block to the other is a long way. I need to pass through each menu and button associated to the block. It is very tiring. Also, accessing options in the menus don’t respond well to VoiceOver commands. I was often redirected to other places in the page like “post settings” or “skip to main content” link.

The insert button it was not intuitive, it took me a while before finding how to insert a block image.

Insert link options buttons (enter, edit and erase) does not seem to have labels. VoiceOver announces them only like “button”.

When inserting a link, if I don’t type a URL address beginning with http://, Voiceover announces that the data is invalid. The insert link object keeps announcing “Enter a URL” like if any text were already typed. There is not a proper message to explain the user why the data is invalid or a placeholder (or something else) to show the expected input format.

What is impossible to do

Without assistive technology:

I think in current version changing the post format is impossible.

Not able to move “Separator” when blocks structure are typical. For better understanding, I have captured a video for the same.

There is always a placeholder “Write…” with text box it’s become confusing to add new block and it consumes one block space as well. For better understanding, I have captured a video for the same.

I have created a table and added data into it. Later I add the table in the same post the table will create with old table data automatically. If I delete the table from the post and later I add the table it will comes with the last data of the table.

With VoiceOver + Safari:
When editing text in a block, it is better to select an option in a menu before writing content. If text is already in the block, it is not possible to select it and then select an option in the menu to apply a format (like for example select a list, or bold or italic). I think it would be nice to have shortcuts for applying format without quitting the block. Something like selecting text and then using a shortcut for applying the desired format without having to navigate all the elements between the block and the menus.

Settings button does nothing when clicking on it.

With Windows 10 with Firefox and JAWS for Windows.

The post screen does not have a very intuitive layout. In visual mode the buttons to edit do not appear until after I begin to add content. I’m unclear on how or if I can change the level one heading for the title.

When I tab from the title field to what should be the content area I think I was adding a line of content. Upon pressing enter to start a new paragraph I was taken out of forms mode and completely lost on the page for a few minutes. I should not be taken out of forms mode in a content body text area type field.

I changed to the text mode, and while typing content was easier when I attempted to select text to make a link I saw no field to add a link like is currently present with the editor in 4.8.

At one point when I selected text to make a link and then pressed enter on the link button in text mode text I had entered disappeared. From reviews I’ve read it seems there are buttons that appear when I first enter a “block”, but using a screen reader I don’t know what those are.

I like to write blog posts and page content outside of WordPress using an editor like Jarte. When I copied text out of Jarte in this test and went to paste it the experience was terrible. I cannot paste without losing all formatting. I also don’t understand “blocks”. Using TinyMCE I feel like I’m in a very accessible environment. With Gutenberg I want to stop blogging.

ON the Gutenberg page it says, “The goal of the block editor is to make adding rich content to WordPress simple and enjoyable.” Well I hate to say it, but as a power user of WordPress it makes adding rich content more complex for me.

I wrote two blog posts, or tried. With the first I used my normal copy editing process and had the post done and ready to go within an hour. WithGutenberg I was still trying to format the text correctly two hours later and had missing content that just disappeared. I gave up in frustration over the process

What don’t you understand

Without assistive technology:
I did not understand the work or use of the first button in post settings panel.
Toggle button in the settings panel

I found that in text editor all top buttons/tags are not working properly and when I click on them or out site the text editor “” and “” added automatically and it looks very confusing for me.

I did not find how to add the new row or new column in table format.

Blogposts with test data and research

If you wrote a blogpost about this or published test results in another way, please add this as comment to this post, or tweet it to WPAccessibility.

June 2017

Juli 2017

Other lists

Call to action

If you wrote a blogpost about this or published test results in another way, please add this as comment to this post, or tweet it to WPAccessibility.

If you want help testing and fixing? please read Help needed from accessibility experts with the development of Gutenberg.

#accessibility-usertest, #gutenberg

Revising the WordPress Editor: Gutenberg and Accessibility

One of the three top priorities for development in the next releases of WordPress is to enhance and modernize the editor. This is an important project to give users the ability to create rich and diverse content without requiring extensive knowledge of code. From an accessibility perspective, this is both an incredible opportunity to build a powerful and flexible experience for all users and an enormous risk that we could end up reducing the effectiveness of the editor for users with disabilities, or require them to use a 2nd-class editor without these enhanced editing capabilities.

We in the WordPress accessibility community embrace the challenge of creating a great new experience, and want to assure the community that we are going to do everything we can to make sure that any new editor experience is as accessible as we can possibly make it.

The most fundamental part of democratizing publishing is the ability to write and publish content. Without that feature, WordPress is not achieving its core mission. There are always challenges in creating content accessibly, but it is not an unachievable goal.

It’s still early in the process, and there are many ideas floating around about how the new editing experience should be structured and how its interface should behave. The concerns for accessibility are universal, however. The new editor should consider accessibility to be a priority both in how content is created and in the nature of the content that is created.

While the accessibility team wants the final implementation to be exceptional and accessible, we don’t want to limit the possibilities by imposing restrictions before they are necessary. However, there are some concepts that should be kept in mind early on that will significantly impact accessibility during development.

Fundamentals of Accessibility to Consider

  1. Some common user interface interactions are extremely difficult to use non-visually. Drag and drop is an interaction that poses significant difficulties, since it is very difficult to disclose in audio how the dragged object and the potential targets are interacting. This doesn’t mean that the editor can’t use these interactions, but if they are used, there will need to be an alternative method to do the same task which is accessible.
  2. Fundamentally, all outputted code is organized in a linear manner. The experience of the content for keyboard users and for screen reader users will also always be linear. Ensuring that the content authoring process encourages a linear path will make the process easier for all users.
  3. Whenever possible, the user interface should encourage people to create semantically valid code; encouraging the use of correct headings (e.g., being content aware to know which headings are valid for a new content block); encouraging the addition of alt attributes, or defining table headings appropriately for tabular data.

Updating the editor is a great opportunity to explore some of the requirements articulated in the Authoring Tool Accessibility Guidelines (ATAG). These requirements discuss how an editor should allow users to navigate the structure of their content and how the editor should encourage the creation of accessible content. A richer editor experience, with integrated prompts and formatting tools, has the potential to suggest best practices throughout the content authoring process. This would be an important growth step for WordPress.

It should be self-evident that the new editor experience needs to meet the standards established for accessibility in WordPress core. The editor is the central experience of WordPress content creation, so planning ways to consider accessibility at every stage through the process is crucial to the success of the Editor project.

Help develop the new editor

If you’re interested in helping with the new Editor project, follow the development conversations in #core-editor and share your thoughts and ideas. You can also follow the GitHub project for the editor, where you can file tickets or follow specific issues like keyboard shortcuts, drag and drop, and the mobile interface. Weekly chats are in #core-editor, Wednesdays at 18:00 UTC.