Jessica Lyschik has spent years working in the WordPress ecosystem and advocating for web accessibility. In a recent WordCamp Europe talk, she set out to demystify theme accessibility and show that, for many developers, building “accessibility ready” themes is far more achievable than it first appears.
Why accessibility matters
Jessica’s journey into accessibility has been gradual and personal. As she learned about the varied ways people use the web—screen readers, speech control, alternative input devices—what had once been invisible became obvious: many sites create barriers for real users. Beyond the moral imperative, accessibility is increasingly a practical concern. Search engines and emerging AI agents rely on correctly structured content, and an accessible site is far easier for an agent or assistive technology to understand and interact with.
A surprising ally: AI agents
Jessica points out a useful way to think about AI agents: they behave a lot like automated screen readers. If a site is semantically correct and well-labeled, an agent can find and act on content (for example, complete a purchase) just as a screen reader user can navigate a page. That makes accessibility not only the right thing to do for people, but increasingly important for future automation and discoverability.
Where themes fit in
Themes still shape a large part of how users experience a WordPress site, so getting theme markup right has real impact. WordPress.org offers an “accessibility ready” tag for repository themes, backed by a set of requirements (currently 18 items). Those requirements are meant to be a practical subset of broader WCAG principles, but Jessica explains they can read as cryptic to people who don’t already know the HTML and accessibility basics.
Because of that disconnect, many developers who could meet the requirements assume they’re too difficult. Jessica’s core message is that if you understand the technical bits behind the wording—semantic elements, labels, and predictable structure—making a theme accessible often involves small, manageable changes.
Low-hanging fruit: quick wins you can do now
– Use correct semantic HTML elements: header, main, nav, footer, section, aside. Semantic structure helps assistive tech understand page layout.
– Add alternative text to images. The media library (and block editor) exposes alt text fields—use them.
– Provide labels for form fields and aria-labels for icon-only buttons. If a button uses only an icon, a screen reader needs an accessible name.
– Include a skip-to-content link. In many modern block themes this can be handled by setting the main HTML element correctly in the template, and WordPress will insert the skip link for you.
– Make links visually identifiable. Underlining or other clear styling for links is a single line of CSS but improves usability.
– Add an accessibility.txt file in your theme to document what’s been done and any known limitations or helper classes for screen readers.
These are practical steps that often take minutes to implement and save far more time than retrofitting accessibility after a site is built.
Block themes vs classic themes
Block themes give theme authors an advantage because WordPress Core handles more accessibility-critical behaviors when blocks are used as intended. Examples:
– Core-generated forms (like comments) and search forms in block themes already include accessible markup.
– Template parts can be designated as header or footer so the correct HTML tags are emitted automatically.
– Assigning a Group block as the main element can enable skip links and proper page structure without custom markup.
Classic themes still require more manual work to ensure appropriate markup and behavior, so transitioning to or learning block theme patterns can simplify accessibility tasks.
Repository realities and the “accessibility ready” tag
Currently, only a small fraction of repository themes carry the accessibility ready tag—Jessica cites roughly 270 of about 14,700 themes (~1.5%). To earn the tag, a theme must meet all the stated requirements. Some newer rules are still being discussed—for example, whether a theme should avoid recommending plugins that are not accessible. Jessica argues for improving documentation and examples rather than enforcing an immediate repo-wide requirement, because gradual adoption and clearer guidance will scale better.
The documentation gap
One recurring problem is documentation that describes “what” must be achieved but not “how” to implement it. Jessica recommends clearer phrasing and concrete examples so developers can connect the accessibility requirements to specific HTML, CSS and editor settings. Better examples, starter themes, and learning resources would reduce friction and increase adoption.
Interdisciplinary responsibility
Accessibility isn’t only a developer concern. Content authors, designers, SEOs and project managers all play a role. Designers should think about color contrast and interactive controls; content authors should use proper heading order and descriptive link text; developers should provide the structure and patterns that make all those contributions work together.
Resources and learning
Jessica follows accessibility experts and contributors in and outside the WordPress community. Names she recommends include Joe Dolson, Rian Rietveld, Amber Hinds (Equalize Digital), and Sara Soueidan. She also encourages using approachable tutorials and videos to complement formal specs like WCAG, which can be dense. Learning practical, example-driven workflows makes adoption easier.
Final advice
– Start accessibility work early. Fixing issues during initial theme design avoids repeated retrofits.
– Focus on the low-hanging fruit first: semantic structure, alt text, labels, and skip links.
– Use block theme patterns and Core features where possible to reduce manual work.
– Improve documentation and share patterns so others can follow.
Accessibility in WordPress themes is not an unsolvable technical black box. With a few straightforward habits, the right examples, and better documentation, theme authors can reach accessibility-ready status and build sites that work for everyone—today and for the AI-driven tools of tomorrow.
