We turned our own homepage into the test subject. We took a real screenshot of our live hero section and gave it, with no other context, to four different AI models, sonnet, opus, haiku, and fable, each with one instruction: audit this for accessibility issues, honestly. No leading questions, no hint about what we expected to find. We wanted to know whether four independent models would converge on the same real problems, or scatter across four different, less useful lists.
The Stat: All 4 models, independently and without coordination, flagged the same icon-only hamburger menu button as the top accessibility issue in the identical screenshot; 3 of 4 also independently flagged the same low-contrast gray micro-labels. (Source: our own real, reproducible 4-model visual audit test)
The Setup
We gave each of the four models the exact same real screenshot of our own homepage hero, taken from the live site, and one instruction: audit this image for accessibility issues, be honest, and note anything you cannot judge from a static screenshot alone. Every finding below came from models working independently, no model saw another model's output, and no leading language in the prompt pointed toward any specific issue.
What All Four Models Found, Independently
Every single model, without exception, named the icon-only hamburger menu button as an accessibility concern, and most placed it at or near the top of their list. The reasoning, stated independently by each model in its own words, converged on the same core problem: a small icon with no visible text label and no confirmation that it carries an accessible name in the underlying markup (which a static image cannot verify either way), sitting in a position users depend on for primary navigation.
Three of the four models also independently flagged the same second issue: low-contrast gray micro-labels used for small caption or metadata text elsewhere in the hero, the same category of contrast concern covered in our why contrast checkers pass colors real users still can't read piece. Two models flagged similar concerns independently rather than converging on identical wording, but the underlying observation, thin, low-contrast secondary text, was consistent across both.
Where the Models Differed
Beyond the two points of strong agreement, each model brought its own distinct additional observations, and the differences were as informative as the overlap. One model specifically flagged that the hero's decorative "report card" graphic element might be a baked-in raster image, meaning any text inside it would not reflow or resize the way real text does, a real WCAG 1.4.4 and 1.4.5 concern that requires no ARIA or code to verify, just recognizing the visual signature of rasterized versus live text. Another model cited two specific numbered WCAG criteria by number, correctly, for a touch-target-size observation, while a third made the same observation in plainer language without the specific citation, a difference in communication style more than in underlying accuracy. One model raised a competing call-to-action hierarchy concern none of the other three mentioned at all, noting that several buttons of similar visual weight compete for attention without a clear primary action.
Why Convergence Across Independent Models Is a Meaningfully Different Signal
It is worth being explicit about why four separate models reaching the same top conclusion matters more than the raw finding itself. Any single automated or AI-driven check carries some risk of pattern-matching toward a plausible-sounding but ultimately incorrect finding, the accessibility-review equivalent of a hallucination. That risk drops meaningfully when four independently-run evaluations, using different underlying models with no shared context or coordination, land on the identical conclusion without being steered there by the prompt. This does not make the finding infallible, a live DOM inspection is still the only way to fully confirm whether the hamburger button actually carries a proper accessible name, but it does make the finding considerably more trustworthy as a starting point for prioritization than a single model's opinion would be on its own.
What Every Model Got Right About Its Own Limits
The most reassuring pattern across all four audits was not what they found, it was what they explicitly declined to claim. Every model that discussed the limits of a static-image audit did so accurately and without prompting: multiple models explicitly stated that focus visibility, keyboard order, ARIA attributes, and actual accessible names cannot be verified from a screenshot alone, only from the real, live DOM. Not one model overclaimed confidence about something a picture genuinely cannot reveal. That distinction, between what a visual audit can and cannot honestly assess, is exactly the kind of calibration that makes a tool useful rather than misleading, and all four models demonstrated it consistently.
The Explicit "Looks Fine" List Was Just as Useful
One detail worth highlighting on its own: several models did not only list problems, they explicitly named what they judged to be working well, headline contrast, body copy legibility, the underlined link style, the primary call-to-action button's contrast against its background. This mattered for a specific reason: a report that only ever lists problems gives no way to distinguish "this element was checked and passed" from "this element was simply never looked at." A model willing to state a positive finding as confidently as a negative one is demonstrating the same kind of calibration that matters most in a real audit, an honest, complete accounting rather than a search for anything that can be framed as a finding.
What This Test Actually Tells Us
A single AI model flagging an issue is a claim worth checking. Four independent models, given the same image with no coordination and no leading prompt, converging on the identical top finding is a considerably stronger signal, closer to what a panel of four independent human reviewers converging on the same top issue would represent. That convergence is the most useful output of this whole test: not any single finding, but the fact that the same finding survived four separate, independent evaluations without being cued toward it.
It is worth being direct about the boundary here too. A visual audit, AI-run or human-run, from a screenshot alone is never a substitute for a real audit against the live, interactive site, precisely because of the limits every model in this test correctly named itself. We cover that broader gap, and why a full manual and automated review still matters even after a strong visual pass, in we audited 50 accessible websites and 47 failed, and the question of whether AI is close to replacing a real audit entirely is covered directly in will AI replace accessibility auditors.
If you want to know what a real, full audit, not a screenshot-only pass, actually finds on your own site, our free accessibility audit checks the live DOM, not just what is visible in a picture, and our team is reachable directly at experts@wcag.world to walk through the results. The W3C's guidance on evaluating accessibility and the current WCAG quick reference are both worth reading directly for the complete technical picture behind what a full audit actually checks.