Meeting Plans for December 2018

Since December incorporates a large number of holidays, WordCamp US,  and other team member travel, we’re planning on a number of changes to the meeting calendar for the rest of 2018.

We’ll have a meeting on December 7th, during WordCamp US, with no agenda. If anybody has questions on WordPress accessibility, accessibility in WordPress 5.0, or other topics to discuss, please show up and ask! Many regular team members will be in Nashville, but those of us not attending WordCamp US will do our best to answer your questions.

Schedule for December

  • December 7th: Bug Scrub: cancelled, Meeting: Open forum.
  • December 14th: Bug Scrub: cancelled, Meeting: normal. Agenda will be published in advance.
  • December 21st: All meetings cancelled.
  • December 28th: All meetings cancelled.

We’ll return to normally scheduled meetings on January 4th. If there are changes to this schedule, we’ll announce them here!

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.

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. 

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.

Team meeting October 15, 2018

Transcript meeting in Slack

Agenda for the meeting

  • The future of a11y team: role and goals of the a11y team in the WordPress project, considering the current accessibility coding standards.
  • Decisional process in the a11y team.
  • Role of the a11y team reps.
  • Based on the approved reps role, nominees for the reps
  • The quarterly team updates for wordpress.org news https://wordpress.org/news/
  • Open floor

The future of a11y team: role and goals of the a11y team in the WordPress project, considering the current accessibility coding standards

At WordCamp US 2015 in Philadelphia the a11y team prepared a proposal for accessibility coding standards to be included in WordPress.

These can be found on the accessibility coding standard page. One of the main points is this:

All new or updated code released in WordPress must conform with the WCAG 2.0 guidelines at level AA. 

In the meeting we discussed that an accessibility coding standard is a little different than other coding standards.

  • Not everything can be measured or fixed by automated tools.
  • It involves design and pretty much every other part of the development process.
  • It needs experience outside of code on how users use tools like WordPress.

The team also discussed the wording of the a11y coding standard. Is there a reason to change “must” conform with the WCAG 2.0 guidelines to “should” conform with the WCAG 2.0 guidelines?

Accessibility team decided to keep the current wording  – All new or updated code released in WordPress must conform with the WCAG 2.0 guidelines. This raises a couple of questions.

  • If Gutenberg has issues that violates accessibility coding standard and guidelines, can the release date be changed before issues are solved? In short, the a11y team doesn’t have the power to make that decision.
  • What is the point of having standards if they’re not enforced? We can only recommend the a11y standards, and keep on working to reach that goal.

Decisional process in the a11y team

Meeting agendas, proposals, and decisions should (see what I did there) be published in this blog. We should also vote and document issues that do not have another place for discussion and decision making.

In short, let’s keep the same process as before.

Team representatives (reps)

Team reps is about

  • representing the team
  • speaking on behalf of the team
  • propose the agenda
  • run the meeting
  • write the meeting notes

We were hoping to get two to four volunteers so that the role can rotate every three months. Joe Dolson and JB Audras are interested to take on the team rep role. The team will decide on the new reps in the next meeting.

The quarterly team updates for wordpress.org news

In every three month there are short updates from teams in News site.

  •  What is the team’s one-sentence top priority right now (and what’s the ETA)?
  • What struggles is the team having?
  • What is one thing you are all proud of this quarter?

From this meeting there were no volunteers to write the summary but in general this can be done from summary meeting notes.

Open floor

We all agreed that Rian Rietveld is awesome. There is no way we can fit in her shoes. But hopefully we have shoes of our own.

Suggested agenda for meeting on October 15th

I’d like to suggest the following agenda for October 15th meeting:

  • The future of a11y team.
  • Leading process of the a11y team.
  • The quarterly team updates for wordpress.org news.

Let us know in the comments if there are any other subjects you’d like to talk about.

I have resigned as the WordPress accessibility team lead. Here is why

I have resigned as the WordPress accessibility team lead. Here is why.

Team meeting September 17, 2018

Transcript meeting in Slack

Topics meeting

Gutenberg progress

@afercia: The Gutenberg team has started working on some of the UI issues, however many of the accessibility issues are still there with no great progress. There are still about 100 issues open, 12 of which are breaking for the merge milestone.

We discussed the accessibility of a new feature proposal: Modal appear animation and where actually amazed that there is still time to develop such extras when there are so many show stopping open issues and bugs left to fix.

WordPress 4.9.9

As noted in the WordPress 4.9.9 Minor Release Roadmap, one of the goals is:

We’d also want to focus on fixing issues in accessibility. There’s lots of ways we can drastically improve the experience for a lot of people with minor effort.

Basically in this release we will try to knock out a bunch of small issues that have been overlooked. @rianrietveld will contact @schlessera about what the best approach will be for this.

To see which of the 150 open tickets can be milestoned 4.9.9 we opened a spreadsheet with a list of them all. Andrea, @audrasjb, @travel_girl, @bamadesigner and Rian will work on this. We will select tickets with some direction of a solution, that seem like an easy fix and that don’t involve major design decisions.

Jean-Baptiste will also look at the accessibility fixes that have already been merged in trunk (which means 5.0) but they’re not in 4.9.8 and won’t be in 4.9.9.
We need to consult Alain if this is something he wants to address too for 4.9.9.

To-do list

  • Test Gutenberg new features Spotlight Mode and Full Screen mode for accessibility issues
  • Find an accessible project management tool
  • Gutenberg AT Manual: Ask for help from marketing team and users of AT
  • Handbook: Process feedback at WordCamp Nijmegen
  • Codex/Develop: Set up a review of the example code in those sections
  • Write blogpost about impact new recommendation WCAG 2.1 AA for WordPress

Next meetings

  • Ticket triage for WordPress 4.9.9: September 24, 14:00 UTC
  • Team meeting: September 24, 15:00 UTC

#accessibility-team-meetup

Team meetings September 3 and 10, 2018

Transcript meeting in Slack

Meeting topics

Gutenberg accessibility work update by @afrecia

There is a new feature (despite of the feature freeze) “Spotlight Mode”: Andrea addressed some a11y concerns here.

Request from Andrea: please test Spotlight Mode and Full Screen mode for accessibility (keyboard use, screen reader feedback, voice recognition control). They are both merged into the latest Gutenberg release.

At this moment there are still 99 open accessibility issues, 12 of them are labeled Milestone Merge Proposal, so have priority.

Gutenberg AT Manual

@abrightclearweb is working on a Gutenberg manual for assistive technology (AT). And while writing she also finds new issues which she reports on the Gutenberg Github repo. Draft version manual.

It’s a lot of work, help with this is very much appreciated. @Wingo5315 is already helping out.

WP a11y handbook

At the contributor day in WordCamp Nijmegen attendees reviewed the handbook. We a Google doc and have now 6 pages of comments; @lucp checked for HTML/CSS errors, @ireneyoast fixed typos , translation and code errors and @jaapwiering did a huge amount of work reorganising and trying to give more structure to the pages. @rianrietveld will process this in the next few weeks.

A11y review codex/develop

We need to review the code examples in the codex (develop) section of wordpress.org. They contain a11y mistakes, and as this code will be copy/pasted a lot, we need to fix them.
Rian talked with Pieter Daalder (@wizzard_) from the docs team. The proper workflow for this is add a comment on the page with the error and ping in the doc channel that you need this fixed.

Drupal and Gutenberg

Drupal shows interest in using Gutenberg. At the request of Per Andre Rønsen, Rian posted in the Drupal #accessibility channel info about where to find the issues in Github and what the status is. Let’s see what happens.

Project management tool

We are going to research a good project management tool for the a11y team. Other teams use Trello, but maybe that’s not accessible enough for our use. An alternative could be GitHub projects.

What we did on a contributor day

Proposal: if you led a team on a contributor day, white a summary about what you did, so we can post it on our blog.

To-do list

  • Test Gutenberg new features Spotlight Mode and Full Screen mode for accessibility
  • Find an accessible project management tool
  • Gutenberg AT Manual: Ask for help from marketing team and users of AT
  • Handbook: Process feedback at WordCamp Nijmegen
  • Codex/Develop: Set up a review of the example code in those sections
  • Write blogpost about impact new recommendation WCAG 2.1 AA for WordPress

Next meetings

  • Gutenberg bug scrub: September 17, 14:00 UTC
  • Team meeting: September 17, 15:00 UTC