Loading today’s stories
Build1 distinct publisher3 min readPublished
WebAIM's 2026 Million puts missing alt text at 16.2% and useless alt text at another 10.8%. GitHub's new scanner plugin explains the design choice that lets alt="IMG_2847.png" through.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A quality check's strictness budget is not set by the defects it could catch. It is set by how likely a team is to disable it, and GitHub's post says so without hedging: a quality-oriented rule that produces false positives is a rule teams switch off [5]. That is why most alt text checkers only test whether an accessible name exists at all [4].
The plugin's vague-alt rule therefore normalizes the string and matches it against a curated closed list, firing only on exact equality. alt="image" is flagged; alt="image of the login screen with the SSO button highlighted" is not [9]. Taarik Ashenafi, a former engineering intern on GitHub's accessibility team [0], writes that rules this literal miss plenty of bad alt text, and that the miss was preferred to the false positive [10].
The arithmetic behind the summary figure is worth doing yourself. WebAIM's 2026 Million found alt text missing on 16.2% of images across the top million home pages, and among the images that did have alt text, another 10.8% were undescriptive [2][3]. Read literally, that second number applies to the 83.8% that had something, which is 9.05 points of the whole, for a total of 25.25% [11]. GitHub's framing of more than one in four [1] survives on that reading by a quarter of a point. Read 10.8% as a share of all images instead and you get 27%, a gap of 1.75 points across a million pages [12]. No dashboard I have seen distinguishes the two.
The bug worth stealing is in the repetition rule. Version one walked images in document order and flagged any run sharing the same normalized alt, which meant a header logo and a footer logo sitting next to each other in the extracted list got reported as a group that no reader ever encounters as a group [13]. The rule now checks rendered geometry, extending a run only when the gap between two bounding boxes is small relative to the boxes themselves [14]. That reclassifies the defect: duplicate alt is a property of the laid-out page, not of the DOM. Hence Playwright's role-based locator rather than querySelectorAll('img') [15], which also drops anything outside the browser's accessibility tree, including every image carrying alt="" [16]. An empty alt is an author declaring the image decorative, and flagging it would punish the behaviour you are trying to encourage [17].
The transferable part is the line the team drew between what a checker can prove and what it can only suspect [18]. Presence is an objective fact, since the attribute is either there or it is not, while quality is a judgment call that markup alone cannot settle [19]. Sort your own gates that way and the provable side comes out smaller than the backlog you were hoping to close: five string-and-geometry rules on by default, and everything else behind a model call you have to opt into [7].
Ranked by verification strength, evidence, and original report placement.
Taarik Ashenafi is a former software engineering intern on the accessibility team at GitHub, and is the author of the post.
GitHub's post states that more than one in four images on the web's most popular home pages have alt text that is missing, vague, or copied from adjacent images.
WebAIM's 2026 WebAIM Million report found alt text missing on 16.2% of images across the top million home pages.
Among images that did have alt text, another 10.8% provided an undescriptive attribute, such as alt="image", a raw filename, or a description duplicated from a neighbouring image.
Automated tooling reliably flags missing alt text but is not as good at fixing poorly written alt text; most alt text checkers test whether an accessible name for an image exists, not whether it says anything useful.
The post describes this as a deliberate design choice: a quality-oriented rule with false positives is a rule teams switch off.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed first-party design record, no effectiveness data
The mechanism claims are unusually concrete for a vendor post: named rules, the exact-match construction of the vague-alt check, a code snippet for the bounding-box gap test, the Playwright role-based locator scoping, and a disclosed false-positive regression. That is strong evidence about what the tool does. It is weak evidence about how well it works: no precision, recall, coverage, or runtime numbers are given, the gap multiplier is conceded to be untuned judgment, and the population statistics come secondhand from WebAIM with an ambiguous base that leaves the headline 'one in four' unreconciled.
Shipped and documented, uptake unreported
The single adoption fact is the release itself: the plugin exists for the GitHub Accessibility Scanner with defaults on and a model-backed rule opt-in. No installs, repositories scanned, internal rollout, customer, or CI-integration figures appear anywhere in the supplied material, and the WebAIM Million data measures the problem's prevalence on the web, not adoption of this tool.
Slightly understated against its own evidence
The post consistently discounts itself: it concedes that literal rules miss plenty of bad alt text, that the gap multiplier was not derived from anything, that the check fails open when a bounding box is unmeasurable, and that the link-context signal is incomplete. The only stretch is quantitative framing rather than capability: the 'more than one in four' headline rests on two WebAIM percentages whose bases are not reconciled, spanning 25.25% to 27.0% depending on the reading. Net, claims sit marginally below the supplied evidence rather than above it.
First-party vendor post about its own tool
Every claim originates from GitHub's engineering blog describing a GitHub product, authored by a former intern on GitHub's accessibility team, so there is a clear promotional interest in the scanner and in framing existing checkers as insufficient. Mitigating factors are the disclosed author affiliation, the volume of self-critical detail, and the absence of pricing or competitive attack claims. No independent publisher is present to offset the interest.
Single-source, verifiable design, unverified effect
Confidence is moderate on what the plugin does, because the description is specific, internally consistent, and testable against a public tool, and low on the surrounding numbers and on impact, because the cluster has exactly one publisher, the WebAIM statistics are relayed secondhand with an ambiguous base, and no effectiveness or uptake measurement exists to corroborate.
build
Yadda 3's real artifact is not the code, it is the rules the agent could not rewrite1 distinct publisher
build
Context rot at 15 iterations: two toolkits that move the spec into Git1 distinct publisher
build
Partition, not consolidation: what a 43-minute Jenkins queue actually cost1 distinct publisher
product
Half the incident clock goes to search, and telemetry tools cannot read the answer1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 24, 2026