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.