Blog

I have resigned as the WordPress accessibility team lead. Here is why.

Update December 5, 2019:
As I am no longer part of the accessibility team and don’t follow closely what is happinging in WordPress core anymore, I’d like to add to following.

This post was about the state of WordPress end 2018. In the meantime other people have stepped up and there have been made improvements to the accessibility and there are effords to change the workflow of a new release and of new features. If you want to know more about the current state of the accesibility of WordPress core, please contact the current WordPress Accessibility team.

Update October 12, 2018:


This post is written with the Gutenberg editor version 3.9.0.

Disclaimer: This post is my opinion and mine alone.

After several years of working on WordPress and accessibility and being part of the accessibility team, I have taken the very difficult decision to leave the WordPress accessibility team. I owe it to the team to explain why I have made this decision and how I hope things can improve for the future.

The last year, especially the last few weeks have been too politically complicated for me. It’s better that someone else takes the lead now.

In this post I’ll try to give an analysis of what the WordPress Accessibility Team (wpa11y team) did during the development of Gutenberg and what the problems are with working on  its accessibility.

Gutenberg

When the development of Gutenberg started, the wpa11y team followed its progress and tested what was there. And we discovered there is much to improve. So Andrea Fercia started to open tickets and tried to find solutions. And that was a huge task.

Codebase

We had four big problems:

  • The codebase of Gutenberg is difficult for all of us, because no one in the wpa11y team is a skilled React developer. So it was hard to implement changes and write PRs ourselves. What we could do is test, tell what’s wrong and what it should be and hope a developer would pick it up. A lot of a11y work has been done by the Gutenberg team but major issues still exist.
  • There was no React developer with accessibility experience in the community, and no React accessibility experts from outside the community willing to work on the issues for free.
  • Functionality that was tested, improved and then approved by Andrea, changed in a later stage, breaking the a11y improvements again. This had quite an impact on Andrea.
  • New functionality was not keyboard tested before implementation (e.g. the date picker).

I used my network to try to get the accessibility experts, companies and developers that know React and accessibility involved. We did a test round in March this year, after asking to the Gutenberg lead when it was ready to do a full test. The results are with the test procedure and with the issues on GitHub.

A complete overview of the test results, with video demos are in the post:
Accessibility of Gutenberg, the state of play.

The results indicated so many accessibility issues that most testers refused to look at Gutenberg again.

Education

Because we could not code all Gutenberg issues ourselves, I decided to help and educate the developers and designers.

Sami Keijonen and I started to extend and reorganise the WordPress Accessibility Handbook adding good practices and ways to test code, content and design. We did a lot of writing, so when filing a GitHub issue, the author can now point to a handbook URL to say: “this is how it’s done”.

This handbook is still being worked on by Jaap Wiering and Daniel Koskinen. See the #accessibility-docs channel in Slack for the discussions about this.

We did research on automated testing. This is still a work in progress as it’s difficult to set up. I wrote a blogpost with my research in Automated accessibility testing during development on the Human Made website and I was gathering the troops to get this on a higher level.

Also, we started a series of dev talks about a11y on meetups and WordCamps.

One good thing to say about all of these Gutenberg preparations is that they increased the visibility of the accessibility team, and it is very good to see them finally getting recognition for their work.

Assistive Technology Manual

For users that depend on assistive technology (AT), like a screen reader or voice recognition software, the learning curve of Gutenberg is very high. If you don’t have a full view of the whole screen or are depending on keyboard focus to perform tasks, Gutenberg is hard to learn.

Claire Brotherton has started to write this manual and she needs AT expert help. See the GitHub issue Manual for users of assistive technology #10373.

5.0 is near

Now Gutenberg is close to release: how accessible is Gutenberg?

In Andrea’s words (and I agree):

“While the Gutenberg team has worked hard to implement some fundamental accessibility features (e.g. focus management, navigate landmark regions), the overall user experience is terribly complicated for users with accessibility needs at the point the new editor is barely usable for them.

The main reason for this lack of overall accessibility is in the overall Gutenberg design, where accessibility hasn’t been incorporated in the design process.

Feedback from accessibility users has been constantly evaluated and Gutenberg is actually a regression in terms of accessibility level, compared to the previous editor.”

Andrea Fercia

What went wrong?

I got feedback this week that we should have written the GitHub issues differently. I was told we should have explained more why they are an issue, so that the developers are more motivated to solve them. Also I got feedback that some accessibility issues are too big, that we should have made them smaller.

It would have been great if this feedback had been added with the issues themselves in a timely way, as some issues are now more than a year old.

In hindsight, what I would have done differently:

  • communicate more often and louder we needed a skilled Gutenberg/React developer way earlier in the process
  • convince the developers that keyboard testing is a must
  • support Andrea more when he asked for a second voice and for testing
  • convince the AT testers to give it a go again
  • invest more effort in recruiting accessibility experts and companies to help

Full time dev

I’m happy that there is now a dedicated developer from Automattic 100% on the accessibility issues. I wish Matthew MacPherson all the best, as he will need it. I hope the accessibility team will help him with everything he needs.

To Matt Mullenweg

To Matt Mullenweg I want to say: please take better care of your community, because WordPress is nothing without it. Cherish the people who dedicate their (own) time and who work very hard to make WordPress the best it can be. Don’t ignore or make fun of them, but talk to them, guide them, inform them. Don’t be disconnected from the community, be part of it.

Thank you

It has been a privilege to work in the accessibility team. I cannot thank them all here. But there are a few people I want give a huge thanks to:

  • Andrea Fercia, who works hard against the odds and often alone on the GitHub issues. I wish I could have provided you with more support for testing.
  • Claire Brotherton, who does a lot of testing and started to write the manual for assistive technology. Claire, you are the unsung hero here, you did so much, and in your own time. You rock girl.
  • Adrian Roselli, who flew several times from the US to WordCamp Europe and London, to help the accessibility team test and find solutions.
  • Eric Wright, who made an excellent video on how difficult it is to use Gutenberg with Dragon NaturallySpeaking.
  • Sami Keijonen, Jean-Baptiste Audras, Laken Hafner, Nic Bertino, Amanda Rush, Rachel Cherry, Chetan Prajapati and all the people in the #accessibility channel, for their contributions and discussions.
  • Morten Rand-Hendriksen, for his help, support, networking, inspiration and time, and for letting me smoke all my cigarettes in his face at the after party in Belgrade.

What now?

I’m not leaving WordPress nor accessibility, and in fact maybe now I can actually work on accessibility again. I will keep giving talks and workshops. I also want to do research and work on tickets. But in my own pace.

I will join the a11y table if asked on contributor days, but maybe I’ll just go to a museum instead.

For Level Level, the company I now work for, I’m setting up workshops and trainings to teach web accessibility and good code practices. Also I will help the designers, content managers and developers of Level Level to become the best agency for accessible WordPress websites there is. Stuff I enjoy to do and that gives me positive energy.

I wish you all the best, and please reach out if you need my expertise or just want to have a chat or share a glass of wine.

Love,
Rian


Quick Accessibility scan of the WordCamp Nijmegen 2018 website.

Date review: 12 Juli 2018

Website: 2018.nijmegen.wordcamp.org
Out of scope: Jetpack addons, the like system in the schedule, the ordering system and the cookie warning. Issues there will be reported to WordCamp Central.

This is a short review of the accessibility of the website for WordCamp Nijmegen 2018. As this is a quick scan,  I didn’t add the why. All this info can be found in the WordPress Accessibility Handbook Best Practices. If the organization of Nijmegen needs help with this, please let me know.

Update July 24: The Nijmegen team fixed the issues that could be fixed in the site. So that’s great!

Found issues

Use of colour

The links in the text are red. They miss an underlining.

Colour contrast

The following elements have a to low colour contrast between text and background:

Orange #fb9634 on white #fff is 2.2.

Used in:

  • Active menu
  • Ticket order image in the main menu

Grey #aaa on white #fff is 2.32

Used in:

  • Forms: the text “(verplicht)”
  • Entry-meta links with a post

Keyboard accessibility

The link “bestel je ticket” is hard to reach with a keyboard, as it’s added to the footer and positions absolute in the top of the page.

The close en accept of the cookie warning misses a focus style.

Heading structure

Header

For every page, in the header here is the code:

<a class="home-link" href="https://2018.nijmegen.wordcamp.org/" title="WordCamp Nijmegen 2018" rel="home">
 <h1 class="site-title">WordCamp Nijmegen 2018</h1>
 <h2 class="site-description">30 augustus t/m 1 september: hét WordPress-evenement voor Nijmegen en omgeving!</h2>
</a>

The following needs to be addressed:

  • This H1 now is not unique for every page and is not telling what the page is about.
  • The site description is a heading now, it should be a paragraph
  • Title attributes on links are discouraged in WordPress

An example of an excellent header is the WCEU 2018 website header. This has a good and logical heading structure.

Homepage

On the homepage, every post has an H1, resulting in multiple H1s for that page. Best practice is to have one H1 per page view, telling what that page is about.

Footer

In the footer the text “Ondersteund door WordPress” is a heading. This should be a paragraph.

Widgets

Widget have a H3 heading, resulting in a missing H2 heading in the heading order.

Headings without content

In some pages an empty H2 is present, like:

<h2 id="aanmelden"></h2>

Code

Again about:

<h2 id="aanmelden"></h2>

This is sometimes places multiple times on a page, resulting in a double id. Ids should be unique for a web page.

Content

Link texts

Don’t use a URL or “here” as link text, but describe in the link text the destination of the link.

Change for example the text:

Wil je op de hoogte blijven van het laatste nieuws rondom WordCamp Nijmegen? Volg ons dan op twitter via https://twitter.com/wordcampnmgn en #WC024. Ook op Facebook kan je ons vinden. Je gaat dan naar facebook.com/wordcampnijmegen of ons event via https://www.facebook.com/events/172282166768794/.

In:

Wil je op de hoogte blijven van het laatste nieuws rondom WordCamp Nijmegen? Volg ons dan op Twitter en via de hashtag #WC024. Ook op onze Facebook pagina kun je ons vinden of via ons Facebook Event.  

 

Going Dutch

This spring comes with change. On May 14th I started working for Level Level, a Dutch WordPress Agency in Rotterdam.  

I left Human Made. And that was a painful decision. But I believe it was the right decision for me to take. Remote working is not for everyone. And I realised, it is also not for me.

Human Made is an absolute wonderful company, my HM colleagues are talented and kind. I did development and a11y reviews for client projects. Human Made gave me time to work on WordPress core, lead the accessibility team, speak at WordCamps, publish research. A true dream job.

But in my heart I was very alone and tired. All the communication in English, working with different time zones, asynchronous communication in Slack, it wore me out. This is me by nature, not the fault of anyone here. Other people thrive on remote working.

The Dutch WordPress community is very close. I always feel at home and between friends in a local WordCamp or Meetup. I realised: this is where I belong. So when Taeke Reijenga, the CEO of Level Level, asked me to work for him in Rotterdam, I said yes.

With Level Level I’m going to join the developers team, teach web accessibility and do reviews. In Rotterdam, not far from where I live.

Besides that I can spend time on the WordPress Accessibility Team; I will continue to work with the Accessibility Team; speak and work at WordCamps and meetups, that will not change.

I’m very grateful for what I’ve learned in my time with Human Made. I’ve made some good friends and I hope to hug and work with them in future WordCamps.

Entering a new chapter in my career now. Feeling good 🙂

Keyboard test Gutenberg, a first try

Goal of this Gutenberg test is to see where currently the problems are and collect data to write a manual for keyboard users. Also I want to learn and construct a standard test for other assistive technology. The test is set up to do the most common tasks for a content manager (who is not a developer). Like add and modify text, headings, images, lists, tables, and embeds.

The test results are part of the large scale Gutenberg  testing for Accessibility, organized by The WordPress Accessibility team.

Continue reading Keyboard test Gutenberg, a first try

Accessible custom styled form elements

The challenge

HTML elements like check buttons, radio buttons or select options can be hard to style with CSS in a custom design. There are many workarounds for this, based on two different approaches:

  1. Hide the form elements from sight and apply the styling on a container or related element
  2. Hide the form elements from sight and rewrite the functionality, using styleable elements like <div>s and JavaScript

Continue reading Accessible custom styled form elements

Accessibility in the Age of the Headless CMS

 Intro

A few months ago I asked in the Human Made general Slack channel: “What shall I talk about at WordCamp Europe?”
And the honourable Ant Miller replied: “Accessibility in the age of the headless CMS.”

React logoGreat, I thought. A new subject, much to learn and tell about, I started to read up on the subject. And then I realised: oh no, I have to learn React!

Continue reading Accessibility in the Age of the Headless CMS

WordPress, state of the Accessibility 2016

How accessible is WordPress now, which improvements were made in the last years and what still needs to be done? Where can you find help and documentation to improve your code? What are the new Accessibility Standards, added to the WordPress Coding Standards?

This post is written for my presentation at WordCamp Europe 2016 in Vienna. You can find the Slides at Slideshare and the video on WordPress.tv. Continue reading WordPress, state of the Accessibility 2016