WordPress Accessibility: How We Build More Accessible Websites

21 August 2026

A Digital Dispatch by Sian Jamieson, Partnership Lead

Accessibility

Making your website accessible is a legal requirement in the UK, and that’s a good thing. The more inclusive your message, the wider your audience.

Modern WordPress, and particularly the Block Editor, gives accessibility a great starting point. If your website is using WordPress Core blocks properly, WordPress is already providing a strong accessibility foundation for you.

But the story definitely doesn’t stop there.

How the WordPress Block Editor Supports Accessibility

One of the reasons we continue to build with WordPress at Pooka is that it has evolved enormously since its launch in 2003. The Block Editor isn’t simply a nicer way of laying out pages. It gives us a framework for creating structured, reusable components while WordPress handles much of the underlying markup.

Take something as fundamental as keyboard navigation. Anything you can interact with using a mouse should also be accessible to someone navigating using a keyboard.

When we use WordPress Core blocks for functionality such as navigation and buttons, much of the navigability functionality has already been considered and built into the blocks that end up on the page.

As a ‘simple’ example, clickable elements should be properly defined in the HTML of the page. For example a link, which in code, looks like this:

<a href="https://example.com">my link</a>

can be navigated to by screen readers.

Whereas alternatives like starting with a generic element (e.g. <div data-link="https://example.com">not actually a link</div>), and then using JavaScript to make it behave like something clickable afterwards, generally won’t work for screen readers.

A Core WordPress Button, for example, will normally be rendered as a link element (<a href="">) when you’re using it to link to another page. We can change how that link looks to suit the design and branding of the website, without changing what that HTML element fundamentally is.

It sounds like a small technical distinction (and apologies if you fell asleep somewhere around example.com), but think about two different people using that page.

One person can see the link, move a mouse over it and click. Another person might be using a keyboard or assistive technology to move through and ‘focus’ on the interactive elements within the page before activating them.

For that second person, the underlying HTML isn’t an invisible technical detail. It’s part of how their software understands and navigates the website.

Building Accessible WordPress Websites for Content Editors

This is somewhere the Block Editor becomes particularly interesting to us.

When we build a website, we’re not only thinking about the pages we’re creating today. We’re thinking about the new campaign page, news story or event that will be added two years from now. We can build patterns and custom blocks that give flexibility while retaining good structure underneath.

‘Heading’ hierarchy is a good example.

Just like you’d do in a Word document, a web page will typically have its title as its <h1>, followed by <h2>’s for the main sections and <h3>’s for subsections within them. If we create blocks containing arbitrary <h3>’s and <h4>’s, it’s very easy for an editor to inadvertently create a confusing non-semantic page structure.

Instead, we can give people sensible structures to start from, that help content editors make the right decisions. We don’t want to make content editors responsible for fixing accessibility problems we could have prevented when we built the website.

WordPress Accessibility Best Practices Start with Good Design

Colour contrast is another obvious example. We could create a beautiful palette of brand colours, hand it over to a client and then expect every member of their team to remember which foreground and background combinations meet accessibility requirements.

Or we can think about those combinations while we’re developing the site’s design system, and ensure that no (or absolutely minimal) thought needs to be made by site authors, to keep their site accessible.

This is in fact a common problem that we see when receiving brand guidelines from visual designers who’ve never known to consider accessibility. At Pooka, all of our website design processes begin with a colour review, and a pragmatic discussion about how brand colours can be safely used either as-is, or with pragmatic but subtle modifications, to ensure accessibility.

The same goes for links in text.

A link buried within a paragraph shouldn’t depend on a subtle difference in colour to tell someone it’s clickable. Underlining links gives people another visual cue and makes content easier to scan. Which is something that benefits plenty of people who wouldn’t necessarily describe themselves as having an accessibility requirement.

Accessibility often works like that. Design something to remove a barrier for one group of people and there’s a pretty good chance you’ve made the experience better for lots of other people too.

Making “Read More” Links More Accessible

There are also plenty of small accessibility decisions that sit with us as developers.

Think about a grid of news articles, each ending with a link saying Read more. Visually, the context may seem obvious because you can see the article title sitting directly above the link. But someone using a screen reader may navigate through the links on a page independently of the surrounding content. A list of links that all simply say “Read more” isn’t particularly helpful.

When we build news feeds and similar custom blocks at Pooka, we can add visually-hidden text that gives assistive technology context. A sighted visitor might still see “Read more”, while a screen reader can communicate ‘read more about x, y and z’.

It’s a small piece of development, and something most visitors will never notice. But that’s rather the point. Good accessibility doesn’t always need to change how a website looks or make it more complicated for everyone else. Sometimes it’s simply about making sure the same interface provides enough information for different people to use it in different ways.

Accessible WordPress Themes Are Only Part Of The Story

WordPress’s accessibility-ready designation doesn’t mean a finished website automatically meets WCAG 2.2AA guidelines. A website is an ecosystem.

There’s the theme, the content, the plugins, images, forms, video, integrations, third-party services and the decisions people make when adding new content.

You can begin with a beautifully accessible theme and then introduce a plugin that creates an inaccessible interface. That’s why at Pooka we consider accessibility as far as possible when we’re deciding how functionality should be delivered, not simply how the finished page looks.

Accessible WordPress Development: Putting Our Approach into Practice

The technology has changed considerably over the years, but the principle hasn’t.

When we developed Access Scottish Theatre for the Federation of Scottish Theatre and Birds of Paradise Theatre Company, accessibility wasn’t a feature on a specification, it was fundamental to what the service was for.

The platform helped audiences find performances according to their individual access requirements, including Touch Tours and Audio Description. Its typography, headings, colours, iconography, search and filtering all had to be considered through that lens.

In other words: accessibility was at the heart of the platform, rather than something bolted on afterwards.

We’ve carried that thinking into increasingly complex WordPress projects.

For Applied Arts Scotland, introducing the Block Editor and structured custom blocks gave the organisation greater flexibility while providing a controlled framework for creating content.

For the bilingual Faodail | Found film archive, accessibility included WCAG 2.2 AA development, but also multilingual content, captions and audio, search and multiple ways of discovering the collection.

And our work with Cotswold Canals Trust brings that thinking into a much more complex digital ecosystem: a bespoke Block Editor website designed to WCAG 2.2 AA alongside membership, donations, ecommerce, events, CRM and secure member functionality.

Accessibility has to survive the whole journey.

It’s little use being able to navigate the homepage perfectly if you can’t then independently join, donate, book an event or manage your account.

Good Accessibility Starts with Clear Thinking

All users, regardless of their accessibility needs, benefit from clear thinking about how a website is structured and how people will use it.

That’s why our Discovery process looks at the people we’re designing for before we start making decisions about individual pages, blocks or functionality.

What are people trying to accomplish?
What information do they need?
What might prevent them from finding or understanding it?
What devices might they be using?
What assumptions are we making about their knowledge, ability, language or circumstances?

These are fundamentally questions about usability and creating an intuitive experience. But they’re also an important foundation for accessibility. If a website is confusing to navigate, difficult to understand or asks people to work unnecessarily hard to complete a task, those problems can become even greater barriers for someone with an accessibility need.

Good accessibility doesn’t sit separately from good user experience. Clear navigation, logical content structures, understandable language and straightforward user journeys make websites easier for everyone to use.

Maintaining WordPress Accessibility After Launch

There’s another person we need to design for: the content editor.

We can create accessible templates, establish sensible colour combinations, use Core WordPress components, build structured patterns and test everything thoroughly. Then we hand over the keys.

The people managing the website still make decisions that affect accessibility: choosing heading levels, writing links, uploading images, adding alternative text, embedding video and creating new pages.

That’s one reason training and ongoing support have always been an important part of how Pooka works. We want our clients to understand not just how to use WordPress, but how to use it well.

Making the Accessible Choice the Easy Choice

There will always be technical standards to understand and tests to perform. WCAG matters. Good semantic HTML matters. Keyboard testing matters. Assistive technology testing matters.

But at Pooka, our overarching guideline is simple: Make the accessible choice the easy choice for our clients.

Modern WordPress gives us increasingly good tools to do that, our job as developers is to use those tools thoughtfully: to build accessible foundations, create good defaults, avoid introducing unnecessary barriers and give the people managing the website the knowledge and confidence to keep doing the same.

Because accessibility isn’t just an extra feature for a particular group of people, it’s part of making digital work properly for humans. And that’s rather the point.

Website’s We Recommend

We recommend The A11Y Project because it makes digital accessibility feel practical and achievable. It’s a brilliant community-driven resource, packed with straightforward guidance, checklists and tools that help anyone creating for the web make more inclusive choices.

We recommend WebAIM’s Contrast Checker because it takes the guesswork out of colour accessibility. Simply add your foreground and background colours and it quickly shows whether there’s enough contrast to meet WCAG requirements, a handy little tool for making sure your content is easier for everyone to read.