This is a concise recap of an interview with Jessica Lyschik about making WordPress themes accessible — and why it’s easier than many theme authors expect.
Who Jessica Lyschik is
Jessica has been involved with WordPress since the mid-2000s and working professionally in the ecosystem since 2015. Over the last several years she’s focused on web accessibility as a developer and community contributor, helping agencies, participating in theme review, and speaking about practical ways to build accessible themes.
Why accessibility matters
Jessica frames accessibility both as a moral obligation and a practical business concern. Beyond legal compliance, accessible websites are simply better to use for more people. She also highlights a newer, practical driver: AI agents and automated assistants. These tools don’t “see” pages visually; they rely on semantic, correctly structured markup the same way screen readers do. If your site is built with good HTML semantics and ARIA where appropriate, AI agents and assistive technologies can reliably navigate and interact with it — for example, locating items and making purchases.
Why accessibility feels hard — and why it’s not
Many developers read the accessibility-ready requirements on WordPress.org and find them cryptic. The requirements describe what a theme must do, but don’t always say how to implement it. Jessica’s main point is that the technical steps are often quite straightforward once you understand the mapping between requirements and concrete HTML/CSS patterns. Improving the documentation and adding clearer, practical examples will lower the barrier for many theme authors.
Low-hanging fruit — quick wins you can do now
Jessica emphasizes practical, fast improvements that make large differences:
– Add meaningful alternative text to images. It’s available in WordPress media fields and blocks — just use it.
– Use the correct HTML landmark elements: header, main, footer, nav, aside, section. These give screen readers and agents the structure they need.
– Provide a skip-to-content link. In block themes this can be achieved by assigning the main element correctly so WordPress outputs the link for you.
– Ensure headings follow a logical order (H1 → H2 → H3, not jumping levels). This keeps document structure clear.
– Add aria-labels or accessible text for icon-only buttons so screen readers know each button’s purpose.
– Make links visually distinct (for example, underline links in main content) so users can recognize them easily.
These steps are small per instance but compound well: fix the template or component once and you avoid repeating work across many pages.
Block themes vs classic themes
Block themes make several accessibility tasks easier because WordPress Core handles many semantic and interactive details for you. If you use the right blocks and template parts and assign their roles correctly, Core will output the correct elements (labels, landmarks, etc.). Classic themes typically require more manual implementation. Jessica recommends learning the right block/template patterns and using accessible starter themes as a base so you don’t re-invent the structure.
WordPress.org accessibility-ready tag
The theme repository offers an accessibility-ready tag for themes that meet the accessibility requirements. There are specific requirements (recently updated) that a theme must satisfy to obtain the tag, and one newer guideline concerns whether a theme recommends or requires plugins that are not accessible. That requirement has generated discussion.
In practice, only a small fraction of repository themes carry the accessibility-ready tag. For that reason Jessica prefers a gradual approach to raising standards: clearer documentation, practical examples, and better onboarding will help more authors adopt accessible practices than immediate, strict restrictions would.
Process advice: make accessibility a habit
Jessica’s work illustrates that accessibility becomes second nature after a while: once you repeatedly use good semantics and add labels where needed, it’s baked into your workflow. Doing accessibility from the start saves a lot of time. Retrofitting accessibility after launch can be tedious if many components need manual fixes.
Interdisciplinary awareness
Accessibility isn’t only for developers. Content authors, designers, SEO specialists, and product owners all play roles. Examples: content teams should use proper heading structure and descriptive link text; designers should consider colour contrast and focus styles. When everyone involved understands the basics, the site becomes reliably more accessible.
Documentation and resources
Jessica calls for clearer, more practical documentation that explains how to accomplish the theme requirements in concrete terms. She recommends learning from accessibility experts and community members. Some people and resources she follows include Joe Dolson, Rian Rietveld, Amber Hinds (Equalize Digital), and Sara Soueidan. There are tutorials, courses, and talks that present hands-on examples and make WCAG concepts easier to digest than the raw specs.
Takeaway
Accessibility in themes is not an impossible burden. Many of the most impactful fixes are small and repeatable: semantic HTML, alt text for images, proper labels for controls, skip links, and consistent heading structure. Block themes reduce manual work by leveraging Core’s built-in accessibility handling, and building accessibility into templates from the start pays off across a site or a theme library. With better documentation, practical examples, and a habit of accessible patterns, theme authors can make much of the web work for everyone.
If you want to explore further, look for Jessica’s WordCamp presentation and the show notes on WP Tavern for links to the resources and names she mentions.
