Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
  1. Code
  2. WordPress

Accessibility, Part 6: Going Beyond Code Best Practices

This post is part of a series called Accessibility.
Accessibility, Part 5: Understandable

In this series we've looked at some simple ways theme developers can help make their theme accessible. If you follow all the recommendations in this series, you will more than exceed the minimum requirements for the accessibility-ready tag in the WordPress theme repository.

However, the tag is accessibility-ready rather than accessible, as no theme can ensure a website is accessible—too much relies on how the theme is used, and the nature of the content added to the site. 

In this final tutorial we look at some simple techniques that we as theme developers could employ, to help the end users of our product use it in an accessible-friendly manner. There is also a lot scope for plugin developers to do likewise (an obvious example being a plugin which allows an audio file to be uploaded and attached to a custom post type could also allow a transcript to be uploaded and linked to that file).

Encouraging a Valid Header Structure

Earlier in this series we discussed ensuring the theme has a reasonable header structure, namely appropriate headings for the site title and post title(s). As mentioned, this structure should meaningfully reflect the page structure, and the <h1> tags should be nested in <h2> tags, <h2> tags in <h3> and so on. 

But, on any given page, if we have used the <h1> (and maybe <h2>) tag outside the page or post's content, it would be a good idea to discourage their use inside the content, so as to prevent breaking that page structure. TinyMCE has a 'blockformat' dropdown which allows users to quickly add paragraphs and headings and so forth. We can remove the header tags which we don't want used in the post content:

Of course, this isn't foolproof, and will be ineffective against users who don't use the TinyMCE editor. Additionally, it does not (and we cannot) ensure that the headers used in the content meaningfully reflect the structure of that content. It does, however, discourage the misuse of the reserved <h1> (and <h2>) tags.

Encouraging Good Colour Contrast

A slightly more involved idea, if allowing users to select their own colours in the theme, is to alert them when they are selecting colours with a low contrast rating (e.g. background and text colours). Exactly which colours you should be comparing will depend on the choices you've made available to the user. Below I've simplified this idea by assuming a fixed font-colour of #444444, and comparing this with the user-provided background colour.

I'll leave the details of how to set up fields in the customiser, and to enable live previews to the codex. Here I just provide an example JavaScript file which alerts the user when their chosen background colour is too low.

First create a file called customizer-a11y.js in your theme, with the following code:

Next we need to create a function which, given any two colours (in hex) format, returns the contrast ratio between them. Details of calculating this ratio can be found on the W3C website, but it is done by first calculating the "relative luminance" (roughly speaking a measure of "brightness". The contrast ratio is then the ratio of those "relative luminance" values, with an added 'penalty' for bright colours.

The following should live at the bottom of the JavaScript file just created.

Lastly we load the JavaScript and print the mark-up for the contrast warning notice.


We have covered only a couple of suggestions in detail here, but the list could go on. There is also a lot of scope for plugin developers to do likewise:

  • Form plugins could discourage the use of empty labels.
  • Slider plugins could discourage the use of the auto-play option.
  • Whenever an audio/video file is to be uploaded and attached to a custom post type, a plugin could prompt for a transcript to also be uploaded and linked to that file.

"Discourage" here doesn't mean removing the option entirely. However, alerting the user of the ramifications to the accessibility of the website can go a long way to educating the user, and ultimately improving web accessibility.


We finish this series with an overview of useful resources and tools to help you learn more about web content accessibility, and more importantly to help you ensure that your next plugin or theme is available to all users.


WordCamp Talks

(Other talks can be found at http://wordpress.tv/tag/accessibility/)

Tools / Plugins

Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.