Accessibility in WordPress Themes: Easier Than You Think

This post summarizes a conversation with Jessica Lyschik at WordCamp Europe 2026 about why making WordPress themes accessible is more achievable than many developers expect. Jessica, a long‑time WordPress community member who’s worked professionally in the ecosystem since 2015, presented “Accessibility in themes — easier than you think.” Her goal was to demystify the repository’s accessibility requirements, point out quick wins, and explain why building accessibility in early saves time.

Who Jessica is

Jessica started experimenting with WordPress in the mid‑2000s and joined the community professionally in 2015. Over time she developed a deep interest in web accessibility — a learning process that involved mistakes, ongoing education, and personal motivation. She emphasized that once you begin to understand how people with different abilities use the web (screen readers, voice control, limited motor control, etc.), the changes you need to make become obvious and meaningful.

Why accessibility feels intimidating — and why it doesn’t have to

A big barrier is documentation. The WordPress.org “accessibility‑ready” requirements are clear about the outcomes but can be cryptic about how to implement them. When read without context, the checklist can sound daunting. Jessica’s message: once you translate those requirements into concrete HTML, template, and editor actions, many of them become straightforward tasks.

Another practical driver is AI. Jessica pointed out that AI agents acting on behalf of users operate similarly to assistive technologies: they rely on a site’s semantic structure and programmatic information. If a site is built with correct elements, labels, and structure, both screen readers and AI agents can read and interact with it more reliably. That perspective can make accessibility feel less abstract — it’s also about future usability and automation.

Low‑hanging fruit you can do now

Jessica shared simple, high‑impact changes teams and theme authors can apply quickly:

• Use correct HTML landmarks and headings: header, main, nav, footer, and a logical H1 → H2 → H3 structure.
• Provide alt text for images: it’s built into the media library and block editor — use it.
• Add skip‑to‑content links: in block themes this can be handled by assigning a block the main role; Core can produce a skip link automatically if templates are set up correctly.
• Label form fields and icon‑only buttons: add accessible labels or aria attributes when a control has no visible text.
• Ensure links are visually distinct (for example, underlined) to improve usability for some users.

These are not theoretical tasks. Many are a matter of using the correct template parts or editor settings — especially with block themes — and can be implemented in minutes rather than days.

Block themes vs classic themes

Block themes make accessibility easier in many cases because WordPress Core handles a lot of the markup and ARIA details when you use the correct blocks and template parts. Core provides accessible search and comment forms and can apply the right semantic wrappers if template parts are assigned properly. Classic themes usually require more manual work to add landmarks, skip links, and properly labeled controls.

The accessibility‑ready tag and the state of themes in the repo

The WordPress.org repository offers an accessibility‑ready tag. To earn it a theme must meet a set of requirements (Jessica referenced 18 specific checks). However, the tag is optional: themes can still be listed in the repo without it. As of her talk, only a small percentage of themes carried the accessibility‑ready tag (Jessica cited roughly 270 out of around 14,700 themes — about 1.5%).

Jessica argued against heavy‑handed enforcement for now. Given the size of the ecosystem, the better approach is clearer documentation, improved examples, and education so more theme authors can reach the standard voluntarily. Better onboarding material and concrete code examples would reduce friction and increase adoption.

Process and mindset: bake it in early

A recurring theme in the conversation was cost of delay. Fixing accessibility issues across a site after launch is often tedious and expensive. Doing it during theme development — especially once you’ve established accessible patterns and reusable template parts — drastically reduces repeated work. Jessica shared a practical anecdote: an agency client found icon‑only buttons across pages that lacked accessible labels; fixing them in the theme or template prevented the same problem from repeating across dozens or hundreds of pages.

Accessibility is interdisciplinary

Accessibility isn’t only a developer concern. Content writers, SEO specialists, designers, and project managers all play a role: headings should be structured properly, content should be written with clarity, and visual design decisions should preserve contrast and readable focus states. Jessica recommended a shared baseline of knowledge across teams so accessibility becomes part of workflow rather than a last‑minute checklist.

Resources and people to follow

Jessica pointed listeners to both WordPress community leaders and broader accessibility experts. Names she mentioned include Joe Dolson, Rian Rietveld, Amber Hinds (Equalize Digital), Sara Soueidan, and Anne‑Mieke Bovelett. She also suggested seeking practical tutorials and recorded talks that bridge the gap between WCAG theory and hands‑on implementation, since the raw WCAG docs can be dense.

Final takeaways

• Accessibility in themes is more attainable than it first appears, especially with block themes and the right examples.
• Small, consistent habits (alt text, correct heading structure, labeled controls, skip links) produce large benefits.
• Investing in accessibility early prevents repetitive fixes later and often improves business outcomes (better UX, broader reach, and potentially improved sales or automation compatibility).
• Better, clearer documentation and examples would accelerate adoption across the theme ecosystem.

If you want to hear the full conversation and find links Jessica mentioned (slides, resources, and episode notes), check the Jukebox podcast episode on WP Tavern and the show notes at wptavern.com/podcast.