Accessibility Team Meeting Notes: September 25, 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.

Accessibility review of toolbars in 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. editor

We reviewed and discussed a few issues that introduce new editing functionality to the block’s toolbar. We agreed that replacing elements “on the fly” was not a recommended pattern. It unexpectedly removes elements from the DOM and can break expected interaction.

We support a solution currently being explored in this Gutenberg PR and will test it once the code is ready.

On-demand announcement to screen readers via a keyboard shortcut of the block’s contents

We also discussed this proposal on a Gutenberg issue that suggests providing a keyboard shortcut to allow screen reader users to hear the full contents of a block when triggered.

There are concerns about keyboard shortcut conflicts and of adding more shortcuts to an ever-growing list. There is one solution currently being explored on this issue in the Gutenberg repo that will allow users to customize keyboard shortcuts. We think that it might help alleviate these concerns.

We also discussed the possibility of adding a skip-link that will let keyboard users quickly jump to and find the list of available shortcuts. We think it’ll be useful to explore.


WordPress Accessibility Day

We were also reminded that WordPress Accessibility Day is next week, October 2nd, 2020 at 17:45 UTC. Make sure to add it to your agenda and the organizing team is still in need of volunteers.

#meeting-notes

Accessibility Team Meeting Notes: September 18, 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.

Update on WordPress 5.6 goals

Updating 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

The team quickly discussed about the formulation of the WordPress accessibility coding standards.

All new or updated code released in WordPress must conform with the Web Content Accessibility Guidelines 2.0 at level AA.

As it doesn’t imply the Community needs to revise the entire WordPress codebase before upgrading from WCAG 2.0 to WCAG 2.1, the team agreed that the first step could be to simply change the number. Such change would be matched by a post on the Make blog with a quick explanation about the implications of such a change. @joedolson opened a pull request on the WordPress Coding Standard repository to upgrade to WCAG 2.1.

The scope of accessibility related documentation will be broadened and will include:

  • an introduction about accessibility guidelines, including links to normative and informative resources by the Web Accessibility Initiative of W3CW3C The World Wide Web Consortium (W3C) is an international community where Member organizations, a full-time staff, and the public work together to develop Web standards.https://www.w3.org/.;
  • a list of authoritative resources (in line with the indications from the documentation team about the external linking policy);
  • a list of anti-patterns that should be avoided inside WordPress;
  • a list of patterns that should be followed inside WordPress;
  • (optionally) a guide to test patches for accessiblity issues before merging.

Discussion about the new accessibility coding standards can continue in the #accessibility-docs 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); feedback can be added to the new accessibility coding standards draft and to the new accessibility testing guide draft.

Twenty Twentyone

Development of the new WordPress default theme is ongoing. A discussion about the links style happened during and after the meeting in a thread on Slack, the menu hasn’t been worked on yet.

The GitHub repository for Twenty Twenty One was made public in the week after the meeting and some members of the team are working on it and looking for possible accessibility issues.

Accessibility statement feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.

Developement of the accessibility statement 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 is underway. As reported by @sarahricker, at the moment there are two versions of the plugin.

  • The first version generates an accessibility statement using the exact same questions from the W3C accessibility statement generator and stores answers in the WordPress database, so that the statement can be regenerated with ease every time it needs to change.
  • The second version (which is currently at a Minimum Viable ProductMinimum Viable Product "A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia stage) aligns more closely with the acceptance criteria and mimics the Privacy Policy functionality currently in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

The accessibility statement plugin repository is public and all people interested can give their contribution.

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/ project board

A couple of days before the weekly meeting, the WordPress 5.6 milestone in the Gutenberg repository was deleted in favor of a GitHub project to track WordPress 5.6 must haves and all issues in the milesone have been moved to the new board.

To ease the workload from the few team members with triage status in the Gutenberg repository, the team agreed to ask those permissions for @sarahricker, @joedolson and @ryokuhi, given that they are already bug-gardeners or committers to WordPress core.

Sidebars accessibility in Gutenberg

Following last week’s discussion, further considerations about sidebars in Gutenberg were made. Here is a summary of the key points.

  • A sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. is a layout model, not an interaction one: an element can be described as a “sidebar” because of its visual aspect, but not because of how users interact with it. A direct consequence is that there is no suitable, expected, semantic pattern that can be followed to implement all sidebars: each of them should be considered case by case.
  • It might be helpful to create a document collecting all the interface sidebars, so that issues and progresses related to each of them can be tracked more easily.
  • The complementary role and the aside element define landmarks: these are navigational tools that can be used to navigate easily between fixed sections of a page. As such, the complementary role can’t be used for components that slide in and out.
  • A possible alternative to sidebars might be to add more alternative modes, like the current “Edit” and “Select” ones. For example, to reorder blocks there could be a “Reorder” mode that transforms the editor canvas in a simplified list with mover buttons.

#meeting-notes

Accessibility Team Meeting Notes: September 11, 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 the accessibility of the 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/ search 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.

To solve the Gutenberg issue to improve the customization of the search block, a first pull request to change some display options of the search block was merged. Unfortunately, the new implementation allows users to create search forms which are highly inaccessible. After some discussion, the Accessibility Team recommends the following:

  • every search form has to have a label, that can be visually hidden if the search form can be identified as such by other means;
  • every search form should have a submit button to identify it as such;
  • the default options for the search block should include:
    • a visible label,
    • a text button, and
    • no placeholder;
  • it’s worth doing an exploration about the possibility of throwing warnings in case a user reduces the accessibility of a search form.

Review the accessibility of new and existing sidebars in Gutenberg

In order to systematically address some problems regarding new and existing sidebars in Gutenberg, it was suggested that team members had a look at some related issues and pull requests before the meeting.

During the meeting, the discussion focused mainly on identifying why a sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. may not be the best pattern in some situations. It’s worth having a look at full discussion on Slack about sidebars accessibility, even if it’s quite technical; following are the main takeaways of the discussion.

  • Regarding the use of a sidebar to change the settings of a specific block: it’s important to keep a logical information architecture to give 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 users a consistent and reliable mechanism to move between the block and the sidebar.
    • The main concern is the lack of proximity (both in the DOM and visually) that can impact especially on users with disabilities (among others: people who rely on keyboard navigation, screen reader users, low-vision users who need text enlarging).
    • Relevant controls should be placed in a meaningful sequence (both visually and in the DOM); the DOM should not be changed to match a visual design that is not helpful.
  • Sidebars should have a global context; settings for a specific item in a collection (a block, a media item, a 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.…) should be inline with them.
  • Interface changes have a big impact on assistive technology users and, as such, should be carefully weighted. For example, the inserter component was changed from a popover with modal behaviour to a sidebar; this means that people used to interact in a certain way with the inserter had to re-learn how to use features they were used to.

#meeting-notes

Accessibility Team Meeting Notes: September 4, 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.

Organization of an extra meeting to discuss specific 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

The team discussed adding an additional one-off meeting to address specific Gutenberg features for the WP 5.6 release that require special attention.

Given that there was no consensus on a date and time for this meeting, we will be using our regular meeting time next week to discuss and address these issues.

During the discussion, it was also proposed for the Accessibility and Design teams to hold office hours once a week. As suggested by @sarahricker:

It is intended a place for general feedback re: Gutenissues and to get a few eyes on big issues so they can be brought to light quicker. And to help anyone who needs help with 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) concepts.

The team thought this to be a great idea and are looking forward to hear more and participate. Be on the lookout for more information coming soon from @sarahricker and @karmatosed.

Adding a screen reader announcement to the last 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. in a list

We finished discussing this Gutenberg issue that proposes to add a screen reader announcement to last block in the block list by @alexstine.

The team agreed this is a good idea and should be tried and tested in a PR.

Adding a sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. for navigating template, posts, and pages inside the block editor

We discussed this Gutenberg issue that explores a new sidebar UI for navigating between templates, posts, and pages without leaving the editor.

A concern around having too many sidebars (and sidebars in general) and how this new one being explored looks different was raised, and an argument in favor of hierarchy and information architecture was also brought up.

The feedback will be added to the issue.

The image block’s editing tools break the toolbar keyboard accessibility

We also looked at this issue that reports that the image block editing tools are triggering a focus loss, thus affecting keyboard accessibility of the toolbar.

We discussed alternatives worth exploring and will leave feedback in the issue.

#meeting-notes

Accessibility Team Meeting Notes: August 28, 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.

WordPress 5.5 release post-mortem

The team shared and discussed what we thought went well and went wrong with our team’s projects and tasks during the release of WordPress 5.5.

The issue of not enough early involvement and feedback during design and development updates to 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. editor was brought up a few times and discussed at length. We all agreed that the process needs to be improved and our team is still very limited in terms of time and resources.

We agreed to explore solutions and ideas that would help us improve this cycle and follow-up in a separate document or post. @sarahricker volunteered to put all of this feedback together.

Team goals and priorities for WordPress 5.6

We reviewed the suggested projects and priorities that were added to the call posted earlier this week. After some discussion and a show of hands, the following projects gathered enough interest and participation:

  1. Updating the WordPress Accessibility coding standards from 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.0 to WCAG 2.1 and document accessibility anti-patterns
  2. Accessibility of the WordPress 2021 default theme
  3. A feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. to create an “Accessibility Statement” tool with features equivalent to Privacy Policy Tools

All other items on the agenda that couldn’t be covered will be added to next week’s meeting agenda.

#meeting-notes

Accessibility Team Meeting Notes: August 21, 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.

Vote to change the day and time of the team’s weekly meeting

Following a first round of voting to change the day and time of the team’s weekly meeting and the tie between moving the meeting to Tuesday, and keeping it on Friday, the team decided to hold a second poll to break the tie. The vote was closed at 17:30 UTC during the meeting and the results were:

  • Tuesday, 15:00 UTC: 42.9% of votes;
  • Friday, 15:00 UTC: 57.1% of votes.

As such, the team’s choice is to keep the meeting on the current day and time. A review of such decision can take place again in the future, but possibily not before six months.

Call for Team’s goals for the 5.6 release

You can find more details about this point in a self-contained post to be published soon on the Make website.

Request for collaboration on 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/ and Full Site Editing

@annezazu reached out to the channel asking for collaboration from the Accessibility Team on two projects.

  • The Gutenberg Team is looking for more help with triage; documentation on triaging Gutenberg is available on 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 requests for joining the triage team can be done in the #core-editor 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/..
  • The Full Site Editing outreach experiment is looking for accessibility focused representation before this initiative starts. More information can be found in the kickoff post about Full Site Editing outreach experiment on the Make website and people interested in participating can join the #fse-outreach-experiment channel on Slack.

Discussion about adding user-editable aria-labels to links in Gutenberg

The Team discussed an issue in the Gutenberg repository allowing users to add aria-labels to links. After a short discussion, the Team agreed that, while having multiple links and buttons with the same text can be harmful for users, using an aria-label attribute is almost surely not the best solution. @alexstine volunteered to sum up the Team’s position and to add a comment to the issue about aria-labels before closing it.

Discussion about communicating expanded/collapsed state in Gutenberg

Next, the team discussed another Gutenberg issue about the expanded/collapsed state of the “More options” button not being communicated to screen readers. Given that the bug was reported after testing on an iPod touch and while the team recognized that the screen reader expanded/collapsed state is not communicated in iOSiOS The operating system used on iPhones and iPads., after a short discussion the team decided to ask for more information to the reporter, given that the actual implementation works as expected. @nrqsnchz volunteered to write a comment on the issue about expanded/collapsed state.

Discussion about adding a screen reader announcement to the last Gutenberg 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. in a list

Finally, the issue with the proposal to add an announcement for screen readers when a user reaches the last Gutenberg block in a list was introduced. Given the little time left for discussion, but the great impact this improvement could have on the 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. for blind users, the Team decided to keep an eye on the issue and rediscuss it in the future.

#meeting-notes

Accessibility Team Meeting Notes: August 14, 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 poll results for the proposed changes to the team meeting day and times

Following the discussion and voting for a new meeting day and time, the team reviewed the result of the poll. We had a tie between two options: moving to Tuesday, at 15:00 UTC, and keeping Friday, at 15:00 UTC as the meeting time.

We decided to hold another voting round in order to break the tie. Please cast your vote on the new poll.

Discussion about updating 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

The team agreed that with the WCAG 2.2 draft already having been published, it was time we updated the WordPress coding standards to conform to WCAG 2.1, level AA.

We think it would be great to aim for the updated coding standards to be updated along with the upcoming 5.6 release. @sarahricker, @azhiyadev, @joedolson, and @nrqsnchz agreed to form a squad and start coordinating the work that will be needed, such as writing the requirements and creating some examples.

Advancing the Editor Interface

The team reviewed this new proposal from @itsjonq that looks to create a new foundation for the WordPress components library. The goal is to make it easier for contributors to create cohesive interfaces and conform to standards and best practices.

While still in the early stages, this proposal can have a great impact by standardizing and enforcing the accessibility of the components we use to build WordPress.

#meeting-notes-2

#meeting-notes

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

Rescheduling of the extra triage session

After a short discussion, the team agreed to reschedule the triage session to identify tickets to be labelled as good-first-bug for Tuesday, August 11, 2020 at 15:00 UTC. To speed up the process, participants are encouraged to indentify in advance possible CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. tickets and 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 to include in the list.

Discussion about support of non-link elements in Gutenberg navigation

A discussion about the Gutenberg issue on how to support non-link elements in the Navigation block and screen followed. The team agreed that it is really useful to explore solutions to allow WordPress users to create mega menus (complex menus including elements other than lists of links) in a semantical and accessible way, without need of recurring to third-party solutions. @joedolson volunteered to add a comment to the issue about next steps for the Navigation block and screen.

Review of the Accessibility team weekly meeting’s day and time

You can find more details about this point in a self-contained post on the Make website about changing the day and time of the weekly meeting of the Accessibility team.

#meeting-notes

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-release 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 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 release

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