Why Accessibility Matters for Theme Developers
About 16% of the world's population lives with some form of disability. That's over a billion people who might struggle to use your website if it wasn't built with accessibility in mind. Beyond the moral argument, accessible websites tend to rank better in search engines and reach larger audiences.
WordPress itself has committed to accessibility. The WordPress Accessibility Team sets standards that core themes must follow. Third-party themes should aim for the same bar.
The WCAG Foundation
The Web Content Accessibility Guidelines (WCAG) 2.1 provide the framework. For most WordPress themes, targeting Level AA compliance covers the essential requirements. Here's what that means in practice:
- Perceivable — Content can be consumed through different senses (text alternatives for images, captions for video)
- Operable — Interface can be navigated via keyboard alone, without time pressure
- Understandable — Content and navigation are predictable and clear
- Solid: Works across assistive technologies and browsers
Color and Contrast
Color contrast is where many themes fail first. WCAG AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. Use tools like WebAIM's Contrast Checker to verify your color combinations.
Common mistakes to avoid:
- Light gray text on white backgrounds
- Conveying meaning through color alone (add icons or text labels)
- Placeholder text as the only label for form inputs
- Links that aren't visually distinguishable from surrounding text
Keyboard Navigation
Every interactive element must be reachable and operable using only a keyboard. Test your theme by unplugging your mouse and navigating with Tab, Shift+Tab, Enter, and Escape.
Focus indicators are critical. That default blue outline browsers add when you tab to an element? Don't remove it with outline: none unless you replace it with an equally visible custom focus style. Users who navigate by keyboard rely on visible focus to know where they are on the page.
Semantic HTML Structure
Screen readers parse your HTML to build a mental model of the page. Using semantic elements correctly makes a massive difference:
- Use
<nav>for navigation,<main>for primary content,<aside>for sidebars - Heading hierarchy should be logical (h1 → h2 → h3, don't skip levels)
- Lists should use
<ul>/<ol>, not styled divs - Buttons should be
<button>, not clickable divs or spans
Images and Media
Every meaningful image needs descriptive alt text. Decorative images should have empty alt attributes (alt="") so screen readers skip them. WordPress makes this straightforward through the media library's alt text field.
For video content, provide captions or transcripts. WordPress supports subtitle tracks through its default video player, and plugins like accessibility-focused plugins from the WordPress Plugin Directory can help automate caption generation.
Forms and Error Handling
Accessible forms need proper labels associated with inputs using the for attribute. Group related fields with <fieldset> and <legend>. Error messages should be clear, specific ("Email address is required" beats "Error"), and announced to screen readers using ARIA live regions.
Testing Your Theme
Automated tools catch about 30% of accessibility issues. Manual testing catches the rest. A solid testing workflow:
- Run WAVE or axe DevTools for automated checks
- Navigate the entire site using only your keyboard
- Test with a screen reader (VoiceOver on Mac, NVDA on Windows)
- Zoom to 200% and verify nothing breaks
- Test with browser extensions that simulate color blindness
Accessibility isn't a feature you add at the end. It's a practice you build into your development process from the start. The good news: most accessibility improvements also improve the experience for all users.