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.
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.
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.
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.
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.
If someone has ideas on a better method, I’d be happy to hear them.
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.
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!
6 thoughts on “Accessible WordPress Theme: Creating a Fully Accessible TwentyTwelve Child Theme”
Wow! I cant thank you enough. You just saved me a boat load of time. That is fantastic as a jumping off point to do something accessible. Now I am off to hammer on some plugins I need to fix for a project. They don’t look too bad though.
I had been checking over some of the so called accessible wp themes. There were not so hot.
Glad you’re finding use for it!
Thanks for mentioning Accessible Zen, Cynthia! Much appreciated!
It does support two menus, each in the footer area. The fact that they aren’t in the header is part of what makes it a bit different. It’s content first. :) If people need a menu in the header, I have a child theme in this Github repo for it: https://github.com/davidakennedy/accessible-zen-theme-pack
Also, worth noting: the list of accessibility-ready themes is growing: https://wordpress.org/themes/tags/accessibility-ready
The WordPress Accessibility team is working with the rest of the WordPress community to help make that happen.
Your Twenty Twelve child theme looks great. Thanks for creating it!
Thanks for the comment! I’ve updated the post itself with those links, and will check them out.
I’m actually hoping that my child theme becomes obsolete as time goes on, at least accessibility wise! I know that some of the issues I posted about have already been fixed, so I know how hard the team works.
Thanks for updating the post!
Either way, it’s a win, win. The more accessible ready themes, the better. :)