Jessica Lyschik, a long‑time WordPress contributor and accessibility advocate, argues that making themes accessible is far less intimidating than many developers think. Speaking at WordCamp Europe 2026, she focused on practical steps theme authors can take—both in classic and block themes—to reach “accessibility‑ready” status without excessive effort.
Why accessibility matters
Jessica frames accessibility as both a moral imperative and a practical benefit. Beyond legal or policy reasons, accessible sites reach more people and often perform better. She also highlighted a rising technical incentive: AI agents and automated tools increasingly interact with sites the same way assistive technologies do. If your site uses correct semantics and markup, an AI agent (or a screen reader) can navigate and act on behalf of users—for example, completing purchases—so accessibility affects not only people but also how future automation will work with your site.
A common barrier: unclear documentation
One major obstacle is that the accessibility‑ready requirements on wordpress.org can sound cryptic to developers who don’t have accessibility background. Jessica notes the guidelines describe what must be achieved and how to test, but they don’t always explain the technical steps to implement those requirements. Improving the documentation to map requirements to specific HTML, ARIA and editor settings would lower the barrier for many theme authors.
Low‑hanging fruit: quick wins you can do today
Jessica recommends a set of easy, high‑impact changes that you can implement quickly:
– Use correct semantic HTML elements: header, main, footer, section, nav, and aside. Proper structure helps assistive tech understand the page.
– Add alt text to images. This is already supported in WordPress media fields and block editor image settings—use them.
– Implement a skip‑to‑content link so keyboard users can bypass repeated navigation.
– Ensure icon‑only buttons include accessible labels (aria‑label or visible text). Screen readers cannot infer meaning from icons alone.
– Make links visually distinguishable (for example, underline links in body text) so users who rely on contrast or visual cues can identify them easily.
These are simple to add and often just a matter of habit. Doing them at the start of a project prevents large, expensive retrofits later (e.g., having to update hundreds of buttons or every page of a site).
Block themes vs classic themes
Block themes are making accessibility easier because WordPress core handles many accessible behaviors automatically when blocks and template parts are used correctly. For example:
– Core manages common forms (comments, search) in an accessible way in block themes.
– Assigning a group block the semantic role of main produces the correct HTML main tag and can enable automatic skip links.
– Using header and footer template parts correctly produces the right landmarks without manual markup.
Classic themes often require more manual work to ensure correct semantic markup and landmarks. If you adopt block‑theme patterns or start from an accessible block theme template, much of the heavy lifting is already done.
Accessibility‑ready tag and the current state of themes
WordPress.org offers an accessibility‑ready tag that requires meeting a set of theme guidelines (currently 18 requirements). Jessica explains some examples—like including an accessibility.txt file that documents what accessibility features exist, and ensuring themes don’t recommend inaccessible plugins. However, adoption is low: only a small fraction of the repository’s themes have that tag. Because there are thousands of themes in the repo, a forced mandatory requirement today would be hard to implement; Jessica recommends improving guidance and education to grow adoption gradually rather than imposing a sudden ban.
Interdisciplinary approach
Accessibility isn’t just a developer issue. Jessica stresses the need for cross‑team awareness: designers, content authors, SEO specialists, and developers all have roles to play. Content authors should use proper heading hierarchies (H1, H2, H3) and meaningful link text; developers should provide semantic markup and ARIA where needed; designers should consider contrast and visual cues. When accessibility is integrated in workflow and design systems, it becomes part of standard practice rather than an afterthought.
Habits and tooling
Accessibility becomes second nature with practice. Jessica gave an example where a client audit revealed many icon‑only buttons missing labels; fixing them was straightforward but repetitive. The lesson: bake accessibility into templates and components so you fix it once and reap the benefits across pages and sites. She also emphasized available tooling, such as automated checks, but reminded listeners that tooling complements, not replaces, good semantics and human testing.
Resources and people to follow
Jessica recommends learning from both WordPress‑centric and general accessibility experts. Names she cited include Joe Dolson, Rian Rietveld, Amber Hinds (Equalize Digital), and front‑end accessibility author Sara Soueidan. She encouraged consuming a variety of formats—tutorials, videos, talks, and practical walkthroughs—because WCAG and spec documents can be dense and hard to approach for beginners.
Final takeaways
– Accessibility in themes is achievable with modest effort, especially if you start early and use the right blocks or template parts.
– Small changes (alt text, semantic tags, skip links, labelled icon buttons) unlock large benefits.
– Block themes simplify many accessibility concerns by leveraging WordPress core behavior.
– Better documentation and education will drive wider adoption of accessibility‑ready practices.
For more details and links mentioned during the conversation, see the WP Tavern podcast show notes at wptavern.com/podcast where the episode and resources are listed.