Every year WebAIM scans the homepages of the top million websites and publishes what it finds. The 2026 edition reported that 95.9 percent still fail WCAG 2, with detected errors per page up roughly ten percent year over year, described as the first regression after several years of gradual improvement.<\/p>\n\n\n\n
The number that gets quoted is the 95.9. The number that is actually useful is the concentration: the same small set of failure types has accounted for the overwhelming majority of detected errors, year after year, for as long as the study has run.<\/p>\n\n\n\n
That concentration is the good news buried in a bad statistic. The web is not failing because accessibility is hard. It is failing on six things, all of which live in templates, and all of which a competent frontend developer can fix in a week.<\/p>\n\n\n\n
The most common failure by a wide margin. Body text at 4.5:1 against its background, large text and UI component boundaries at 3:1. That is the whole rule.<\/p>\n\n\n\n
It fails because designers pick greys by feel on a colour accurate laptop in a well lit room, and because placeholder text, disabled states, and footer copy get chosen last and checked never.<\/p>\n\n\n\n
The fix is not to check pages. It is to check tokens. Compute the ratios for every text colour in your palette against every surface it can land on, once, and correct the palette. If your muted grey is 3.7:1 you do not have a page problem, you have one variable that is wrong everywhere.<\/p>\n\n\n\n
\/* before: #6d6d76 on #0f0f0f = 3.74:1, fails AA for body text *\/\n--color-text-muted: #6d6d76;\n\n\/* after: 4.70:1, passes *\/\n--color-text-muted: #7d7d86;<\/code><\/pre>\n\n\n\nOne line, entire site. Watch specifically for text over images, gradients, and video, where the effective background changes per asset. Those need a scrim rather than a palette change.<\/p>\n\n\n\n
2. Missing alternative text on images<\/h2>\n\n\n\n
Second most common, and the one most often fixed badly. An image with no alt attribute causes a screen reader to fall back to announcing the filename, which is how users end up hearing a string of hex characters.<\/p>\n\n\n\n
The rule people miss: decorative images need an empty alt, not a missing one, and not a description.<\/p>\n\n\n\n
<!-- decorative: correctly skipped -->\n<img src=\"divider.svg\" alt=\"\">\n\n<!-- informative: describes purpose, not appearance -->\n<img src=\"chart.png\" alt=\"Revenue grew from 1.2M to 3.4M between 2024 and 2026\">\n\n<!-- functional: describes the action, not the icon -->\n<button><img src=\"trash.svg\" alt=\"Delete item\"><\/button><\/code><\/pre>\n\n\n\nStructurally, make alt a required prop on your image component. Not optional with a default of empty string, required, so that omitting it is a type error and the developer has to make a decision. Most alt text problems are not disagreements about wording, they are the absence of a moment where anyone was forced to think about it.<\/p>\n\n\n\n
3. Empty links<\/h2>\n\n\n\n
A link containing only an icon, only an image without alt, or nothing at all. The screen reader announces link and then the URL, which is useless, and keyboard users tab onto something that gives no indication of where it goes.<\/p>\n\n\n\n
Social icons in the footer are the classic offender. So are logo links, arrow buttons in carousels, and card wrappers where the whole card is an anchor with the text nested three levels down in a way that produces an empty accessible name.<\/p>\n\n\n\n
<!-- broken -->\n<a href=\"\/x\"><svg>...<\/svg><\/a>\n\n<!-- fixed: visible text hidden from sight but present in the tree -->\n<a href=\"\/x\">\n <svg aria-hidden=\"true\" focusable=\"false\">...<\/svg>\n <span class=\"visually-hidden\">Follow us on X<\/span>\n<\/a><\/code><\/pre>\n\n\n\nUse a clip based visually-hidden utility. Not display none, not visibility hidden, not zero width. Those remove the element from the accessibility tree and you are back where you started.<\/p>\n\n\n\n
4. Missing form input labels<\/h2>\n\n\n\n
The failure with the highest real world cost, because forms are where transactions happen. An input with no programmatic label is an input a screen reader user cannot identify.<\/p>\n\n\n\n
Placeholder text is not a label. It disappears on focus, it usually fails contrast, and assistive technology support for treating it as a name is inconsistent. Search fields and newsletter signups fail this constantly because the design called for a clean box with no visible label.<\/p>\n\n\n\n
<!-- visible label, best option -->\n<label for=\"email\">Email address<\/label>\n<input id=\"email\" type=\"email\" autocomplete=\"email\">\n\n<!-- design forbids a visible label -->\n<label for=\"q\" class=\"visually-hidden\">Search products<\/label>\n<input id=\"q\" type=\"search\" placeholder=\"Search\"><\/code><\/pre>\n\n\n\nWhile you are in there, add autocomplete tokens. They are a separate WCAG criterion and they measurably reduce errors for everyone.<\/p>\n\n\n\n
5. Empty buttons<\/h2>\n\n\n\n
Same shape as empty links, different consequence. Icon only buttons with no accessible name: hamburger menus, close buttons on modals, quantity steppers, filter toggles.<\/p>\n\n\n\n
<button aria-label=\"Close dialog\">\n <svg aria-hidden=\"true\" focusable=\"false\">...<\/svg>\n<\/button><\/code><\/pre>\n\n\n\nOne caution on aria-label: it overrides any visible text inside the element. If a button reads Add to cart on screen and carries an aria-label of Add, a speech input user saying the visible words will not activate it. Only reach for aria-label when there is no visible text at all.<\/p>\n\n\n\n
6. Missing document language<\/h2>\n\n\n\n
The cheapest fix in the entire list and it still appears on a large fraction of homepages.<\/p>\n\n\n\n
<html lang=\"en\"><\/code><\/pre>\n\n\n\nWithout it, a screen reader reads your content using whatever voice and pronunciation rules it defaults to. Spanish text read by an English synthesiser is not slightly awkward, it is often incomprehensible.<\/p>\n\n\n\n
If you run multiple locales, verify that the attribute actually changes per locale rather than being hardcoded in a shared shell. And mark inline language changes where a section genuinely switches language, using lang on the containing element.<\/p>\n\n\n\n
Doing all six in one pass<\/h2>\n\n\n\n
These are template concerns, not content concerns, which is what makes them tractable. A realistic sequence:<\/p>\n\n\n\n