Accessible WordPress development
Accessibility is a requirement in most of the work we do, not an upgrade line on the quote. We build to WCAG 2.1 AA as standard, to WCAG 2.2 AA where a project or a tender specifies it, and we set the site up so the content added after launch stays accessible without a developer in the room.
- WCAG 2.1 AA as the default build standard, 2.2 AA where it is specified
- Designed and built in, rather than audited on at the end
- Editor guardrails, so accessibility survives the next few hundred pages
- The technical information a procurement response needs, taken from what the build actually does
Accessibility is a line item, not a checkbox
Public-sector and institutional procurement in Canada routinely names an accessibility standard in the requirements: WCAG 2.1 or 2.2 at level AA, the Accessible Canada Act for federally regulated organizations, the AODA in Ontario, the Québec government’s SGQRI 008 standards for provincial public bodies, or EN 301 549 where a European reference is used. Which one applies depends on who is buying and what they are buying.
What they have in common is that the question is rarely answered yes or no. It is scored. An evaluator is comparing what two vendors said they would build, how they would prove it, and what happens to the site eighteen months later when a communications officer has added two hundred pages. Those are three different answers, and most responses only give the first.
Name the standard in writing
The first thing we settle is which standard and which level applies, and we write it into the scope. “Accessible” on its own is not a specification, and a project that never names a version cannot be tested against one at the end.
Evidence rather than assertion
A claim of conformance that nobody can check is worth nothing in an evaluation. We record what was built to, what was tested, how it was tested, and what is known not to conform.
Documents and embedded services
PDFs, maps, video players, chat widgets and consent banners are usually where conformance actually breaks, and they are usually outside the theme. They have to be in scope or explicitly out of it.
The parts of a build that decide the outcome
Accessibility in a WordPress project is not one task. It is a set of decisions spread across the design, the theme, the block library and the editing experience, most of which are cheap when made early and expensive when found in testing.
Semantic structure and landmarks
Correct heading order, real landmarks, lists that are lists, and tables used for data rather than layout. Screen reader navigation depends almost entirely on this, and it is the cheapest thing to get right and the most disruptive to retrofit.
Keyboard operation
Every interactive element reachable and operable from the keyboard, in a sensible order, with nothing that can be entered and not left. Menus, accordions, modals and carousels are where this is won or lost.
Colour and contrast
Contrast checked in the palette, before it reaches a comp, including text on images, disabled states, focus indicators and chart colours. Brand palettes frequently cannot pass at AA, and that is a conversation to have in week one, not in QA.
Focus, motion and timing
A visible focus indicator that is not the browser default hidden by a reset. Animation that respects prefers-reduced-motion. No carousels that move on their own without a control to stop them, and no timeouts a person cannot extend.
Forms and error handling
Labels bound to inputs, errors announced and associated with the field that caused them, required fields marked in more than colour, and a submission path that works without JavaScript reordering the page under the user.
ARIA last, not first
Native elements wherever a native element exists. ARIA is used to describe behaviour HTML cannot, not to paper over markup that should have been a button. Most of the broken ARIA we find was added to make an audit tool quieter.
Where accessibility is actually lost
In practice, sites rarely fail on the theme a developer wrote. They fail on the things attached to it. These are the six we find most often, and all six are decisions rather than accidents.
Plugins that ship their own markup
A plugin chosen for its feature set brings its own front end, and you inherit whatever it does with focus, contrast and roles. We check what a plugin renders before it is in the stack, and build the component ourselves when the answer is bad enough.
Hand-rolled interactive components
Accordions, tabs, modals and carousels written from scratch are the single most common source of keyboard traps. We build them once, correctly, as part of the block library, so that they are right everywhere they appear.
PDFs treated as content
Agendas, reports and forms published as PDFs are outside the website’s conformance and usually inside the obligation. Either the document is remediated, or the information also exists as a page. Both are valid; pretending the question does not exist is not.
Third-party embeds
Maps, video players, booking widgets, chat and consent banners are rendered by someone else’s code. Consent banners in particular can take focus on load and refuse to give it back. Each one needs to be tested, replaced, or declared as a known exception.
Brand palettes that cannot pass
A palette signed off in a brand guide can make AA contrast impossible on buttons and small text. This is solvable, usually with a darker variant reserved for interface use, but only while the design is still open.
The editing experience is the deliverable that keeps the site conformant
A site is accessible on the day it launches because developers built it that way. It is accessible two years later because the people adding content could not easily break it. Those are different problems, and only one of them is solved by code review.
We build editorial interfaces as constrained block systems rather than open canvases: components that already carry the right structure, headings that follow the document outline instead of being picked for their size, image fields that ask for alternative text where it is needed, and layouts an editor cannot accidentally reflow into an unreadable order. Where a pattern has accessibility requirements an editor cannot see (a minimum contrast, a required label, a caption), the block enforces it rather than documenting it.
The result is narrower than a page builder, deliberately. An editor gives up the ability to place anything anywhere, and gets a system where the accessible option is the default one and the inaccessible option mostly is not available.
Accessibility in your requirements?
Tell us which standard applies and what the site has to do. We will tell you what it takes to meet it, what falls outside the website, and what it costs, before you commit to the whole project.
Where accessibility sits in the build
Requirements
The standard, the level and the scope are written down, including which third-party services and document types are in or out. If the project is a tender response, this is taken from the tender rather than assumed.
Design
Contrast, focus states, target sizes and error states are decided in the palette and the component set, while changing them is still free.
Build
Semantic markup and keyboard behaviour as the components are written, not as a pass afterwards. Interactive components built once and reused.
Content
Alternative text, heading structure and link text handled during content entry or migration, with the editorial rules built into the blocks.
Testing
Automated checks for what they can catch, then manual keyboard and screen reader testing for the majority they cannot. Findings are fixed, not just listed.
Handover
Editor guidance written for the people who will actually use it, plus a record of what was tested and what is known not to conform.
What you receive
A statement of what was built to
Which standard, which level, and which parts of the site it covers, in writing, at a level of detail a procurement reviewer can use.
A record of testing
What was tested, how, and with what. Automated tooling and manual keyboard and screen reader testing are reported separately, because they answer different questions.
A list of known exceptions
Third-party embeds, legacy documents and anything else that does not conform, stated plainly with what it would take to resolve. A short honest list is worth more than a clean claim nobody can verify.
Editor guidance
The rules the content team needs, specific to the blocks they have, rather than a general introduction to WCAG.
What we do not claim
We are a development studio, not a certification body. We build to a named standard, we test what we build, and we document both. But our own testing is not a third-party audit, and we do not present it as one. Where a project needs independent certification or a formal audit, that is a separate engagement with an accessibility auditor, and we will say so rather than absorb it into a quote.
We can prepare the technical information an Accessibility Conformance Report or a VPAT-style response requires, based on what was built and what was tested. We will not complete one with claims the build does not support.
We also do not install accessibility overlay widgets. They do not make a non-conformant site conformant, they are frequently detected and rejected in evaluations, and they add a layer of JavaScript between users and content that assistive technology users broadly report as making things worse. If accessibility is a requirement, the fix belongs in the site.
Frequently asked questions
-
Which accessibility standard do you build to?
WCAG 2.1 level AA as the default, and WCAG 2.2 level AA where a project or a tender specifies it. Which standard applies is settled in writing at the requirements stage, because “accessible” without a version and a level cannot be tested against at the end.
-
Can you make an existing WordPress site accessible?
Usually yes, and how far it goes depends on the build underneath. Structural problems in the theme and in hand-rolled interactive components are the expensive ones; colour, contrast, labels and alternative text are generally straightforward. We start by testing what is there and separating what can be fixed in place from what needs rebuilding, so the decision is made on real numbers.
-
Do you provide a VPAT or an Accessibility Conformance Report?
We prepare the technical information such a report needs: what was built to, what was tested, how, and what is known not to conform. We are not a certification body, and our own testing is not an independent audit. Where a project requires formal third-party certification we will say so and work alongside the auditor.
-
Are accessibility overlays or widgets enough?
No. An overlay does not make a non-conformant site conformant, it is routinely identified and discounted in formal evaluations, and assistive technology users widely report that it makes sites harder to use rather than easier. If accessibility is a requirement, it belongs in the build.
-
Do you test with screen readers or only with automated tools?
Both, and they are reported separately. Automated tooling reliably catches a minority of issues (missing alternative text, some contrast failures, some structural problems) and is useful as a first pass. Keyboard operation, focus order, meaningful alternative text, and whether a component is actually usable are manual tests.
-
How do you keep the site accessible after launch?
By constraining the editor rather than relying on training. Blocks carry their own structure, headings follow the document outline, and images ask for alternative text where it is needed. Editors get a narrower set of choices in exchange for the accessible option being the default one.