Our redesign quote doesn't mention accessibility — what does it cost to add, and what should we refuse to pay for?

The same piece of accessibility work can cost nothing or cost a week, and the only variable is when someone raised it. A colour palette that clears contrast is not more expensive to draw than one that fails. It becomes expensive the moment it has been approved, printed on a pitch deck and used in a campaign.

This is why a quote with no accessibility line item is not automatically a bad quote. A studio that decides these things while the design is still being drawn has nothing separate to bill you for. A studio that plans to check at the end has a large invoice coming, and neither of you knows it yet.

So the useful question is not how much accessibility costs. It is: which parts of this are choices someone is making anyway, which parts are genuine build time, and which part is a re-do we could avoid by asking one question at kickoff.

A set of accessibility decisions sit inside work the studio is doing regardless. Someone has to pick a text colour. Someone has to decide how big body copy is, where form labels sit, and what happens visually when you tab onto a button. Every one of those choices gets made in every redesign. The only question is whether it was made with the requirement in mind.

In a build that runs on a design system, these decisions live in tokens and components rather than in pages. Contrast is settled once in the colour tokens. The minimum body size lives in the type scale. The focus ring is designed once in the button and input components, so every page inherits it without anyone thinking about it again. That is the mechanism that makes this bucket free: the decision is made once and reused a few hundred times.

Concretely, the items that belong here are the colour palette checked for contrast before approval, a type scale with real minimum sizes rather than 11px captions, visible focus styles designed into the component set, form labels above fields instead of placeholder text that vanishes when you type, tap and click targets sized in the button component, and heading order that falls out of the page templates rather than being chosen per page.

You are not buying accessibility in this bucket. You are buying attention. It is worth nothing on the quote and a great deal in the build.

Anything interactive that is not a plain link or a native browser control costs real time to make work with a keyboard and a screen reader. Menus that open and trap focus. Modals that need to return you where you came from when they close. Tabs, carousels, filter panels, multi-step forms, custom dropdowns, video players. Icon-only buttons that need a name a screen reader can read out. Async states — a filter applying, a form saving — that need to announce themselves rather than silently changing the page. Error messages that are spoken, not just turned red.

The rule of thumb that surprises most people: this cost scales with the number of distinct interactive components, not with the number of pages. A 40-page site of articles and static content is cheap, because the browser already handles almost all of it. An 8-page site with a booking flow and a filterable product grid is not cheap, because both of those are custom behaviour someone has to build and then test with the mouse unplugged.

So you can estimate this yourself. Go through the brief and count the distinct custom interactive components, ignoring pages entirely. In our projects, each custom one is roughly a day of build-and-test that a native form control or plain link would not have needed. A filter panel with a custom dropdown, a modal and a multi-step enquiry form is about three days of work that a static brochure site simply does not contain. If your quote covers those components but never mentions testing them, that is the gap to ask about.

The retrofit premium is the cost of raising accessibility after sign-off, and it is the single most avoidable expense in this category. It is not the cost of the fix. It is the cost of the re-approval around the fix.

The pattern repeats. A brand palette is signed off with a mid-grey used for secondary text. At QA, that grey fails contrast on white. Now there are two options: change the brand colour, which means going back to whoever owns the brand, or darken the text everywhere, which means new hover, active and disabled states for every component that used it, a fresh design review, a rebuild and a re-test. The pixel change takes an hour. The stakeholder round takes two weeks.

Two more that come up constantly. A hero built on light grey type over photography, where the fix is not a colour tweak but a different hero design. And a navigation pattern that only reveals its submenu on hover, which cannot be operated by keyboard at all, so the nav has to be rebuilt after every page has already been laid out around it.

Same work, different invoice. Decided at kickoff it is free; discovered at QA it is a rebuild plus a re-approval. That is the whole cost story, and it is caused by the accessibility conversation happening in QA instead of at kickoff.

Overlay scripts and accessibility widgets sold as one-line compliance. You add a line of JavaScript, a little icon appears in the corner, and the underlying markup is exactly as broken as it was. They do not fix unlabelled buttons or unreachable menus. Actual screen-reader users are broadly hostile to them, and buying one has not stopped complaints being made. The more useful signal is what proposing one tells you: a studio offering an overlay instead of doing the work is telling you how the rest of the build will go.

A full audit of a site you are about to delete. An audit of the current site produces a detailed document about pages that will not exist in three months. The one exception is a phased migration where the old site stays live for months alongside the new one — then the surviving pages are worth auditing, and only those.

Accessibility priced as a separate optional phase after launch. If it is optional, it will be cut when the launch date slips. It will then come back as bucket-three money. Anything sold as an add-on phase should be argued back into the design and build lines instead.

A small brochure site with no forms beyond a contact form, no custom interactive components and no specific legal obligation can reach a genuinely decent standard from bucket one alone, plus using native HTML controls instead of building your own. Sensible contrast, real text sizes, visible focus, labels above fields, honest heading order, and a plain<form>with browser-native inputs. That is most of the way there and it costs nothing on top of the design work.

Not every reader needs a formal conformance statement or a third-party audit report. If nobody is asking you for one and you have no interactive behaviour beyond a contact form, buying one is buying a document. Spend the money on the copy instead.

Obligations do differ by market and sector, and public-sector bodies and larger commercial organisations generally face harder and more specific requirements than a small private company. We are not the people to tell you where you sit on that; your legal advisor is. What we can tell you is that the practical work is the same either way, and it is cheaper before sign-off than after.

Look inside the design and build lines rather than for a heading called accessibility. Its absence as a heading is not damning. Its absence from any description of testing is. If the quote describes browser testing and responsive checks but never mentions a keyboard or a screen reader, nobody has planned to do it.

Then ask which components are being built from scratch and which are native browser controls. A quote full of bespoke dropdowns, sliders and custom selects is a quote with hidden bucket-two cost, whether or not the word accessibility appears anywhere in it.

Then ask what they test with. A good answer names a keyboard and at least one screen reader. An answer that names only an automated scanner is an answer about the third of problems a scanner can see.

These are ordered so that the first one is the one that saves the most money. Ask them by email so the answers are in writing.

1. At what point in this project do you check colour contrast — before or after we approve the palette?
2. Which of these interactive components are you building from scratch rather than using native browser controls, and what does testing them involve?
3. If something fails accessibility after design sign-off, whose time pays for the rebuild?

Unplug your mouse. Now try to complete the main task on your existing site — buy the thing, book the call, submit the enquiry — using only the Tab, Enter, arrow and Escape keys. Watch one thing above all: can you always see where you are.

If focus disappears into an invisible element, if the navigation cannot be opened at all, if a modal opens and Tab keeps cycling through the page behind it, or if you get stuck and have to reach for the mouse, you have found a bucket-two problem. That is true regardless of what an automated scanner reports, because scanners cannot judge whether a keyboard user can finish a task.

This test predicts most of what an audit would tell you, and it costs you five minutes rather than a fee. Run it before your next call with the studio, and bring the specific place you got stuck.

Being honest about where this leaves us: it is easier for a studio, including this one, to bill accessibility as remediation after launch than to argue for constraints in the middle of the enjoyable part of design. The constraint-first version earns us less and serves you better, which is why it is worth you asking for it rather than waiting to be offered it. Your quote does not need an accessibility line. It needs a studio that has already decided when contrast gets checked.