Accessibility Team Meeting Notes: February 4, 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, February 4, 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 on time at the conclusion of the bug scrub, a welcome to new attendees with introductions, and rules for a family-friendly meeting.

Updates from working groups

  1. Report from General Team — Since it is right after a major releaseMajor Release A set of releases or versions having the same major version number may be collectively referred to as “X.Y” -- for example version 5.2.x to refer to versions 5.2, 5.2.1, and all other versions in the 5.2. (five dot two dot) branch of that software. Major Releases often are the introduction of new major features and functionality., they’ve been focusing on issues milestoned for the next minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality.. And they’re checking issues in the awaiting review queue, to avoid things piling up. There’s no set timeline for the 6.0 release yet, so, if possible, we’ll try to dedicate more time during bug-scrubs to 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/ issues.
  2. Report from Gutenberg Team@alexstine brought Ticket #37934 Fix useFocusFirstElement in non-contenteditable Blocks up for discussion, stating that this item could use a lot of testing. The code used was great for older Blocks but not as good fro the newer ones. Suggestion by @joedolson is to try to replicate the scenario described in the "How has this been tested?" section. Questions like, "is there a list of blocks this issue applies to?" assuming it not only applies to columns but also groups, etc. Groups will be harder (to test) because there is nothing currently in a Group 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. right now that will receive focus because they are all child Blocks. This will be improved in future pull requests, making sure every Block has at least one focussable element. There should be some improvement with the Columns Block. Finally, this does work despite the failing tests meaning @alexstine will need to track down some dedicated help to debug.
  3. Report from Media Team — Most of the goals for media are set. There are a handful of accessibility issues to tackle. Time permitting, Joe will add some other things, but if the admin image editor redesign is going to have any feasibility, he can’t add much more.
  4. Report from Meta Team — Although there was a member present to report, the big change is the new headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. across .org. It could probably stand a review, if anybody has time. There is one bug that needs to be reported, but could use further investigation.

Open Floor

Our weekly meeting closed with these comments:

  • Destiny asked how the Learn session prep going and volutneered to assist if needed; and
  • To catch up on team news, goals, and more articipants were pointed here to get meeting recaps, agendas, and upcoming meeting information.

#meeting-notes, #training

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.

#meeting-notes

Accessibility Team Meeting Notes: February 12, 2021

These are the weekly notes for the 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 happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.

Updates from working groups

  • Documentation: updating the existing documents for accessibility standards to provide better guidance. Publishing information about WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/. 2.1 changes. Track progress in the WCAG 2.1 WP Update Google Document.
  • Media: #47120 will be committed before betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 3; #50105 will be deferred to 5.8-early. It’s almost there, but it’s a major 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 that would require a significant push to have ready by Tuesday, and should really sit in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. for longer. Joe Will probably commit as soon as alpha opens for 5.8, however. All media tickets are either committed or already bumped to later.
  • Themes: Accessibility Ready tag reviews in progress, a couple days out of the week. Working on developing workshop on Learn WordPress.
  • Design: good progress with design/A11yAccessibility 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) joint bug scrub.
  • MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress.: a Meta TRACTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. ticket worth checking out: Category archives pages : accessibility improvement (HTML)
  • General: during the bug scrub, we reviewed the five tickets with milestone 5.7 that are still open. 16 tickets in the milestone have been closed.

Open floor

  • WordPress 5.8 is open for development, now is a good time to start coming up with accessibility goals.
  • The next Learn working group meeting is being held in #training on Thursday, 18 February 2021, 19:00 UTC.
  • @mgifford will be giving a presentation at the DC Drupal meetupMeetup All local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through https://www.meetup.com/. A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com will help you find options in your area. group about the accessibility of the new White House website (built with WordPress). If possible, consider attending! Drupal NoVA: 10 Things We Can Learn from the New WhiteHouse.gov on Accessibility

#meeting-notes