Accessibility in WordPress Themes: Easier Than You Think

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.