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. [product_banner product=”seo”]
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.
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
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.
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.
React and accessibility
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.
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.