The reading room · Digna Legi
Your alt text passes automated checks. That doesn’t mean it’s any good.
/100
80–100: high value. 70–79: worth the time. Below 70: below the usual publication threshold.
Evidence-reviewed score based on available publisher text. The evidence is a product-engineering post and cannot establish broad real-world effectiveness beyond the described implementation and tests.
Scores reflect one reader’s profile, not an objective quality rating. Best is a separate personal selection.
How scoring works →This brief · about 3 min with detail
Why read this
Accessibility automation works better when provable string errors and context-dependent judgments about image meaning are treated as different problems.
AI brief · Checked against source text
The main idea
The article argues that accessibility checks should separate what software can prove from what it can only suspect. GitHub’s plugin keeps literal, low-false-positive rules on by default, while model-based quality review is opt-in because image meaning depends on layout, surrounding text, links, captions, and human intent. Better automation does not replace judgment; it routes attention toward images likely to need it.
Go a little deeper
False positives decide adoption
The plugin deliberately favors narrow checks because a noisy quality rule trains developers to ignore or disable it. That leads to an important product distinction: the goal is not to catch every bad alt string, but to preserve trust in findings that run automatically. Exact-match rules miss fluent but poor descriptions, yet they create a stable baseline that teams can keep enabled.
User experience beats document order
Repeated alt text cannot be judged only from the page’s markup. Two identical logo descriptions may look adjacent in extracted document order while appearing far apart on the screen. GitHub’s rule therefore compares bounding boxes and extends a repeated run only when images are visually close, reflecting what a screen reader user would experience as repetitive grouping.
Models need procedure, not taste
The model-backed check initially produced too many findings because it treated improvement as an always-open invitation. The fix was to make it behave more like a reviewer following a decision tree: classify decorative, caption-redundant, functional, or informative cases; avoid nitpicks; and generate structured reasoning before verdict. The mechanism reduces arbitrary preference without making the model authoritative.
External review changes the data problem
Once image content and page context leave the scanner for a model, the check becomes a data-flow system, not merely a lint rule. The article’s practical controls are specific: make the rule opt-in, require credentials, redact URL query and fragment data, omit src and srcset in model-bound markup, and remember that page text may try to steer the model.
A case from the article
The five-star repetition failure
A row of five star-shaped icons with the same alt text can pass a crude existence check but still waste the listener’s attention: the same phrase is heard repeatedly, with no new information after the first item. GitHub’s first duplicate detector overcorrected by using document order, so the improved version used on-screen proximity to distinguish real repetition from unrelated repeated labels elsewhere on the page.
How the case is made
The case is made through implementation experience from GitHub’s alt-text scanner, supported by WebAIM figures and an offline grading harness using accessibility teaching materials.
Where the idea has limits
The supplied argument is explicitly bounded: the plugin checks only HTML img tags, can miss authenticated images, may duplicate built-in checks, and treats model findings as prompts for review rather than verdicts.
A question to take away · from Digna Legi
Where in your own checks are you treating a suspicion as if it were a proven defect?
What the original adds
The original adds implementation-level detail: exact deterministic rule categories, layout-based duplicate detection, model prompt design, privacy redaction choices, cost implications, and a frank list of current blind spots.
About this brief
AI-written, then separately checked for source support, useful detail and clarity. The author’s claims and our editorial question are kept separate. The original remains the author’s work. How we select and summarise →
How was this brief?
Rate this summary, separately from the author’s article.
Optional. Saved in this browser; shared only if you allow analytics.
How was the original article?
Rate the author’s original after reading it.
Optional. Saved in this browser; shared only if you allow analytics.
Digna legi. Worth reading.