Making WordPress Themes Accessible — Easier Than You Think

In a recent Jukebox Podcast interview from WordCamp Europe 2026, Jessica Lyschik made a clear, encouraging case: making WordPress themes accessible is far less daunting than many theme developers assume. Jessica, a long‑time WordPress community member who has worked professionally in the ecosystem since 2015, has focused much of her work on web accessibility — joining agencies, contributing to theme reviews, and helping improve documentation and standards.

Why accessibility matters

Jessica frames accessibility as both a moral obligation and a practical improvement. Beyond legal requirements that many organizations face, accessible sites simply work better for more people — and that includes emerging use cases. As AI agents and automated assistants become more common, they will interact with websites much like assistive technologies do. If a site is built with correct semantic structure and clear labels, those agents can more reliably read, interpret, and act on content (for example, help a user buy a product). Accessibility becomes not just an ethical choice, but also a technical advantage.

Where people get stuck

A big obstacle is documentation. The WordPress repository offers an accessibility‑ready tag with a list of requirements, but those requirements can read as cryptic to people who aren’t familiar with the technical specifics. Jessica explains that the gap between “what the requirement says” and “how you actually implement it in HTML or in a theme” is the part that scares people off. If documentation were clearer about the concrete steps — the exact HTML elements, attributes, or theme configuration needed — more authors would take action.

Low‑hanging fruit: easy wins you can implement quickly

Jessica emphasizes several practical improvements that are simple and fast to apply:

• Use proper semantic HTML: tags like header, main, nav, footer, section, and aside help assistive technologies understand page structure. This is often the single most important change.
• Add alternative text to every meaningful image: WordPress already exposes alt fields in both classic and block editors; use them.
• Provide skip‑to‑content links: these can be configured automatically in block themes by assigning the main HTML tag to a group or template part, so WordPress can add the skip link for you.
• Add aria labels where needed: icon‑only buttons require aria labels so screen readers can convey their purpose. Fixing them in one place (for example, a header template part) avoids repetitive manual fixes site‑wide.
• Make links visually identifiable: ensure links are visibly distinct (for example, underlined) so users relying on visual cues aren’t confused.

Block themes make accessibility easier

Jessica points out that block themes lower the technical barrier. Core handles a number of accessibility details automatically when theme template parts and blocks are used correctly. Common elements such as comments and search forms are managed by Core; template parts assigned as header and footer will produce the proper HTML semantics. In contrast, classic themes often require developers to implement these details manually.

The accessibility‑ready tag and the current landscape

To earn the accessibility‑ready tag on wordpress.org, themes must meet a set of requirements (18 at the time of discussion). These include technical items and newer expectations, such as not recommending or requiring plugins that aren’t accessible and including an accessibility.txt file that documents what was done and how to use screen‑reader helper classes.

However, only a small fraction of repository themes carry the tag — Jessica referenced roughly 14,700 themes in the repo and about 270 with the accessibility‑ready tag (around 1.5%). Given those numbers, she advocates for education and clearer documentation rather than sudden enforcement. A gradual approach — improving guidance and making accessibility easier to adopt — will likely have better uptake than rigidly blocking themes from the repository.

Accessibility is interdisciplinary

Accessibility isn’t only a developer responsibility. Content authors, designers, and SEO specialists all play roles: writers should use proper heading hierarchy, designers should choose color contrast and visible focus styles, and developers should provide proper markup and ARIA where necessary. When accessibility is baked in from the start, it becomes habitual rather than an onerous retroactive task.

Where to learn more

Jessica recommends following accessibility experts and resources both inside and outside WordPress. Names she mentioned include Joe Dolson, Rian Rietveld, Amber Hinds (Equalize Digital), and Sara Soueidan, among others. She also stressed that while the WCAG and technical specs can be dense, there are many practical, approachable tutorials and videos that make the concepts easier to absorb.

Parting advice

Start small and start early. Implement the low‑hanging improvements, use block themes and properly configured template parts to let Core handle structure, and treat accessibility as part of your standard workflow. The payoff is immediate: fewer fixes later, better experiences for visitors, and future‑proofed content that works with assistive tech and AI agents alike.

If you want links and resources from Jessica’s talk, the WP Tavern show notes for the episode include the materials referenced during the interview, and her full presentation should be available through WordCamp recordings.