In this Jukebox Podcast episode from WP Tavern, Nathan Wrigley talks with Jessica Lyschik about why making WordPress themes accessible is more straightforward than many developers expect. Jessica, who’s been involved with WordPress since the mid 2000s and professionally in the ecosystem since 2015, has been learning, building, and advocating for web accessibility for years. Her WordCamp Europe 2026 talk, “Accessibility in themes: easier than you think,” aimed to demystify the repository requirements and point out practical, immediately usable wins.
Why care? Jessica frames accessibility as both a moral obligation and a practical advantage. Accessible sites help more people, and there are business benefits too — accessibility improvements can lift conversions and prepare sites for new ways people interact with the web. She calls out one emerging angle: AI agents. These agents don’t “see” pages visually; they rely on semantic HTML and correct structure — just like assistive tech. If your markup and ARIA are correct, an AI agent can navigate, pick options, and even complete purchases for users, making accessibility increasingly important for real-world automation and discoverability.
A common blocker is documentation and language. The wordpress.org accessibility-ready requirements exist, but reading them can feel cryptic if you’re new to accessibility. Jessica explains that many rules essentially map to familiar technical tasks: use correct semantic elements (header, main, nav, footer, section, aside), add descriptive alt text for images, ensure form fields have labels, provide skip-to-content links, and use correct heading structure (H1, then H2, then H3, etc.). The repository has 18 accessibility-ready requirements; they’re largely stable and based on WCAG principles, but the guidance often stops short of telling developers how to implement them.
Low-hanging fruit Jessica recommends you can accomplish quickly:
– Add alternative text to every meaningful image (the media library and block editor include fields for this).
– Ensure links are visually distinguishable (for example, underlined links where appropriate).
– Provide skip-to-content links so keyboard users and screen readers can bypass repeated navigation.
– Use semantic HTML and proper heading order rather than skipping levels.
– Add ARIA labels for icon-only buttons so screen readers know each button’s purpose.
These changes are small per instance, but huge in aggregate. Jessica recounts a client case where header buttons used only icons; adding ARIA labels took a little time up front but prevented repetitive retrofitting across many pages.
Block themes vs classic themes
Jessica is optimistic about block themes. A lot of accessibility plumbing is handled by Core when you use the right blocks and template parts. For example, assigning the main HTML tag to a content group and using template parts for header/footer lets Core generate the correct semantics and skip links for you. Classic themes often require manually adding accessible markup and behaviors, so block themes can make many accessibility tasks significantly easier — provided you know which blocks and settings to use.
Repository realities and the accessibility-ready tag
Getting the accessibility-ready tag in the WordPress theme directory requires meeting the listed requirements; it’s optional. There are thousands of themes in the repo (around 14,700 at the time Jessica cited), and only a small fraction — roughly 270 — carry the accessibility-ready tag. Because adoption is low, Jessica argues for gradual improvement: better, clearer documentation and examples will onboard more authors than heavy-handed enforcement. One newer requirement calls for themes not to recommend inaccessible plugins — a point that’s still under discussion and highlights areas where policy and practice need refinement.
Process and mindset
Jessica stresses building accessibility in from the start. If accessibility is part of the theme or component design, you avoid costly retrofits later. Accessibility should be interdisciplinary: developers, designers, content creators, and SEO specialists all play a role. Content teams should use proper headings and meaningful link text; developers provide the semantic structure and ARIA where needed.
Resources and people to follow
Jessica points to experienced practitioners inside and outside the WordPress community: Joe Dolson, Rian Rietveld, Amber Hinds (Equalize Digital), and Sara Soueidan, among others. She recommends watching talks, following practical tutorials, and using approachable resources (video walk-throughs and examples) rather than diving straight into dense WCAG or HTML specs.
Final thoughts
The core message is optimistic: accessibility is not as intimidating as many think. With a handful of practical steps, thoughtful habits, and clearer documentation, theme authors can deliver sites that work better for more people. Block themes lower the barrier further by letting Core handle much of the heavy lifting. Jessica’s talk and the conversation on the podcast encourage theme authors to treat accessibility as an essential, achievable part of building modern WordPress sites. For links and resources mentioned in the episode, visit the WP Tavern show notes where the team will add Jessica’s recommended materials and presentations.