Most writing on the subject explains what the result looks like: stronger contrast, visible focus outlines, alt text. That is correct, and it still helps very little when you are planning a project. Because the difference is not the list of features. It is the order in which decisions are made.
A project planned for accessibility has the same phases as any other — concept, design, build, handover. All that moves is when certain questions get asked. A few travel out of the build and into the concept phase, a few out of remediation and into the design. That shift is the entire difference between a surcharge nobody notices and a retrofitting project.
Why building it in is cheap and retrofitting is expensive
The reason is technical and easy to miss: most of accessibility does not live in how a page looks but in how it is structured. And structure is the one thing that cannot be changed afterwards by adjusting a setting.
A colour value is one line in the design template. You change it once and it takes effect across every page at the same time. A heading, by contrast, that is on the third level only because somebody liked the text size, is not a colour — it is a statement about how the page is put together. Correcting it means changing the template, checking every page that uses it, and reworking the layout, because the new level looks different. The same goes for a button that technically is not one, for a form field whose label merely sits next to it rather than being connected to it, and for an order that is right in the mockup and wrong in the markup.
On top of that comes something that has nothing to do with technology: by the time you are remediating, the design has been signed off. Every structural correction is then no longer a decision but the reversal of one — with discussion, approval, and the entirely fair question of why it was not done that way in the first place. In the concept phase the same question costs ten minutes.
Concept phase: the outline comes before the first mockup
In an ordinary project the outline of a page emerges as a by-product of designing it. In a project planned for accessibility it exists beforehand and in writing. For every page template — home page, service page, blog post, contact page — you set out what the single main heading is and which sections sit beneath it at which level. That is a writing exercise, not a design step, and it takes roughly half an hour per template.
The second point is the one that saves the most money later: every interaction gets its no-mouse counterpart at concept stage. Not as a test item, but as part of the description. If the concept says “hovering reveals the price”, the same sentence has to say what happens on a phone and from the keyboard. If that is not written down, it gets built, signed off, and eventually built again.
- A written heading outline per page template — one main heading, and levels beneath it that reflect the structure rather than the type size
- For every moving or expanding component, one sentence on how it is operated without a mouse and how it closes again
- The order in which the page is traversed, including a skip link to the content — before the layout, because the layout only reflects it afterwards
- A decision about which components genuinely need to be built. Carousels, tabs and dialogs are the most expensive parts of an accessible project, and half of them can be replaced with a list
- For forms: which fields are required, what format is expected and what happens after submission — in the concept, not in the code
These points sound like paperwork, and they are the reason an accessible project does not take longer in the end. Our Standard projects run in two to four weeks, larger ones in four to six. That does not change, because the time simply moves to a different place.
Design phase: decisions that live in colour values and spacing
The design phase contains the decision most often got wrong, and it is got wrong because it is checked at the wrong moment. Contrast is normally measured once the site is finished. By then the colour has long been approved, it is on the business cards and in the logo, and any correction is heard as an attack on the brand.
The right moment to check contrast is the moment the colour is chosen. When we rebuilt our own website in August 2026, this was exactly the situation: our signal colour reads beautifully on a dark background and does not work as body text on white. The answer was not a compromise on the logo but a second, darker value in the palette that applies everywhere colour becomes text. Two values instead of one, settled once, never discussed again.
- From the outset the palette holds, for every brand colour, the variant that works as text on a light background — as a component of the palette, not as an exception
- Meaning is never carried by colour alone: a required field says “required” rather than only wearing a coloured asterisk, an error appears as a sentence rather than only as a red outline, a status has a word or a symbol beside the colour
- The focus outline gets designed. It is a visible brand element like any button — in practice the alternative is not an ugly one, it is none at all
- Text sizes are tested with the longest real text, not with dummy copy. Body text below the size you comfortably read yourself does not improve when your customers are older than you are
- Tap targets are designed as areas, not as lines: a telephone icon in the header needs a target you can hit with a thumb while walking
- States are drawn as well — resting, hover, focus, pressed, disabled. Whatever is not drawn gets invented during the build
Almost all of that effort sits in the palette and in the first draft of a template. After that it does not repeat, because every further page uses the same values.
Build: the structure underneath the layout
During the build this is less about extra work than about choice. A real button already brings everything with it: it is reachable from the keyboard, responds to Enter and the space bar, receives focus, and announces itself as a button. An element rebuilt out of a generic container has to supply the same in four separate steps, any one of which can be forgotten. So the basic rule is not “build more elaborately” but “use the element that already exists”.
- Buttons are buttons and links are links. The difference is not cosmetic: one does something on the page, the other takes you elsewhere, and the two are announced differently and operated differently
- Labels are connected to their field rather than laid out beside it. A side effect for everybody: clicking the label jumps into the field, which doubles the tap target on a phone
- The order in the markup matches the visible order. If the layout pulls a column visually to the top, it belongs at the top of the markup too — otherwise the focus jumps across the page
- Anything that expands reports whether it is open or closed. An accordion that only swaps its icon has no state at all for someone who cannot see the icon
- Dialogs and overlays keep the focus inside, close with Escape, and hand the focus back to wherever they were opened from
- Alt text is written by whoever knows what the image is for. The same photo of a workshop needs different wording in an article about equipment and on a page about the team. That decision belongs to whoever edits the content, not to whoever develops it — it just has to be built into the process, or the file name ends up there instead
The most expensive part in this phase is almost always one that was described in four words in the concept: a carousel, a multi-step filter, a booking calendar. If you want to reduce the cost of an accessible project in one place, this is it — by deciding at concept stage that the component is not needed.
Handover: staying accessible, not just launching accessible
This is where most carefully built websites give back what they had: after handover, you maintain the content yourselves. Twenty blog posts and three new service pages later, heading levels, images and link text are no longer decided by the agency but by whoever has a spare half hour. Without a single page of guidance that reliably goes wrong — and with no ill intent, because none of it is visible inside the editor.
A complete handover therefore includes not only the logins but five rules that fit on one page:
- Headings reflect the structure, not the size you want. A sub-heading does not become a second-level heading because it ought to look bigger
- Every image gets a sentence at upload saying what it shows and why it is there. Purely decorative images deliberately get nothing — the file name is always the worst possible answer
- Prices, opening hours and menus go in as text, never as an image or a scanned PDF. That is also the only version Google can read
- Link text says where it leads. Eight instances of “learn more” on one page is an imposition on anyone skimming
- Colours and text sizes come from the palette. If the editor offers a free colour picker, it is the quickest route back to unreadable text
More effective than any guidance, though, is taking the wrong options away from the editor. WordPress lets you set which heading levels a text block may offer at all and whether a free colour picker exists. What cannot be clicked needs no explaining. You get all the logins and the website belongs to you in any case — the only question is how many traps are left inside it.
Which decisions belong to which phase
The third column is the real answer to whether this is worth it. Not because retrofitting is impossible, but because at almost every point it is a different kind of work from building it in.
| Project phase | What changes | What it costs if deferred |
|---|---|---|
| Concept | The heading outline and keyboard operation are settled in writing before anything is designed | The outline emerges from type sizes. Correcting it means changing templates and layout at the same time |
| Design | Contrast is checked as the colour is chosen; the palette holds a text variant of every brand colour | The colour is approved and in use. Any correction is a brand discussion rather than a design question |
| Design | Focus, states and tap targets are drawn as part of the design | Invented during the build or left out — and later reworked on every template one at a time |
| Build | Existing elements rather than rebuilt ones; labels connected to fields; markup order matching the visible order | Rebuilt components get taken apart and reassembled. That is structural work, not restyling |
| Content | Alt text is written by whoever knows the purpose of the image — as a step in the process, not as clean-up | Hundreds of images get described in hindsight by somebody who does not know why they are there |
| Handover | Five editorial rules on one page, plus an editor that does not offer the wrong options in the first place | The site gradually loses what it had at launch — and nobody notices when it happened |
If you are planning a relaunch anyway, that is the cheapest conceivable moment: you are paying for the concept and design phases regardless. And if you are not planning one, the more honest answer is that a rebuild rarely pays for itself on accessibility alone — whereas the points from the handover list you can apply today, without anybody rebuilding anything.
Common questions about building an accessible website
By taking four decisions earlier than usual: the heading outline before the design, the keyboard operation of every component in the concept rather than in the build, the contrast check as the colours are chosen rather than afterwards, and the alt text written by the person who knows what the image is for. Most of the rest follows on its own, because the structure is right from the beginning.
Usually not noticeably, because the effort only moves: more time in the concept, less in remediation. Our Standard projects stay at two to four weeks, larger ones at four to six. It takes longer only when elaborate components such as carousels, filters or booking calendars are genuinely needed — and those cost time whether they are accessible or not.
Partly, and with varying success. Colours, text sizes and alt text can usually be corrected while the site is running. Everything that sits in the structure — heading levels, rebuilt buttons, form labels, the order you tab through — means work on the templates, and that is why retrofitting regularly costs more than building it in.
Yes, and the platform is rarely the problem. What matters is the theme you choose, the plugins you use and how the editor is set up. A builder-style theme full of ready-made effects often ships components that cannot be operated without a mouse — which is why choosing the theme and the plugins belongs in the concept phase and not in the build.
It restricts three things: very light text colours, invisible focus outlines, and meaning carried by colour alone. Everything else stays open. In practice it feels less like a restriction and more like a grid — much like a fixed type scale, which tends to make drafts better rather than poorer.
For the images loaded during the build, we do — for everything added afterwards we cannot, because we do not know what the image is for. A photo of your team, your workshop or your product is best described by whoever knows why it is there. That is why the rule sits in the handover.
Free consultation
We look at your website up front and show you the biggest levers for more enquiries.
