Accessibility Team Meeting Notes: January 20, 2023

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 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 the meeting’s agenda here.

Updates from the working groups

Only groups that provided updates are shown below.

Documentation

@ryokuhi updated the group on a discussion in the channel about links opening in a new tab and it was pointed out that there isn’t anything about it in the Accessibility Handbook. @joedolson clarified provided a link to this topic in the Docs guide although without the accessibility reasons and mention by @sabernhardt it’s also in the Accessibility Handbook. Brings up the need for cross-referencing. Anyone interested, please make a Pull Request to the Doc Style Guide to add the cross-reference.

General

@ryokuhi shared that the General Team is:

  • currently focusing on the Awaiting Review queue and on tickets milestoned for 6.2;
  • at the moment, all the 12 tickets Awaiting Review have been reviewed at least once;
  • there are 15 tickets milestoned for 6.2, with 14 of them already reviewed in the last two bug scrubs;
  • following discussion on #56228 last week, we need a few eyes on the related Gutenberg Issue 42373, so that we set the time frame to milestone the related coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. issue; and
  • 6 more tickets were already committed for the next release.

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/

Before the meeting, @annezazu reported this for the Gutenberg Team and welcomes comment:

  • Latest update for phase 2 items: https://github.com/WordPress/gutenberg/issues/33094#issuecomment-1384570000
  • Accessibility review for the offcanvas editor issue: https://github.com/WordPress/gutenberg/issues/46939
  • A run down of items for the training/docs/polyglot crew that might be helpful: https://make.wordpress.org/training/2023/01/13/information-sources-for-wordpress-6-2/#comment-3629

Media

@joedolson shared a post on media management that we may want to discuss during our next Media Team meeting.

Open floor

Notes during Open Floor:

  • Our Call for Team Rep nomination is still open at https://make.wordpress.org/accessibility/2022/12/02/call-for-team-rep-nomination-december-2022/. We’d love for someone to step forward to support this team’s efforts; and
  • @joedolson reiterated the need for testing on the FSE experience; anybody can do it: just spend time with the environment and see what accessibility issues you spot.

#accessibility, #meeting-notes

Accessibility Team Meeting Notes: December 16, 2022

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 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 the meeting’s agenda here.

Updates from the working groups

Only groups that provided updates are shown below.

General

@ryokuhi reported a few statistics for TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets collected at the time of the meeting.

  • There were 10 tickets in the Awaiting Review queue, all of them reviewed at least once. One of them is in the process of being moved to the next 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..
  • There were 16 (+ 1) tickets already milestoned for the next major release (6.2), with no timeline for the release set yet.

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/

Before the meeting, @annezazu reported that the Pull Request to introduce browse mode broke the ARIA landmark structure: this is being addressed in issue 46509. She also reported that the 19th call for testing for the Full Site Editing Outreach Program has been released and, as always, testing with keyboards and screen readers is really appreciated.

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.

@joedolson shared a request for feedback about the refresh of the showcase site, which was published in the #accessibility channel the week before the meeting.

Open floor

@joedolson and @alh0319 shared about an offer from Pagely to pay for some WordPress user testing. Full discussion was very long and can be found in the #accessibility channel. @alh0319 is working on a list of instructions for testers, which will be shared for feedback here as soon as they are ready.

@afercia made a proposal to establish Accessibility Office hours. The proposal was met with wide support, and @afercia is free to work out the details.

Hostinger has offered team contributors attending the Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/. of WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Asia 2023 an invitation for a Contributor Day dinner. If anyone is attending and is willing to volunteer as a representative for the Accessibility Table, please let the team know in the Slack channel.

For the next two weeks, the Team will check on Wednesday whether someone is available to facilitate the bug scrub.

@ryokuhi is stepping down from his role as Accessibility Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts.. The Call for Team Reps is still open: if you want to candidate yourself or if you have a name for a possible Team Rep, write it in the comments to that post.

#meeting-notes

Call for Team Rep Nomination – December 2022

As usual at this time of the year, we’re opening a call for (at least) one new 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 RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts.. I’ve been Team Rep for almost two-and-a-half years, which is way longer than usual, and now it’s really time for me to step down. It’s been an incredible journey, I learned a lot, and I’m really grateful to everyone who I got to know during my term.

To learn more about the role, you can check the article about what it means to be a Team Rep. Here are the main takeaways.

  • Team Rep is an administrative role, not a Lead one.
  • Letting go of the Team Rep title is not a loss of status, just a handing off of responsibilities.
  • Someone who is a leader in a team can lead whether they are doing the team rep job or not.

Traditionally, the Accessibility Team has had two Team Reps, which allows them to share responsibilities, divide tasks and cover each other when needed. Since the election of @joesimpsonjr, we switched to having three Team Reps (at least temporarily) to reduce the burden even more.

If you want to be considered for the role or know someone who would be a great fit, you have the opportunity to nominate yourself or others by adding a comment to this post. Remember that if someone proposes your name, but you don’t feel like accepting, you should feel more than free to say no: we will consider your nomination only if you agree.

Nominations review will happen during the meeting on Friday, December 16, 2022, at 16:00 UTC. We’ll decide if and how to manage the voting round, depending on the number of submissions. During the transition period, we will support the new Team Reps to be ready and operational as soon as they feel like it.

If you have questions about the Team Rep role or the nomination process, please feel free to reach out to @alexstine, @joesimpsonjr, or me (@ryokuhi) in the comments or on 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/., either with a Direct Message or in the #accessibility channel.

Props go to @alexstine and @joesimpsonjr for reviewing this post before publication.

#team-reps

Call for Team Rep Nomination – July 2022

As announced during the last weekly meeting, we’re opening a call for (at least) one new 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 RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts.. I’ve been Team Rep for more than two years, which is twice the usual time, but I stayed in the role to support @alexstine and @joesimpsonjr. They are incredibly hard workers, but, right now, they are committed to many aspects of the Team and WordPress, including organizing events such as WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. US and the WordPress Accessibility Day: it would be unfair to leave them alone in the role.

To learn more about the role, you can check the article about what it means to be a Team Rep. Here are the main takeaways.

  • Team Rep is an administrative role, not a Lead one.
  • Letting go of the Team Rep title is not a loss of status, just a handing off of responsibilities.
  • Someone who is a leader in a team can lead whether they are doing the team rep job or not.

Traditionally, the Accessibility Team has had two Team Reps, which allows them to share responsibilities, divide tasks and cover each other when needed. Since the election of @joesimpsonjr, we switched to having three Team Reps (at least temporarily) to reduce the burden even more.

If you would like to be considered for the role or know someone who would be a great fit, you have the opportunity to nominate yourself or others by adding a comment to this post. Remember that if someone proposes your name, but you don’t feel like accepting, you should feel more than free to say no: we will consider your nomination only if you agree.

Nominations review will happen during the meeting on Friday, August 5, 2022, at 17:00 UTC. We’ll decide if and how to manage the voting round, depending on the number of submissions. During the transition period, we will support the new Team Reps to be ready and operational as soon as they feel like it.

If you have questions about the Team Rep role or the nomination process, please feel free to reach out to @alexstine, @joesimpsonjr, or me (@ryokuhi) in the comments or on 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/., either with a Direct Message or in the #accessibility channel.

Props go to @alexstine and @joesimpsonjr for reviewing this post before publication.

#team-reps

Accessibility Team Meeting Notes: July 1, 2022

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 happen on Fridays. You can read the full 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 find the meeting’s agenda here.

1. Accessibility Team Rep Discussion

@ryokuhi mentioned that he’s served as Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. over two years 9since June 2020) and he will be stepping away. What is the best approach to move forward? Currently a role shared with Joe and Alex, elections could be held now or later in September. Agreement that the elections should happen sooner than later, Stefano will remain until end of year if the role isn’t filled.

The normal process is to publish a post on the Accessibility Team’s blog and ask (or propose) contributors for the role and based on replies move foward. @joedolson nominated @sabernhardt during the discussion.

2. Updates for the working groups starting with General Team

@ryokuhi provided a status for General, sharing that the Proposed Schedule for WordPress 6.1 has been published. There are currently 20 tickets in the milestone, with 11 bug scrubs to take care of them, so we have plenty of time for that.

3. Documentaton Team

@joedolson proposed a change to the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party handbook a few weeks ago, but there hasn’t been any movement on the issue. @Hauwa Abashiya will plan to view this week.

4. Media Team update

Joe Dolson is working on the image editor with hopes of releasing it in July.

#accessibility, #meeting-notes

Accessibility Team Meeting Notes: April 1, 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, April 1, 17:00 UTC. @joesimpsonjr filled in for @ryokui for this meeting. 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 led by @sabernhardt, a welcome to new attendees with introductions, and rules for a family-friendly meeting.

Updates from working groups

  1. Report from Documentation Team@joedolson has been coordinating with @Hauwa Abashiya to follow up on the docs she brought last week, so those are progressing. For better clarity, I’m going to create a fully-realized demo of wp.a11y.speak() and place it in the wpaccessibility githubGitHub GitHub is a website that offers online implementation of git repositories that 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/ repo. He also been working on getting an accessibility doc added to the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party developer’s handbook. Accessibility Document can be found here. Practically, only the main page probably needs to be in the plugin handbook; the four sub sections might be good additions to our handbook;
  2. Additional Report from Documentation Team@sabernhardt provided more General Updates later:
  • WordPress 6.0 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. 1 is April 12, with 20 tickets left in the 6.0 milestone.
  • Today’s bug scrub covered the 8 features and enhancements.
  • There are also 12 open bug tickets with the same deadline.
  • The Awaiting Review queue has 7 tickets, with only one opened since last week; and
  1. Report from 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/ Team@alexstine reported that Add screen reader instructions for navigating child blocks on block selection is currently blocked. @joedolson also asked for an update on #35483: Accessibility improvements for the Bulk Edit form

Open Floor

Our weekly meeting closed with this comment: @joesimpsonjr mentioned he is a Team Captain on the WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. US organizing team for this year’s event on September 9 through 11 in San Diego, California. It is in-person (if things continue to progress from a health perspective), but I wanted to invite anyone to participate:

#accessibility, #accessibility-docs, #meeting-notes

Accessibility Team Meeting Notes: March 18, 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, March 18, 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 Design Team@ryokuhi is testing the change from the hash to the link icon in documentation, which is an improvement;
  2. Report from Documentation Team — There are two code snippets for @joedolson for review that @Hauwa Abashiya posted in the #accessibility-docs channel; and
  3. Report from General Team — The team is still keeping the awaiting review queue under control; There is one ticket milestoned for the 5.9.3 (the one about the accessibility-ready label for Twenty Twenty-Two); There are 7 tickets milestoned for 6.0 and marked as enhancements or feature request; and There are 17 tickets milestoned for 6.0 and marked as enhancements or feature request; Also, the feature freeze deadline was cancelled, so there’s no more need to differentiate between type of tickets. Finally, 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. 1 will be on 12 April, which leaves this team one extra week to work on tickets in this milestone.
  4. Report from Gutenberg Team — This team landed several big accessibility improvements 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/ as described by @alexstine:

These updates ensure there will not be any regressions for list view in the future.

  • https://github.com/WordPress/gutenberg/pull/39302
  • https://github.com/WordPress/gutenberg/pull/39265

List view improvements:

  • https://github.com/WordPress/gutenberg/pull/38639
  • https://github.com/WordPress/gutenberg/pull/38679

Best of all, this adds much better support for blocks without the contenteditable attribute. Still a lot of work to do but heading in right direction.

  • https://github.com/WordPress/gutenberg/pull/37934
  1. Report from Themes Team@joedolson reported that there has been a fair amount of movement on https://github.com/WordPress/gutenberg/issues/39266, with the goal to create a mechanism for viewing & testing the output of blocks. A couple of PRs already available with ideas, plus another tool that could be incorporated into core to generate the data. This development is promising that they will be reaching the point where we can do proper testing of all of that output in a solid, reusable model. This is a very important step for serious auditing of block output and open a pathway for FSE theme to be considered accessibility-ready.

Open Floor

Our weekly meeting closed with this comment:

  • @ryokuhi won’t be able to attend the April 1 and possibly the April 15 meetings and @alexstine and @joesimpsonjr will fill in. Thanks for the huge amount of work accomplished and to everyone for attending.

#accessibility, #meeting-notes

Accessibility Team Meeting Notes: March 4, 2022

These are the 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 every other Friday. You can read the full transcript on our Slack channel and find the meeting’s agenda here.

Revision of meeting and bug-scrub times

In view of the switch to Daylight Saving Times in various parts of the Northern Hemisphere, the team agreed to keep the current starting time for bug-scrubs (16:00 UTC) and meetings (17:00 UTC) until the end of March. Beginning with 1 April 2022, weekly bug-scrubs will be held every Friday at 15:00 UTC and meetings will happen on the first and third Friday of each month at 16:00 UTC.

Team involvement during WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe

Members of the organizing team of WordCamp Europe reached out to the team to discuss how the accessibility team could be involved in the activities of WordCamp Europe, especially during the Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/. happening on 2 June 2022. @ryokuhi plans to attend and already made himself available to facilitate work at the accessibility table.

On the other side, it’ll be very difficult for the accessibility team to facilitate also a second accessibility table dedicated to the Accessibility WP Theme Auditor, as suggested: the people who were coordinating the project at the time are no more active in the accessibility team and the team size has shrunken since last WordCamp Europe. As such, the team agreed to focus on a single accessibility table.

If someone else is attending WordCamp Europe, and if they are available and willing to contribute to the activities of the accessibility table during the Contributor Day, they can reach out to @ryokuhi on 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/. either directly or in the #accessibility channel.

Updates for the working groups

Only groups that provided updates are shown below.

Documentation

@azhiyadev reported before the meeting that there are no updates from the group.

General

The group continues to monitor tickets in the Awaiting Review queue, to avoid them piling up. There are 2 tickets milestoned for 5.9.2, which the group is monitoring. There are 9 enhancement or feature request tickets milestoned for 6.0, with two more weeks to get them committed. There are 15 bug tickets milestoned for 6.0, with four more weeks to get them committed.

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/

Before the meeting, @getdave shared a Pull Request about converting classic menus in block ones that will probably benefit from some feedback from the team.

@isabel_brison left a comment to the meeting agenda (apologies for not mentioning it during the meeting), asking for feedback on an issue about keyboard shortcuts and the best alternatives to the current 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. editor setup. List View is crucial to accessible navigation of the editor content, so it would be good to ensure that the shortcut to open it works across all screen readers. In order to include this feature in the 6.0 release, it should be ready 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. 1, which leaves not too much time to work on it.

Media

@joedolson reported that work is in progress; as the features the group is working on are quite complicated, it isn’t easy at the moment to predict what will make it in the release. A couple of easy fixes should be done in about a week.

Themes

@joedolson reported that he’s working to identify some better workflows for testing Gutenberg blocks. Given that the accessibility of Full Site Editing themes is highly dependent on the output of blocks, this is extremely important to assess if such themes are accessibility-ready.

Open floor

No topic was raised during open floor.

#accessibility-docs, #meeting-notes

Changes in WCAG 2.1

The 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 is updating the existing WordPress accessibility standards for development. Web Content Accessibility Guidelines (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/.) are the industry standard recommendations for improving web accessibility. The current WordPress accessibility standards are shifting from WCAG 2.0 to WCAG 2.1.

WCAG 2.1 was published on June 5, 2018. WCAG 2.0 guidelines are built into 2.1 so by conforming to 2.1, you are conforming to 2.0. Where it differs is that WCAG 2.1 has an additional 17 success criteria targeted at users with cognitive or learning disabilities, low vision, and disabled users on mobile devices. 

The WordPress Accessibility Handbook, Accessibility Core Standards, and Accessibility Pattern Library are being updated to reflect these changes and provide better guidance. This will include:

  • the principles, guidance and success criteria for conforming to WCAG 2.1
  • a list of documents and resources (technical and non-technical) for reference
  • a library of patterns (good and bad) with examples that will help improve the user interface

Below is a summary with examples of the additional success criteria for WCAG 2.1 under each of the principle and corresponding guideline.

Principle: Perceivable

Guideline 1.3 Adaptable

1.3.4 Orientation — Level AA

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential. 

Example:

This would be an uncommon scenario in WordPress. A hypothetical example might be implementing an editing interface that only worked in landscape format, because some tools were not visible on screen in a narrower viewport. 

1.3.5 Identify Input Purpose — Level AA

The purpose of each input field collecting information about a user can be programmatically determined.

Example:

This success criteria essentially means “use supported autocomplete attributes when they are relevant.” When collecting common user information, such as name, email, address, or other common information, the fields collecting that information must use the relevant autocomplete attribute. This aids users with cognitive or mobility impairments.

Guideline 1.4 Distinguishable

1.4.10 Reflow — Level AA

Content can be presented without loss of information or functionality and without scrolling in two dimensions.

Example:

The table element, in normal usage, has a significantly limited capability to be responsive while retaining the semantic value of a table. This commonly results in the need to scroll vertically to see all rows and horizontally to see all columns. Interfaces must avoid requiring users to scroll in multiple directions to see content. 

1.4.11 Non-text Contrast — Level AA

The visual presentation of content images and user interface components must have a contrast ratio of at least 3:1 against adjacent colors.

Example:

Form fields, buttons, or icons that are not supplemental to text are all examples of design elements that now have a contrast requirement. WordPress has applied this expectation in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. for several years already, so this should not have any profound impact on design expectations.

1.4.12 Text Spacing — Level AA

No loss of content or functionality should occur when line-height, paragraph spacing, letter spacing, and word spacing is changed.

Example:

Users may employ custom stylesheets or other mechanism to make text more readable for their needs. While primarily targeted at text, it may result in unexpected overlaps when containers become wider or taller. Test with the text-spacing bookmarklet (https://codepen.io/stevef/pen/YLMqbo/

1.4.13 Content on Hover or Focus – Level AA

When hover or focus states are used to reveal and hide content, the content can be dismissed without moving hover or focus; hover can be moved over the revealed content without a loss of visibility of the content; and the content remains visible until the hover or focus trigger is removed, the user dismisses the content, or the information is no longer valid.

Example:

A standard tooltip (using the ‘title’ attribute) violates most of these requirements. It becomes visible only on hover, you cannot move the hover pointer over the content, and disappears after a pre-set timeout. An accessible tooltip would need to meet the criteria specified. Principle: Operable

Guideline 2.1 Keyboard Accessible

2.1.4 Character Key Shortcuts – Level A

If a keyboard shortcut is implemented using only letter, punctuation, number, or symbol characters, then it is possible to either disable or remap the shortcut or the shortcut is only active when the reacting component has focus.

Example:

A shortcut that requires a non-printable key to activate, such as Alt, Cmd, or Ctrl is not a single-key shortcut. However, the comment navigation shortcuts (j, k, a, s, d, z, u, r, q, and e) in WordPress are single-key shortcuts that could cause problems. They are disabled  on a user-by-user basis and default to off, however, which meets the required criteria. 

Guideline 2.5 Input Modalities

2.5.1 Pointer Gestures – Level A

All functionality that uses multipoint or path-based gestures can be operated with a single pointer without a path gesture.

Example:

A slider or carousel that is navigated by swiping, pinch gestures to zoom in and out on a map, or a value slider incremented only on strict left/right axis operation are examples of problematic interfaces. 

2.5.2 Pointer Cancellation – Level A

For functionality operated using a single pointer, at least one of these is true: execution does not occur on the down event; completion is on the up event, and a mechanism is available to abort or undo after completion; the up event reverses the outcome of the preceding down event, or it is essential that the event occur on the down event.

Example:

The purpose of this criteria is error prevention. Events executed on a down event have no safety exception to prevent accidental actions. The primary example of essential action include keyboard emulations or other examples emulating a trigger action (piano keyboard, shooting game implementations, etc.)

2.5.3 Label in Name – Level A

For interface components with labels including visible text, the accessible name of the component contains the visible text. 

Example:

If the visible text on a button is “Submit”, then “Submit” is a valid accessible name, and so is “Submit the Entry Form” (with “the entry form” as hidden screen reader text.) If the button contained an aria-label with the text “Send the Entry Form”, that would not be valid, as the aria-label attribute has overridden the accessible name and there is no match between the visible text and the control’s name. 

2.5.4 Motion Actuation – Level A

If functionality is activated or operated using device motion, the motion can also be operated using user interface components and the motion actuation can be disabled.

Example:

Features such as “Shake to Undo” or tilt to advance pages may impose barriers to users. A mobility impaired user with a device held in a fixture may not be able to tilt the device; a user with Parkinson’s or Multiple Sclerosis may undo an action unintentionally. 

2.5.5 Target size – Level AAA

The size of the target for pointer inputs is at least 44 by 44 CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. pixels unless it’s: duplicated by another control that meets this requirement; an inline target with a sentence or 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. of text; determined by the user agent; or essential to the information conveyed.

Example:

This is a level AAA criteria, but it is our intention to meet the requirement as well as we can. This primarily effects the size of controls, such as buttons to close modals, tools within the editor, or submit buttons. An example of an essential target size might be when displaying an uploaded image; if the image is smaller than 44 x 44 CSS pixels but is an actionable control, it should be displayed at true size. 

Principle: Robust

Guideline 4.1 Compatible

4.1.3 Status Messages – Level AA

Status messages can be programmatically determined through role or properties such that they can be presented using assistive technologyAssistive technology Assistive technology is an umbrella term that includes assistive, adaptive, and rehabilitative devices for people with disabilities and also includes the process used in selecting, locating, and using them. Assistive technology promotes greater independence by enabling people to perform tasks that they were formerly unable to accomplish, or had great difficulty accomplishing, by providing enhancements to, or changing methods of interacting with, the technology needed to accomplish such tasks. https://en.wikipedia.org/wiki/Assistive_technology without moving focus.

Example:

This is an extremely common pattern throughout WordPress. Most status messages can be communicated by using `wp.a11y.speak()`, though in some cases it may be necessary to use an independent handler. ARIA roles such as ‘alert’ or properties like ‘aria-live’ are required to receive messages that will be observed by assistive technology.

How to Meet WCAG (Quick Reference) offers a complete list of all the success criteria and techniques for 2.1. Please help us make WordPress more accessible.

Thanks to @joedolson @afercia and @jillmugge for drafting, editing and providing feedback to this post.

#accessibility, #accessibility-docs

Accessibility Team Meeting Notes: March 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.

Meeting time change following Daylight Saving Time introduction

Meeting and bug scrub times will stay the same. Bug scrub at Friday 15:00 UTC and meeting at Friday 16:00 UTC. The day will stay the same on Friday.

Improvement of onboarding for new contributors

Here is a list of ideas that the accessibility team came up with to improve the onboarding process for new contributors to the accessibility team.

  • Add information about the bi-monthly meeting for new core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. to the accessibility handbook
  • Ease participation to tickets and issues with good-first-bug and needs-accessibility-feedback labels: make them more discoverable and improve how to ask for feedback from team members about them
  • Add a Slackbot welcome announcement when someone joins the #accessibility channel on 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/.
  • Update the “Get involved” chapter in the accessibility handbook and make the handbook more friendly for new contributors (discussion will happen in the #accessibility-docs channel on Slack)

Open floor

@annezazu informed the team that Taylor Arndt very kindly joined a Zoom meeting to share some feedback around the Full Site Editing experience when using screen readers. Here’s a quick summary of issues to be aware of (she’ll include some of these in a recap post she’s doing for the FSE Outreach Program’s second call for testing):

@annezazu also flagged the following items:

Here are a couple other issues brought up by the team.

If you have time to review/contribute to the new accessibility standards, your feedback is welcome and much appreciated.

#meeting-notes