Accessibility Is a Design Decision, Not a Test Somebody Runs at the End
Screens, flows and a clickable prototype you can sign off before anybody writes production code — drawn from the start to meet WCAG 2.2 AA, because for a growing number of UK buyers that is now a condition of the contract rather than a nice-to-have.
An Audit at the End Only Tells You What You Cannot Afford to Fix
The usual sequence is: design the interface, build the interface, commission an accessibility audit a fortnight before launch, receive a document with sixty findings, fix the cheap ones and write the rest into a remediation plan nobody has budget for. Everyone involved has done their job and the outcome is still poor, because the decisions that caused most of the findings were made in the first week of design.
Reversing that costs almost nothing. Contrast is chosen when the palette is chosen. Target sizes are set when the components are drawn. Focus order follows from a sensible layout. Alternatives to dragging are designed alongside the drag. Done this way, an audit at the end confirms what you already know instead of pricing a rescue. That is the whole argument, and it is a commercial one rather than a moral one.
Where design sits in the processWhat the Standard Actually Asks You to Draw
The specification is written for auditors. Translated into design decisions it is considerably less intimidating, and most of it is simply careful work.
| Requirement | What it means when you are drawing the screen | Who it helps most |
|---|---|---|
| Contrast | Body text at a measured ratio against its actual background, and interface components such as button borders and input outlines held to their own threshold. Measured, not judged by eye. | Anyone with reduced vision, and every user outdoors in daylight |
| Text resizing and reflow | The layout has to survive enlarged text and a narrow viewport without clipping, overlapping or hiding content. That rules out fixed-height boxes around text. | Older users, and anybody whose phone is set to large type |
| Target size | Interactive elements at or above a minimum size, or spaced sufficiently. In practice it removes tiny icon-only buttons crowded into a toolbar. | Anyone with a tremor, gloved field staff, most people on a train |
| Focus visible and not obscured | Keyboard focus must be clearly indicated and must not be hidden behind a sticky header, a cookie banner or a floating chat widget. | Keyboard and switch users, and power users generally |
| Dragging alternatives | Anything achieved by dragging needs a non-dragging route as well — a menu, a pair of buttons, a text field. | Users with limited dexterity and anyone on a poor touchscreen |
| Consistent help | The route to help or contact appears in the same place on every screen rather than migrating around the interface. | Users with cognitive differences, and confused users of every kind |
| Redundant entry | Do not ask for the same information twice in one journey. Carry it forward or offer it for selection. | Everyone, particularly on long forms and applications |
| Accessible authentication | No cognitive puzzle as the only way in. Password managers must be able to paste, and there should be an alternative to remembering or transcribing a code. | Users with memory or dyslexia-related difficulties |
| Not colour alone | Status, errors and required fields carry an icon, a label or text as well as a colour. | Colour-blind users, roughly one in twelve men |
A summary rather than the specification. We work to the published guidance and flag where a requirement affects a decision you are about to make, so the trade-off is visible while it is still cheap.
Selling to Councils, the NHS or Universities Makes This a Contract Term
The UK public sector is one of the largest software buyers in the country, and accessibility arrives in its procurement questionnaires as a pass or fail question rather than a discussion point.
The Regulations Themselves
The public sector accessibility regulations require websites and mobile applications provided by public bodies to meet the accessible standard and to publish an accessibility statement. If you are supplying a council, an NHS trust, a university or a housing association, their obligation becomes your specification through the contract.
The Accessibility Statement
A published page describing how the service meets the standard, listing what does not yet comply, explaining why, and giving a date for each item. Buyers read it, and an honest statement with a credible plan is treated far better than a vague claim of full compliance that the first test disproves.
The Equality Act Behind Everything
Outside the public sector, the Equality Act 2010 still requires service providers to make reasonable adjustments. It sets no technical standard, which is precisely why WCAG is used as the working benchmark — it is the only widely accepted way to demonstrate that the question was taken seriously.
A caution worth stating plainly: we are designers and engineers rather than legal advisers or certified auditors. What we do is design and build to the published criteria, test with screen readers, keyboard and enlarged text, document the decisions, and draft the accessibility statement for your team to review and publish. Where a product carries real risk or a buyer expects independent evidence, we will recommend a specialist audit rather than imply that our own testing substitutes for one.
One Complete Journey, Drawn Before Any Screen Is Styled
A pile of attractive screens is not a product. The flow is where the awkward questions live, and answering them on a diagram is a great deal cheaper than answering them in code.
Drawing the flow is also where the questions that only the client can answer surface: who approves this, what happens at month end, and what the person on the phone tells a customer when it goes wrong.
Six Conditions Every Interface Has to Handle
Specifications describe the screen when everything is working. Users spend a surprising amount of time in the other states, and if they are not designed, somebody improvises them during build.
Nothing Here Yet
The first screen a new user sees, and the one most likely to lose them. It should explain what will appear here and give a single obvious action, not present an empty table with column headings.
Still Working
A skeleton of the layout rather than a spinner in a void, so the page does not jump when content lands. For anything genuinely slow, say what is happening and roughly how long, and announce it to a screen reader rather than leaving silence.
Something Went Wrong
What failed, whether their data survived, and what to do now. Never a code alone. Never colour as the only signal. The user typed something, so the error goes next to the thing they typed, not in a banner at the top they have already scrolled past.
Far Too Much of It
Design the list at four hundred rows, not four. That is where sorting, filtering, pagination and search stop being optional, and where a layout that looked elegant in the mockup starts to fall apart.
No Connection
Especially on mobile. What still works offline, what is queued, and how the user knows their work is safe. A silent failure that loses twenty minutes of a site survey is the kind of thing people never forgive.
Not Allowed to See This
Different roles see different things, and the difference has to be designed rather than discovered. A greyed-out button with no explanation generates a support call; a clear line about who can do this and how to request it does not.
What You Are Agreeing to When You Approve the Prototype
The prototype is a clickable version you can open on your own phone and walk through. Sign-off is the gate between design and build, so it is worth being exact about what it does and does not settle.
The Screens, the Flow and the Words
Which screens exist, what is on each, the order they come in, what every button does, and the actual copy including error messages and empty states. Also the contrast, target sizes and focus order that carry the accessibility commitments. This is the thing being built and the thing the fixed price refers to.
Motion, Real Data and Edge Content
Transitions and micro-interactions get refined in build, because they have to be felt on a device rather than approximated in a prototype. Real data always contains longer names and stranger values than sample content, so some layouts get adjusted. None of this changes the scope or the number.
Swaps of Roughly Equal Size
If something looks wrong once it is real, you can swap a designed feature for another of similar size at no cost, or price an addition in writing and decide. What we avoid is silent drift, where three small changes are absorbed and the fourth one causes an awkward conversation about the date.
What the Prototype Is Not
It is not the app. It has no database, no real accounts, no permissions, no payments and no performance characteristics. A prototype can appear to do something a real build will take three weeks to support, so we mark those areas clearly rather than letting a convincing demonstration set an expectation the budget cannot meet.
Before sign-off we put the prototype in front of five or six people who resemble the real users — ideally your own staff or customers rather than your senior team — and watch without helping. It reliably finds two or three things nobody in the project had noticed. Comments go on the screens themselves rather than into an email thread, so every decision stays attached to the thing it is about.
Why a Component Library Pays for Itself in Year Two
Not an expensive artefact for its own sake. A modest, well-named set of components is what stops the eleventh screen looking like a different product from the first.
Named Values, Not Loose Hex Codes
A colour called danger rather than a code somebody pasted. Change the value once and every screen follows. It is also how an accessible palette survives contact with a new designer in eighteen months.
Every State Drawn
Default, hover, pressed, focused, disabled, loading, error. The focused state in particular, because that is the one that decides whether a keyboard user can see where they are and it is the one most often forgotten.
The Same Components in the Codebase
The same components exist in the codebase with the same names, so a design change is a code change in one file rather than a hunt across thirty screens. Without this a design system quietly becomes a document nobody opens.
As Small as the Product Allows
A fifteen-screen app needs a component library, not a design language with a governance model. We build the smallest system the product actually uses and extend it when a real need appears, rather than producing a handsome document and a bill.
What Has to Travel From Design Into Development
Whether the developers are ours or yours, the same things have to cross the gap. Where they do not, engineers guess, and guessing is where consistency and accessibility both leak away.
A Live File, Not a Folder of Exports
The live design file with real layers, components and tokens — not a folder of exported images. Developers need to read measurements, colours and type off it themselves rather than asking somebody each time.
Behaviour Written Down
What each screen does at narrow and wide widths, which elements wrap and which stay put, what a table does on a phone, and what happens at very large text settings. Responsive intent is a decision, not something to be inferred from one mockup.
Accessibility Notes Attached
Focus order, screen reader labels for anything that is not plain text, which headings are which level, keyboard alternatives to gestures, and the measured contrast ratios. Attached to the screens so an engineer does not have to reconstruct the intent.
Final Copy and a Reachable Designer
Real words rather than placeholder text, including error messages, and assets exported at every density. Then the designer stays available through build to answer the questions that only arise once something is running on a device.
If You Already Have a Designer, or a Brand Book
A fair number of clients arrive with something already. We would rather use it than charge you to reproduce it, and we will say plainly where it needs work before it can be built from.
You Have Finished Designs
We start with a short paid design review rather than a quote, because designs from a visual designer are frequently beautiful and incomplete: no error states, no empty states, one screen width, contrast that has never been measured, and no indication of what happens with two hundred records. The review lists what is missing, what will fail an accessibility check, and what it costs to complete. Then you decide whether we finish them, your designer does, or we build as-is with the gaps recorded.
You Have a Designer We Work Alongside
This works well when the boundary is explicit. Your designer owns the visual language and the brand; we own the interaction patterns, the states and the accessibility criteria, and we agree a component set jointly at the start so two people are not drawing the same button differently. Comments go on the screens rather than through a project manager. What does not work is a designer who is unavailable during build, because design questions do not stop at handover.
If all you have is brand guidelines
Very common, and genuinely useful as a starting point. Guidelines written for print and marketing usually need translating before they can drive an interface: a palette needs interface-safe variants that meet contrast, a typeface needs a scale that behaves under enlarged text, and a logo needs an icon treatment that reads at a small size. We do that translation with your marketing team, document the result as named tokens, and hand it back to you as an extension of the brand rather than a departure from it. Where a brand colour genuinely cannot meet contrast for small text, we will tell you which criteria fail and let you decide knowingly rather than quietly.
Design also sells on its own. If you want screens and a clickable prototype to raise money, test an idea or brief another team, we will do the design phase and stop there, and you keep every file. It is a normal way to start, and it pairs well with MVP development once the direction is settled.
Design Questions UK Clients Ask
Does WCAG 2.2 AA apply to us if we are a private company?
The public sector accessibility regulations bind public bodies rather than private ones, so strictly they do not apply to you directly. Two things usually make that academic. The Equality Act 2010 requires reasonable adjustments from service providers generally, and an interface that cannot be used with a screen reader or at enlarged text is hard to defend against that duty. Second, if any of your customers are public bodies, the obligation arrives in the contract through their procurement process. Our position is that designing to WCAG 2.2 AA costs very little when it is done from the wireframes and a great deal when it is retrofitted, so we do it by default and tell you which criteria a given decision affects.
We are bidding for an NHS contract. What will we need to show?
Expect to be asked for an accessibility statement describing how the service meets WCAG 2.2 AA, an honest list of any parts that do not yet comply with a plan and a date for each, and evidence that real testing happened rather than only an automated scan. Health buyers frequently also want to see how clinical safety, information governance and data residency have been handled, and those questions arrive alongside the accessibility ones in the same questionnaire. We produce the design-side evidence as part of the project: the contrast and target-size decisions, the keyboard and screen reader test notes, and the statement draft for your team to own and publish.
Can accessibility be added after launch if the budget is tight now?
Some of it, expensively, and some of it not without redrawing the interface. Colour contrast, text sizing, focus indicators and labelling can be corrected later but touch every screen, so the work is broad and dull rather than deep. The expensive category is structural: a navigation pattern that cannot be operated by keyboard, a flow that depends on dragging with no alternative, a custom control with no accessible equivalent. Those get rebuilt rather than adjusted. Getting the structural decisions right in design is close to free, so if the budget is genuinely tight the answer is to build fewer screens accessibly rather than more screens badly.
Our brand colours fail the contrast requirement. What happens then?
It happens on most projects and it is resolvable without abandoning your brand. Usually the failing pairing is a mid-tone brand colour used for small text or for a button label, and the fix is an adjusted shade reserved for interface use while the original colour continues on large headings, backgrounds and marketing. We take this to your marketing team during design with the measured ratios attached rather than an opinion, and we document the result as a named token so nobody reverts it six months later. If your brand guidelines genuinely cannot flex, we will tell you which criteria will fail and let you take that decision knowingly.
Do you test designs with people who actually use assistive technology?
We test with screen readers, keyboard-only operation, enlarged text and reduced motion as standard during design and build, and we are clear that this is not the same as testing with disabled users. Automated tools catch perhaps a third of the real problems and the rest are judgement calls about whether an announcement makes sense in context. Where the product carries genuine risk or a public sector buyer expects it, we recommend commissioning a specialist audit or a user testing session with people who use these tools daily, and we will design around the findings. We would rather recommend that than imply an expertise we do not have.
Who owns the design files when the project finishes?
You do, and it is worth checking that your other suppliers say the same. The design file lives in your own workspace rather than ours, with our designers invited to it, so nothing has to be handed over at the end because it was never in our custody. That includes the editable source, the component library, the exported assets and the prototype links. Intellectual property in the designs transfers to you on final payment along with the code. If we stop working together you keep the lot and we remove our access, with nothing held back as leverage.
Before Design, and Straight After It
Mobile App Development
Including the accessibility expectations that now arrive with public sector and enterprise buyers.
Learn moreWeb Application Development
Portals and internal tools, where keyboard operation and screen reader support matter most of all.
Learn morePricing
How a design phase is quoted in sterling, and how it fits inside a fixed-price build.
Learn moreSee the Product Before You Pay to Build It
Tell us who has to use it and what standard you are being held to. You get a scope for the design phase and a sterling range excluding VAT within two working days.