This is not a listicle. Every fault below is one we have found and measured — most of them on our own work first — with the count where we have one. They repeat across trades, across builders, and across price brackets, because they all come from the same few decisions.
Each one comes with a two-minute check you can run yourself, and an honest note on how bad it is. Work down the list in order: it is roughly sorted by how many people it stops.
1. A brand colour used as small type
What it is. The brand accent — the teal, the gold, the orange on the logo — gets used for section eyebrows, service labels and captions at 10 to 14 pixels. Brand colours are chosen to look good as a large shape. Almost none of them are legible as small text.
How we know. When we first put our seven demonstration sites under a blocking WCAG audit, 81 failing elements across five of the seven came back, and every one but a single case was contrast. They collapsed to one cause: a brand colour used as type. The worst measured 2.55∶1, where small text owes 4.5∶1 — barely half. On this website the same shape produced 306 real failures, including 48-pixel numerals in a bright bronze that the design system's own notes said, twice, was a fill colour and never type.
Two-minute check. Screenshot a page and open it in any image editor. Convert to greyscale. Any text that fades into its background has failed, and you have just done the test the way a colour-blind visitor does it by default.
How bad. Bad, and universal. This is the single most common real failure we see.
2. A theme nobody has ever tested
What it is. The site has a light mode and a dark mode — or inherits one from the visitor's operating system — and only one of them was ever looked at.
How we know. Our own site. A blocking accessibility gate had run on every deployment for twenty releases and been green every time. It had only ever run in the default theme. When we finally measured the other one, it returned 302 findings. The cause was a single dark-palette typography class applied without a condition, so in light mode every heading and every bold term rendered white on near-white.
The worst of it was on our privacy policy, where the invisible words included the "not" in "is not used to make any automated decision about you". A negation the reader cannot see inverts the sentence.
Two-minute check. Switch your operating system between light and dark mode, then reload your site in both. If your site offers its own toggle, use that too — and check your legal pages, which is where nobody ever looks.
How bad. Severe when present, and completely invisible until someone enters the other mode. The light theme is often the one a low-vision or dyslexic reader deliberately chooses.
3. Words that vanish over a photograph, a gradient or a glass panel
What it is. White text over a hero image. A caption over a gradient. A price over a frosted-glass card. It reads perfectly on the designer's monitor and disappears wherever the picture happens to be pale.
How we know. Automated tools will not judge these at all. On a run our demo audit reports as having no detectable failures, it also reports 1,540 elements as "needs review" — mostly text whose background it cannot resolve into a single colour. That is not a pass; it is the tool declining to answer.
Two-minute check. Look at your hero on a phone, outdoors, in daylight. Then look at the widest browser window you have, where the image crops differently and the text may land somewhere else entirely.
How bad. Moderate to severe, and the least likely fault to be reported by any scanner you buy.
4. A page that scrolls sideways on a phone
What it is. Something on the page is wider than the screen — a table, a fixed-width image, a padded container, an overflowing heading — so the whole page can be dragged left and right.
How we know. Our own site did it by 187 pixels, and the person who found it was the business owner looking at his phone, not any of the gates we had built. We now measure page width against viewport width at two widths on every deployment, because it turned out no test we owned could see it.
Two-minute check. On your phone, swipe left on the body of the page. If it moves, you have it.
How bad. Genuinely bad for anyone with a motor impairment or using magnification, and it makes a site feel broken to everyone else.
5. Something reachable only by dragging
What it is. A wide table or card row inside a horizontal scroller. A mouse user drags it. A touch user swipes it. Someone using a keyboard cannot reach the far end at all, because nothing inside the scrolling box can take focus.
How we know. One of our own demonstration sites had a reclamation ledger — a wide table in a scroller — where at phone width the last column was reachable only by dragging. Our audit caught it as the one non-contrast finding among the 81, and the fix was to make the scrolling region focusable and give it a name.
Two-minute check. Tab through the page and try to reach the right-hand end of every horizontally scrolling thing on it.
How bad. A complete block for keyboard-only users on whatever information is out there.
6. A form field whose only label is placeholder text
What it is. The grey word inside the box — "Name", "Email", "How can we help?" — with no actual label. It disappears the moment the visitor types, so anyone interrupted mid-form has no way to know what they were filling in, and a screen reader may announce the field as nothing at all.
Two-minute check. Click into each field and type one character. Can you still tell what the field is for? Then Tab through the form with your eyes on the labels rather than the boxes.
How bad. High, and it costs you enquiries from people with no disability at all. This one is also cheap to fix: a visible label above every field, permanently.
7. Link and button text that means nothing on its own
What it is. "Click here." "Read more." "Learn more." Five identical "Find out more" links on one page. Icon-only buttons — a magnifier, a hamburger, a phone — with no accessible name.
Why it matters. Screen-reader users routinely pull up a list of every link on the page and read that instead of the page. A list of nine "read more" entries tells them nothing. It is the same reason people who scan visually read only the first two or three words of each link.
Two-minute check. Write out every link on your busiest page as a bare list, with no surrounding sentences. Can you tell where each one goes?
How bad. Moderate, universal, and the cheapest thing on this list to fix — it is a copy edit, not a build.
8. Headings picked for their size, and images with the wrong alt text
What it is. Two faults with one cause: markup chosen for how it looks rather than what it means. A subheading dropped two heading levels because the correct one looked too big, so the page's outline is nonsense. A decorative flourish given the alt text "image1.jpg". A photograph of your team described as "team photo" when the useful description was "the four of us outside the workshop with the van". An image of text — a price list saved as a JPEG — with nothing to read.
Two-minute check. Read your headings alone, in order, top to bottom. Do they form a sensible table of contents? Then ask of each image: if this vanished, what would a reader need to be told? If the answer is nothing, its alt text should be empty — not missing, empty.
How bad. Moderate, and it compounds: headings are how screen-reader users navigate a page at all.
The pattern behind all eight
Six of these eight came from a decision that was reasonable in isolation — use the brand colour, use the dark palette, put the text on the photo, keep the layout tight, use the placeholder, use the smaller heading. None came from carelessness, and none were caught by looking at the source code. They were caught by rendering the page and measuring it, in more than one theme, at more than one width, with the mouse unplugged.
That is the whole method, and it is why we automated it into our build rather than trusting a checklist.
Where Neubor fits
We run a blocking WCAG 2.2 AA audit plus a pixel-level contrast probe on this website and on all seven of our public demonstration sites, at phone and desktop widths, in both themes, on every single deployment. Several of the faults above are on this list because those gates found them in our own work — which is the only reason we can describe them honestly.
If you would like your own site put through the same measurement, get in touch or read what an accessibility audit actually tests first. If you want to start fixing today, accessibility without a rebuild is the practical order to do it in.
Kieran Bourne is the founder of Neubor, a Stoke-on-Trent web development and AI studio. Every count in this guide is from Neubor's own audits, including the ones that found Neubor's own mistakes.