Drawing of a red/green colour blind test with a logo in the middle

The accessibility-ready Tag Should Be Required for All WordPress Themes

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.

 


About Morten Rand-Hendriksen

Morten Rand-Hendriksen is a staff author at lynda.com specializing in WordPress and web design and development and an instructor at Emily Carr University of Art and Design. He is a popular speaker and educator on all things design, web standards and open source. As the owner and Web Head at Pink & Yellow Media, a boutique style digital media company in Burnaby, BC, Canada, he has created WordPress-based web solutions for multi-national companies, political parties, banks, and small businesses and bloggers alike. He also contributes to the local WordPress community by organizing Meetups and WordCamps.

12 comments:

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

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

  2. 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!

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

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

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

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

  3. 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).

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

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

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>