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

There are some quirks to auditing themes for accessibility. Themes are not Websites, and that has consequences.

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

I wrote the requirements for accessible themes carefully – most of the time, you’ll know whether you’ve succeeded or failed to meet them. However, there are a number of decisions you can make as a theme author that send you into ambiguous areas of accessibility.

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

Using background images in your theme

Many themes create large headers with background images and use semi-transparent backgrounds so those images are visible. This is one of those cases where you can create a demo site that meets the guidelines, because you’ve selected content that shows in empty space from your images. But I’ll install the theme using WordPress theme unit test data, and suddenly it’s a mess. In a real scenario, a user changes to an image with a different pattern of light and dark that makes your carefully worked out contrasts inaccessible.

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

As a theme author, you should think about how to protect the accessibility of the site from poor 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 try testing your theme with alternate images – for example, picking a favorite snapshot with no consideration for whether you think it will work on the site. This is how users of your theme might act, and you should prepare 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 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 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 was almost impossible to see.

Having a sharply differentiated focus state is crucial. 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 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 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 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 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, that’s a lot of ARIA landmarks

ARIA landmark regions should wrapp all content on a given screen. 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 end up with over a dozen complementary regions and multiple navigation landmarks.

It is allowable to have multiple landmarks for both navigation and complementary regions – but to what degree is it reasonable? In order for users to use landmark regions well, a user needs to know which region contains 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 it. You haven’t placed text in that region, but that doesn’t mean that your users won’t!