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.

How accessible is WordPress core at the moment?

Well… It depends…

It depends on

  • How smart you are using the internet
  • What assistive technology you are using (like keyboard only, zoom text, a screen reader, adjusted colours, voice recognition software)
  • How well you can use your assistive technology
  • How good your internet connection is
  • Which browser and device you use
  • Where you live: who tests for Opera Mini, a mobile browser widely used in Africa?

But overall, if you don’t get too fancy and keep it simple: the accessibility of WordPress core is pretty good!

If we look at the front end

And the Admin

If you are a keyboard only or screen reader user you can:

  • Add and edit content and markup, with now also editor shortcuts and in WP 4.6 an improved Tag and Category management
  • Add and edit a menu
  • Add and remove a widget, in the screen options you can enable the accessibility mode, which makes it keyboard accessible

So, overall

Publishing and maintaining an accessible website can be done, sometimes with more explanation and training for content managers using assistive technology.

But the basis: an accessible front end theme, adding and maintaining content and setting up a menu: all totally doable.

Work that still needs to be done

But there is still a lot that needs improving and is work in progress. At the moment we have more than 100 tickets in WordPress trac labelled accessibility.

Colour in the Admin

The colour contrast between text and background in the admin can be improved. This is work that needs to be done together with the design team. We don’t want to end up with something ugly or totally different from the official WordPress colour scheme.

But besides this: what about adding an additional very high contrast Admin Colour Theme? This would help many users with difficulties seeing contrast.

Legacy code

How to improve the HTML we inherit from previous releases and that is also heavily used by plugins? We can’t just change this into something decent, it will break plugins or themes.

For example:

  • The Settings API is still in HTML-tables and we all know now: tables are for displaying data and not for handling layout.
  • The “add new” link inside the headings of admin screens.
  • The title attribute in the tag cloud widget. To remove that we may need extra CSS in the front end of a theme, like screen-reader-text class support.

Solving this need the cooperation of the design team and core team, but also the help from theme and plugin authors. If we change code like this we need to communicate this with them very carefully. We don’t want to break stuff while trying to fix it. Broken stuff isn’t accessible at all…

Consistency within the admin screens

“Don’t make me think” is a universal rule in web development. People expect things to work in a certain consistent way. This is not only the case for people using assistive technology, it is the same for all of us.

For example the Search in the admin.
In list tables like all posts and all pages, the search input field is on the right together with a submit button.

 

On the search theme page it is on the left next to the title, without a visual submit button, but with a placeholder.

 

On the search plugins on the right again, also without a visual submit button, with a placeholder.
How many times have I unintentionally installed JetPack because the “install now” button was the first button in site, as I am used to press a button to start the search.

 

A good read on how to design plugins (and featured projects) is by Tom McFarlin Improving WordPress Plugin User Experience:

Try to make sure that your project tightly integrates with the core WordPress user interface

Review of accessibility-ready themes

Not a code issue, but a workflow issue is the way we are reviewing themes submitted for the accessibility-ready tag in the WordPress.org repository.

A theme developer submits a new theme, takes pride in making it beautiful and also accessible. And then has to wait up to 5 months to get a response. That’s way too long.

When eventually the theme author gets a response about the accessibility they’ve already moved on and abandoned the theme. Or dropped the accessibility-ready tag altogether.

So if a review is delayed, in a lot of cases it’s time wasted. We need to find a way to turn this around. This is not the fault of the people who do the reviews. They are volunteers, doing this besides their full time job, and reviewing takes time, also there are a lot of themes submitted.

So we now have a situation where themes are submitted and withdrawn or abandoned for the accessibility-ready tag, that is such a pity!
What we need is a better workflow, more reviewers and a way to automate the process. If you know how to solve this and want to contribute to this, please reach out to us in the #accessibility Slack channel.

Subtitles and translations WP.tv

During the last year work has been done for wordpress.tv to make the video’s more accessible for screen readers and keyboard users. That’s wonderful! So lets take this to the next level:

On May 18, 2016 there were 4648 videos of presentations on WordPress.tv, of which 246 have subtitles.

That’s 5%.

We can do way better than that!

Maybe, from now on, every speaker should add subtitles to their own presentation (or organise someone who does that for them). We all hate it to hear our own voice and listen to the mistakes we made. But subtitles and translations give you a larger audience and that’s why you were speaking in the first place anyway.

And then there is the Media

Where to start.

In my opinion the Media needs to be a featured project, we need to rebuild the Media, new, from scratch.
We need to research how to add and maintain images, galleries, files, audio, video, subtitles, translations, captions, descriptions. How to do this in a beautiful, usable, consistent and accessible way.

All the accessibility repair work we do now is like solving problems with duct tape instead of building for sustainability.
The Media is complex functionality and at the moment people using keyboard only or a screen reader have major difficulties using, understanding and navigating it.

Changing the Media will be huge effort, will take time and team work. Not only from the accessibility team, but also from the design team, the core team and the people working on Images Flow project. If you have ideas on how to start and manage this, please contact us.

We need to keep focused

WordPress is constantly changing and being improved on. We are lucky to be part of such an active,  enthusiastic and knowledgeable community.
We all need to stay alert and keep focussed on the accessibility of what we build.

If not, we end up with functionality that is built from a visual and mouse driven point of view only, with no respect for semantic HTML or W3C code validation or accessibility.
Where accessibility is added later with duct tape solutions. This results in ugly code that is more difficult to maintain.

Like recent big developments based on React in the WordPress world, stating that we can keep and use the old Admin as fallback is not the way to go. Good code works for everyone.

To be clear: JavaScript is not the enemy, we just need to do more research and keep testing new functionality. Aim to keep everything as accessible as we can for everyone.

For example: the Customizer is an accessibility challenge and a playground where we tried out improvements limited to the Menu Customizer.

Milestones

And now for the good news: 2015 and 2016 have been amazing!

WordPress goes WCAG

To start with the best news:

On February 15th, 2016, the WordPress Accessibility Coding Standards were approved and added to the Core Handbook as a part of the code standards WordPress developers are expected to meet when contributing to core. So: WordPress goes WCAG.

In short:

All new or updated code released into WordPress core and bundled themes must conform with the WCAG 2.0 guidelines at level AA.

Wat does this mean?

In April this year the European Union agreed on an accessibility directive for websites, intranets, digital documents like PDFs and mobile apps. Heather Burns wrote an excellent overview on what this means: Bigger, better, and brilliant: EU approves a new #a11y directive.

When your country makes this directive into law (as many already have or soon will do), governement and public sector web sites must be WCAG 2 AA accessible. So by adopting WCAG, WordPress is getting ready for laws within the EU.

Implementing this will mostly be an effort for theme and plugin developers and we need to reach out to them and help. Coders and designers need to learn the how and why. We can’t expect everyone to know all the WCAG guidelines by heart.

So the accessibility team started to provide help with:

Documentation

Last December, at the community Summit before WordCamp US 2015, Trisha Sales and
Barrett Golding laid out the framework of our new Handbook, to provide developers, designers and content managers with good resources on accessibility. The aim was not to rewrite every document there already is on the web, but to guide you to the resources already there and also give specific WordPress info.

This is still work in process and the documentation will change and improve over time. But if you need a place to start your study, read the Handbook and go from there.

Let WP speak

A useful new JavaScript method was added in WP 4.2: wp.a11y.speak().
According to Joe Dolson:

This method provides live updates for JavaScript events to users of screen readers – with the side benefit that developers of plug-ins and themes can also make use of it either on the front or back end.

Test team

You might not realise this, but WordPress is used as a content management system by many people using assistive technology. And when we called for testers we got responses from many of them. They finally could speak their minds and were eager to help, to make their own life and that of others easier.

We now have a test team with more than 75 people: users, accessibility experts, WordPress developers. They get an email regularly with an issue to test and we report the results back to the core developers.
For this we have a dedicated test server, kindly sponsors by Nimbus Hosting Ltd.

 

If you are doing work for WordPress core, and want your work tested for accessibility, please contact us in Slack. We can set up a test and get the result back to you with  recommendations on how to improve your work.

Where do we stand now?

We’ve got a great accessibility team and the support of the core developers and release leads. We have time on our side: Web accessibility has became an important worldwide topic, with countries changing their laws to ensure government and public service sites become accessible. WordPress is following that trend thankfully.

Better communication

The Accessibility team works more effectively and we communicate better with the other teams. Last year Andrea Fercia did a ton of work on fixing and researching issues in core. By doing this he earned rock start credits for 4 releases in a row, and is now a core committer. Very well deserved!

Going to the yearly Community Summit, WordCamp US, other WordCamps and contributor days proved to be very useful.

https://twitter.com/RianRietveld/status/718480106591817728

Life outside WordPress

Not only inside, but also outside the WordPress community, people are reaching out to us, for discussion and research.  Together we can test and research the issues we share, like we did for Select2, a jQuery based replacement for select boxes.

And I discovered: WordPress can push buttons.

With such a large percentage of the web running on WordPress, it is also important for browsers and assistive technology companies that their software runs well with WordPress.

For example: When we called for testers with Dragon NaturalSpeaking, Alex Korik, the head of Software Quality at Nuance, offered to help.

And the best thing ever: WordPress developers and designers start to learn a11y and take responsibility. Like developers in the Genesis Community.

We are no longer a standalone group easily to be ignored, but we are integrated in the teams and accepted as a part of the workflow.

So… what can you do?

While you are learning JavaScript deeply,
please learn accessibility deeply too!