The a11y Monthly: Web content accessibility at Yoast

Universal access to content is an essential aspect of the web. Helping people finding content is one of the first steps. For that reason, it is the responsibility of every developer to make sure content is accessible for everyone. At Yoast, accessibility matters a great deal. We’re all focused in an ongoing effort to improve the accessibility of our plugins. This is the first in a series of posts aimed to highlight some of the relevant work done. I’ll discuss the decisions we made to enhance the accessibility of our products.

Web accessibility is a process

You’ll never be 100% accessible for everyone. People have different needs. What’s accessible for somebody might be inaccessible for someone else. That’s why it’s clear in our minds that continuous improvement forms the basis of accessibility. We have to integrate it into the design and development process. Of course, the technical choices and implementations are very important. But sharing knowledge and building accessibility expertise on our team is also important.

How we started

Improving accessibility on an existing, vast codebase can be challenging. A few months ago we decided to start with the basics and focus on the Yoast SEO meta box first. This is where the content analysis happens. It is also the most used part of our flagship plugin.

First things first, good accessibility starts from a clean, semantic, HTML structure. The content analysis shows users a significant amount of information. So, it can be hard to organize that in an understandable way. Our priorities were simple: we had to identify content sections with headings, label all the user interface controls, and ensure all form elements had corresponding associated labels.

Better headings

With headings, for example, it’s not just a matter of better semantics. Users of assistive technologies use headings as the predominant mechanism for finding page information. Headings must have a proper hierarchy and should not skip levels. Because of this, you avoid that users find the page difficult to navigate.

We did a complete review of the headings on all the plugin settings pages as well. We introduced several other improvements, including better form elements, labels, and grouping related elements. After that, we also improved the focus style to give feedback to keyboard users and improved the user interface controls semantics. Besides that, these enhancements are part of our ongoing effort to improve accessibility.

Contributing to Select2

Yoast SEO uses a JavaScript library called Select2. This library replaces native HTML select elements with a widget. The widget provides search and autocomplete functionalities. At Yoast, we are firm believers of open source and collaboration. Thus, we’ve donated one week of research and development time to improve the accessibility of Select2.

Advanced JavaScript widgets can be challenging for accessibility. Due to that, we found this a nice opportunity to experiment with advanced solutions. The Select2 team was always open to feedback. We look forward to seeing accessibility improvements in the next Select2 release.

Accessible tooltips

When looking at a user interface, you see that controls in a user interface feature icons. However, these controls need some textual alternative to convey a correct information. First of all, icons seldom have a universal meaning. Depending on the local culture, people use these to communicate different things. Additionally, icons are ambiguous for users because they have different meanings on various platforms and interfaces. They need some text.

Some experts say you should always use a text label alongside an icon. However, we’ve opted for a solution based on the aria-label attribute to provide an accessible name. So, assistive technologies can announce the aria-label text. At the same time, we use the aria-label attribute to generate visual “tooltips”. These reveal themselves when hovering over the icons with a mouse or focusing them with a keyboard. What’s more, it’s a CSS only solution, so no JavaScript involved. The GitHub implementation inspired this solution. It’s a good balance between design and accessibility requirements.

Color contrast ratio

Approximately 1 in 12 men (8%) and 1 in 200 women in the world have some form of altered color perception, from moderate to severe. That’s one of the reasons why the Web Content Accessibility Guidelines recommend a color contrast ratio of at least 4.5:1 for the AA level. We must ensure that color contrast is always visible. Because of this, we’ve decided to base all our future developments on a standardized color palette.

A11y-speak

Inspired by wp-a11y.js, we’ve built a simple tool to dispatch audible messages to screen readers. Updating discrete regions of a web page with JavaScript is pretty common nowadays. The update is easy to see at a glance, but there’s no audible feedback for screen reader users that an action has started, completed or failed. To create audible feedback, you can make and append an ARIA live notifications area to the <body> element. Developers can use this area to dispatch text messages. Assistive technologies will automatically announce any text change in this area.

We want to make the wp.a11y.speak functionality available for everyone. Therefore, we’ve decided to create a dedicated JavaScript module for it, called A11ySpeak. It’s a breeze to use, and besides that, open source. Developers can include it in their projects and contribute to improving it.

React and accessibility

Modern JavaScript libraries offer a different challenge for accessibility. Continuous updates of web page regions and heavy DOM manipulation can confuse assistive technologies. It can result in a degraded experience for people using them. React is a JavaScript library for building user interfaces and we will use it to build our future interfaces.

At Yoast, we’re open to experimentation. In a traditional web accessibility view, we prefer native HTML interfaces. Software, including assistive technologies, know how to deal with HTML and its “classic” interaction model. We do believe in innovation and progress, so we’re always experimenting new solutions and development patterns. From an accessibility point of view, this is an exciting challenge. We’re looking for a good balance between modern interfaces and a good level of accessibility.

One of the first components we’ve developed with React is our Knowledge Base search. We’ve integrated this into our main plugin. Our team did an excellent job, and the search is fast and effective. The best approach to accessible user experience is to integrate accessibility into the development process from the beginning. That’s why we’ve made sure that the Knowledge Base search interface is fully operable with a keyboard. It uses A11ySpeak to give feedback to users when necessary.

Yoast SEO configuration wizard

One more recently released React-based interface is the new Yoast SEO Configuration Wizard. It’s a tool aimed to perform a complete initial configuration of our main plugin in ten steps. Being a single-page mini application, it uses heavy DOM live changes that need a special accessibility treatment. In these cases, ensuring the interface is always operable using only the keyboard and the keyboard focus is never lost is a priority. From a technical point of view, this was interesting.

On a personal note, this was my first active, direct, participation on improving the accessibility of a React component. It’s great to be part of a team that enjoys working with modern development patterns. It’s a magnificent opportunity to experiment with new directions for web accessibility and to help to build accessible solutions for the modern web.

Stay tuned

We’re constantly improving our interfaces, and we’re aware we can improve the existing ones to a certain extent. Further improvements often need a complete re-design that requires time and development. We’re on it. Stay tuned.

Want to help?

As said, accessibility is a process. It’s based on continuous improvements, testing, iteration, and development. You can help. We’re always open to feedback and contributions. Please do not hesitate to let us hear your voice and please do report any issues or potential improvements you notice in our products.

Read more: Documenting JavaScript in WordPress »