There has been some progress on minor issues.
Major issues still need to be addressed but those will require discussion and decisions.
One of the main issues reported in the first testing round is that there are too many tab stops.
Currently, navigation through all the interface works with tabs meaning ALL the controls are tabbable.
Considering how some of the Gutenberg UI parts are actually ARIA widgets, ideally, they should implement focus as recommended by the ARIA spec and the ARIA Authoring Practices. For example, toolbars and menus should be navigated with arrows only.
There’s definitely a need for more people to do testing and give feedback but we also need help with coding solutions.
The code can be confusing for those who are new to react. In light of this, it was proposed that we add an additional label to help React devs understand the expected outcome and make sure they know the end goal. Some possibilities are `[Type] A11y Task`, `needs React dev` or `has-a11y-feedback-needs-implementation`
To clarify the issue about too many tab stops, consider this example:
This is a Gutenberg “inline toolbar”. They change depending on the block.
All the controls in the toolbar are tabbable.
Instead, according to ARIA, if we want to treat this an ARIA toolbar, there should be just one tab stop on the toolbar and then all the controls should be navigated with arrows only.
That would greatly help to reduce the number of tab stops. The mixed tab/arrows navigation is a solid ARIA pattern borrowed by our operating systems.
1 Handbook
Sami Keijonen asked about the handbook: I actually really like the structure of theme handbook, can or should we use the same kind of format?
Also, the Breathe Theme is broken that we are using for https://make.wordpress.org/accessibility is broken:
On mobile Genericon is missing on “hamburger” menu.
Mobile menu doesn’t open at all.
We would like to do an a11y review on the theme for the theme handbook and fix the theme itself
2 Other a11y documentation in wp.org
We’ll start next week’s meeting with the handbook as well as other wp.org documentation.
We talked about five topics in our weekly meeting:
How to process test results for Gutenberg.
New Handbook topics.
Project managing a11y tickets in trac.
Windows High Contrast mode.
Open floor.
We tried Slack Threads for the first time. Each topic was in it’s own thread. It was mostly confusing and you can’t put images or code snippets in the thread. Good thing is that afterwards it’s easier (at least for me) to follow discussions.
It’s worth noting that Devon Persing and Scott Vinkle joined our meeting. They work in a team called Simply Accessible.
Here are short summaries about discussions.
How to process test results for Gutenberg
First Gutenberg test results are full of data. Andrea Fercia have filtered the report and I’ll post issues in Github. We also agreed to follow accessibility label in Github. We should know at least the titles of the accessibility issues. Unfortunately most of the team members doesn’t have enough time to contribute on Gutenberg.
It’s also important to create more specific tests with simple tasks like
keyboard navigation.
focus management.
navigating between different parts.
screen reader text issues.
New Handbook topics
We have started gathering topics to new accessibility handbook. The idea is to educate others by writing summaries of different topics and collect good resources of them. For now ideas are in Google Sheet, let me know if you have more topics in mind or want to help out in any other way.
Project managing a11y tickets in trac
Trac can be overwhelming even if looking info from Trac Handbook. Therefore Morten Rand-Hendriksen pulled data from CSV export into Google Sheet. We are exploring would that help
to get a quick overview of what’s happening.
see what tickets new contributors should focus on.
see who is involved and what the status is.
We are not sure yet how to make use of this and Morten will look into it more. For example could it be automated.
Windows High Contrast mode
High contrast mode benefit users with low vision or people working in dark environments. More information can be found in two places:
In this post we gathered testing results for the new text editor Gutenberg.
As the functionality is work in progress, we will use these test results to create issues and add to the discussion on GitHub.
If you wrote a blogpost about this or published test results in another way, please add this as comment to this post, or tweet it to WPAccessibility. Then we’ll add it to the list of blog posts with testdata.
In this post:
Results WPa11y test team
Blogposts with test data and research
Call to action
Results WPa11y test team July 6th 2017
Thanks to: Janki Moradiya, Riddhi Mehta, Shah Rishi, Geof Collis, Gabriela Nino de Rivera, Reagan Lynch, Shaun Everiss
We asked the accessibility test team to look at the plugin. Below are the reported a11y related experiences and issues:
General opinion:
Reagan: My first and initial impression, and yes I understand this is early testing, is that Gutenberg is a major change and major step backward in WP accessibility. I strongly encourage the WordPress development team to NOT put this as the default editor. If you want to force it then do so on wordpress.com, but give us a choice with the .org (self-hosted) version. Gutenberg as it currently stands will force me to consider other platforms. In fact, after giving up on the second blog post I opened a Ghost account for the first time ever and began learning how their system works. If Gutenberg becomes the default Ghost will be the more accessible platform. (Using Windows 10 with Firefox and JAWS for Windows.)
Geof: To put it mildly, I don’t like it, it is too complicated and busy. I found it easier to add an image and move it around with in the main body if necessary, using a screen reader there are too many actions to deal with, I hope they drop the idea. (Using IE 11.096, JAWS 11 with latest updates, Windows 7.)
Shaun: I think in general, as long as you never need to change styles, add lists of media or ever interact with the button panels, then you should be fine. So what if you have to? You just can’t [Editor: mild translation of the original text]. (Using Win7 Pro, NVDA, Firefox)
What is a better experience
Without assistive technology:
Block arrangement and easily adding blocks on the post
Embedded any video or clip is too easy.So, now add media it’s not tedious anymore
The main part is code option is we can add the shortcodes and other PHP code directly. It’s so cool
Display latest post via Widgets is too easy
Add all HTML element easily and mainly add and other tags which are very interesting.
Easily move blocks with the up-down errors is too useful
The look and feel of the visual editor are good and it is very easy to manage content and I think it’s time-saving for development.
What is worse
Without assistive technology:
Aligning blocks and makes clicking into content areas are problematic.
Having a whole section for Embeds of only tangential use seems clumsy.
When I publish the post there is not a “VIEW” button available for that post edit screen of Gutenberg.
If writing something in the text block and click on undo button it was removing the whole section instead of new word or sentence.
If I select any text from the content block then it’s selected the whole block for delete so, it’s considered my selection as deleting a block. For batter understanding, I have captured a video for the same.
With VoiceOver + Safari:
It was very difficult to navigate between blocks and options for formatting. If I have more than 2 blocks moving from one block to the other is a long way. I need to pass through each menu and button associated to the block. It is very tiring. Also, accessing options in the menus don’t respond well to VoiceOver commands. I was often redirected to other places in the page like “post settings” or “skip to main content” link.
The insert button it was not intuitive, it took me a while before finding how to insert a block image.
Insert link options buttons (enter, edit and erase) does not seem to have labels. VoiceOver announces them only like “button”.
When inserting a link, if I don’t type a URL address beginning with http://, Voiceover announces that the data is invalid. The insert link object keeps announcing “Enter a URL” like if any text were already typed. There is not a proper message to explain the user why the data is invalid or a placeholder (or something else) to show the expected input format.
What is impossible to do
Without assistive technology:
I think in current version changing the post format is impossible.
Not able to move “Separator” when blocks structure are typical. For better understanding, I have captured a video for the same.
There is always a placeholder “Write…” with text box it’s become confusing to add new block and it consumes one block space as well. For better understanding, I have captured a video for the same.
I have created a table and added data into it. Later I add the table in the same post the table will create with old table data automatically. If I delete the table from the post and later I add the table it will comes with the last data of the table.
With VoiceOver + Safari:
When editing text in a block, it is better to select an option in a menu before writing content. If text is already in the block, it is not possible to select it and then select an option in the menu to apply a format (like for example select a list, or bold or italic). I think it would be nice to have shortcuts for applying format without quitting the block. Something like selecting text and then using a shortcut for applying the desired format without having to navigate all the elements between the block and the menus.
Settings button does nothing when clicking on it.
With Windows 10 with Firefox and JAWS for Windows.
The post screen does not have a very intuitive layout. In visual mode the buttons to edit do not appear until after I begin to add content. I’m unclear on how or if I can change the level one heading for the title.
When I tab from the title field to what should be the content area I think I was adding a line of content. Upon pressing enter to start a new paragraph I was taken out of forms mode and completely lost on the page for a few minutes. I should not be taken out of forms mode in a content body text area type field.
I changed to the text mode, and while typing content was easier when I attempted to select text to make a link I saw no field to add a link like is currently present with the editor in 4.8.
At one point when I selected text to make a link and then pressed enter on the link button in text mode text I had entered disappeared. From reviews I’ve read it seems there are buttons that appear when I first enter a “block”, but using a screen reader I don’t know what those are.
I like to write blog posts and page content outside of WordPress using an editor like Jarte. When I copied text out of Jarte in this test and went to paste it the experience was terrible. I cannot paste without losing all formatting. I also don’t understand “blocks”. Using TinyMCE I feel like I’m in a very accessible environment. With Gutenberg I want to stop blogging.
ON the Gutenberg page it says, “The goal of the block editor is to make adding rich content to WordPress simple and enjoyable.” Well I hate to say it, but as a power user of WordPress it makes adding rich content more complex for me.
I wrote two blog posts, or tried. With the first I used my normal copy editing process and had the post done and ready to go within an hour. WithGutenberg I was still trying to format the text correctly two hours later and had missing content that just disappeared. I gave up in frustration over the process
What don’t you understand
Without assistive technology:
I did not understand the work or use of the first button in post settings panel.
I found that in text editor all top buttons/tags are not working properly and when I click on them or out site the text editor “” and “” added automatically and it looks very confusing for me.
I did not find how to add the new row or new column in table format.
Blogposts with test data and research
If you wrote a blogpost about this or published test results in another way, please add this as comment to this post, or tweet it to WPAccessibility.
Are you an accessibility expert? We need your help!
At the moment work is done to improve the WordPress content editor. This project is called Gutenberg. The goal is to improve the interface and make it ready for the future. The new editor is now available as plugin and the work is done on Github.
The accessibility team needs help to safeguard it’s accessibility and we can’t do this alone.
If you are a developer, accessibility tester or work for company that specialises in web accessibility, please help testing or join the work and discussions on Github. WordPress is used by +27% of all websites, so this will have a huge impact on the way people (can) publish on the web worldwide. And we need all the help we can get at the moment.
We agreed on the following new structure: Per topic short explanations, then links to good articles and examples. The resources do not need to be WordPress specific.
We’ll need some method for ensuring the currency and accuracy of resources listed, if we’re going to list specific resources. So probably restrict the resources to the most authoritative ones. And we need to check the resources regularly.
Order of things:
make a list of topics
add an intro per topic
add resources to it
@samikeijonen and @rianrietveld will start with a spreadsheet gathering the topics, everyone can add possible resources to that later, so we can see what we can use for the handbook.
@joedolson is working on a new draft, work in progress.
New Settings API
The plugin Settings API enhanced is now an almost complete prototype, but still needs refinements and design. It’s a prototype though, many things could change. We would like feedback from more people before moving on.
Next New Setting API meeting: July 3 ,2017 at 16:00 UTC in the Slack #core channel
Next WPa11y meeting: July 3, 2017 at 17:00 UTC in the Slack #accessibility channel.
So the community summit, the contributor day and WordCamp Europe happened in Paris. And this is what we learned from all the discussions we had during that warm week in June:
Education instead of taking over
The accessibility team must not try to do everything themselves. Like raise and solve all accessibility trac tickets themselves. What we should do is add to the tickets how they should be solved and let other developers do the patches (or ask them to do). Hopefully this will attract more developers to do accessibility tickets. That way the developers will learn instead of handover to us. Now the team is like a proxy, everything needs to go though us, slowing the process down. What we need to accomplish is that the developers solve the issues themselves, and we just help them if needed.
Handbook
The handbook must be replaced by a list of resources, good examples and test tools, with short explanations. We don’t need to write everything ourselves, but make list of links with a short intro per subject. Focus on education and point to good info. In other words: help and educate the developers instead of fixing ourselves.
Testing and research
We need to ask more a11y experts from outside the WordPress community to assist us with the testing and research. For this we can reach out to companies specialised in accessibility, ask them if they can sponsor time to do research on WP core and featured projects.
So this defines 3 tasks for the a11y team
Teach: Provide easy to use overview of resources for developers
Research: Test and research current and new functionality for accessibility
Help: Review and raise accessibility tickets and provide developers with info on how to solve the issues
This doesn’t mean we won’t be working on tickets and issues on GitHub, we want to move our team focus to research, education and support.
@flixos90 dropped in during the meeting to say 38768 is done! 🎉
@afercia is currently fixing the tests for the custom logo alt attribute, thanks to @flixos90
A11y-task tickets
@afercia helped to define the a11y-task tickets for us.
To summarize:
A11y-task tickets are more related to a11y “topics”. (infinite scrolling, proximity, placeholders, CSS generated content, etc)
A11y-task tickets have an educational purpose 😀
A11y-task tickets are something we don’t have the resources to address right now, but something we should talk about with other people, to increase awareness.
A11y-task tickets are something to point people to when they ask about big a11y pending issues… hey look, there’s this Trac report you can have a look at.
A11y-task tickets are something that should be brought to other teams attention (Design Team, for example)
A11y-task tickets can be used as tracking tickets for separate smaller tickets.
Everything needs to be tested, from the most basic text operation to the most complex interactions. For example: navigation in text with the keyboard, select text, select all, etc.
Installing the plugin is very easy if you already use VVV and are familiar with GitHub
See instructions for installing the plugin here: https://github.com/WordPress/gutenberg/blob/master/CONTRIBUTING.md
The plugin is not complete yet, but feedback should be given as soon as possible.
As a reminder: today is May 22nd and the Gutenberg deadline for a first 1.0 version is the end of June, as far as I know.
There are already several issues open on GitHub with the `accessibility` label.
https://github.com/WordPress/gutenberg/issues?q=is%3Aopen+is%3Aissue+label%3AAccessibility
Discussion about tickets for Future Releases will be put on hold until we are more comfortable with the state of accessibility in Gutenberg.
WCEU Contributor Day
The WCEU Committee has requested that each team come up with a list of goals due by June 9th for contributor day.
@sami.keijonen asked how we should prioritize and organize tasks given that we will have 30-40 people in attendance.
@joedolson mentioned “Training is frequently the most valuable part of contributor days – just trying to get people better educated about a11y. Getting a patch done is nice, but getting 40 people to know a11y better has more long-term value. I’d suggest segmenting the group according to experience, and have different plans for groups with more or less experience.”
The plan is to do both workshops and training along with identifying some simple tickets to have ready.
Homework for the team is
Have a list of goals ready for next week (5/29/2017)
Identify some ‘good first bug’ accessibility tickets
The following is a post by Adam Soucie (@adamsoucie)
Yesterday was Global Accessibility Awareness Day! In celebration, the WordPress Accessibility Team (WPa11y) would like to present the State of WordPress Accessibility for 2017. The WPa11y is always working towards making WordPress more accessible. We have several active projects, and are currently planning larger goals for future WordPress releases. Here’s a breakdown of what we’re looking at for both the present and future of WordPress.
Current Projects
The WPa11y has several active projects, ranging from small changes that the average user wouldn’t notice like color contrast in the admin or removing title attributes to larger projects like making sure the new Gutenberg editor is as accessible as possible before launch.
Tag Cloud Widget
Andrea Fercia, Sami Keijonen, and David Kennedy are currently reworking the tag cloud widget, as it has several accessibility issues. The tag cloud project involves not only reworking the widget, but updating the bundled themes as well. Each theme handles the HTML output slightly differently, and the team is working on standardizing them. This project was born at the first WordCamp US (Philadelphia 2015) and hopes to see release in time for 4.8.1.
Enhanced Settings API Plugin
The Settings API could use some work, so Felix Arntz and Andrea Fercia have created a plugin that ties all of the patches together for easier testing. This enhanced version of the settings API improves on the default render callbacks and proves a more accessible layout. The plugin is available on GitHub and is ready to be tested.
For more on our current projects, review the April 5th meeting notes where we unveiled all of our current projects.
Future Plans
The future of accessibility in WordPress is bright, but filled with work. Just like the rest of WordPress. We have a few big targets including: media, the Customizer, themes management, menus, and plugin management.
A Media Rework
The WPa11y’s biggest future priority is a rework of the media system, particularly the Media Library. To be blunt, it’s a mess. It really needs to be rebuilt from the ground up with accessibility in mind, instead of having the team try to graft on accessibility to what’s already there. Because this will be such a labor-intensive project with input and assistance from nearly every group involved in contributing to WordPress, it will take months of planning to accomplish. Still, media is a vital part of WordPress and a vital part of the web experience in general. We’re committed to making it as accessible as possible for a future release.
The Customizer
Like the Media Library, the Customizer needs a lot of work. With the Customizer getting more and more focus, now is the time for the WPa11y to be making sure that future updates are accessible while improving what’s already there. It is clear that the Customizer is the future of WordPress. It needs to be accessible.
How You Can Help
Accessibility can be scary. It seems like a foreign, complex concept. It isn’t. Testing for accessibility is as simple as using your browser’s inspector to check font sizes and color values or using browser settings to make sure fonts resize. If you’d like to learn more and help contribute to making WordPress more accessible, join the WordPress Accessibility Team for our weekly Slack meetings at 1pm EST on Mondays. We’ll show you the ropes and have you up and contributing in no time!
If you’re a developer who already knows accessibility, even better. There’s a lot of code that needs to be written or refactored to make each of these projects an accessibility success, and you have an opportunity to impact a large part of the internet, from a user as well as a development perspective. You have the opportunity to create code other WordPress developers can and will learn from. The core WordPress Accessibility Team is very small, and the number who are developers is even smaller. Add to this that every one of us are further constrained by the amount of time we have available to devote to WordPress, and you have a recipe for glacially slow accessibility improvements.
To be sure, we’re not asking for all of your free time. But wouldn’t it be excellent if everyone who is a developer, already knows web accessibility, and uses WordPress either in their side projects or as part of their business contributed five percent of their working time, or code, back in order to make WordPress more accessible, faster? Right now, there are one hundred and thirty-four accessibility ready themes available for free in the WordPress theme repository, and reviews for the accessibility ready tag can take months, because there’s more demand for the tag than there is supply of reviewers. Imagine how many themes we could have for people to build accessible sites with if there were no cue?
Please consider contributing to the efforts of the WordPress Accessibility Team if you are able. If you’ve written accessible components for WordPress themes, consider contributing them to the WordPress Accessibility pattern library on GitHub. If you know of a translation of WCAG and its associated documents in a language other than English, send links our way so we can spread them around. And if you can help with any of the projects listed above, please do so.
