Accessibility Team’s goals for WordPress 5.6 and beyond

Following a pattern established during the last WordPress releases, it has become common for the WordPress Accessibility Team to set targets for each release during the final stages of the previous one.

Given the heavy involvement of the Team between 5.5 RC 1 and the 5.5 release, it was impossible to discuss possible goals before. Also, given that the kickoff meeting for WordPress 5.6 took place on Wednesday, 19th August, this discussion can’t be delayed anymore.

As such, the Accessibility Team is going to discuss possible targets for WordPress 5.6 during the next weekly meeting, which will take place on Friday, 28th August, 2020 at 15:00 UTC.

If you have an accessibility goal you would like to see the team pursue on WordPress core, you are more than invited to add it in the comment section below and let us know. You are then invited to attend to the next weekly meeting, when possible goals will be discussed and prioritized.

If a certain goal won’t be selected for the 5.6 release, it can always be included in the list that will be created for the 5.7 release.

While a strict timeline can’t be set too many months in advance, the next Call for Accessibility Team’s goals will likely be published around Friday, 13th November, 2020, that is, the Friday before WordPress 5.6 RC 1. Possible goals will then be discussed during the weekly meeting on Friday, 20th November, 2020. Around the same time, an extra bug-scrub to identify possible good-first-bug Core tickets and Gutenberg issues will take place.

All the above dates are flexible and can be changed according to specific needs, in particular in case they run the risk of detract from bug fixing during Release Candidate.

Such an early planning will probably become even more useful with next releases, given that four major WordPress releases are already planned for 2021 and each release cycle will be shorter. Planning in advance possible goals during Release Candidate will also allow contributors to have a break in between releases, reducing possible sources of burnout.

#5-6, #goals

Hey everyone! In case you haven’t heard, I will be acting as the 5.6 a11y Release Lead along with cohort Hauwa Abashiya (@azhiyadev). I am SO EXCITED to help make this the best, most #a11y focused release ever! If there is anything I can do to help along the way, please don’t hesitate to reach out!

On that note, I’ll kick off our goal planning list with a few ideas I’ve been collecting from recent Slack Conversations, posted individually below. Please add your support to any you would like to see included in 5.6, or, add your own! All ideas are welcome here!

Project: Updating the WordPress Accessibility coding standards from WCAG 2.0 to WCAG 2.1

As the first few drafts of WCAG 2.2 have already been published, and there is still some support left to accomplish to meet 100% of WCAG 2.0, the goal here is to move towards supporting all of 2.0 and as much of 2.1 as possible to avoid falling too far behind.

For reference: What’s new in WCAG 2.1

Per @joedolson, the following is an outline of proposed first steps for this project:
1. Simplified explanations of the new WCAG 2.1 AA criteria
2. Examples of either existing bugs that violate said criteria or external examples, if none found from within project.
3. General update of existing code standards documentation to incorporate new standards.
4. Review of existing accessibility-related documentation to incorporate references as relevant.
5. Update Accessibility team handbook to add WCAG 2.1 criteria.

So far, the following a11y folks have already pledged their support. Join us!
@joedolson, @nrqsnchz, @azhiyadev, @williampatton and @sarahricker

Hey team!

On my side, I’d like to extend the first pass we made on Alternate views for WP list tables during WP 5.5. My goal is to add more extensibility to the current implementation, and more useful stuff for users as a result of the “extended” option.

And, of course, fix all the bugs 🐛 😎

Project: Mechanism for Accessible Tooltips in Core
The need for a11y tooltips is a concept that comes up a lot in Slack. The goal here is identifying all of the tooltip needs, resolving existing issues, and determining a mechanism to keep our tooltips accessible going forward as new features are developed across the editor.

Some existing tickets already exist re: a11y tooltips, for example: http://wayback.fauppsala.se:80/wayback/20200913083803/https://core.trac.wordpress.org/ticket/51006

@joedolson for more info.

Project: WP 2021 theme – the most a11y theme ever released!

It sounds like a new theme may be on the roadmap. The goal here is to aid the themes team as much as possible to create the most accessible theme ever released by our amazing community.

Hoping to shoot for the stars on this one. Dare I say, “A theme that passes WCAG 2.1 AAA“?

@williampatton, @poena for more info

Would love to chat more about this!

I’d like to see a solution found to the current dilemma of the block toolbar space issue. So much of the accessibility issues are a result of trying to cram multiple things into a small space:

  • The block switcher doesn’t use an appropriate “switcher”/”transform” icon, but rather the block icon. This also means there’s no place to put the current block title in a tooltip, so to find out what block you’re editing, you have to look in the inspector. This is not good, if you ask me. Ideally, the block icon would be a separate thing with a tooltip/aria-label stating the block title. (I think the title is already announced to screen readers, so this would mainly benefit sighted users.)
  • The movers are stacked, causing their buttons to be half the standard size, and appearing at first glance as if they were a single button. This is not ideal for touch usability, and it’s also somewhat confusing.
  • There is no visible drag handle. Instead, dragging the mover buttons initiates a drag action. This is perhaps the most problematic issue, as many users have assumed that drag-and-drop has simply been removed.

All of these issues can’t be solved via current methods unless the toolbar gets longer. So there’s a lack of available space, and no immediately apparent solution in sight.

The only thing I’ve been able to come up with is a possible “toolbar-replacement” idea, where clicking a button in the toolbar replaces the contents with a sort of “sub-toolbar” containing controls specific to a certain type of action, e.g. block movement. (And of course, there would be a button to get back to the main toolbar.)

This idea could be used to have a dedicated sub-toolbar for things like:

  • block movement (up, down, move to top, move to bottom, drag handle, “move to…” (currently in the ellipsis menu))
  • standardized block-level styling (text alignment, background color, text color, block “alignment”, item/content alignment, maybe even the style variations could be moved here); this could provide a standardized place for all the various block-level styling controls, without having to put them in the inspector for some blocks but not others

If such a thing could be done in an accessible way, it may be able to solve this growing toolbar space issue. But if not… well, I have no other ideas. But this is a critical point of friction between the accessibility and design teams, and I think it ought to be resolved sooner rather than later.

I’m 100% behind finding a good solution for this!

A lot of different ideas have been discussed over the past few weeks. Perhaps some high fidelity / interactive design mock ups for each idea paired with details regarding the pros/cons of each would help visualize each solution proposal. As a joint team, we could then vote on a path forward and commit to having that solution be part of the 5.6 release.

I can also help facilitate an extra weekly design + a11y check-in where we discuss progress on this very important topic if that helps! 🙂

I’d like to see the removal of the title attribute from nav walker menus. Creates repetitive screen reader announcements for some screen reader/browser combinations. From what I hear, this has been on the docket for some time now.

Project: A feature plugin to create an “Accessibility Statement” tool with features equivalent to Privacy Policy Tools

Goal here is to help educate and spread awareness on Web Accessibility through an open ended and optional feature similar to the the existing Privacy Statement feature. Early ideas for the tool are to provide the W3C “minimal example”, and to encourage the site owner to use the W3C Generator for a more custom statement.

Ideally this would start as a feature plugin, and if it gained traction, could be merged into core in a future release.

See the original proposal from @mrwweb and a summary of #a11y meeting notes here: http://wayback.fauppsala.se:80/wayback/20200913083803/https://core.trac.wordpress.org/ticket/50673

From a practical perspective (as in: not “higher level goals”) worth reminding there are a few important tickets from the previous release cycle that didn’t make it for 5.5 and need to be prioritized for 5.6. First of all:

Remove infinite scrolling behavior from the Media grid
http://wayback.fauppsala.se:80/wayback/20200913083803/https://core.trac.wordpress.org/ticket/50105
together with the related tickets:
http://wayback.fauppsala.se:80/wayback/20200913083803/https://core.trac.wordpress.org/ticket/50410
http://wayback.fauppsala.se:80/wayback/20200913083803/https://core.trac.wordpress.org/ticket/50025
http://wayback.fauppsala.se:80/wayback/20200913083803/https://core.trac.wordpress.org/ticket/46127
http://wayback.fauppsala.se:80/wayback/20200913083803/https://core.trac.wordpress.org/ticket/47215

Secondly: the Trac tickets we asked help from other teams:

For the Editor team:

Allow Ctrl+Y redo in post editor
http://wayback.fauppsala.se:80/wayback/20200913083803/https://core.trac.wordpress.org/ticket/49459
Featured image is missing ‘Alt Attribute’ value on the edit window
http://wayback.fauppsala.se:80/wayback/20200913083803/https://core.trac.wordpress.org/ticket/49651 also reported on the Gutenberg GitHub: http://wayback.fauppsala.se:80/wayback/20200913083803/https://github.com/WordPress/gutenberg/issues/14416

For the Media team:

Fix crop image functionality within edit flow
http://wayback.fauppsala.se:80/wayback/20200913083803/https://core.trac.wordpress.org/ticket/30155
Media modals: Upload errors and field information are not associated with their control
http://wayback.fauppsala.se:80/wayback/20200913083803/https://core.trac.wordpress.org/ticket/47120
PDF uploads are treated like images: empty alt attribute and PHP notices
http://wayback.fauppsala.se:80/wayback/20200913083803/https://core.trac.wordpress.org/ticket/48710

Lastly, there are at least three important Gutenberg issues the team identified as regressions in the accessibility level in WordPress 5.5 that still need to be addressed:

Accessibility regression: The selected block isn’t outlined any longer
http://wayback.fauppsala.se:80/wayback/20200913083803/https://github.com/WordPress/gutenberg/issues/23892

New buttons design: buttons can’t be visually identified as user interface controls
http://wayback.fauppsala.se:80/wayback/20200913083803/https://github.com/WordPress/gutenberg/issues/23890

Accessibility regression: Firefox and NVDA don’t announce the blocks in navigation mode any longer
http://wayback.fauppsala.se:80/wayback/20200913083803/https://github.com/WordPress/gutenberg/issues/24121
where a temporary, not ideal, fix was implemented for WordPress 5.5 but this issue needs a better solution.

Some more “high level” goals 🙂

Recruiting campaign
One of the accessibility team historical problems is that it’s a small team 🙂 The team has always been struggling with the lack of time and contributors. Also, the Gutenberg development pace creates new challenges. In the past, the team made some efforts in involving new contributors but recently the focus went a bit lost.

On one hand, Gutenberg poses complex challenges and there’s the need for high level specialists with advanced accessibility expertise. On the other hand, there are many pending tasks that the team isn’t able to complete and that would need new contributors willing to bring in new energies.

It would be greatly beneficial for the team and for accessibility in WordPress to make this a constant effort from now on.

Document accessibility anti-patterns
I don’t think the accessibility team should ever produce documentation on how to code accessible components and accessibility best practices. Plenty of documentation out there. It’s 2020 and I’d expect designers and developers to be able to get trained and learn HTML and accessibility deeply.

Instead, I’d tend to think it would be beneficial for WordPress that the accessibility team documents and explains what are the most common accessibility anti-patterns identified in the last years, especially thinking at the Gutenberg project.

Some examples:

  • parts of the user interface that continuously appear and disappear
  • visual/reading order and DOM order mismatch
  • lack of good information architecture (linearization of content)
  • icon-only controls
  • lack of good focus indication

Make keyboard testing a required step of the development process
Start a conversation with the other teams to make basic keyboard accessibility testing a required step for any change and new feature in Gutenberg and in core.

Especially thinking at Gutenberg: most of the accessibility regressions identified right before the 5.5 release could have been caught way in advance if the related features were tested _a few minutes_ using a keyboard. Looking at those specific issues, it’s pretty clear to me that most of them were very visible when using a keyboard. The fact they haven’t been caught timely makes me think that most of them haven’t been tested for keyboard accessibility at all.

I don’t think this is an efficient process. In order to fix as many of those regressions as possible, the involved teams had been forced to a final rush that implied creating new issues, new PRs, testing, etc. and that has been stressful for all the ones involved. Not to mention the amount of time spent to fix all that.

Testing keyboard accessibility while developing and making it a required step to merge PRs would save a lot of time and make everybody happier.

I’d like to strongly recommend to make an effort to come to a consensus and make keyboard testing a required step for all the Gutenberg and core changes that touch the user interface.

Dogfood the Gutenberg plugin
As said above, the Gutenberg development pace is challenging and for many team members following closely the development is not sustainable. The accessibility team has their own responsibilities though. I often noticed that, while discussing accessibility issues related to Gutenberg, not all the team members had a clear picture of the issue being discussed.

Far from pretending to ask anyone to follow the Gutenberg development on a daily basis, but I’d tend to think the team members should make an effort and at the very least always use the Gutenberg plugin (the development one, cloned from the GitHub repo). This way, all the team members would be able to test new features as soon as they’re introduced in Gutenberg and provide feedback in a more efficient and timely way.

We’re not going to make a great progress if only one or two persons from the team dedicate their time to monitor and contribute to Gutenberg 🙂 Making this a team effort would certainly speed things up and contribute to make Gutenberg a better, more accessible, product.

[…] 5.5 release post-mortem Team goals and priorities for WordPress 5.6 Gutenberg issues: Continue discussion of Add screen reader announcement to last block in list Full […]

To keep track of them, I’d like to add for consideration projects that were considered or worked on during the 5.5 release cycle and that didn’t land.

  • Accessible color schemes: provide new accessible color schemes for wp-admin (worked on during 5.5)
  • “Howdy fly-out menu”: refine/replace the upper-right WP-Admin fly-out menu (worked on during 5.5)
  • Uniform search: redesign of the search for wp-admin (already milestoned for 5.6)
  • wp-admin colors: reviewing wp-admin default color scheme for accessibility (not milestoned)

[…] Accessibility team has published their goals for WordPress 5.6 and beyond and has started working on […]

[…] Accessibility team has published their goals for WordPress 5.6 and beyond and has started working on […]

[…] read more about 2020 do_action events on the WordPress Foundation blog.The Accessibility team has published their goals for WordPress 5.6 and beyond and has started working on them.WordCamp Minneapolis/St. Paul was held successfully on August 21. […]

[…] Accessibility team has published their goals for WordPress 5.6 and beyond and has started working on […]

[…] Accessibility team has published their goals for WordPress 5.6 and beyond and has started working on […]

[…] Accessibility team has published their goals for WordPress 5.6 and beyond and has started working on […]

[…] Accessibility team has published their goals for WordPress 5.6 and beyond and has started working on […]

[…] Accessibility team has published their goals for WordPress 5.6 and beyond and has started working on […]

[…] Accessibility team has published their goals for WordPress 5.6 and beyond and has started working on […]

[…] Accessibility team has published their goals for WordPress 5.6 and beyond and has started working on […]

[…] Accessibility team has published their goals for WordPress 5.6 and beyond and has started working on […]

[…] Accessibility team has published their goals for WordPress 5.6 and beyond and has started working on […]

[…] Accessibility team has published their goals for WordPress 5.6 and beyond and has started working on […]

[…] Accessibility team has published their goals for WordPress 5.6 and beyond and has started working on […]