A UK firm can publish a careful page and still ship the same accessibility faults as the rest of the web, because those faults are built into colours, components and content habits. WebAIM's latest look at the top million homepages shows how rarely a rendered page gets the basics right. The useful response is not a one-off audit the week before launch. It is a design system that makes the accessible choice the ordinary one.
The study is an automated reading of public homepages, not a full WCAG assessment of every UK business site. It is still a fair picture of what visitors meet. Low contrast, images without a description, and forms that do not say what a field is for are not edge cases. They are the default.
What the 2026 WebAIM Million recorded
In the 2026 WebAIM Million study, WebAIM analysed the homepages of the top one million websites and found detectable WCAG 2 failures on 95.9% of them. The average was 56.1 errors per homepage, from automated evaluation of the rendered pages. Low-contrast text was the most common detected issue, on 83.9% of homepages. Missing alternative text appeared on 53.1%. Missing labels for form inputs appeared on 51%. Empty links and buttons were common as well.
Those percentages are detection rates, not a ranking of legal risk, and they come from automation. They still point at work a team can specify. Text that people can read. Images that say something when the picture does not load or cannot be seen. Form fields with a visible, programmatic label. Controls that have a name, so a link or a button is not an empty clickable shape. WCAG is the reference for what "enough" means, and the W3C Web Accessibility Initiative is where the supporting guidance lives. An updated French text of WCAG 2.1 and 2.2, covered in the September 2026 W3C translation update, matters when a UK team also ships a French site.
Put the fix in the component, not in a reminder
Design systems stop these issues returning on every new page. If the approved text colours already meet contrast, a marketing page has to go out of its way to fail. If focus styles are part of every interactive component, keyboard users can see where they are without a developer remembering a CSS outline on Friday. If the form components require a label, an unlabelled input does not sneak into a campaign landing page. If the image component asks whether the picture is meaningful, alternative text becomes a content decision rather than a blank attribute.
Reusable components earn their place when the accessible behaviour is easier than the inaccessible one. A button component with a required name is harder to misuse than a clickable div copied from an old page. A colour token named for text on a light background is harder to misuse than a hex code pasted from a slide. This is design work and engineering work together. A library that looks consistent and fails contrast has only done half the job.
- Set text and background pairs that meet contrast, and use those tokens by default.
- Show a visible focus style on links, buttons and form fields.
- Build form fields so a label is part of the component, not an optional extra.
- Decide, for each image, whether it needs a description or should be ignored by assistive technology.
- Give every link and button a name that still makes sense out of context.
Automation finds the common faults and misses the rest
Automated tools are good at the issues WebAIM counted. They are not a complete accessibility review. WebAIM notes that its automated analysis cannot detect every WCAG failure. A page with no detected errors should not be treated as accessible. Manual checks still matter: can someone complete the task with a keyboard, in a sensible order, without a trap? Does the page make sense with a screen reader? Do people with disabilities, using the site for a real task, hit barriers the scanner never named?
A UK team can run the automated check on every build and still schedule the manual pass before a release. The scanner will catch the grey text and the missing label. It will not tell you that the error message is only a colour change, or that the booking flow cannot be finished without a mouse. Both layers belong in quality assurance, next to the visual check and the content review.
Treat it as part of publishing
Accessibility holds up when it is part of the design system, the way content is published, and the release checks. A launch-week checklist finds the mistakes already baked into ten templates. A default that is accessible prevents the eleventh. Teams that do this reduce the barriers that show up in the WebAIM numbers, and they make the site clearer for a wider group of customers, including people who are not using assistive technology but are tired, on a phone, or in bright sunlight.
The legal and commercial reasons for a UK organisation are real, and they are not a substitute for the practical ones. A form that 51% of major homepages fail to label is a form some of your customers cannot complete. That is lost enquiries, not only a compliance line.
Make the accessible path the normal path
UI and UX design is where contrast, focus, labels and reading order should be decided, before a page is built ten times. Web development is where those decisions become components that the next page has to use. A design that only exists in a file will not change the homepage WebAIM would scan.
Web Works Rise is a UK-led team in Birmingham, with delivery from a development hub in Tunisia. If a site keeps failing the same contrast, label and keyboard checks, talk to the team about putting the fix in the design system rather than in another round of page-by-page repairs.