At WordCamp Europe 2026, Jessica Lyschik — a long‑time WordPress contributor and accessibility advocate — argued that accessible themes are far more achievable than many developers believe. Her talk, “Accessibility in themes: easier than you think,” focused on practical steps theme authors can take, how block themes simplify the work, and why accessibility should be part of every site team’s toolkit.
Why accessibility matters
Jessica described accessibility as both a moral imperative and a practical business improvement. Beyond legal obligations and compliance, accessible sites reach more people, improve usability for everyone, and will become increasingly important as AI agents and automated assistants interact with websites. She noted that AI “agents” behave like another form of assistive technology: they don’t “see” pages visually and rely on correct semantic HTML, labels, and structure to navigate, extract information, and complete tasks like shopping. Making content machine‑readable helps both humans and automations.
A practical, beginner‑friendly approach
What intimidates many theme authors is unclear or technical documentation. WordPress.org provides an “accessibility‑ready” theme tag with 18 requirements, but those guidelines can seem cryptic. Jessica’s goal is to translate those requirements into concrete, easy steps so developers can actually implement them.
She emphasized low‑hanging fruit that yields immediate benefits:
– Use correct HTML structure: header, main, footer, sections and logical heading hierarchy (H1, H2, H3…).
– Add meaningful alt text to images; the field is available in the media library and block editor.
– Provide skip‑to‑content links so keyboard users can bypass repeated navigation.
– Ensure form fields and controls have labels; add aria‑labels to icon‑only buttons so screen readers can identify purpose.
– Make links visually distinguishable (for example, underline) so they’re obvious to users with low vision.
These are simple changes that can often be implemented in minutes. More importantly, doing them from the start prevents a much larger cleanup later when dozens or hundreds of instances must be fixed across a site or a theme.
Block themes vs classic themes
Block themes make several accessibility tasks easier because WordPress core already handles much of the semantic markup when blocks and template parts are used correctly. For example, assigning a group block as the page’s main element or using header/footer template parts results in proper HTML landmarks without manual markup. Search and comments forms are also handled by core, reducing the manual work required to meet form and labeling requirements.
Classic themes still require more manual attention: developers must ensure appropriate landmarks, skip links, and correct structure are present. The upside is that once you know the pattern, you can create accessible templates and reuse them across projects.
Accessibility‑ready tag and repository realities
Jessica walked through the accessibility‑ready tag requirements and explained items like including an accessibility.txt file (a place to document what was done and provide guidance or CSS classes for screen‑reader‑only content) and avoiding recommending or requiring inaccessible plugins. She shared repository context: of roughly 14,700+ themes in the WordPress.org directory, only around 270 themes carry the accessibility‑ready tag (~1.5%). Because of the repo’s scale, Jessica recommends improving documentation and providing examples rather than trying to force a sudden mandate; clearer instructions and better starter themes will encourage broader adoption.
Documentation, community, and continuous learning
Accessibility is an ongoing learning process. Jessica urged teams to adopt an interdisciplinary view: developers, designers, content authors, and SEO specialists each play a role. Content teams should use proper headings and descriptive link text; developers should provide the technical structure that makes content accessible.
She also recommended learning from established resources and people in the field, including WordPress accessibility contributors and accessibility practitioners outside WordPress. Names she mentioned include Joe Dolson, Rian Rietveld, Amber Hinds (Equalize Digital), and Sara Soueidan, among others — and she encouraged builders to use tutorials, videos, and approachable guides in addition to the formal WCAG documentation.
Common pitfalls and a mindset shift
Jessica shared examples from real projects: icon‑only buttons without aria labels, headers missing skip links, and other small oversights that compound across pages. Her advice is to bake accessibility into the development workflow so these issues are fixed once rather than repeatedly. That shift — from “oh no, more work” to “this is part of how we build” — reduces friction and makes accessible products the natural outcome.
AI and the next wave of attention
One provocative point: as AI agents and automated assistants become more common, accessibility will gain new relevance. If an agent is expected to navigate a shop, compare products, or complete purchases on behalf of a user, the site must be technically correct and well‑structured. That alignment between accessible design and machine consumption could accelerate adoption.
Final thoughts
Jessica’s core message: accessibility is not an arcane or unreachable set of requirements. With clearer documentation, a few simple habits, and the right use of WordPress features (especially block themes), theme authors can make large improvements with modest effort. Start small: add alt text, use semantic markup, label controls, and leverage core behavior. Those steps make sites better for more people now and prepare them for the web tools of tomorrow.
For further reading and links to the resources Jessica mentioned, see the show notes on WP Tavern or watch her WordCamp presentation for concrete examples and demonstrations.