The accessibility team plans to organise pair programming for Gutenberg on the WordCamp Europe contributor day, pairing up accessibility experts and Gutenberg developers.
The a11y team doesn’t have enough expertise to write some of the pull requests for the Gutenberg milestone issues and most Gutenberg developers have not enough expertise on web accessibility. So pairing them up at the contributor day seems like the best solution to get work done quickly.
Are you a developer that knows her/his way around the Gutenberg code and are you going to WordCamp Europe in Belgrade? Please help us out! Give @rianrietveld a ping in WordPress Slack and we will add you to the Gutena11y table.
Publishing Flow accessibility:
The conclusion of the discussion with this ticket is: we need to work with the current design and get that working for keyboard. We should probably start trying to fix keyboard interaction, tab order, focus management, etc. Needs a developer.
Consider a mechanism to customize shortcuts, e.g. Ctrl + backtick:
There is a good discussion with the issues but no PR or actual progress so far.
Still marked for merge proposal, because without this some features are not available for all users. Needs a developer.
Components and features should be logically placed within the main regions:
From a coding perspective, it’s mainly about the publishing flow.
Once that is fixed, it should be made clear in the Gutenberg developers documentation that any UI must live inside the landmark regions, with the exception of modals and the like, since they’re typically injected before the closing <body>.
Switches should always show On/Off label:
This is a design decision that conflicts with accessibility. It’s hard to create consensus over this.
Our question: what is the value of these switches compared to native checkboxes, besides being pretty. Native checkboxes are universal, simple, clear and very accessible.
Team meeting
Handbook
Going steady. We just need people to read the pages in the section Best Practices. For readability, completeness and accuracy. Volunteers are very welcome
Gutenberg
About the Gutenberg Assistive Technology manual: Rian talked with the docs team and the best place for a Gutenberg AT manual will be the new HelpHub. We now have access to write content there. Maybe (in the far far future ) we can convert it into an overall AT manual for the Admin.
The Gutenberg “Inserter” is probably going to change, there’s one more iteration and a pending PR that changes it significantly. In a first look it’s an improvement, accessibility wise.
We plan to organise a “Pair/Peer programming with a Subject Matter Expert and Dev” for the WCEU contributor day.
The a11y team has not enough expertise to write a pull request for some of the milestone issues and the Gutenberg developers have enough expertise on web accessibility. So pairing them up at the contributor day seems like the best solution to get work done quickly. We will write a dedicated blog post about it and make some noise to recruit developers.
Action
Write ATAG statement: Joe Dolson
Write about what WCAG 2.1 means for the WordPress project: Rian (planned for end of May)
Organise Gutenberg Pair/Peer programming for WCEU contributor day: Rian (this and next week)
Simplify and streamline keyboard navigation through blocks:
First: what if the block toolbar had only one tab stop and navigating through its controls would be possible with the arrow keys? Would users be able to get it?
Interaction modal: ARIA toolbar example
Conclusion: we are going to try this and let it test by some advanced keyboard / screen reader / VIM users
Second: the tab order
A good tab order would be for example: insert block, then editable area and then the rest. But should the visual order meet match DOM order? @afercia will try to investigate on the first two things in the next days
Publishing Flow accessibility:
Nic Bertino did research on this and created a design proposal, that needs following up by the design and develop team.
Weekly meeting
Handbook
We added new pages added about Test for web accessibility to the handbook’s Best Practices chapter. If there are people who want to review what is published, please do.
Sami Keijonen tweeted posts from the handbook in a series on Twitter. Nobody uses Facebook in the team, so we won’t start a Facebook campagne.
Gutenberg
Summarised: Minor fixes went in, the bigger issues are still to solve.
We need to write a manual for AT users. We need people who are familiar with Gutenberg to be involved in writing the manual for AT users of Gutenberg. We can start outlining the processes and AT combinations to be documented. Rian will investigate what the best place is to publish this manual. Rian and Sami want to help writing.
We will dedicate our weekly bugscrub now on Gutenberg for now
Nicolas Steenhout has a podcast: A11y Rules. He’d love to speak to people that are NEW to accessibility, either working full time in it, or developers that are exploring #a11y.
I would love to speak to people that are NEW to accessibility, either working full time in it, or developers that are exploring #a11y. I'm looking at that "fresh to the work" perspective for my A11y Rules Podcast. Please let me know if you're interested. https://t.co/XFrhFN0h9U
We picked a new time for the weekly a11y bugscrub and team meeting:
During the daylight saving time (as in now):
Accessibility bug scrub: Wednesday 14:00 UTC
Accessibility Team meeting: Wednesday 15:00 UTC
Starting next week, May 2, so the meeting on Monday 30th will be cancelled.
Handbook
After the handbook is sort of finished we want to maintain it via GitHub. That way more people can contribute or file issues. @nicbertino will help migrating the content we have now to GitHub and we are looking for an easy way to push the GitHub pages back in the handbook pages on wordpress.org.
Kudos to WPTavern for publishing a post about the handbook and the need for help.
At the moment we don’t need writers, but we desperately need reviewers with knowledge of accessibility and native English speakers to go through the pages on Best Practice we have published or are in draft on Google Docs.
@samikeijonen will post a series of tweets on @WPAccessibility to promote finished content in the Best Practice section. Which already gave discussion on Twitter, so that works well 🙂
At the moment @rianrietveld and @samikeijonen are writing pages about how to test for accessibility to add to the handbook best practices chapter, for developers, designers and content managers. This at the request of the Gutenberg team. The pages are in draft now, to be published this or next week.
Gutenberg, priorities for WordCamp London
@karmatosed suggested the following workflow for this:
sit down together at a11y table on the contributor day prioritising all a11y issues in a spreadsheet
create a solid few weeks plan for accessibility, get everything in milestones, get everything so we all know we’re on track
get a ‘hot list’ from that and give easy wins to developers present at the contributor day
leave that clearly knowing what needs to be done for a11y and how help can get there
focus on a plan of tasks and that all tasks have enough information to be developed by anyone working on project
Contributor drives
Angela Jin asked us to write up content for their info pages about work that can be done for the different teams during a contributor drive (a bite sized contributor day). @rianrietveld also adjusted the page Getting Started at a Contributor Day for this too.
If a contributor wants to select an a11y task:
Tell the #accessibility channel in WordPress Slack that you are hosting a Contributor Drive and request specific projects and direction.
If you need assistance during the Contributor Drive, ask questions in Slack.
To avoid having to maintain a page with a list of tasks in the documentation of the contributor drive.
Open floor
@postphotos came with the idea of organising “contributor drives” in regions across the world, focused on a11y. Like the translation days. He will research this further. We agreed this is a fun idea (wpa11y day?)
@arush will publish her research on the screen reader accessibility of Gutenberg this week
We had a discussion about adding hreflang to links in translatable strings, like e.g. <a href="%s" hreflang="en"> . Adding the hreflang="en" in the translation triggers a warning
We discussed setting a new date/time for the meetings. There will be a separate post about this tomorrow.
How accessible is Gutenberg in its current state (version 2.4)? To answer this the Accessibility team set up a list of minimum requirement, did code reviews and research, gave recommendations and set up user tests.
The short answer is:
Gutenberg still needs extensive work to meet basic standards, like keyboard accessibility and semantics
Especially for screen reader users, Gutenberg as it stands right now is a dramatic step back in usability
We need to write a manual/documentation for assistive technology users
From the start
During development, almost from the start, Andrea Fercia (@afercia) did extensive a11y (accessibility) testing and research. He and others created issues labeled accessibility on GitHub to address the issues found (Andrea created more than 50 of them).
At the moment 70 a11y issues are open, 166 are closed. A lot has been addressed, but there are still very important issues open (like for keyboard accessibility, tab order and navigation).
User testing
When Gutenberg 2.3 was released, Tammie Lister (@karmatosed) considered it ready enough for a complete accessibility test.
We wrote a user test, that includes the basic functionality needed to publish a post. Like add a title, headings, paragraphs, a list, a table an image and a video, use the block options and publish.
On our testserver wpaccess.org we installed the plugin, version 2.3, and gave our a11y test team access. Joe Dolson also recruited accessibility experts for a test of version 2.4 at the CSUN conference. All results are reported in the Google spreadsheet Gutenberg a11y test results.
So far we’ve got good quality test results for
Keyboard only
Dragon Naturally Speaking
VoiceOver / Safari
NVDA / Firefox
Andrea created new GitHub issues from the reported problems or added extra information with the already reported ones.
Videos with user tests
Note: These users (Eric Wright and Sina Bahram) are leading accessibility experts, using their assistive technology on a daily basis and using WordPress for their work.
Minimum requirements before merge
To set a baseline, what should be fixed before merge we set up a list of requirements:
Keyboard navigation through blocks needs to be greatly simplified and streamlined
For some components, there’s the need to constrain tabbing within the component (i.e. they should behave like “modals”)
The publishing flow needs to be simplified, currently its accessibility is terrible
Everything needs to live inside the landmark regions
Text mode: a simple textarea is the only guarantee to enable users to publish content, regardless of the device / technology they use
Write documentation for keyboard and screen reader users.
Consider a mechanism to customize shortcuts, e.g. Cmd/Ctrl + backtick, see issue #3218
Block toolbars position counter intuitive for keyboard users, see issue #3976
The Date picker must be keyboard accessible
Severe issues
One of the most severe issue is the keyboard accessibility. The keyboard tab order is unpredictable. The tab order for and backwards is not the same. Publishing a post is a puzzle and the date picker is unreachable with a keyboard only.
Another issue is the need for quick navigation tools, like shortcuts and better use of landmarks and headings. There are so much more actions to take for adding or modifying a block. Compared to the current classic editor, publishing a post with a screen reader takes much more time and effort.
Because the extensive use of icons, voice recognition users have to guess the accessible names for buttons to activate them. This needs a design decision.
Actions to take
Fixing the keyboard accessibility and screen reader navigation is a high priority. Andrea opened issues for this and we need to prioritize these
At WordCamp London and Europe we will do extra user testing with assistive technology and discuss the results with Tammie Lister and the Gutenberg developers present
The accessibility team needs to take responsibility for the manuals and documentation. This documents only can be written after the minimum requirements as listed above are met
@joedolson was at then CSUN conference last week and asked Léonie Watson and Sina Bahram to have a go at the Gutenberg test. Both are internationally recognized experts in web accessibility, WordPress users and highly experienced both at testing applications and coding.
Test results
Leonie Watson found the system extremely difficult to use. She currently runs her own WordPress site, and has for many years, so her starting assumption was to expect her past knowledge to be useful, and to attempt to use it as a standard page.
Sina Bahram immediately assumed that Gutenberg was an application, and should be operated as one, but found it frustrating that this turned out to only sometimes be true. Strongly suggested using the application role so that interactions would be more predictable. Video of Sina’s session (20 min)
One comment that both users made specifically was that they “didn’t trust” the focus management, and both elected to try alternate methods of navigation (link nav, heading nav, find in page) specifically because they didn’t trust that tabbing would take them where they expected. The most problematic issue there was the block menus having different forward and backwards action.
Both users also attempted to search for help at some point, feeling that there should be some kind of instruction to inform them how the interface worked, but did not find any.
Unpredictability is one of the biggest enemies Joe saw in these tests. Users got frustrated not knowing where their next interaction would go.
CTA
During the meeting we discussed use of role="application" and role="textbox" and we will do an A/B test on the test server to see if that makes the interface better usable for the combination Firefox & NVDA.
We will publish a post this week summarizing all test results and the work that needs to be done on Gutenberg before merge.
Underlining of links in the content
In new committed code, there is no underlining for links in text blocks. But according to WCAG: links must stand out in the text, not by colour alone. To prevent this from happening this should be added to the Accessibility Coding Standards for WordPress Core. This was also added earlier to the Theme Guidelines.
