Tricky issues: Accessible WordPress Themes

One of the volunteer activities I do is to manage accessibility reviews for the WordPress accessibility-ready theme project. I do the majority of the accessibility audits, and try and help other accessibility reviewers and theme authors figure out what is needed for their themes. The guidelines and how to test for them is documented pretty extensively in the Accessibility guidelines for Themes.

There are some quirks to auditing themes for accessibility since Themes are not Websites. As a corollary to that, there are some quirks to building themes for accessibility.

These quirks have a lot to do with the absence of content: you can build your theme with sample content that optimizes the design – but, by doing that, you're really building a demo web site. That content is still not really part of the theme.

The requirements for accessible themes are carefully written to be clear cut – most of the time, you'll know whether you've succeeded or failed to meet them. But there are a number of decisions you can make as a theme author that send you into ambiguous areas that can be tricky.

With a few years of reviewing themes behind me, here are a few issues that I've encountered numerous times that may be useful to you!

Using background images

Many themes create large headers with background images and use semi-transparent backgrounds so that those images will be visible. This is one of those cases where you can create a demo site which easily meets the guidelines, because you've carefully selected content that falls in gaps in your images. Then, I'll install the theme using the WordPress theme unit test data, and it'll be a mess. Finally, in a real usage scenario, a user changes the image to something with a completely different pattern of light and dark backgrounds that makes your carefully worked out contrasts completely inaccessible.

For me, seeing a theme with extensive background images and semi-transparent colors is maddening. Yes, it is absolutely possible for a web site to use that technique and be fully accessible – but it requires a lot of care and carefully consideration of content.

As a theme author, you should be thinking about how you can protect the accessibility of the site from poor image choices. Darker semi-transparent backgrounds for content will help. Text shadows can help, but only if the background stays in the same shade range. You should absolutely try testing your theme with alternate images – for example, picking one of your favorite snapshots with absolutely no consideration for whether or not you think it will work on the site. This is how users of your theme might think, and you should be prepared for it.

Subtle focus states

The letter of the rule is that focus states must be visible. There must be a visible change between the normal view of a focusable element and how it looks when it receives keyboard focus. The rules don't attempt to quantify that difference. However, keep in mind that contrast rules also apply to the difference between states.

When assessing color contrast, we need to test the difference between a link and its neighboring text, a link and its background color, and between a link and its focused state. If there are differences between the link and its neighboring text or between the link and its focused state, we don't need to check those specific contrast differences. But… contrast is still relevant. I've seen changes that added an underline on focus, but the underline was so subtle that it would be almost impossible to see.

Having a sharply differentiated focus state is enormously important. Think about the difference between how a mouse works and how keyboard navigation works: when navigating using a mouse, you are specifically directing the mouse pointer to a point on the screen. You know where the cursor is and how it relates to the item you are pointing at. The mouse pointer itself should change shape to indicate whether there are actions you can take. This is a lot of specific directed information.

When navigating visually via the keyboard, however, you don't get this feedback. First, while you can guess where the next focusable element will be, you do not know this. Keyboard navigation is not directed – you will need to find your new location after you change it, rather than choosing your location and then moving there. Second, there is no cursor to give you actionable feedback. As a result, you need effective, clear feedback to be able to identify your visual location on the screen.

Navigation should go forward and back

It's one thing to make a menu usable via tab, another to make it predictable. If pressing tab moves you forward one tab stop, then pressing shift+tab should move you backwards to the item you were previously on. Normally, this is exactly what will happen – but if you start doing strange things with dropdown menus and toggled menus, this pattern can break down. It doesn't make the interface unusable, but it does make it more difficult. Should I fail a theme because it's inconvenient? No. But I will certainly push back!

Wow, there are a lot of ARIA landmarks

All content on a given screen should be wrapped in an ARIA landmark. But I've seen many themes where this goes a bit too far. Some of the default themes used a pattern where widgets were wrapped in the aside element. This element is mapped automatically to a 'complementary' landmark region. This means that in a site with multiple sidebars and multiple widgets in each sidebar that you can quickly end up with over a dozen complementary regions, in addition to multiple navigation landmarks.

It is absolutely allowable to have multiple landmarks for both navigation and complementary regions – but to what degree is it reasonable? In order for landmark regions to be useful, a user needs to be able to have an idea which region to move to to get the information they want. A dozen complementary regions does not help with that.

Color contrast for text that isn't there

Yes, you need to consider the color contrast for text you aren't using. If you have a footer region that only contains links, and haven't considered what color plain text in that region should be, I *will* flag that if it violates color contrast. You haven't placed text in that region, but that doesn't mean that your users won't!

Source: Tricky issues: Accessible WordPress Themes