When was the last time you tried navigating your WordPress site using only the keyboard? Chances are you never have, and if you do you are likely to have a sub-optimal experience at best. The alarming reality is only a handful of WordPress themes (and thus WordPress-powered sites) meet basic accessibility guidelines. This is not OK. I’m issuing a challenge to the WordPress community:
Accessibility should be a requirement for all WordPress themes.
WordPress accessibility should not be an option
WordPress currently powers more than 22% of the web and that number is growing by the day. With great power comes great responsibility. That responsibility includes providing solutions that anyone and everyone can use as well as being a thought-leader and trend setter for the larger web community.
Presently, thanks to the great work of the WordPress Accessibility Team, a theme developer can choose to add the accessibility-ready tag to her theme when it is submitted to the WordPress Theme Directory. If she chooses to do so the theme will undergo an accessibility test and any accessibility concerns will be addressed before the theme goes live.
My proposal is we change the accessibility-ready tag from an option to a requirement.
Here’s the thing: Accessibility is not an option. An inaccessible website is a site that discriminates against groups of people based on disabilities and other concerns. And the platform that powers 22% of the web cannot move forward while treating a right that many countries now mandates by law as an optional feature. It is both morally and legally wrong and sets an unacceptable precedence.
Presently the onus is on the site owner to ensure her site is accessible. This is unreasonable considering its importance and the nature of WordPress (and in particular WordPress.com) as an application with a low-to-no web skills entry point. A person who uses WordPress to host a website should not be required to know what accessibility is and why it matters any more than she should be required to know what browser prefixes or HTML5 shims are. In fact accessibility is not something the WordPress site owner should have to to think about or even be aware of. It should just be there by default in the same way that support for Closed Captioning is a standard feature on North American TV sets.
The Inaccessible Status Quo
If you visit the WordPress Theme Directory today you’ll find 2,513 themes. Of these only 13 are tagged accessibility-ready. That’s 0.5%. On WordPress.com the total number of accessibility ready themes is 3 out of 266 (1.1%). Granted the accessibility-ready tag was only introduced recently and there is a good chance there are older themes that meet these requirements, but the fact remains where accessibility is concerned WordPress themes are failing dismally.
What does this mean? If you are a web user who relies on keyboard navigation, voice commands, high-contrast displays, or a text-to-speech browser and you visit a WordPress-powered site you are likely going to have a bad user experience. Same goes for anyone with other accessibility concerns including color blindness, poor motor control, arthritis, the list goes on. Presently there is only a marginal chance the site you visit will be accessible, and that is most likely because the site owner has made a conscious and deliberate decision to make it that way because of her awareness of accessibility as an important issue.
The current situation also has serious legal ramifications. Web accessibility has been elevated to a rights and discrimination issue by municipalities and countries all over the world and legislation is forthcoming in many more places. These laws and regulations mandate accessibility and impose severe penalties on sites that do not meet accessibility guidelines. Because WordPress powers a significant portion of the web that means many WordPress site owners will be facing financial penalties and legal issues in the near future due to lack of accessibility support in their themes. And for most of these site owners this will come as a surprise because they were never made aware that WordPress themes by default are not accessible.
Accessibility is not an option: It’s a requirement
Why are there so few WordPress themes that meet basic accessibility standards? For the same reason that most websites don’t meet accessibility standards: Developers have long considered accessibility an add-on option, and an unimportant one at that. Nothing could be further from the truth:
Accessibility is a rights issue. An inaccessible website is a site that discriminates against groups of people based on disabilities and other accessibility concerns.
Shipping an inaccessible website is like saying “Here is some interesting content. If you can’t access it because of your disability too bad for you. I don’t care.” Imagine if a restaurant did that to a wheel chair user. Or a municipality refused to add audio signals to a pedestrian crossing because they considered it an inconvenient or expensive option. Web content is no different.
Accessibility on the web is neither costly nor time-consuming or complicated
Whenever the issue of web accessibility is brought up there is an immediate reaction from some web developers that accessibility is costly and/or time-consuming or complicated to implement. This is a myth. Yes, accessibility is costly if it is applied after the project is otherwise complete. But so is web standards, responsive web design, and anything else. Yes, accessibility is time consuming and complicated if you have never done it before. That’s not a reason to ignore it: It’s a reason to learn it.
Accessibility should be one of the first steps of your development process for any web project including the development of WordPress themes. That way it’s not costly, time consuming, or complicated: It is just standards-based web development.
And if you read the WordPress Accessibility Guidelines you’ll realize meeting them and getting the accessibility-ready tag approved is not hard. To get you started here are some tips:
- Use _s (Underscores) as your base for new WordPress themes and you’re 90% there. All you have to do is add a script like Superfish to make the main menu keyboard navigable and make some other subtle tweaks.
- Familiarize yourself with the Web Content Accessibility Guidelines.
- Think of accessibility not just as an enhancement feature for disabled visitors but also a standard feature that allows search engines to index your content better and users to access your content using new and future non-standard devices like a voice controlled phone or car, web enabled glasses, smart watches, and so on.
- Embrace accessibility as one of the first requirements of your WordPress themes and web projects.
Accessibility is not a feature. It’s a standard. Let’s make it the WordPress theme standard.
19 replies on “The accessibility-ready Tag Should Be Required for All WordPress Themes”
Hi, thank you for this article. I am with you on this necessity. However, we have to be true to our readers. It’s not fair to say that “Accessibility on the web is neither costly nor time-consuming or complicated”. Accessibility is still a challenge and it adds costs to the project and the maintenance (as RWD does too). It’s a fact. I’ve lived it many times in my projects. Nonetheless it doesn’t mean that we don’t have to integrate it in all themes. It also true that often costs come from ignorance or because it is done after the project itself as a last minute action.
Thanks for your input Benjamin. I both agree and disagree: Yes, making a project accessible is marginally more costly than not, but only marginally. If accessibility is part of the overall development process from day one and whatever baseline you work from is accessible out of the box the added cost in time and money is negligible. The issue here is that developers don’t consider accessibility until after the rest of the project is done. At that point adding accessibility in as a feature is going to be costly.
On a higher level this entire discussion is about perspective. Like I say in the article accessibility isn’t a feature: It’s a requirement. And that means the cost of accessibility is just the cost of doing business much like the cost of writing proper HTML that renders correctly is part of doing business. Accessibility shouldn’t be part of the client pitch nor even a line item in the breakdown of project costs. It should be there by default. If a developer feels it’ll add 10 hours to the project then that extra 10 hours should be bundled in with the overall work. If accessibility is broken out into a separate costed line item the client will start considering it an optional feature which it is not.
Completely agree. I have worked for companies as a software tester where clients were given two options: QA from North America or QA from a less expensive country.
Clients always chose the cheaper option, but that isn’t even the point… QA should be part of the service. No one expects to get software that hasn’t been thoroughly tested, yet it was always presented as an option.
The crazy thing is, it always became painfully obvious that QA was essential and the company inevitably ended up paying for it, thereby losing money time and again.
Thanks for this great article! I agree that the accessibility-ready process should be required for all themes – and we discussed the possibility worth the theme review team, in fact. At this point, we decided against it largely on the grounds of training and education – but it’s definitely on the radar as a potential future requirement.
And if anybody reading this is interested in such training, and is in the Chicago area, I’ll be giving a talk about this at WordCamp Chicago in June!
Thanks for piping in Joe. You and the rest of the team do important work. While I understand the reasoning of not making the tag mandatory I disagree with the conclusion. If we wait for people to educate themselves we’re going to wait forever. Accessibility is not something developers care about because it’s not visible to them.
It’s a chicken and egg problem: Do you require accessibility to get people to learn it or do you ask people to learn it to eventually require accessibility. Considering governments are taking the 1st approach and there are legal issues at play in addition to the moral ones I think the only right thing to do is requiring it now. There are no valid arguments from a developer standpoint to not apply accessibility standards so any pushback would be squarely based on a reluctance to learn something new. Call me extreme but I think our community needs extreme measures here.
There is a secondary issue, as well – the review of accessibility-ready themes. It’s not just the requirement that themes meet these standards, but that the theme reviewers be able to review for them. At the moment, I personally review every theme that goes through the accessibility-ready review process. I’m working on expanding that, but it’s slow going.
That is crazy! If I can pitch in to help I will. I also saw you are working on automatic accessibility testing which would be a huge help. And again I think this is a chicken and egg problem. The reason the other theme reviewers don’t learn accessibility is because they don’t have to. It seems the theme review system has several bottlenecks already and this might initially cause another one but it is an issue that is bigger than WordPress which you already know.
It would be crazier if there was a high volume of accessibility-ready themes coming through, but it is definitely challenging.
You can absolutely help; you don’t need to be part of the theme review team to do the accessibility-ready review, since it’s currently a separate, optional review. It’s not a complex process most of the time, since themes in the WordPress repository are generally pretty traditional in format, and aren’t doing a lot of crazy stuff.
The theme review process does have a lot of bottlenecks — undoubtedly because we (the accessibility team) aren’t the only people to feel that we can’t just let people self-identify their themes as meeting our standards!
The automated accessibility testing currently on the table is being targeted as a pre-commit check for core development, but I’ve got plans for developing an automated testing tool for themes, as well, personally. I’m hoping to get that done this summer.
Automated testing just doesn’t get us far enough, though; there are just too many things that can’t be tested for with automation.
I’m so grateful to you for writing this! It seems very in line with the vision of Tim Berners-Lee that undergirds the Web — something that most developers (not just WordPress developers) are sadly unfamiliar with.
One thing that makes me particularly sad is how little attention Lynda.com pays to accessibility. Yours is one of only two courses — and first one is now terribly out-of-date (2007).
Thanks for your support Anna. As for our current coverage on accessibility it is something I have on my radar. Stay tuned.
Speaking to the education issue, I think part of the problem is that when developers learn new markup languages or programming languages, accessibility as it applies to those languages is almost never covered. Accessibility is a separate course or a separate book. So I think this contributes to the chicken/egg problem. As someone who uses a screen reader, and further is part of the WPAccessibility team, I’d be the last one to say accessibility is not a requirement. And I’m looking for ways to help educate developers, because most of the ones I’ve come across don’t take issue with accessibility as a requirement.
I couldn’t agree more Amanda. Accessibility needs to be part of the overall education of web designers and developers. It is something I am now working to incorporate in my training materials as a baseline requirement.
Awesome. Brick by brick, as they say.
I have just come across your Simone theme and I instantly took a like to it. I am looking for a theme for a site that will be a resource for people affected by Parkinsons Disease. So accessibility is even more important. I would like to understand better how Simone encapsulates accessibility as regards use of the mouse.
Specifically, I have already tried to make categories and menus easy to navigate using access keys – using the plug-in ‘Access Keys for WordPress Menus‘ by Aaron Harun. But do I need to use this plug-in or does Simone provide an equivalent?
Access keys are useful but do not make every link accessible as they only work on menus.
Off-topic question about Simone (if I may, while I mention have your attention) – I am embedding articles from facebook into posts, but only the most recent article displays in full – older ones just show a link. Is that a feature I can disable?
I would also like to point out that the link you included above: https://make.wordpress.org/themes/guidelines/guidelines-accessibility/
is a 404
I really enjoyed your presentation, and bringing up accessibility again at the State of the Word Q&A.
Just trying to navigate form fields properly with tab on WP sites can be hellish.. so certainly something as simple as that is being overlooked of course more detailed accessibility issues are swept under the rug.
But I do believe making it part of the regular conversation is a great place to start and to help pull people into learning about what it means to make a website, theme or plugin accessibility-ready. From there I think it will push off into a standard protocol but only once people are educated enough to begin implementing it – or comfortable experimenting with the standards.
Superfish is not necessarily accessible. I have seen this plugin used many times and on most sites it does not provide a great experience for keyboard-only users, many of whom are physically unable to use a mouse. I can often activate the drop-downs via keyboard but often I need to tab through every item (and sub-item) on the menu in order to get out of it. I was on a site recently where it was necessary to tab over 200 times to get out of the menu. I would definitely recommend testing it, using only a keyboard to navigate, to make sure it works before relying on this for your site’s navigation.
Ohh! Thanks for this awesome article. I didn’t knew about this. But after reading it I completely clear that how much the web accessibility is important & what actually it is. Great!
Isn’t it a requirement now?
Check out the WordPress Theme Review Team site at the accessibility section: https://make.wordpress.org/themes/handbook/review/accessibility/required/
It would be nice if when a theme is tested and fails then the tag would be changed to “not-accessibility-ready”. It would also be nice if a theme author knows his theme isn’t accessible he would voluntary tag it that way. That way if we find a theme without a tag we’d know if it would be worth our testing.