Earlier this month WordPress developer Morten Rand-Hendriksen released Simone, a free theme based on Underscores. Like many themes, Simone is responsive, wired for translation, utilizes the customizer, and includes editor styles. One feature, however, sets Simone apart – a heavy emphasis on accessibility.
Rand-Hendriksen believes that the accessibility-ready tag should be required for all WordPress themes. “My main inspiration for accessibility is that I want everyone, regardless of accessibility challenges, to be able to access all content on the web in the way they want and/or need,” he said. To that end, he has educated himself on the requirements for making a WordPress theme accessible. He is, however, only one among a very small minority of theme developers to do so.
WordPress Themes Lag in Meeting Accessibility Guidelines
“The alarming reality is only a handful of WordPress themes (and thus WordPress-powered sites) meet basic accessibility guidelines,” Rand-Hendriksen said. As WordPress powers an ever-increasing segment of the web, the platform and its themes play a big role in the accessibility of the web as a whole.
“[pullquote]Accessibility can no longer be treated as a bonus feature[/pullquote],” Rand-Hendriksen told the Tavern. “In many countries it is now a legislated requirement and that trend will likely go global in a few years.”
When examining the official WordPress Themes Directory, you’ll be hard-pressed to find much of a selection when it comes to accessibility-ready themes. In fact, there’s only one page of them. Rand-Hendriksen calculates that accessibility-ready themes account for “a dismal 0.5%,” and said that the directory is severely lagging in regard to presenting options.
One major reason for this is that theme developers mistakenly believe that meeting accessibility guidelines is only for the experts. “In building Simone I wanted to prove that building an accessibility-ready theme is not hard and does not require a lot of extra work,” Rand-Hendriksen said. He believes that if you can follow web standards, then you can build accessible WordPress themes.
For the most part, the challenges involved in web accessibility are imaginary and based on the myth that accessibility is hard and expensive. Here’s the thing: It’s neither. Web accessibility mainly has to do with following web standards and coding for content first. This does require a bit of a reframing of the development process which historically is mainly focused on getting code to match intricate designs, but that is not a hindrance.
Rand-Hendriksen chose Underscores as a base for Simone because it meets nearly all of the requirements for using the accessibility-ready tag on a WordPress theme. He subsequently submitted two patches to _s that got baked in to get it even closer to the specifications. From there the only thing remaining was to make the drop-down menu keyboard accessible and continue following web and WCAG standards as he built the theme.
Resources for Building Accessibility as a Baseline Requirement
Rand-Hendriksen’s advice for theme developers looking to build accessibility-ready themes: Change your mindset so that accessibility considerations are no longer an afterthought.
The key is to build accessibility in as a baseline requirement, not a feature added on after the fact. When you start building accessibility in as a baseline you discover your code gets more structured, easier to understand, and as a developer you start caring more about the content itself, not just how to bend to the will of the design.
Once you’ve made up your mind to develop accessible themes, there are many excellent resources available to help you. “The Accessibility Project recently published a set of living patterns that can be baked into any project,” Rand-Hendriksen advised. His next step on the Simone theme is to swap out the currently accessible (albeit a bit clunky) Superfish menu for the one proposed in the pattern library.
Rand-Hendriksen cites the WordPress Theme Accessibility Guidelines as a helpful resource for keeping your theme on the right track. The instructions there are straight-forward and easy to follow and understand. “Most of them are just web standards that should be followed anyway,” he said.
He outlined the process for submitting an accessibility-ready theme to WordPress.org:
Once a theme is submitted to the Directory with the accessibility-tag applied it will be manually tested by the WP Accessibility Team (currently Joe Dolson is the sole person responsible for doing this). They (or rather he) will go through the theme with a fine-toothed comb, test everything, and come back with very detailed instructions on what, if anything, needs to be changed.
Rand-Hendriksen believes that the process doesn’t have to be complicated. His advice? Start with _s, add in a solution for a keyboard accessible menu, and follow web standards. You’ll be well on your way to being able to use that accessibility-ready tag.
“In addition, I run my themes through a set of manual tests that include disabling my mouse and working with the theme for several hours, using ChromeVox to experience the theme through a screen reader, and using voice commands and screen readers on mobile devices to make sure everything works as expected.”
For ensuring that contrasts are high enough, Rand-Hendriksen recommends the Contrast Ratio tool built by Lea Verou.
7 Practical Tips for Developing Accessible WordPress Themes
Most WordPress theme developers don’t consider themselves to be accessibility experts. In reality, you already have all of the knowledge and tools you need to start getting your themes up to standards. Someday, meeting accessibility requirements may be mandated by law, so if you want to be ahead of the game you should start now.
How can you make accessibility part of your standard baseline for all projects? In summary, a few of the practical takeaways from our interview with Morten Rand-Hendriksen include:
- Get a new mindset: Build accessibility in as a baseline requirement, not a feature added on after the fact.
- If you don’t know where to start, try Underscores as a base theme for meeting most of the requirements
- Check out the Accessibility Project’s widget and pattern library
- Familiarize yourself with WordPress’ guidelines for the accessibility-ready tag
- Try disabling your mouse and working with your theme with ChromeVox
- Use voice commands and screen readers on mobile devices to make sure everything works
- Make sure contrast ratios are high enough using this handy tool built by Lea Verou
Why is Accessibility Such a Big Deal?
Rand-Hendriksen believes that accessibility is a rights issue:
As I mentioned earlier accessibility is now becoming a legislated requirement in many countries. This is because accessibility is a rights issue. To put it bluntly, if you are building a website that is not accessible you are discriminating against anyone with accessibility challenges. Those are not my words by the way: That’s the reasoning used by several governments including the government of Norway for passing accessibility laws.
The situation may soon become critical as accessibility mandates are adopted by more countries. “WordPress is facing a huge challenge here because once these laws kick in (in many places later this year) website owners running WordPress will for the most part be in breach of the laws thanks to the almost universal lack of accessibility support in WordPress themes,” Rand-Hendriksen said.
His warning applies to both self-hosted WordPress sites and WordPress.com sites: “If we as a community don’t embrace accessibility now we will quickly paint ourselves into a corner it’ll be hard to escape from.”
Um, no.
Yes, there’s an “accessibility-ready” tag. But behind it are a set of draft guidelines that only one or two people know how to use to review Themes, and that are still being worked out, because there are no established, best-practice ways to implement them.
We’ve gotten a ton of pushback on implementation of the existing Theme Review guidelines, from the initial Guidelines to the revisions/improvements made over the past four years. But we have operated under a very effective approach: first establish best practices, then focus on education (teach developers how to implement those best practices), then make the best practice Recommended, and then, once the practice is in common enough use that we think it feasible for everyone to follow/implement, make it Required.
Rand implies that implementing the accessibility-ready Guidelines is all but a trivial matter for Theme developers. I beg to differ. And the crushing workload of forcing what is currently a one-man accessibility review team to review every single Theme submitted to WPORG would grind the Theme Review and Approval process to a halt.
Do we need to get there? Yes. And eventually there should be a set of accessibility-related Guidelines that are Required – either a revision to or a subset of the current draft Guidelines. But it’s going to take time.
Given the reaction from Theme developers that I got to the suggestion that we make implementation of Theme Options into the Theme Customizer Recommended (not even Required; just Recommended), I can only imagine how Rand’s suggestion would go over.