X-post: WordPress 5.5 Core Editor Accessibility Improvements

X-comment from +make.wordpress.org/core: Comment on WordPress 5.5 Core Editor Accessibility Improvements

Accessibility Team Meeting Agenda: August 7, 2020

This is the proposed agenda for the weekly 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 on Friday, August 7, 2020 at 15:00 UTC.

If you want to have a topic added to the agenda, please mention it in the comments of this post.

The Accessibility Team bug scrub will be held on Friday, August 7, 2020, at 14:00 UTC.

This meeting is held in the #accessibility channel in the Making WordPress 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/. (requires registration).

#agenda

Accessibility Team Meeting Notes: July 31, 2020

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.

This week we decided to continue the discussion around 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. focus outlines that started during the accessibility bug scrub right before our team meeting.

Rather than try to summarize it, I encourage those interested to follow the discussion in Slack.

We agreed to revisit this topic and discuss possible proposed solutions during our next extra bug scrub planned for Tuesday, August 4, 2020, at 15:00 UTC.

We also agreed to revisit the agenda items planned for today’s meeting during our meeting next week.

#meeting-notes-2

Accessibility Team Meeting Agenda: July 31, 2020

This is the proposed agenda for the weekly 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 on Friday, July 31, 2020, at 15:00 UTC.

  • Finalize the date and time for the extra pre-alpha bug-scrub.
  • Review our team meeting day/time and look at options to make it friendlier for folks across the globe.
  • Discussion: update the WordPress accessibility coding standards to 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
  • Open floor

If you want to have a topic added to the agenda, please mention it in the comments of this post.

The Accessibility Team bug scrub will be held on Friday, July 31, 2020, at 14:00 UTC.

This meeting is held in the #accessibility channel in the Making WordPress 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/. (requires registration).

#agenda

Accessibility Team Meeting Notes: July 24, 2020

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.

Review 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/ issues marked as accessibility regressions

The first part of the meeting was dedicated to reviewing Gutenberg issues marked as accessibility regressions; it was a continuation of the bug scrub that had started an hour before. In the end, the team analyzed eleven issues and discussed which of them were considered as must-have to be included in WordPress 5.5.

The complete discussion about Gutenberg accessibility regressions (including items addressed during the bug-scrub) is in 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/..

Planning of an extra pre-alpha triage session

Following the discussion we had two weeks ago about how to better address accessibility bugs in WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and issues in Gutenberg, the team agreed on organizing an extra bug-scrub after WordPress 5.5 Release CandidateRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. 1. The scope of the additional triage is to identify easier and self-contained tickets and issues to mark as good-first-bug.

The team agreed to separate the Friday bug-scrub from the extra once-per-releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. triage: half of it will be focused on WordPress Core tickets and the other to Gutenberg issues.

The suggested time for this extra bug-scrub is Tuesday, August 4th, 2020 at 15:00 UTC, but the team will choose the final date and time and the bug-gardener in charge of conducting the triage during next weekly meeting. If we can’t get through all tickets and issues in a single meeting, a follow-up will be planned.

Updates on WordPress Accessibility Day organization

Organization of WordPress Accessibility Day, the 24-hour event about WordPress and accessibility starting on Friday, October 2nd, 2020, is in progress, but the organizing team asked for some help.

They are looking for people to volunteer as Emcees, moderators, and monitors during the event, and a specific call for volunteers will go live in the next few days.

If someone wants to participate to a greater extent, please join the #accessibility-events channel, where discussion about the event is ongoing and a weekly meeting happens every Wednesday at 16:30 UTC.

#meeting-notes

Accessibility Team Meeting Agenda: July 24, 2020

This is the proposed agenda for the weekly 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 on Friday, July 24, 2020 at 15:00 UTC.

  • Review of Gutenberg issues marked as accessibility regressions and discussion about priorities and steps to take in view of Release CandidateRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. 1
  • Planning of the pre-alpha triage session to identify tickets to be labelled as good-first-bug
  • Updates on the organization of WordPress Accessibility Day
  • Open floor

If you want to have a topic added to the agenda, please mention it in the comments of this post.

The Accessibility Team bug scrub will be held on Friday, July 24, 2020, at 14:00 UTC.

This meeting is held in the #accessibility channel in the Making WordPress 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/. (requires registration).

#agenda

Accessibility Team Meeting Notes: July 17, 2020

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.

Removal of aria-labels for links opening in new tabs

We discussed this Gutenberg PR that removed the aria-label property from links set to open in a new tab. It was previously suggested by the team to remove since the old implementation was doing more harm than good.

That said, a proper solution has yet to be implemented and we’d like to discuss all the alternatives with the relevant teams.

@ryokuhi volunteered to create a TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. ticket so we can follow up and start the conversation.

Create “Accessibility Statement” tool with features equivalent to Privacy Policy Tools

We also looked at this Trac ticket that proposes to mimic the tools already in place for creating Privacy Policy pages, but for Accessibility statements.

We discussed the pros and cons of such a tool and agreed that if done well, it can be a great medium to help spread accessibility awareness and education.

@sarahricker volunteered to summarize our discussion and add a comment to the ticket.

Initial implementation of <details>
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.

We then discussed this 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/ PR that looks to add a <details> block and agreed that we should follow the ARIA Authoring Practices implementation for an accordion component instead.

We added our feedback to the parent issue the PR is linked to.

#meeting-notes-2

Accessibility Team Meeting Agenda: July 17, 2020

This is the proposed agenda for the weekly 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 on Friday, July 17, 2020, at 15:00 UTC.

If you want to have a topic added to the agenda, please mention it in the comments of this post.

The Accessibility Team bug scrub will be held on Friday, July 17, 2020, at 14:00 UTC.

This meeting is held in the #accessibility channel in the Making WordPress 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/. (requires registration).

#agenda

Accessibility Team Meeting Notes: July 10, 2020

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.

Review of the team activity for WordPress 5.5 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 releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software.

As first topic of the meeting, we reviewed the team activity for WordPress 5.5 Beta 1 release and looked for possible improvements to the workflow, in particular regarding tickets and issues shared with other teams.

There are a few remaining tickets in the 5.5 milestone with the accessibility focus keyword: specifically, they are tickets #49715, #50512 and #50416. Moreover, the team is in charge of writing a few dev notes.

It was pointed out that cross-team collaboration and co-dependancies are slowing the progress of the software in general and not only for accessibility related tickets, so a discussion about possible improvements should probably happen on a higher level and in a broader context.

For what concerns specifically the accessibility team, there was a very rich discussion with many proposals on how to improve the team work. Here is a list of takaways from the discussion.

  • For tickets shared with other teams (especially with the design team), contributors to the accessibility team should be bolder and propose changes, instead of waiting for feedback and only reacting to changes proposed by other teams.
  • To better track blocking issues, it was suggested to add a blocked-by keyword/label, so that it’s easier to generate lists of issues that are currently blocking other issues and that the team can triage them more effectively.
  • The team should start to focus on bigger projects, instead of mainly fixing small bug. Given the limited number of contributors and the constantly changing available time and level of commitment of single team members, the team agreed to make a broader use of the good-first-bug keyword for easier and self-contained tickets, so that more new contributors can possibly solve them. The team will organize a formal pre-alpha triage session happening around RC1 or RC2 (RCRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. stands for Release CandidateRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge.) to identify such tickets at the beginning of the release development cycle. If tickets with the good-first-bug keyword are still unfixed after four months, they get slated for the next release they’re eligible for.

The most complex aspect to address as a team is following 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/ development. At the moment, team members don’t have enough time to tracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. both WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and Gutenberg and have the feeling that they are constantly too far behind to be able to participate effectively.

@joedolson proposed to create two subcommittees within the team, one focused on WordPress core and the other focused on Gutenberg. During weekly meetings, both subcommittees will share what they’ve focused in the previous week and can ask for advice on selected issues. This way, each individual team member will be responsible for tracking only one system. At the moment, the accessibility team probably doesn’t have enough people to do that effectively, but such proposal will be discussed during one of the next meeting.

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. movers and “Transform to” button in Gutenberg

Second item in the agenda was a follow-up to last week’s discussion on the Gutenberg issue about recent changes to the block movers and the “Transform to” button and a discussion about the related Gutenberg issue to improve the usability of the parent block selector button.

First, the team made a quick summary of issues that were already pointed out during last week’s meeting:

  • small size of mover controls (while the target area was increased in the latest iteration, the buttons are still too tiny, especially for people with motor impairments, or for people with low vision and using larger-than-standard pointers);
  • different size of movers on mobile and desktop;
  • movers button are wrapped inside the control surface used for drag-and-drop and get a draggable cursor (but there’s an open pull request to remove the drag cursor about this);
  • caret icon is used in the same context with two different meaning (moving blocks and opening dropdown menus).

Since during last week’s meeting the team agreed to consider the new interface as an accessibility regression and given that the new interface will be included in WordPress 5.5, the discussion focused on the following points:

  • what it would take from the accessibility point of view to consider the issues resolved;
  • whether the team should push for a revert or not;
  • if yes, what should be reverted;
  • how to get the reversion.

The accessibility team agreed that, at the very least, controls for moving the block and changing the block type should be separate and possibly all other new issues should be solved in time to be shipped with 5.5 (e.g. buttons size is not a new issue).

As is, the new interface should be reverted, unless the above points are addressed. In case the solution to pointed out issues can be reached by small improvements, the team is OK with shipping the new interface with WordPress 5.5; but in case of major changes (especially from the design point of view) the team strongly suggests to take more time and make the interface better: it would be very bad if a new version of the toolbar is released, only to release another new version of the toolbar in WordPress 5.6.

The scope of reverting should be considered carefully, since changes to the movers are part a bigger Gutenberg issue about advancing the block interface and they were decided in the first place because of other interface interferences.

Regarding how to get the reversion, all above points will be added to the Gutenberg issue and, in case, a Trac ticket will be created.

aria-label removal from links opening in new tab in Gutenberg

The third item in the agenda, about the Gutenberg pull request that removed aria-labels for links opening in new tabs, could not be discussed because of lack of time: this item will be moved to one of the next meetings.

Open floor

For open floor, @ryokuhi informed the team that he had a quick chat with @alexstine about documenting accessibility features in Gutenberg. He asked if someone can help to put down a list of these features, so that he can test them, give feedback and draft some documentation. If anyone is interested in volunteering for this task, they can leave a comment to the meeting notes.

#meeting-notes

Accessibility Team Meeting Agenda: July 10, 2020

This is the proposed agenda for the weekly 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 on Friday, July 10, 2020 at 15:00 UTC.

If you want to have a topic added to the agenda, please mention it in the comments of this post.

The Accessibility Team bug scrub will be held on Friday, July 10, 2020, at 14:00 UTC.

This meeting is held in the #accessibility channel in the Making WordPress 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/. (requires registration).

#agenda