Real accessibility: the agent audits, the person confirms
An agent sweeps WCAG in minutes, contrast, alt text, focus order, ARIA roles, covering at scale what a manual checklist would take days to do. Except technical approval isn't real experience: cognitive load, reading order, and label confusion are things only a person feels. Real accessibility is the sum of both.
A city government orders an inspection of a public building's access ramp. The inspector arrives, measures the slope with the right instrument, checks the minimum width, looks at the handrail, all within technical standards. Stamps it approved. Except nobody actually pushed a real wheelchair down that ramp: the surface is too slippery when it rains, the door at the top is heavy and has no support bar, and a person in a real wheelchair can't open it alone after going up. The ramp passed the measurement. The real experience of whoever needs it is still impossible.
A bank reconciliation system automatically checks all of the month's transactions and marks them "reconciled," because each entry matched a corresponding record. It passes the technical ruler. Except a human auditor, looking at the values with attention, notices three "reconciled" transactions were paired with the wrong record, similar values but different accounts, something the automatic ruler had no way of noticing because it only checks whether a pair exists, not whether the pair makes business sense.
A contract review tool checks, clause by clause, whether each one matches the firm's standard template. All pass the individual check. Except a lawyer reading the whole contract, start to finish, notices that clause 4.2 on termination, correct on its own, contradicts clause 9 on penalties when read together, a problem that only shows up in the continuous reading, not in the isolated check of each clause.
An automatic brand checker verifies that every piece of a campaign uses the right color, the right font, the logo at the right size. A hundred percent technical compliance. Except a human reviewer, reading the piece the way the customer will read it, notices the opening line sounds condescending to that region's audience, something no color or font check would ever catch, because it's about tone, not form.
An automatic screening system approves a candidate because the résumé matches the job's keywords: the right certifications, the right years of experience. It passes the filter. Except the human interviewer, in conversation, notices the candidate never actually led a team through a real crisis, only documented it on paper, a difference no keyword would catch, because it requires human judgment about the real experience behind the text.
An automated test suite runs before every deploy and approves the whole build, all tests green. It passes the technical ruler. Except in a test with a real user, a person gets stuck on the second step of onboarding because they don't understand what the "continue" button will do, a problem no automated test would catch, because it tests whether the code works, not whether the person understands what's on the screen.
A CRM automatically validates that a deal is ready to move to the next stage, all required fields filled, checklist green. It passes the system's ruler. Except the salesperson, on the real call, senses the client is hesitant and the deal is at real risk of going cold, something no form field would capture, because it's a human reading of tone of voice and hesitation, not structured data.
An SLA dashboard shows level-2 support within target, a hundred percent green for the month. Approved on the dashboard. Except a frontline agent knows that, for one specific type of ticket, the team always stretches the deadline to the limit and disguises it in the report, a problem the monthly average dashboard doesn't reveal, because it measures the aggregate, not the specific case that almost always fails.
An automatic checklist verifies whether the privacy policy cites every item required by LGPD, and it does, item by item. Technically approved. Except a human reviewer, reading the consent flow the way the user actually lives it, notices the accept button is big and highlighted while the decline one is an almost invisible gray link, a practice that passes the text check and completely fails the spirit of the law.
A CI pipeline runs the unit and integration test suite before merging, all green, code coverage above target. Technically approved. Except in production, under real load, a human engineer discovers a rare race condition brings the service down once a week, something no automated test caught because the condition only shows up under real user concurrency, not in the test's controlled environment.
You run an accessibility scanner on your product's checkout flow and it approves in minutes: contrast within the required minimum, every image with alt text, keyboard focus order with no gaps, ARIA roles present where they should be. A hundred percent green on the technical ruler. Except when you yourself navigate that same flow with your eyes closed, using a real screen reader, you discover the "Finish" button is read before the order summary, so whoever uses the screen reader hears "finish" without knowing yet what they're finishing. Technically, each element passed its isolated check. In the real experience of whoever depends on the screen reader to buy something, the whole flow makes no sense.
An OKR dashboard shows all the quarter's indicators in green, every numeric target hit on time. Approved on the dashboard. Except an executive reviewing the plan calmly notices the green targets don't actually touch the competitive threat that motivated the plan, the team hit the number, but the real problem the board wanted solved is still standing, invisible to a dashboard that only measures what was defined as a metric.
Whoa, let me tell you about the scene that fools good people the most in this track. You run an accessibility scanner on your checkout, it comes back all green, contrast ok, alt text ok, focus ok, ARIA ok, and you breathe a sigh of relief thinking you solved it. Except when you yourself navigate that flow with a real screen reader, without cheating by using the mouse, you discover the reading order makes no sense at all: the finish button is read before the order summary. Technically approved and unusable in practice, at the same time, in the same flow. This lesson is about understanding why that happens, and about the right ruler so you don't fall into that trap.
The core idea of this lesson. An AI agent can audit WCAG (color contrast, alt text on images, keyboard focus order, ARIA roles) at scale and in minutes, covering what a manual checklist would take days to review across the whole product. That solves technical compliance. It doesn't, on its own, solve the real experience of someone using a screen reader, navigating only by keyboard, or with low vision: cognitive load, a reading order that makes sense, a label that technically passes contrast but confuses in practice, are things the agent doesn't feel, only the person feels. This lesson's ruler is simple to state: the agent does the broad sweep and covers the volume nobody has time to check manually everywhere; the person, ideally someone who actually uses assistive technology, or a test guided by human heuristics, confirms what really matters in the experience. Real accessibility is the sum of both. Never just the automated sweep, which can approve a screen that's still unusable.
01What the agent solves fast: the sweep at scale
Start with what AI genuinely does well, and it's quite a lot. An agent with access to your product can run, in minutes, an audit against accessibility's objective technical ruler, WCAG 2.2, the W3C standard that defines measurable criteria: is the contrast between text and background above the minimum, does every image have alt text describing what it shows, does the focus order when navigating by keyboard follow a logical sequence, do interactive elements have the correct ARIA role for assistive technology to understand what they are.
That's volume a manual checklist can't handle across the whole product, every screen, every component, every time something changes. An agent runs that sweep again with every change, without tiring and without skipping a screen. It's exactly the kind of mechanical, repetitive work worth taking off human hands, so there's time left for what only a human hand can evaluate.
02What only the person feels: cognitive load, an order that makes sense, real confusion
Now the other side, which is where the trap lives. An element can pass every technical criterion, individually, and the whole flow still not make sense to someone using assistive technology. The case in the example that opened this lesson is exactly that: each element in the checkout, on its own, matched WCAG. The button had correct contrast. The image had alt text. The ARIA role was present. Except the order in which the screen reader read those elements didn't follow the logic of what a person needs to know before deciding: hearing "finish" before hearing what's being finished breaks the whole experience, even with every technical criterion approved one by one.
That happens because there are dimensions of accessibility that don't reduce to a binary pass-or-fail rule. Cognitive load, is it easy to understand what this screen is asking of me, or do I need to reread it three times. Reading order, does what comes first make sense for the decision I need to make. Label clarity, "click here" technically has good contrast, but it doesn't say anything about what will happen when I click. None of these three things is measured by an automated tool, because they aren't properties of the code, they're properties of the experience lived by a person navigating that flow in a specific way. Only someone who actually depends on a screen reader, or navigates all day by keyboard only, feels this kind of friction in their skin.
03This lesson's ruler: the agent covers the volume, the person confirms the experience
We've arrived at the division of labor that solves the problem without discarding either side. The agent goes first, and does the broad sweep: the whole product, every component, against the objective ruler of WCAG 2.2. That already eliminates a large amount of real problems, because a lot of accessibility barriers are, indeed, technical and mechanical, bad contrast, an image with no description, an element with no ARIA role, things the sweep catches directly and that represent a good share of the most common problems on the web today.
Except the industry's literature is honest about the limit: less than half of real accessibility problems tend to be detectable by tooling alone, the rest requires human evaluation, with judgment about the experience of use. That's why the right ruler isn't choosing between agent or person, it's using both in sequence: the agent sweeps everything, fast and cheap, covering the volume no team would have time to review manually on every screen. The person, afterward, tests the flow for real, ideally someone who uses assistive technology day to day, or at least a test guided by human heuristics (navigating by keyboard only, listening to the whole flow with the screen reader on, without cheating by looking at the screen). What the person finds there is exactly what the agent, by nature, can't feel.
Why "technically approved" isn't a synonym for accessible
It's worth understanding the root of the problem so you don't fall into it again in another context. WCAG 2.2 is written as a set of success criteria, each designed to be verifiable, minimum contrast of 4.5 to 1, presence of alt text, and that's a virtue of the standard, because it allows objective auditing at scale. But verifiable isn't the same as sufficient. An isolated criterion can pass and the combination of criteria, in the order a person actually encounters the elements, can still fail. It's the same reasoning as any rule-based system: you can follow every individual rule and still produce a result nobody wanted, because the rule didn't capture the intent behind it. WebAIM's annual report, which sweeps millions of real pages, finds year after year a huge number of basic technical errors still present on the most-used web, which shows that even the easy part, automated auditing, isn't being done on most products. In other words: before debating whether automated auditing is sufficient, most of the market isn't even running it yet. Do both steps, in the right order, and you'll already be ahead of most.
Now build
Choose a real flow in your real task, ideally one that involves a user decision, a checkout, a sign-up, an approval step. Do both steps, in sequence, without skipping either.
STEP 1 · THE AGENT SWEEPS
- Ask an AI with access to your product (or paste the screen's HTML) to audit that flow against WCAG 2.2: contrast, alt text, focus order, ARIA role.
- List the problems it found, one by one, with the technical criterion each one violates.
STEP 2 · THE PERSON CONFIRMS
- Now navigate that SAME flow yourself, by keyboard only, without touching the mouse, start to finish. Note where you got stuck, where the focus jumped somewhere that made no sense, where you no longer knew which field you were in.
- If you can, turn on your system's native screen reader (VoiceOver on Mac, Narrator on Windows) and listen to the whole flow with your eyes closed. Note what sounded confusing, out of order, or incomplete, even if the automated tool approved that same section.
Compare the two lists. The first is your technical basement solved quickly. The second is what only showed up because a person, not a tool, lived the flow for real. If the second list has any item the first one didn't catch, you've just confirmed, in practice, why real accessibility is never just the automated sweep.
Practice
1. An accessibility scanner approves checkout with contrast, alt text, focus, and ARIA all correct, but a screen reader user can't complete the purchase. What does this reveal?
2. What's the correct role of WCAG 2.2 in this division of labor between agent and person?
3. Why are cognitive load and a reading order that makes sense hard to audit with tooling alone?
4. What is this lesson's correct ruler for dividing accessibility work between AI agent and person?
Fair? Let's close the message of this lesson together. An agent with access to your product audits WCAG 2.2 at scale, contrast, alt text, focus order, ARIA role, in minutes, covering the volume a manual checklist would never manage to review everywhere. That solves technical compliance, and solves it fast. But cognitive load, a reading order that makes sense, and label clarity are things only a person navigating the flow for real can feel, and no automated sweep replaces that. The ruler that remains: the agent covers the volume, the person confirms the experience. Real accessibility is the sum of both, never half of it passing itself off as the whole. Next.
For the board
On the green scanevery element can pass on its own and the whole sequence can still confuse someone who depends on a screen reader.
On the splitthe agent covers the technical volume. The person confirms the lived experience.
On what cannot be measuredcontrast becomes a number. Cognitive load and an order that makes sense depend on someone living the flow.
Thanks for the feedback. It helps sharpen the next lesson.