WordPress Accessibility: Building Themes Everyone Can Use

Quick answer: WordPress accessibility means designing and coding themes so people can perceive, operate and understand the site, including those using keyboards, screen readers or high contrast needs. Start with semantic HTML, visible focus states, sufficient color contrast, labeled forms, text alternatives for media and skip links. Test with a keyboard and a screen reader, not only with an automated checker.

Why accessibility belongs in the theme

Themes control structure, color, typography, navigation patterns and many interactive widgets. If the theme gets those wrong, content editors cannot fully fix the problem later with careful writing. Building accessibility into the theme protects every page that uses it.

Accessibility also overlaps with quality: clearer headings, sensible tab order and readable contrast help everyone, including mobile users in bright light.

Legal requirements vary by country and sector. Even when a formal standard is not mandated for your client, inaccessible sites lose customers and create support friction. Treat WCAG 2.1 Level AA as a practical target for business sites in 2020 unless a contract specifies otherwise.

Semantic structure first

Screen readers and assistive tech rely on meaning in the markup.

• One logical h1 per page view; descending heading levels without skips when possible
• Landmarks: header, nav, main, aside, footer used for real regions
• Lists for real lists; buttons for actions; links for navigation
• Tables only for tabular data, with headers

Avoid using heading tags only for visual size. In block themes and classic PHP themes alike, train content teams to keep the outline honest. Our WordPress theme development notes pair well with an accessibility pass during build.

Gutenberg (the block editor) ships with WordPress 5.x and can produce clean structure when blocks are used well. Custom blocks should expose proper headings and labels, not only nested div soup. See custom Gutenberg blocks if you extend the editor.

Keyboard navigation

Many users cannot use a mouse. Everything interactive must work with Tab, Shift+Tab, Enter and Space where expected.

• Logical tab order that follows visual order
• Visible focus styles (do not remove outlines without a clear replacement)
• Dropdown menus operable by keyboard, including Escape to close when that is the pattern
• Modals that trap focus while open and return focus on close
• No keyboard traps inside carousels or media players

Menus are a frequent failure point. If you build mega menus or complex mobile drawers, test them early. Our guide to keyboard navigation accessibility goes deeper on patterns and failure modes.

Add a “Skip to content” link as the first focusable item so keyboard users can bypass repeating chrome.

Color contrast and visual design

Text must contrast enough with its background. WCAG 2.1 AA expects roughly 4.5:1 for normal text and 3:1 for large text, with related rules for UI components.

• Check body text, links, buttons and form placeholders
• Do not rely on color alone for errors or required fields
• Test hover and focus states, not only the default look

Brand palettes sometimes fail contrast. Adjust shades rather than asking users to squint. For a focused primer, see color contrast accessibility.

Dark overlays on hero images need the same care: white text on a busy photo often fails unless you add a solid scrim.

Images, media and motion

• Meaningful images need descriptive alt text; decorative images use empty alt
• Linked images need alt that describes the destination when there is no nearby link text
• Video should offer captions; audio should offer transcripts when the content matters
• Avoid autoplaying sound; respect reduced-motion preferences for heavy animation when you can detect them

Train editors: alt text is content, not a keyword dumping ground.

Forms and errors

Contact, quote and account forms convert only if people can complete them.

• Visible labels tied to inputs (label with for / id)
• Group related fields with fieldsets when needed
• Clear required-field indication that is not color-only
• Error messages that name the field and how to fix it
• Sufficient time to complete; warn before timeouts on sensitive flows

Placeholder-only labels fail when the field is filled or when contrast is weak. Keep labels visible.

WordPress-specific theme tips

Menus and walkers. Output valid nested lists. Ensure current page indication is not color-only.

Widgets and sidebars. Headings for widget titles should fit the page outline.

Comments. Labels, nested threads and keyboard-friendly reply links matter on sites that use them.

Pagination and previous/next. Use clear link text; avoid “click here.”

PDFs and downloads. Theme templates should not imply that a PDF is accessible when it is not. Note accessibility of documents in the content process.

Page builders. Builders can produce inaccessible markup if modules skip labels or duplicate IDs. If the project uses a builder, audit the generated HTML, not only the canvas. Comparisons like Gutenberg vs page builder help teams choose tools with eyes open.

WordPress 5.4 is current for early August 2020; accessibility improvements continue across releases. When you adopt new editor features after upgrades, retest keyboard and screen reader paths.

Testing workflow that catches real issues

Automate first, then verify with humans:

1. Automated checks (axe, WAVE or similar) on key templates
2. Full keyboard pass on home, inner page, form, menu and modal
3. Screen reader spot check (VoiceOver, NVDA) on navigation and a form
4. Zoom to 200% and confirm layout still usable
5. Fix issues in the theme; retest after content entry

Automation misses many interaction bugs. Budget time for manual passes before launch and after major theme changes.

Include accessibility in QA tickets the same way you include browser checks. “Looks fine in Chrome with a mouse” is not done.

Content and theme partnership

Developers own theme patterns. Editors own text alternatives, heading order in content and link clarity. Offer a short checklist in client training so new pages do not undo the theme’s work. WordPress client training can include a 15-minute accessibility section.

Common theme failures to avoid

• Icon-only buttons without accessible names
• Carousel slides that cannot be paused
• Focus styles removed for aesthetics
• Off-canvas menus that leave focus on hidden content
• Custom select components that are mouse-only
• Low-contrast footer links on dark backgrounds

Fix these in components once so every page inherits the improvement.

FAQ

Does an accessibility plugin make a theme compliant?

No. Plugins can help with toolbars, skip links or contrast toggles, but they cannot rewrite poor markup everywhere. Fix the theme.

Is WCAG AA enough?

It is a widely used target for business sites. Some organizations need AAA or additional standards. Confirm contract and jurisdiction requirements.

Should we retrofit or rebuild?

Small gaps (contrast, focus, alt patterns) retrofit well. Deep structural problems in a builder-heavy theme often cost less to rebuild cleanly than to patch forever.

How does accessibility relate to SEO?

Clear headings, link text and alternatives help users and can support how search engines understand pages. Accessibility is not a ranking trick; it is inclusive design with side benefits.

Build themes people can actually use

WordPress accessibility starts in the theme: semantics, keyboard support, contrast, media alternatives and labeled forms, verified with real testing. Bake those habits into development and client training so every new page stays usable. For CMS and front-end builds that take this seriously, see our Turn visitors into customers services.