The accessibility check that skips half the problem

WebAIM scanned the home pages of the top million websites in February 2026 and counted 66.6 million images. On 16.2% of them the alt attribute was simply absent, the short written description a screen reader announces in place of a picture. Of the images that did carry one, another 10.8% said nothing worth hearing: alt="image", a filename, or the same sentence as the picture beside it. More than one in four images on the most visited pages of the web describe nothing, and the checks that certify accessibility only look for the half that is blank.

So if you have ever accepted a green accessibility score from an agency, a website builder or an automated check in your deployment pipeline, what you bought was a presence test. It confirms a field was filled in. It was never built to tell you a person can use the page.

The checkers skip quality on purpose

On 24 August 2026 GitHub's accessibility team published the reasoning behind an alt text plugin it built for its own scanner. The interesting part is what it refuses to check. "Most alt text checkers test whether an accessible name for an image exists, not whether the provided alt text says anything useful about the associated image," the authors write, "and that's a deliberate design choice: a quality-oriented rule with false positives is a rule teams switch off."

So alt="IMG_2847.png" passes. So does the same alt="3/5 stars" repeated on five star icons in a row. GitHub's vague-alt rule fires only on an exact match against a curated list of words that carry no information, so it misses plenty of bad descriptions, and the team says why it took that trade: "a reliable checker that developers enable beats one that gets switched off."

Our read is that this is the shape of every automated quality gate, not a quirk of accessibility tooling. A gate reports what was cheap to be certain about. Everything expensive to judge falls outside the score, which then gets treated as the whole thing.

The right description depends on where the image sits

Alt text is not a property of a picture. The W3C alt decision tree branches on placement: if the image is the only content of a link, the description names where the link goes, not what the photo shows. If the surrounding text already says it, the correct answer is an empty alt, the author stating on purpose that the image is decorative. GitHub excludes empty alt from its scan, since flagging it would punish the behaviour you want.

The same photograph of a person smiling can be right on a generic banner and wrong under a heading that names someone. Nothing in the code of the image tells you which situation you are in, which is why the check resists automation. The answer lives in the sentence next to the picture.

GitHub's repetition rule hit the same wall from the other side. Its first version flagged images sharing a description in document order, which would catch a header logo and a footer logo that sit next to each other in the code and nowhere near each other on screen. The rule now measures the gap between rendered boxes. "What matters is where images land on screen, not where they sit in the markup."

What this blog does, since we are the example

Every cover image on this blog carries the post title as its alt text. Same on the index card, the article header and the related post cards, straight from post.title in the template. It passes every automated check that exists. It is also the exact case WebAIM counts as questionable: alternative text identical to adjacent text. The title is already on screen, in larger type, one line away.

There is nowhere for a real description to go. The template reaches for the title because no other field exists, which makes this a template problem rather than a content one, the boring kind of finding no automated check will surface, because the field is populated and the value is a real sentence.

A model has opinions, and that is the problem

GitHub also shipped an optional rule that sends the image and its surrounding context to a vision model, one that reads images rather than only text. The failure was not misreading. "Our failure modes were rarely the model misreading a picture. They were the model having opinions." Given good alt text, the first version suggested different alt text anyway, "because 'could this be better?' is a question a language model always answers yes to." Every image became a finding and the signal disappeared.

The fix was a fixed decision procedure with explicit anti-nitpick rules, and it ships off by default. GitHub's own summary: "Every finding is a prompt for human attention, not a verdict." Our position is that this is the honest shape and rarely the one that gets sold, because a verdict demos better than a queue of things a person still has to read. It is the same gap we wrote about between an AI sparkle icon and an actual disclosure: the artefact exists and does not assert what people assume.

What to ask for instead

Stop asking whether the site passes. Ask who wrote the image descriptions, and against what. The average home page now carries 66.6 images, and each one is an editorial decision no scanner reads.

WebAIM says as much in its own methodology, where it notes that no automated tool detects every conformance failure: "Absence of detected errors does not indicate that a page is accessible or conformant." WebAIM sells accessibility testing and WAVE is its own engine, so that is a vendor arguing against its own scoreboard.

The number we will be watching is the one that moved the wrong way. Problematic images kept falling as a share of the total, but 95.9% of home pages had detectable failures against WCAG, the international accessibility standard, in 2026, up from 94.8% in 2025, reversing six years of small improvements. The pictures got better while the pages got worse. What we expect the next report to settle is whether alt text keeps improving once a model writes the first draft, or stops, because a fluent and confidently wrong sentence passes every check anyone has built.

Sources

• The WebAIM Million, WebAIM, February 2026 data.
• Your alt text passes automated checks. Taarik Ashenafi and Keenan Zhou, GitHub, 24 August 2026.
• An alt Decision Tree, W3C Web Accessibility Initiative.
• Tranco, Le Pochat et al., the ranking the sample is drawn from.