Accessibility Team Meeting Notes: January 21, 2022

These are the notes for the Make WordPress AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team meeting, that occurred Friday, January 21, 17:00 UTC. You can read the entire meeting transcript on our SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel and view the Meeting Agenda here. The meeting begins three minutes after the hour at the conclusion of the bug scrub, a welcome to new attendees with introductions, and rules for a family-friendly meeting.

Review Goals for WordPress 6.0 Release

Discussion of Goals for WordPress 6 Release and comments received on post written by @ryokuhi. Thanks for comments provided by @Benachi and @joedolson.

Major Goal Proposals

We have two proposals as major goals for the next release:

1. Revise a requirement for accessibility-ready themes. @joedolson will work with @benachi to determine what changes are needed and author appropriately.
2. Contribute more heavily to the accessibility of GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/. More proactive monitoring is needed with issues and testing.
3. Changing the issue and/or Pull Requests template asking explicitly for steps to follow to reproduce is crucial to reduce testing time and improving feedback.
4. Dedicating some time during bug-scrubs to Gutenberg issues might be a starting point to reduce accessibility issues.
5. Reviewing how accessibility labels are used in GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ and how we’re getting notified in this channel might also be beneficial.

Open Floor

A lively discussion closed with these comments:

• In terms of prioritization, the WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. Editor needs to be used to build a site whereas Full Site Editing experience is not (unless they use themes that support it). As such, it is the reasoning to priority the Widget Editor; and
• If anyone is interested in what the #training team is planning for 2022, comments are still open

Suggested Priorities during Discussion

1. Get Keyboard use for the BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Widget environment (currently not an option);
2. Try to make Columns Block accessible via dialog which should help in several areas including the Full Site Editor; and
3. Gutenberg accessibility should be a priority. As described in this ticket by @alexstine, a group of patches around problems don’t work when new functionality comes along. The Team needs to determine what attention can be put on Gutenberg, being more effective, and invest the appropriate time testing and commenting on issues.

Additional Perspective Requested

What are the challenges faced in seeing accessibility issues through on block editor, full site editing, etc (for those new to the Team)? In response, the Team hasn’t had a Lead on Gutenberg Development since the departure of Andrea Fercia with only one person actively working in from Accessibility (@alexstine). It is a a shortage of availability from our Team, coupled with the very high levels of complexity required to work on Gutenberg with a level of comfort with ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/..
Some of the challenges are:

• Learning React is a low priority environment or isn’t often a requirement for projects professionally for many; and
• There’s also a correlation with no WordPress Accessibility Contributor Sponsorships for development;

Other Discussion Talking Points

• Is there agreement on what topics are a top priority for the Team that can be brought to a wider group for implementation assistance?
• Are any of these things we can help push to the finish line or find more eyes for (mention of seven current issues in progress)?
• Get more GitHub notifications coming in to Slack ensuring that any items labeled Accessibility lands there;
• Being aware of issues or having the time to review while balancing too many (could become spammy if too much). Every UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it./UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. change has the potential to upset the accessibility of the experience regardless of tags. This is one of the biggest issues with trying to keep current with Gutenberg accessibility. We as a Team need to catch more than we currently do. With a very small team, can we set up a monitoring rotation?;
• Pros and cons of notifications, applying milestones (possibly coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.), use of labels, tracking issues and pull requests reviews discussed at length;
• When issues are resolved, accessibility wins should be pushed out to a larger audience to garner attention;
• Although an Accessibility Review is already required, our Team needs to have better management of the process and a bigger team is needed. Often time is wasted trying to figure out what needs to be tested and how;
• Pull requests should include testing steps. An example of this issue can be found at https://github.com/WordPress/gutenberg/pull/38012;
• @alexstine provided a list of Accessibility GitHub labels noting that all the sub-labels were created following the WP Campus audit;
• Based on extensive discussions around creating new issues, issue sweeping ridealongs, custom fields, labels on pull requests @alexstine opened a proposal to modify the pull request template to include a subheading for specific testing instructions; and
• Further clarification on ridealong suggestion by Destiny, Hauwa Abashiya suggested doing something similar to a First-time Contributor session to onboard new Team members to the nuances of Accessibility and the issues discussed today. She’d be happy to work on a lesson plan to put on Learn WordPress for new contributors. She’ll follow up with @joedolson.