Accessibility in WordPress Themes: Easier Than You Think

In a recent Jukebox Podcast interview, Jessica Lyschik — a longtime WordPress community member and accessibility advocate — makes a clear, optimistic case: making themes accessible is far more achievable than many developers expect. Her WordCamp Europe talk framed accessibility as both a moral imperative and a practical, technical challenge with lots of low-hanging fruit. Below are the main takeaways, practical steps, and resources Jessica recommends.

Why accessibility matters (beyond compliance)

• Moral and practical: Accessibility opens the web to people who rely on assistive tech or alternative interaction patterns. Beyond legal obligations, it’s about fairness and inclusion.
• Business incentives: Accessible sites can reach more users; some organizations saw sales increases when they improved accessibility.
• AI agents: Emerging AI “agents” and automated assistants interact with websites similarly to screen readers. If your site’s structure and semantics are correct, these agents can perform tasks (like shopping or booking) on users’ behalf — making accessibility increasingly valuable.

Why many people overestimate the difficulty

• Documentation gap: WordPress.org’s “accessibility ready” requirements exist, but their wording can be cryptic. They tell you what should happen but don’t always show the simple technical steps to get there.
• Perception vs. reality: Once you understand basic HTML semantics and a few key practices, most accessibility requirements become straightforward to implement.

The state of themes in the WordPress repository

• There are roughly 14,700 themes in the repository; only about 270 have the accessibility-ready tag (≈1.5%).
• To earn that tag, themes must meet around 18 requirements. These map to well-established accessibility principles (a subset of WCAG) and include items like using proper landmarks, labeling form fields, and providing information in an accessibility.txt file.
• Jessica argues for gradual improvement and better documentation rather than immediate, strict gating. Improved docs and examples will make compliance easier for many authors.

Block themes vs. classic themes

• Block themes make accessibility easier: WordPress core handles many semantics for you when you use the correct blocks and template parts. For example, assigning a group as the main element or using header/footer template parts will output correct HTML landmarks automatically.
• Classic themes require more manual work: you must ensure landmarks, labels, and skip links are present and correctly implemented yourself.
• Practical benefit: If you build a correct template once in a block theme, you can reuse it across pages or sites and avoid repetitive fixes later.

Low-hanging fruit you can fix quickly (30–60 minutes)

• Add alt text to every image. The media library and block editor expose this field; use it.
• Ensure links are visually obvious (e.g., underlined or clearly styled). A single CSS rule for link styling goes a long way.
• Check heading structure. Use a logical sequence (H1 → H2 → H3) and avoid skipping levels.
• Add aria-labels for icon-only buttons. If a button shows only an icon, add an accessible label so screen readers know its purpose.
• Configure skip-to-content or ensure the main landmark is set. In block themes, assign the main tag to the content group so WordPress can provide a skip link.
• Use core-provided form elements in block themes where possible; they are already accessible.

Build accessibility habits

• Implement accessibility from the start of a project. Fixing hundreds of issues later is far more work than adding correct markup and labels early on.
• Make accessibility a cross-discipline concern: developers, designers, content authors, and SEO specialists all play a part. Teach content teams to use headings correctly and write meaningful link text.

Notable people and resources

• Within WordPress: Joe Dolson, Rian Rietveld, Amber Hinds (Equalize Digital).
• Outside/related: Sara Soueidan (web developer and accessibility expert). Jessica also mentioned Anne-Mieke Bovelett as a fellow speaker.
• WCAG and other formal standards remain the baseline, but look for accessible, developer-focused tutorials and videos to make learning less dry.

Repository rules and a few specifics

• Requirements include things like not recommending inaccessible plugins, providing an accessibility.txt file with notes on what’s been done, and meeting technical checks (landmarks, labels, keyboard focus, etc.).
• Some newer requirements (like plugin recommendations) raise discussion about grey areas and how strict the repo should be.

Final thoughts

Jessica’s message is practical and encouraging: most theme accessibility work boils down to applying established HTML semantics, labeling interactive elements, and leveraging the accessibility features that WordPress core provides—especially with block themes. Start small, fix the easy items, bake accessibility into templates and workflows, and reuse accessible patterns. The long-term payoff is less rework, broader audience reach, and a web that works better for everyone.

If you want to learn more

Jessica’s talk and linked resources are available in the podcast show notes at wptavern.com/podcast. Look up the names mentioned above and search for practical tutorials and videos to make the WCAG guidance more approachable.