On a recent episode of the Jukebox Podcast from WP Tavern, Nathan Wrigley spoke with Jessica Lyschik about making WordPress themes accessible — and why it’s less intimidating than many developers expect. Jessica, who’s been involved with WordPress since the mid-2000s and working in the ecosystem professionally since 2015, has focused in recent years on accessibility advocacy, theme reviews, and helping teams improve standards.

Her WordCamp Europe 2026 talk, “Accessibility in themes, easier than you think,” aimed to demystify the accessibility-ready requirements for themes on wordpress.org and to show practical, achievable steps that both classic and block themes can take to become accessible.

Why accessibility matters — beyond compliance

Jessica described accessibility as both a moral and practical imperative. It makes websites usable for people with a range of needs — people who are blind, hard of hearing, motor-impaired, or who use different input methods — and it also has business benefits. Examples exist where improving accessibility increased sales, and Jessica flagged a new driver of attention: AI agents. Those agents don’t interpret visual layouts the way humans do; they rely on correct semantic HTML and metadata to navigate and act on sites. If a site is technically accessible, it’s more likely an AI agent (or assistive technology) can perform tasks like shopping or booking for a user.

Jessica’s accessibility journey was gradual. She emphasized that once you learn a few fundamentals, accessibility becomes part of your routine: using semantic elements, labelling form controls, adding descriptive alt text, and ensuring interactive elements communicate their purpose to assistive tools.

Low-hanging fruit: quick wins you can do now

A recurring theme in the conversation was that many accessibility improvements are straightforward and fast to implement:

– Use semantic HTML tags: main, header, footer, nav, section and proper heading hierarchies (H1 → H2 → H3) clarify structure for screen readers.
– Add alternative text to images: the alt field in WordPress’s media library or the image block’s alt attribute is a tiny effort with big payoff.
– Provide skip-to-content links: block themes often make this trivial by letting you designate a main content block so Core can generate the link for you.
– Label icon-only buttons: if a button shows only an icon, add an accessible name (aria-label) so screen readers can describe the button’s purpose.
– Avoid hiding content from assistive tech: use CSS techniques that keep content visible to screen readers if needed (not display:none or visibility:hidden).

Jessica stressed that addressing these issues early — while building a theme or site — saves immense time later. Fixing 12 or 200 occurrences after launch is far more effort than designing accessible patterns up front.

Block themes vs classic themes

Block themes make many accessibility tasks easier because WordPress Core handles more of the semantics if blocks and template parts are used correctly. For example, placing content in a group block and assigning it the main HTML role can automatically produce a skip link and proper structure. Core also manages common forms (comments, search) in accessible ways if you use the provided blocks or template parts. Classic themes still require developers to wire up more of these details manually, so there’s more room for errors if you don’t follow best practices.

Accessibility-ready tag and the repository

Themes in the wordpress.org repository can carry an accessibility-ready tag if they meet a set of requirements. Jessica reviewed the recent update: there are roughly 18 requirements that mix low-hanging technical items and some policy statements (for example, a newer suggestion is that a theme should not require or recommend an inaccessible plugin). While the requirements are relatively stable and built from WCAG concepts, the documentation isn’t always explicit about the exact technical steps, which makes onboarding harder for newcomers.

Only a small fraction of listed themes have the accessibility-ready tag — Jessica quoted around 270 out of over 14,700 themes (about 1.5%). Because the ecosystem is large, she prefers improving documentation and education over sudden enforcement: clearer, practical guidance will lift adoption more effectively than strict rules that users don’t understand.

Interdisciplinary responsibility

Accessibility isn’t only a developer task. Content authors, designers, SEOs, and product managers should understand the basics: proper heading structure, descriptive link text, sensible color contrast, and when to rely on developers to implement ARIA or other technical details. Jessica called for interdisciplinary awareness so accessibility is treated as a normal part of the workflow rather than a special chore added at the end.

Resources and next steps

Jessica recommended following community leaders and resources that translate WCAG and technical specs into practical guidance for WordPress. She mentioned contributors and advocates such as Joe Dolson, Rian Rietveld, Amber Hinds, and Sara Soueidan, and highlighted that video courses and approachable tutorials make the dry WCAG specs easier to absorb.

Her final practical advice: bake accessibility into themes from the start. Use the right blocks or template parts, add labels and alt text, and keep patterns consistent across pages. That initial discipline prevents large-scale rework and makes sites more usable for everyone — and better positioned for emerging tech like AI agents that depend on good semantics.

If you want to hear the full conversation and check the resources Jessica referenced, listen to the Jukebox episode via WP Tavern’s podcast feed or find her WordCamp Europe session recording. For theme authors, taking a few of these small steps today makes a measurable difference for users and keeps your themes future-ready.

In a recent Jukebox Podcast episode, Nathan Wrigley speaks with Jessica Lyschik about why making WordPress themes accessible is more achievable than many developers believe. Jessica, who’s been part of the WordPress ecosystem since 2015 and a long-time accessibility advocate, walked the audience through practical steps, common misconceptions, and why accessibility should be baked into theme development from the start.

Who is Jessica Lyschik
Jessica has years of experience working with WordPress agencies, contributing to theme review processes, and helping raise accessibility standards across projects. Her approach has been gradual and hands-on: learning from mistakes, listening to people who use assistive technologies, and translating accessibility guidelines into actionable development tasks.

Why accessibility matters — beyond compliance
Jessica highlights two motivations for accessibility: legal/regulatory drivers and a moral imperative. Beyond those, she points out a new, practical reason to care — AI agents. As AI tools increasingly interact with websites programmatically, they depend on well-structured, semantically correct HTML. In other words, a site that is accessible to people is often easier for automated agents to understand and interact with. That means accessibility helps not only real users but also emerging automation that will perform tasks like shopping, scheduling, and content retrieval on users’ behalf.

Common low-hanging fruit
Jessica emphasizes several quick wins you can implement in minutes that yield large benefits:
– Use correct semantic HTML elements: header, main, footer, section, aside. These give assistive tech and automated agents structure to work with.
– Add descriptive alt text for images. The media library and block editor expose this field — use it.
– Provide visible link styling (e.g., underlined links) so users can identify interactive elements easily.
– Ensure skip-to-content links are present. In block themes this often requires just one setting; Core can handle much of the work for you.
– Add aria-labels for icon-only buttons so screen readers can announce their purpose.

These are simple changes, but when added early they save hours of rework later. Jessica shared an example where a client needed aria labels added to a handful of header icons — a small fix that, when handled correctly in the theme, prevents repeating the task on many pages or across many sites.

Block themes vs classic themes
One of the clearest takeaways: block themes have made accessibility easier. WordPress Core handles more structure and accessibility considerations if you use the right blocks and template parts. For example, comments and search forms, which historically required extra attention, are handled by Core in block contexts. Header and footer template parts can automatically produce correct semantics if configured properly. Classic themes still require developers to add more manual markup and accessibility glue.

Documentation and the accessibility-ready tag
WordPress.org offers an accessibility-ready theme tag, backed by a set of requirements (around 18 checks). These are intended to help theme authors and reviewers, but Jessica notes they can be cryptic—describing what should be achieved without always explaining how to implement it. She advocates improving the documentation so developers can map each requirement to concrete HTML, CSS, or theme settings.

A few specifics to know about the tag:
– To receive the accessibility-ready tag a theme must meet the requirements and testing instructions listed by the repo.
– One newer suggestion is that a theme should not recommend or require plugins that are not accessible — a point under discussion and worth considering when packaging themes.
– An accessibility.txt file is encouraged. It documents what’s been addressed and provides helpers such as utility classes for screen-reader-only content.

Current adoption is low: only a small percentage of the thousands of repo themes carry the tag. Jessica argues that a practical, educational approach will be more effective than forcing strict requirements immediately.

Interdisciplinary awareness
Accessibility isn’t just the developer’s job. Jessica stresses the importance of interdisciplinary knowledge: content authors, SEO specialists, designers, and front-end developers all play a role. For example, content teams should use correct heading structure (H1, H2, H3) rather than skipping levels. Developers provide the technical scaffolding, but everyone needs to understand basic principles so the whole site stays accessible.

Resources and learning
Jessica recommends following established accessibility leaders in and out of the WordPress community to bridge the gap between the WCAG specs and practical implementation. People she follows include Joe Dolson, Rian Rietveld, Amber Hinds (Equalize Digital), and Sara Soueidan, among others. She also suggests using videos, tutorials, and community talks to make the subject less dry than raw standards documents.

Practical mindset: build it in
The most consistent piece of advice from Jessica is to build accessibility in from the start. Doing so turns accessibility from a dreaded audit checklist into a natural part of creating templates, components, and content. It reduces rework, improves experience for more users, and future-proofs sites for both assistive tech and automated agents.

Final thought
Accessibility for themes is not an all-or-nothing mountain. With a few semantic decisions, consistent habits, and the right use of block theme features, theme authors can make major improvements with modest effort. Better documentation and community education will only make those wins easier. For theme authors, the takeaway is simple: learn the small, repeatable practices, bake them into your theme, and you’ll save time while making the web more inclusive.