Most accessibility advice arrives as a list of everything that is wrong, which is why most of it gets ignored. The useful question is narrower: what can be fixed on the site I already have, and what genuinely needs rebuilding?
That line is real, and it is not where suppliers usually put it. A great deal of what looks structural is a copy edit or a colour value. A small amount of what looks cosmetic cannot be fixed at all without starting again. This guide sorts the work by the only currency that matters to a business owner — time — and it is honest about which side of the line your site may be on.
An afternoon: fixes that need no developer at all
If you can edit your own pages, you can do all of these today, and between them they remove a large share of the barriers we typically find.
Give every form field a visible label. Not placeholder text inside the box — a real label above it that stays put when someone types. This is the single cheapest fix on the list and it wins you enquiries from people with no disability whatsoever.
Rewrite your link text so it makes sense alone. Replace every "click here", "read more" and "learn more" with the destination: "see our fixed pricing", "read the bathroom case study". Screen-reader users routinely list every link on a page and read that list instead of the page; nine identical "read more" entries tell them nothing.
Write real alt text, and empty alt text. For each image ask: if this disappeared, what would a reader need to be told? That sentence is the alt text. If the answer is "nothing, it's decoration", the alt text should be empty — not missing, empty. And an image of text, like a price list saved as a picture, needs its content typed out on the page.
Fix your headings so they form an outline. Read the headings alone, top to bottom. If they read as a sensible table of contents, they are right. If a heading was chosen because the correct level looked too big, that is a styling problem being solved with structure, and it breaks how screen-reader users navigate.
Put your phone number and email in text. Not only in an image, not only behind an icon. A tappable number in real text is reachable by every visitor and every assistive technology there is.
Take one thing out. An autoplaying carousel, a video that starts by itself, a pop-up that arrives after four seconds. Movement that starts without permission is a barrier for people with vestibular conditions and an irritation for everyone else. Removing something is the fastest accessibility work there is.
A week: fixes that need a developer but not a rebuild
These need someone who can edit the theme or the code, but none of them touch the architecture.
Make the focus ring visible and obvious. Tab through the site. If you cannot always see where you are, the ring has been styled away — a two-line fix, and without it a keyboard-only visitor is navigating blind.
Correct the colours that fail, in the right direction per theme. Split each brand colour into a type value and a fill value, correct the type value against the background it actually lands on, and leave the fill alone. This is the fix behind most contrast failures and it is measured in hours. The detail is in colour, contrast and the ground it lands on.
Stop the page scrolling sideways on a phone. Something is wider than the screen. Finding it takes minutes; fixing it is usually one overflow rule or one image width.
Make horizontally scrolling areas keyboard-reachable. A wide table in a scroller is unreachable by keyboard unless the scrolling region can take focus. One attribute and a name.
Make error messages say what to do. "Invalid input" is not a message. "Please enter a phone number, including the area code" is. Plain words, next to the field, describing the fix rather than the failure.
Add a skip link and check your landmarks. A "skip to main content" link as the first thing on the page, and the page's regions marked up as header, navigation, main and footer, gives screen-reader users the ability to jump straight past your menu. It is a small amount of markup and it changes how the site feels to use.
Check it works at 200% zoom, and at a phone width. Two states, one afternoon, and a lot of layout bugs.
A month, or a phase of work: the deeper items
Captions and transcripts for video and audio. Auto-captions are a starting point and they are not good enough on their own — trade names, product names and place names are exactly what they get wrong.
Documents. A PDF price list or terms document is usually the least accessible thing a small business publishes. The durable fix is to put the content on a web page and keep the PDF as a download, rather than the other way round.
Any custom interactive thing — a booking calendar, a configurator, a filter panel, a chat widget. These need keyboard operation, focus management and correct announcements, and each is its own piece of work. Ours are built and tested this way, which is why we know how long it takes.
Then measure it, and keep measuring it. A site that was accessible in March and has had four content edits since is a site with an unknown status. This is the argument for putting the check in your deployment process rather than in a diary.
What actually needs a rebuild
Being straight about this, because it is the question you are really asking:
- A site built as a single image or canvas, or one where headings, prices and body copy are pictures of text. There is nothing to fix; there is no text.
- A theme whose components cannot be reached by keyboard and cannot be replaced. Some page-builder plugins are structurally closed. When the menu, the tabs or the modal cannot take focus and cannot be swapped out, patching stops being cheaper than replacing.
- A layout that cannot survive 200% zoom because everything is absolutely positioned to a fixed pixel grid.
- A site whose content is only in a system you cannot edit — the enquiry form, the reviews, the service list living inside a third-party embed that you have no control over.
If two or three of those describe your site, the honest advice is to stop paying for patches. Everything above them, though, is genuinely fixable in place — and most sites we look at need the copy edits far more than they need a new build.
About accessibility overlay widgets
You will be offered a script that promises to make any site accessible in one line of code. Our position, stated plainly as opinion and not as law:
An overlay cannot fix markup it does not own. It can offer a visitor bigger text, a different colour scheme or a reading guide — genuinely useful preferences, and worth having. It cannot invent a label for a field that has none, make a table meaningful, reach a control the keyboard cannot reach, or write your alt text. The barriers it leaves in place are the ones that actually stop people, and a widget in the corner does not change what a screen reader reads.
We ship an accessibility preferences panel on every site we build — two text sizes, a dyslexia-friendly reading mode using the British Dyslexia Association's recommendations, text spacing set to the values WCAG's own text-spacing criterion tests with, colour-universal and monochrome modes for colour-vision differences, high contrast, always-underlined links and motion off — and we are careful about what we say it is: a set of preferences, not a compliance layer. The underlying pages have to be right on their own, and ours are measured on every deployment to prove it.
Where to start on Monday morning
- Twenty minutes: unplug the mouse and Tab through your busiest page. Write down everywhere you got stuck or lost.
- Twenty minutes: read your links as a bare list and rewrite the meaningless ones.
- Twenty minutes: open the site on your phone, outdoors, and in the other colour theme.
That hour will produce a better work list than most paid scans, because it is your actual site being used the way people actually use it. Everything on that list is then either an afternoon, a week, or a conversation.
Where Neubor fits
We build websites for local businesses and trades across Stoke-on-Trent and Staffordshire, with fixed prices published on the pricing page and every account in your name. Accessibility is not an add-on line on our quotes: a blocking WCAG 2.2 AA audit and a pixel-level contrast probe run on every deployment of our own site and all seven of our public demonstration sites, in both themes, at phone and desktop widths.
If you want to know which side of the rebuild line your site falls on, get in touch and we will measure it and tell you straight — including when the answer is "you don't need us for most of this".
Kieran Bourne is the founder of Neubor, a Stoke-on-Trent web development and AI studio. Neubor publishes what its accessibility gates measure, including the failures they have found in its own work.