Accessibility team meeting agenda: November 16th

This is the proposed agenda for the accessibility team meeting on November 16, 2018 16:00 UTC

  • Current progress on Gutenberg accessibility
  • Current progress on Gutenberg accessibility documentation
  • Feedback from 5.0 accessibility lead about the information message for assistive technologies users (see comments on ticket 45270). 
  • WCUS Contributor Day accessibility team table / The Hackaton
  • Open floor and/or Discussion on a few tickets/issues, time permitting

If you have anything to propose to add to the agenda or specific items related to the above, then please leave a comment below. Either way, everyone is welcome to join!

This meeting is held in the #accessibility channel in the Making WordPress Slack (requires registration).

Hackathon automated accessibility testing with Deque on the WCUS contributor day

At WordCamp US in Nashville, Deque Systems will join the accessibility team for a hackathon to set up automated accessibility testing for WordPress core, on Sunday, December 9th.

The goal is to include accessibility checks for core, together with the current tests, like Unit and e2e tests and the checks for PHP coding standards we have now.

Deque develops tools like aXe core that can be used for automated testing and they will be sending one or two of their lead developers to work on this with the WordPress core developers.

From the WordPress side we would like to invite core developers to join in and help find solutions to set this up.

Do you know your way around the automated testing system of WordPress core, do you attend the contributor day and do you have time to help?
Please contact the accessibility team in WordPress Slack in the #accessibility channel.

Gutenberg Accessibility Status Update

Gutenberg 4.3 was released today with a number of continuing accessibility adjustments.

Major accessibility changes in Gutenberg 4.3 include:

  1. PR 11466: Add aria-label to images in Gallery block during edit mode/a>: Uses aria-label to communicate the position of the image inthe gallery as well as information about the image. (Furthers the work on Issue 3836, mentioned last week.)
  2. PR 11459: aria-checked only allowed on matching ARIA roles – fixes an issue so that the active block will be announced in the block navigation list.
  3. PR 11607: Alt+F10 should navigate to block toolbar regardless of visibility – Fixes an issue where block toolbar could not be focused by shortcut if it was not already visible.
  4. PR 11543: Return focus to element that opened publish panel – Ensures that focus is not lost after publishing post.
  5. PR 11422: Add multi-block selection announcement. – Read out the number of blocks selected when more than one block is selected.
  6. PR 11403: Constrain tabbing with post publish panel – Completed in-progress feature identified last week.

A few more minor issues have also been addressed:

  1. PR 11560: Improve empty block text – Resolves issues #9076 and #5591 by fixing the text present for empty blocks to a) make it self-consistent and b) clarify how to use the forward slash shortcut to change blocks.
  2. PR 11653: Change aria-label depending on content of paragraph block – Ensure that empty paragraph blocks get instructional text and non-empty blocks get descriptive text.

There are currently 90 open accessibility issues on Gutenberg. (Versus 89 as of last week.)

Pull Requests in Progress

There are currently 19 open pull requests labeled for Accessibility.

Requests 11218 (alt attributes on images in the editor) and 10462 (move block toolbar below block contents) were highlighted as important requests in progress, and are still in progress.

Accessibility Team Meeting Notes: November 9, 2018

Meeting transcript on Slack

Current progress on Gutenberg Accessibility

At the time of the meeting, major issues with Publishing Flow were near merge and expected to land soon. Otherwise, minor fixes to labels are all that’s been implemented. The publishing flow fixes were the last of the accessibility issues previously listed in the Merge:Accessibility milestone (although Gutenberg was in fact merged prior to meeting these issues.)

@tofumatt indicated that he intends to work on identifying a next phase of high priority issues now that these are resolved.

Current progress on Gutenberg accessibility documentation

@abrightclearweb sent an update indicating that the accessibility documentation for Gutenberg is mostly finished, but needs editing. 

Feedback about the information message for Assistive Technology users (#45270)

The accessibility team greatly desires a transparent notification to give users of Assistive Technology immediate information about the state of accessibility in Gutenberg and the opportunity to install the classic editor plug-in. Given recent conversations about bundling the classic editor plug-in on updates, this would greatly assist feasibility, and may change the way it is presented.

We will provide further ideas and suggestions within the ticket to try and identify the best method and text to express this. 

Discuss current Gutenberg Block issues

Some blocks (notably the media with text,  table, column, and list blocks) have noticeably worse accessibility than others. We need to decide whether we want to specifically recommend that blocks be omitted from the release until they are improved. Some of these blocks are in need of significant work due to bugs in essential functionality, so they should improve, regardless. 

We will post recommendations on Monday, based on a review of progress at this point in the release candidate.

Open floor

We discussed issue 10559 “Current block invisible focus when Unified Toolbar is on“. This issue touches on the removal of focus and hover outlines on blocks when using the unified toolbar interface option. We feel that there are users who may prefer to have both the focus tools and the unified toolbar option, and this is currently not possible, despite the fact that there is an additional option (spotlight mode) that also removes the focus and hover outlines. 

Author note: at the time of the meeting, WordPress 5.0 was scheduled for November 19th. The release of WordPress 5.0 has been shifted to November 27th, and other dates have also been adjusted. The meeting record reflects the dates as known at the time of the meeting.

Accessibility team meeting agenda: November 9th

This is the proposed agenda for the accessibility team meeting on November 9, 2018 at 16:00 UTC:

  • Current progress on Gutenberg accessibility
  • Current progress on Gutenberg accessibility documentation
  • Feedback from 5.0 accessibility lead about the information message for assistive technologies users (see comments on ticket 45270). 
  • Discuss some current Gutenberg blocks issues:
    • Media & Text
    • Columns
    • Table
    • List
  • Open floor and/or Discussion on a few tickets/issues, time permitting

If you have anything to propose to add to the agenda or specific items related to the above, then please leave a comment below. Either way, everyone is welcome to join!

This meeting is held in the #accessibility channel in the Making WordPress Slack (requires registration).

Gutenberg Accessibility Progress Report

Since the release of Gutenberg 4.1.0, 18 pull requests labeled as accessibility issues have been committed to Gutenberg. Not all of these fixes are in the current release (4.2), as work has already begun on Gutenberg 4.3.

Major issues include:

  1. Issue 3836: Gallery block: images and selection and removal not keyboard accessible. Addressed in Pull Request (PR) 3836. Still needs further testing and fixes to image labeling that needs to consider cases where the user-provided images do not have alt attributes.
  2. Issue 9583: Keyboard navigation when inserting a block has unexpected behaviour. Addressed in PR 11088. This is a significant change towards making keyboard navigation behave more predictably.
  3. Issue 8266: Can’t edit an existing link using only the keyboard. Addressed in PR 10983. Fixes an accessibility regression from after Gutenberg 2.9.0 that made this impossible.
  4. Issue 8079: Sidebar header: avoid focus loss and other improvements. Addressed in PR 10917 and PR 10927.
  5. Issue 10583: Regression: The inserter search results don’t use an audible message any longer. Fixed in PR 10755.

These changes include important changes impacting the reliability and predictability of Gutenberg for assistive technology (AT) users. More of the blocks are functional for AT, and navigation tools work more predictability.

The remaining 12 pull requests primarily address a variety of minor interaction issues and labeling issues.

There are 89 open accessibility issues on Gutenberg. 

Pull Requests in Progress

There are 23 pull requests in-progress and labeled for Accessibility, as well. PR 11403 is particularly important in moving towards a more accessible publishing flow, partially solving the issues raised in Issue 4187. Another key in-progress PR is PR 11218, which provides alt attributes on images in the editor that don’t have author-provided alt text. This will be key in completing the resolution of issue 3836, above.

PR 10462 is in early stages of development, but would make a significant difference in resolving some of the keyboard challenges in navigating between the sidebar block settings and the block itself, by moving the block controls after the block in the DOM. In the example keyboard navigation provided in the Accessibility Status Report last week, this change would eliminate 13 of the 34 keyboard stops in that process. 

Accessibility Team Meeting Notes: November 2, 2018

Meeting transcript on Slack

Scheduled bug scrub for 5.0 release

WordPress 5.0 bug scrub sessions are scheduled and listed on this post.

Move meeting and bug scrub timeslot after end of Day Saving Time

The new Accessibility meetings timeslots are:

Accessibility bug scrub: Friday, 15:00 UTC
Accessibility team meeting: Friday, 16:00 UTC

Gutenberg accessibility documentation

@abrightclearweb got back to working on the documentation but have had to revise a fair bit of what was there due to the UI changes.

This Document is available here. Feel free to contribute, it is open for comments and suggestions.

Feedback after the Gutenberg Accessibility Report

Note: we refer to the Gutenberg Accessibility Report Post.

@joedolson ’s overall feeling is that it’s been good for exposing issues to the larger community and clarifying the concerns, but it has not had any effect on the proposed schedule.

The Accessibility team members have made their stance clear, and they think it would be nonproductive for the team to continue to make noise about that – if this article wasn’t enough to budge the schedule, then the team needs to embrace what they have and just try to get specific issues resolved.

In that end, @joedolson is going to write a post detailing accessibility improvements in Gutenberg since last Monday, and try and keep positive momentum.

The team agreed that It’s fair to say Gutenberg is better than block-based equivalent interfaces because of the accessibility work done.

Side note: If you want to be acknowledged as signatory of the report, please feel free to reply to the first comment with your name.

Notice for assistive technologies users to include in WordPress 5.0

The Accessibility Team ask to include a clear notice to inform users of assistive technologies they can still use the Classic Editor plugin which is maintained by the WordPress community. 

A Trac ticket was created following this discussion.

Conclusion

The remaining items of the agenda will be discussed during the next Accessibility Team Meeting.

Next meeting: November 9th, 2018 at 16:00 UTC

Accessibility team meeting agenda: November 2nd

This is the proposed agenda for the accessibility team meeting on November 2nd, 2018 at 15:00 UTC:

  1. Move meeting and bug scrub timeslot after end of Day Saving Time
  2. Feedback after the Gutenberg Accessibiity Report
  3. Notice for assistive technologies users to include in WordPress 5.0
  4. Gutenberg issues that have been closed as “solved” but we don’t consider really solved based on the Accessibility Report
  5. WCAG success criteria: should the team refer to WCAG criteria in issues?
  6. Open floor and/or Discussion on a few tickets, time permitting

If you have anything to propose to add to the agenda or specific items related to the above, then please leave a comment below. Either way, everyone is welcome to join!

This meeting is held in the #accessibility channel in the Making WordPress Slack (requires registration).

Accessibility Team Meeting Notes: October 26, 2018

Meeting transcript on Slack

Agenda for the meeting

  1. Discuss bug scrub weekday/time
  2. Discuss and validate Gutenberg accessibility feedback before publishing
  3. Open floor

Bug scrub weekday/time

As the Accessibility meeting weekday/time has moved to every Fridays, 15:00 UTC, bug scrub meeting also moved to Friday, 1 hour before the meeting.

Accessibility bug scrub: Friday, 14:00 UTC
Accessibility team meeting: Friday, 15:00 UTC

Please note that both will move after Day Saving Time end in the US.

Discuss and validate Gutenberg accessibility feedback before publishing

The aim of this document is to address in an objective and professional way the accessibility issues encountered with the Block Editor. The focus is set on the ability to author, edit, and publish posts, which is the primary purpose of WordPress.

There is 5 groups of issues:

  • Cognitive Load & Complexity
  • Inconsistent User Interface Behavior
  • Accessibility Anti-Patterns
  • Keyboard Shortcuts
  • Keyboard Navigation

The post is available on Make/Accessibility Blog:

The team tried to make this communication accessible to users with no or little accessibility expertise. If you have any question about this document, please comment it.

Open floor

The team discussed some best practices for a better accessibility in Slack conversations:

  • Do not use threads as they are not accessible
  • Avoid large blocks of text
  • Give some time between messages
  • Consider people have different typing speed
  • Use formal beginning/end markers
  • Emojis: are they accessible?

Persons with accessibility needs are encouraged to give feedback and ask for improvements they would like to get.

Next meeting: November 2nd, 2018 15:00 UTC

Report on the Accessibility Status of Gutenberg

On October 3rd, the schedule for WordPress 5.0 was proposed. Prior to this, the accessibility team had not been made aware of a release time frame, and had no reason to believe WordPress 5.0 and the Gutenberg editor were under time pressure. The schedule proposed a release date of November 19th – 6 weeks from the announcement date.

The initial reactions to the announcement of the release schedule were negative, which is unfortunate. We have no desire to increase the fear, uncertainty, and doubt surrounding the release of Gutenberg. To that end, this article is intended to shed light on the issues the WordPress Accessibility Team sees as most critical to the success of Gutenberg at release.

We want to give some background on the Accessibility Team, the commitment WordPress has made to accessibility, and then dive into the issues in Gutenberg as of this writing. The issues addressed come from reviews of version 4.1.0 of the Gutenberg plug-in released on October 24th, 2018.

Who is the Accessibility Team

For anybody reading this post who’s not already deeply involved in the WordPress project, it’s important to give some background about the team structure in WordPress generally, and about ourselves specifically.

All teams in the WordPress project are made up of people who  volunteer their time to focus on a specific issue affecting the project. We’re not employees of any specific company,  and for the most part, our roles in the WordPress project are the results of our own choices, not because of an assignment from our employers. We can’t speak for every individual in the project – there are probably some people who work in a specific focus area because their employer wants to have an impact there.

On the Accessibility Team, we all have volunteered to participate on this team out of a desire to see WordPress provide a more accessible experience.

The team includes people who have 10-20 years of experience working professionally on web site accessibility and people who are completely new to the topic, but are motivated to learn.

The Accessibility Coding Standards for WordPress

In December 2015, members of the team met at the WordPress Community Summit in Philadelphia and proposed adding a commitment to accessibility as part of the core coding standards. These standards were published for public feedback in January 2016, and approved as part of the core standards in March 2016.

These guidelines are intended to set an expectation that all new code or significant updates embrace the standards in WCAG 2.0 at level AA.

It is important to acknowledge that it is possible to meet the standards in WCAG 2.0 AA without providing a reasonable user experience for users with disabilities or dependent on assistive technologies.

The Accessibility team – like any team in WordPress – has no specific authority over the project. Because we’re a small team of volunteers, we’ve been pragmatic in how we apply the guidelines. We have made tradeoffs in prioritization. Gutenberg is a place where we feel it is necessary to draw a line. The ability to author, edit, and publish posts is the primary purpose of WordPress.

Is Gutenberg an Accessibility Regression?

We want to acknowledge that the Gutenberg team has worked very hard, and have resolved many of the important accessibility issues raised by the Accessibility Team during development. They’ve built entirely new components to replace problematic interfaces like date pickers and color pickers. Keyboard accessibility has been built into the end-to-end testing processes. The accessibility work in this project is impressive.

Despite this  dedication to accessibility in individual interactions, Gutenberg remains a system with significant challenges for users.

Gutenberg remains a problem because users cannot succeed by using only discrete components of the application. Even though each individual component is or will be accessible, the user needs to use the entire application.

Because the complexity of interaction with Gutenberg is an order of magnitude greater than in the classic editor, we believe that Gutenberg is less accessible than the existing classic editor, though it offers many great features that are not available in the current editor.

Issues with Gutenberg

The specific issues with Gutenberg are reasonably well represented by the issues published under the Accessibility label in Github. What is not so easily identified from a review of these issues is the systematic nature of some of the accessibility problems.

While we can’t address all issues or types of issues in this article, we can address a handful of the problems with Gutenberg that have a profound impact on users of assistive technology and need to be addressed systematically.

Cognitive Load & Complexity

At the very top of our list of concerns, we feel the overall experience for users with accessibility needs is an accessibility regression. This is due to the complexity of the interface and unexpected, non-native, interaction with many components. These non-native interactions impose a  steep learning curve on users of assistive technology as their normal modes of interaction may not work as expected.

Contributing to the challenges of locating and remembering the location of controls, we find  visual design considerations have been given priority over information architecture. The order and logical grouping of the user interface controls should be paramount for all users. Instead controls are grouped in a way which may seem arbitrary. In addition to the lack of a systematic organization of the controls, they are continuously appearing and disappearing.

Constantly shifting controls are confusing for screen reader users in particular, as they don’t get the visual affordance to know when something is no longer available in the interface. The classic editing experience was linear, contained within a single block. The controls were in a single fixed location on the page. This provides a predictability that is no longer present in the interface.

This issue has been regularly reported by users of screen readers, but has not been effectively resolved. Rather than addressing the specific issue – buttons that appear and disappear in an unpredictable fashion – new tools have been added to provide another alternative mode to navigate between blocks. (See issue 10545, “Adds the block hierarchy navigation menu…”).

This tool is potentially useful, but it does not serve to simplify or streamline navigation.

Inconsistent User Interface Behavior

The cognitive load in Gutenberg is heavily influenced by inconsistent behaviors within the user interface. An issue reported in August 2018 reflects the experience of a JAWS user attempting to explore Gutenberg (and has not yet been handled). This user cited random changes of focus (which is likely related to keyboard navigation changes depending on the type of block, whether or not that block has content, and whether you’re navigating forwards from a block or backwards from a block.

Without any visual context clues about these controls, the focus would appear to be arbitrarily changed.

Additionally, some toolbar controls behave differently from others. This contributes to the impression of focus moving arbitrarily, since a user cannot readily predict what will happen on triggering these controls.

The combination of behaviors that are self-consistent, but appear inconsistent when you are not clear of the rules governing the changes (such as the block navigation) and behaviors that are not self-consistent (like toolbar buttons) creates a major usability problem.

Accessibility Anti-Patterns

While the efforts towards accessibility have been significant, there has been a strong dependence on methods we consider to be anti-patterns. First among these is a heavy use of ARIA attributes. ARIA, while sometimes necessary, should be considered only as a final option when no native HTML interactions are available.

This reflects a problem in the design process: beginning with custom controls (such as the “switch toggle”), then attempting to make them accessible rather than beginning with standard controls and making a functional interface.

Other anti-patterns incorporated in the design that should never have been under consideration include:

  • Placeholders replacing labels
  • Icon-only controls (buttons with no visible text label)
  • The Switch Toggle and other custom interface elements

Incorporating best practice accessibility into design at the beginning can help avoid these problems.

Keyboard Shortcuts

One of the only practical ways to ease the complex navigation between sections of the application from the keyboard is to introduce a variety of keyboard shortcuts. These can be helpful, but they create their own new problems.

The only way to totally avoid conflicts across browsers, assistive technology, and operating systems is to allow a mechanism for user to re-map and customize shortcuts. This has been an unresolved open issue since October 2017.

Keyboard shortcuts have inherent challenges in discoverability, but they do provide a learnable system to improve the user experience. Providing a method to customize these shortcuts would also act as a method to allow users to learn and reference the shortcuts from within their editing environment.

As it stands, Gutenberg provides these keyboard shortcuts for  people who depend on the keyboard, but does not fairly ensure that they can be functional.

Keyboard Navigation

The ability to navigate through a document is a key element of the editing process. In the current iteration of Gutenberg, this is a significant challenge.

Keyboard navigation through blocks is possible, but it requires a vast number of keyboard actions. There is a committed proposal from the accessibility release lead that’s related to this topic, but it’s unclear whether it truly resolves the issue.

The introduction of a ‘block hierarchy navigation menu‘ allows users to see a list of all blocks in a post and move their focus to a given block. This is certainly related, but it does not resolve several key concerns:

  • Keyboard navigation from block to block requires easily 10 or more tab stops, and the exact number of stops is highly variable.
  • Keyboard navigation by tab
  • Arrow key navigation between blocks can have some disconcerting behavior with screen readers. (In NVDA with Firefox it works reasonably well, but in NVDA with Chrome the reading cursor reads from the previous block though editing focus moves to the next block.)
  • Arrow key navigation sometimes moves directly between blocks and sometimes includes button controls, depending on where focus is currently set.
  • Moving between your current block and block settings is very difficult. You can use the landmark navigation keyboard shortcut to jump to the settings, but this requires multiple usages of a multi-key combination to get to the correct settings, the discovery of the settings in that panel, the discovery of the link to return to your selected block, then tabbing through all controls attached to the block before you reach the block content to return to editing. In a test to change the font size in a paragraph block, the following keyboard sequence was required (starting with the cursor in the block text.)
    • Press Ctrl + ` four times to locate the block settings.
    • Press tab five times to reach the font size selector.Discover the usage of the non-standard selector dropdown (normal selector: arrow key down to desired value, press enter to select, tab through rest of document. This selector: Enter  to expand dropdown, tab key to choose desired value, Enter to select that value, esc key twice to exit selector.)
    • Press tab six times to locate skip link back to selected block.
    • Press Enter  to activate the selected block.
    • Press tab thirteen times to reach the editable text of the block.
  • The above navigation scheme required 34 separate keyboard stops in order to change the font size of the selected text and return to the previous position, and is aided in efficiency by the tester’s prior knowledge of how to navigate the process. (Tested in Chrome and in Firefox using NVDA.)

We want to be clear that the above example is not comparable to the options available in the classic editor – there is no mechanism for increasing the font size of a paragraph in the existing editor. However, given the above requirements, there may as well not be one in Gutenberg. Changing the font size is just one of many editing features that are exclusively available from the block settings sidebar.

While this demonstrates an accessible process, when compounded into an interaction system that depends on dozens or hundreds of similar interactions, the end result poses significant burdens on the user.

One limitation of the block hierarchy navigation menu is in understanding the value of the represented blocks. What a user might want to do is edit the paragraph that starts with “The quick brown fox…”. What they are presented with is a list of enumerated block types. What value does “Paragraph 5 of 6” provide the user? Reaching a specific paragraph easily is only valuable if you have context for what you will be doing, and that information is not provided here.

Who is affected?

The accessibility issues in Gutenberg only affect the authoring and editing of content in WordPress. We don’t have any significant concerns about the code produced by Gutenberg – in fact, some of the tools in Gutenberg will hopefully improve the accessibility of produced code on the front-end.

All authors and editors will be affected by these changes. Administrators responsible for deciding whether Gutenberg is appropriate for their sites need to be informed that it may pose unacceptable barriers for their authors.

There is a long history of people with disabilities losing their jobs because they were provided with new ways of doing the job that imposed barriers for them. WordPress should not cause anybody to lose employment.

To this end, the accessibility team proposed a clearly discoverable notice in the WordPress 5.0 release to inform administrators of the risks in allowing Gutenberg for users of assistive technology and provide instructions on installing the Classic Editor plug-in. At this time, that proposal has been closed with the ambiguous note “5.0 will point users to the classic editor plugin if they need it.” It is not clear what this means or how it might be implemented.

In Conclusion

The main accessibility issues in Gutenberg stem from design issues, whether those are about the organization of controls, large architectural decisions, or specific small interface elements. We see WordPress as an inclusive community that embraces much of what is wonderful in the open source community, and has a history of providing a publishing platform that empowers all users to publish their content.

Gutenberg is the way of the future in WordPress, but the direction it has taken so far has been worrying. We do not want to miss the opportunity to build a modern and inclusive application for WordPress, but in order to achieve that goal, accessibility needs to incorporated in all design processes in the project.

These problems are solvable. Retrofitting accessibility is not an effective process. It is costly in terms of time and resources.

We hope for a truly inclusive end product. The progress made within Gutenberg is not trivial – there have been many very difficult problems to solve. Solving these larger design issues will give us a positive path towards the equal inclusion of all.

In the short term, we hope to resolve all accessibility issues that are true barriers to the use of Gutenberg. In the long term, we hope to improve the integration of accessibility into all future WordPress design processes.

The accessibility team will continue to work to support Gutenberg to the best of our ability. However, based on its current status, we cannot recommend that anybody who has a need for assistive technology allow it to be in use on any sites they need to use at this time.