WPCampus Accessibility Audit
Discussion about how to organize both Gutenberg, Accessibility and Design teams to handle accessibility issues (GitHub issues but also fundamental issues found in the editor).
The accessibility team main concern is that the Gutenberg team would maybe going to focus on GitHub issues (which is understandable) and ignore the wider UI/usability issues uncovered in the report.
The idea is not to ignore GitHub issues but to find ways to handle broader fundamental issues with the editor.
@mapk: “One super helpful way to understand the usability issues from the report would be to actually see the tests performed”. The question to be asked to WP Campus (@bamadesign).
The Gutenberg team asked to open issues for these general issues to they can be milestoned. There is a need for a starting point.
@afercia noted many (if not all) of the broader accessibility/usability issues reported in the Accessibility Audit were already reported by the team: Report on the Accessibility Status of Gutenberg (October 29).
@karmatosed: “I’ll add that whilst we all need to learn and iterate, there’s been a large move on that front. I want to for example call out the work of @lukepettway and others coming to the design meeting. @bemdesign has been incredible coming to design a11y audit triages”. Which is a good starting point to work together on design principles in the editor and in WordPress in general.
According to the Gutenberg Team, it would be useful to use concrete examples for each issue so it can be better surfaced/discussed/addressed.
@afercia: “I’d like to outline is that these broader issues can’t be solved with technicalities. There’s no ARIA, no focus management, no JS tricks that can solve these broader issues.”
@audrasjb said moving from the main editor to the sidebar and go back to the editor is an example of very difficult tasks the users have to do to manage their post when they use assistive technologies.
@matveb: said it also shows something everyone was aware, but never reached a good solution for.
@afercia listed some examples:
- Keyboard navigation from blocks to the sidebar and back to blocks (closed)
- Simplify keyboard navigation through blocks
These two examples are more related to the general design rather than technical implementation. Settings should be easily reachable starting from the block. Ideally, they should follow the block in the DOM order. That makes the whole idea of sidebar an accessibility anti-pattern.
@joedolson: “Getting a shared understanding of the essential characteristics of interaction flow for users of assistive technology is a valuable step in getting a better process; discussing the technical issues with the sidebar/block interaction helps us get closer to that.”
@matveb: “I’d like to understand if the problem is even more fundamental between trying to accommodate editing and navigation under a single view mode […] it can be an essential paradigm for framing the conversation”
@afercia said other similar editors have a clear distinction between “view” and “edit” mode.
@joedolson: “Understanding the problems with jumping between disparate objects using the keyboard is a big part of it. Keyboard are largely dependent on linear flow, moving one step at a time between neighboring focusable objects. Keyboard shortcuts, while possible, are extremely difficult to make 1) perceivable, 2) understandable and 3) robustly supported, which makes them hard to depend on. So recognizing that elements that aren’t sequential is very difficult to navigate between is important. The problem isn’t in making the keyboard navigation better, but placing related elements next to each other in the DOM.”
In conclusion, it was decided to add a 15 minutes timeslot in the accessibility meeting time dedicated to having an open floor period where anybody can show up and chat on any accessibility topic.