WordPress Themes Suck at Accessibility: It’s Time to Fix It

simoneEarlier 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?

photo credit: allaboutgeorge - cc
photo credit: allaboutgeorgecc
If the dire lack of accessible WordPress themes on WordPress.org is any indication, then 99%+ of WordPress theme developers have no concern for accessibility. The rationale behind not caring is usually something like this: The vast majority of the people who access my website will not be disabled at all, so why should I care?

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.”


28 responses to “WordPress Themes Suck at Accessibility: It’s Time to Fix It”

  1. Rand-Hendriksen believes that the accessibility-ready tag should be required for all WordPress themes.

    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.

    • I agree, his suggestion is quite radical. However, if we don’t start moving aggressively in that direction now, I wonder if we’ll be way behind when mandates are adopted in more countries. What steps are currently being worked on to advance theme developer education in general? Just curious, as I’m not very much in-the-know about everything behind the scenes.

      • I agree with movement now (and we’re doing that); but why does that movement have to be aggressive? What would it help? Right now, I could not teach someone how to implement the accessibility guidelines, nor could I teach a reviewer how to review against them. I really don’t see how universally frustrating developers and reviewers is going to help the cause.

        Joe’s doing a great job of getting the Guidelines implemented, but we’re still very much in the alpha stage. And as far as Theme-Trac is concerned, the workflow is entirely manual. Trying to make it required right now would be like taking a bleeding-edge core Plugin, and forcing it onto everyone’s production servers.

        We’re trying to get there, but we have to start somewhere. Most designers – and especially, most (Theme) developers – aren’t accessibility experts. An oversight? Sure. But we can’t undo decades of accessibility education negligence overnight.

        • There is a very good reason why the movement needs to be aggressive: We (the entire web design and development community) have been resting on our laurels and ignoring a large portion of the population in the process and now governments across the globe are taking the necessary steps to force us to shape up. In Norway and several other countries laws are kicking in as of June 30th that mandate all websites except personal blogs and certain media-specific solutions to meet WCAG 2.1 standards. If new websites do not meet these standards the owners (usually businesses) will be on the hook for it. These owners will immediately turn around and blame WordPress. This will be especially nasty for WordPress.com which markets itself to small business owners.

          That’s just the tip of the iceberg. In Canada several provinces now mandate anyone working for or with a government agency to meet WCAG 2.1 in all their projects. Same goes for several US states. If we as a community don’t get on this right now we will be left behind for other solutions like Drupal who are already ahead.

          I understand the argument that we need practical standards and application and education, but if we are going to wait for developers to educate themselves on this we will have to wait a very long time. And that’s time we simply don’t have. Accessibility is not a feature. It is a requirement if you want to make the web accessible to all. And as far as I’m concerned that is the mandate of WordPress as well.

          • We’re volunteers. We have no magic wand to wave and *poof*, workable guidelines, a manageable workflow, knowledgeable/educated developers, and an army of reviewers suddenly appear.

            Your approach leads to situations like the SAFE ACT in New York, where police officers’ service pistols became illegal overnight, because idiot legislators didn’t know what they were doing, and in their rush to pass gun control legislation banned all magazines with a capacity greater than 10 rounds.

            We understand the issue, and are working to implement it. But we’re not going to make something Required overnight, when we’re not even certain on how to implement the requirement. Instead, we’re going to do it right. If you have ideas to help that process along, I’m sure Joe Dolson would love to have your input.

          • We’re actually on the same page here Chip. The work the theme reviewers are doing is great and the work the Accessibility Team is doing is also great. My approach is to make the community aware that while we are in a holding pattern the world is moving forward very quickly.

            Of course the accessibility-ready tag can’t be mandated overnight and of course the standard needs to be established and routines need to be put in place. To propose otherwise would be idiotic and I know you know that’s not what I’m saying. However, waiting for the community to educate itself on this issue is not going to get us where we need to be fast enough. What we need to do, together, all of us, is to put Accessibility front and center and make it something people not only know about but care about and make part of their process. And part of that process should be to draw a line in the sand and say “beyond this point accessibility is a requirement”. Where exactly that line should be depends on everything being in place, but if we stake it too far into the future we will be left behind by other platforms that are moving ahead full force on this issue.

    • Chip, who would you suggest I chat to to figure out what I need to change to meet accessibility guidelines. To the best of my knowledge, my theme passes all of them, but that’s just a guess on my part, so not keen on tacking on that tag until I’m sure.

    • That’s because the accessibility Guidelines are so new, and in such a draft form, that Joe is still working on how to revise them so that they can actually be followed by someone who isn’t an accessibility expert (including developers trying to implement them, and reviewers trying to review against them).

  2. What about dealing with accessibility via plugins?

    One thing many Toronto newspapers have is the – | + (font sizer buttons).

    On most browsers, you have CONTROL and + buttons to make the font bigger. you need to two hands since both keys are on opposite sides on keyboard.

    Another issue….that not everyon calls it an accesibility issue is language barrier…google translator plugin.

    A client of mine that deals people that have different accesibility issues had a town hall in the community. 7 town halls to be exact.

    Two of the biggest issues were font size and how not everybody can do CTRL + buttons.

    second one was language accessibility (their words not mine).

    So client wrote things down at town halls (which I attended all) and was decided to put a font size plugin on the sidebar and below it google translate.

    I know this doesn’t deal with ALL issues with accessibility.

    • The ability to increase and decrease font size is one of the elements required in new legislation in Norway. However the wording is a bit vague on this point so I’m not sure if it actually requires dedicated buttons or just the ability (so essentially em or rem sizing of fonts). Plugins do a good job of some of the accessibility concerns, but other items like skip to content links, accessible menus, and so on need to be built in from the ground up. And like I’ve said in the interview and elsewhere accessibility shouldn’t be an add-on feature that requires a plugin. That puts the onus on the user to choose to activate it. The onus should be on the developer to make sure the product ships to current standards which means with accessibility built in.

  3. I second pretty much everything Chip said about the theme review process.

    While I’m a firm believer in providing equal access to everyone, I would fight tooth-and-nail any law that required personal Web site owners to meet accessibility guidelines. In the U.S., I’d consider such a law overstepping the bounds of what the government is allowed to do. Of course, that wouldn’t be anything new.

    But, I want to make this clear: I agree with the movement to make accessibility a standard. I disagree with the government getting involved.

    With all that said, accessibility is one of the top things I’m looking at right now. I want my themes to be as accessible as possible to all people. I’ve already been making themes friendlier for non-English users. The next step is all about accessibility. I like what I’m seeing with the updated theme review guidelines for the accessibility-ready tag. They’re a bit clearer than they were before.

    It’s really all about education and having the proper tools. I’ve been building Web sites since 2003, and I’m still not familiar with everything I need to be doing. Anyone who says this is easy has lost touch with what it means to be a noob when it comes to accessibility.

  4. Morten describes a future goal here. Certainly, it won’t nor it shouldn’t happen overnight, but I think the pace at which we get there lies somewhere between how fast we’re going now and “radical,” “aggressively” or whatever you’d like to call it.

    This post and its comments have a lot of seeds for future growth around accessibility in WordPress:

    If you’re interested in accessibility, join the WordPress Accessibility team. You can do that here: http://make.wordpress.org/accessibility/ You don’t have to be an “expert” either. Beginners welcome!

    We know the current draft guidelines need work. Joe has been working hard on that. We’d love to get feedback from designers, themers, developers, theme reviewers (read: everyone!). Do that here: http://make.wordpress.org/accessibility/2014/06/12/theme-review-accessibility-guidelines-update/

    Do you want to see more accessible WordPress themes? Joseph Karr O’Connor, the WordPress Accessibility Team rep, leads a project called Cities, meant to increase the number of accessible WordPress themes available in the theme directory. Join a team building one, or build one yourself. More info here: http://accessiblejoe.com/cities/

    Justin: You’re a well-respected WordPress developer and it’s great to hear you’re striving to learn more about accessibility. You’ve helped me a ton over the years with your excellent blog posts! I’m glad to return the favor. I’d be happy to review any theme you want to have the accessibility-ready tag and provide feedback from an accessibility perspective. The only catch? You have to blog about it! :) I think it could help a lot of developers in the community.

    We just need to keep doing what we’re doing. Making progress. There are many things that annoy me about WordPress – not just the fact that it’s not as accessible as I’d like. I hate that we don’t have a way to do content blocks. I wish the editing experience happened more in-line. The theme on-boarding process kind of stinks. And man, I wish I could output content in some other formats beside HTML so other apps can benefit from WordPress. But you know what? All of those things are being worked on or have been worked on recently. Let’s keep moving.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: