Accessible WordPress Theme: Creating a Fully Accessible TwentyTwelve Child Theme

To make up for the lack of post last week (apologies, things have just been too busy), a special post this week. Before working on the new website, I once again did some searching for an accessible WordPress theme. Unfortunately, I found little that would meet my needs as I required WCAG (Web Content Accessibility Guidelines) level AA at the minimum, but preferably something that would be as accessible as possible.

If you’re not sure what WCAG is or why it’s relevant, consider doing a quick read through of my post on understanding WCAG.

Existing Accessible WordPress Themes

I did find some themes that are supposed to be accessible, and there is a list of Accessible WordPress themes on the WordPress site.

• Web Experience Toolkit WordPress Variant – WP variant of the toolkit used by the Canadian government, meaning it meets WCAG. Unfortunately, I found out about this after I started.
• Default themes: TwentyThirteen and TwentyFourteen – Not sure if it meets WCAG, but both were looked over fairly carefully by the WP accessibility team, and consider that I didn’t have to do a lot to TwentyTwelve.
• Accessible Zen – Meets WCAG AA (according to developer). Downsides: no sidebar, two menus but in footer area. This was done purposely (as per the comment below). There is a sidebar version of Accessible Zen on github.
• Blaskan – Close to meeting WCAG (according to developer), but not keyboard accessible.

The two main reasons I decided to go with a custom child theme are that 1) I could be sure the theme would as accessible as I could make it and 2) that I could easily work with the existing theme’s design.

That’s why I ended up with TwentyTwelve, which already has a lot of accessibility features built-in. I’m sure that the newer WordPress themes are more accessible by default, but TwentyThirteen is very much designed for a blog and TwentyFourteen is designed for an image heavy site such as a portfolio.

Many of the other themes I didn’t find out about until later or didn’t meet the basic design layouts I wanted, such as having a sidebar. Not having fully tested some of the themes, I’m also not sure how well they integrate with WordPress itself.

I also warn you that when I was doing some searching, I found some people (developer or referrer) claimed that a theme is accessible, but isn’t.

Accessibility of TwentyTwelve

I won’t go over all the features of TwentyTwelve, but the theme is close to meeting WCAG AA on its own. I actually only had to make a few changes, and in particular, these features really helped:

• responsive, mobile first design
• good content/code order
• skip links (and the code to make these visible when using a keyboard to navigate)

Nevertheless, remember that accessibility of websites very much depend on the content and not the theme or framework that is used.

Why a Child Theme?

While I would love to see the TwentyTwelve theme itself become more accessible, I had to get this theme made fairly quickly. It meant a lot of CSS overwrites, but I still made changes to only a few files. For purely accessibility purposes, the child theme only involves 3 files.

I also made a few layout changes that is not consistent with the original theme (which I will talk about in a later post).

Making TwentyTwelve Accessible

As I said, I did very little, but some key pieces needed to be changed.

Colour Contrast

One of the obvious issues was the colour contrast on the visited links in the entry content and the widgets.

The light grey on a white background was rather far from meeting the colour contrast guideline, so I played around with the numbers until I found something that met at least the AA guideline.

Having checked all the other colours in the checker, I only found one other colour I had to change, namely the input button colour.

When changing the colours, I tried to keep it consistent with the original look. I essentially kept the same ratio of red, green, blue, simply making it darker or lighter as necessary.

Skip Links

While the original theme comes with a ‘Skip to Content’ link just before the menu, WCAG tells us we should have skip links for any repeated block, which I think also includes the header area.

Many readers will read the title of the page, which already has the name of the site, so having a reader repeat the site title and tagline on every page can be rather repetitive.

Therefore, I added a ‘Skip to menu’ link at the very top of the page. From the menu, the ‘Skip to content’ link is still available.

Easy Reading

I disabled auto hyphenation. I understand that it makes the layout look nicer, but the text itself is harder to read. So a general usability fix, though depending on interpretation might also fall under WCAG.

Keyboard Accessibility

One of the biggest issues in navigating a website with a keyboard is the visibility of what the user is focused on. Frequently, there are hidden links or links that cannot be accessed using only a keyboard (usually because display:none has been set). There are also plenty of interactive elements that need some sign that the user is focused on them.

Visible Focus of Inputs & Buttons

While it’s not the only method, the most common is to have an outline or glow around the element to show the user that element has focus. Some browsers actually have visible focus of input and buttons built-in, such as Safari. However, because not all browsers have it, visible focus needs to be added using code.

Visible & Accessible Menu Links

In this case, the ‘menu’ button when the menu is collapsed, is not something you can tab to. Without the ability to tab to the button, you cannot access the navigation menu. [Update: this has been fixed as of version 1.4]

I decided to make the hidden links available to a reader and to keyboard navigation. To do this, I used the same method as for the skip links. Basically, you use clip (instead of display none) and then when it receives focus, you display the link in the top left corner.

Side note: Using the CSS clip property is not the only method of making links available but visibly hidden, however, I made use of the existing code and decided to keep it consistent with the parent theme.

The problem when you start playing around with the links in the menu is having to deal with all those other cases: when the menu is displayed, and when the menu is not collapsed.

This was the hardest problem to solve, because it required doing a lot of CSS rewrites. I didn’t want to rely on JavaScript, because I didn’t want the child theme to rely on loading JavaScript of any sort, plus this is a problem solvable by CSS if in a rather convoluted manner.

If someone has ideas on a better method, I’d be happy to hear them.

Other Changes

I made some other changes namely for aesthetic reasons and layout purposes. Having written this post, I will definitely be considering separating the changes I made for accessibility reasons and for other reasons. Nevertheless, except for moving the header image, I made many of the other changes for increased readability and usability, so maybe not.

The Outcome

As I mentioned, purely from an accessibility perspective, this child theme only needs 3 of the files I created, but add usability then I could argue at least a few more, if not all of them.

In any case, this is how it looks now:

TL;DR: Grab it on Github (complete with readme) and report any issues, provide feedback, or discuss with me!