Accessibility and Content Review

Open by naming the pattern honestly. Almost no team disagrees that accessibility and copy quality matter, and almost every team defers the review of both. They are deferred because they are slow to do well by hand, because the people who can do them well are scarce, and because the work is mostly careful reading at scale — exactly the kind of work that loses to a deadline every time.

This module applies the structure built in Modules 1 to 3 — named criteria, findings with evidence, severity, and a human gate — to these two specific review types. The methods are not new. What changes is the cost: an agent can read every route and every string against the same standard in under an hour, which means the review can happen every release instead of once before an audit.

Set one expectation early: this module will be careful about what these reviews can and cannot prove. Passing an agent sweep does not make a product accessible, and a copy audit does not make the writing good. The sweeps make the mechanical part continuous so the human judgment is spent on decisions rather than on hunting.

The accumulation point deserves the most time. Nobody ships an inaccessible product or an incoherent voice on purpose. They ship it one decision at a time: an icon button without a label here, a low-contrast badge there, an engineer writing an error string at midnight, a marketer naming a feature. Each change is reasonable locally. The problems only become visible when someone reads the whole surface as a whole — and users are usually the first people who do.

The scarcity point matters for how the agent fits in. Most organisations have far fewer accessibility specialists and content designers than product teams. The traditional answer is to ration their time: they review the highest-risk flows and hope the rest holds. The agent does not replace them; it changes what their scarce time is spent on. Instead of reading 1,800 strings or tabbing through forty routes, they review a ranked findings list and make the calls only they can make.

The forcing-function point is the cost argument. When the trigger is an external audit or a statutory deadline, fixes happen under pressure, in bulk, and late — which is the most expensive way to do them. The case studies later in this module show the same fixes costing a fraction when they are caught as part of a routine sweep.

Be precise about the division of labour, because over-claiming here damages credibility with anyone who has done accessibility work. Automated checkers like axe-core are excellent at what they measure: contrast ratios against the WCAG AA thresholds, missing alt attributes, invalid ARIA, form fields without a programmatic label, broken landmark structure. They are also famously incomplete — common estimates put automated coverage at well under half of WCAG criteria, and the gap is precisely the part that requires judgment about meaning.

That gap is where the agent review earns its place. An agent can read a component and judge whether the accessible name actually describes what the control does, whether the focus order follows the order of the task rather than the order someone happened to write the DOM, whether an error message tells the user what to do next, whether a status is communicated by colour alone, and whether a custom dropdown behaves like the native pattern it imitates. None of that is something a rule-based checker can decide.

The sequencing matters as much as the split. The accessibility-sweep workflow this module is built on runs the static checks first and hands the results to the agent. That keeps the agent from spending its effort confirming what a tool already proved, and it gives every agent finding a concrete anchor: this axe violation, in this file, on this route. Findings without anchors get argued with; findings with anchors get fixed.

Walk the diagram top to bottom. Band one is the automated checks: axe-core, contrast tools, scripted keyboard walks recorded by something like Playwright. Their character is precise but incomplete — they prove specific failures and miss everything that requires interpretation. Band two is the agent review, one reviewer per route or surface, covering both the accessibility semantics and the content rules: names that do not describe the control, focus order against task order, errors with no next step, colour-only signals, and terminology, voice, and readability drift. Band three is human judgment: severity calls and approved exceptions, naming and voice decisions, testing with real assistive technology and real users, and the release trade-off itself.

The arrows are the point of the picture. Findings flow downward as evidence for the next band, and each band exists to make the one below it cheaper. The tool results stop the agent re-deriving proven facts. The agent's ranked, located, evidenced findings stop the human spending their judgment on hunting.

The right-hand column of each band lists what that band misses, and the bottom band's list is the one to dwell on: severity decisions, naming decisions, real screen reader behaviour across browser combinations, and release trade-offs cannot be delegated to either tools or agents. That is not a temporary limitation to be engineered away; it is where accountability lives, and the same point recurs from Module 1 of this course.

This slide describes the accessibility-sweep workflow from the school's workflow library, so point participants there for the full prompts and the scan script. The structure is simple enough to remember: capture static evidence first, fan out one reviewer agent per route, merge the findings into one ranked list, and hold a human gate before anything is fixed.

The scan script does two jobs. It runs axe-core against each route in scope, and it performs a basic keyboard walk — tab through the page a few dozen times, record which element receives focus at each step, and note any element that takes focus without a visible indicator. That recorded focus order is worth emphasising because it converts the vaguest class of accessibility complaint, keyboard users get lost, into a concrete sequence that can be compared against the visual and task order. In the dashboard case study from the workflow, the recorded order made a problem visible that nobody had been able to reproduce reliably: the side panel was rendered early in the DOM and pulled forward in the tab order ahead of the filters.

The reviewer agent is defined once, as a read-only subagent, and reused on every route and every run. That is what keeps the standard consistent — every route is held to the same criteria, in this sweep and the next one. Requiring the agent to separate tool-proven findings from judgment-based findings keeps the report honest, and requiring a concrete fix on every finding keeps it actionable. The fix passes themselves happen later, under the severity gate covered on the next slide.

The severity scale used in both workflows is deliberately simple. P0 blocks task completion or fails AA on a core flow and is fixed before anything else. P1 is a serious barrier with a workaround, fixed in the same release. P2 is friction or inconsistency scheduled into normal work. P3 is advisory, fixed opportunistically. The human gate review confirms the P0s are real, demotes anything with an approved exception, and approves the first fix pass — and it is fast precisely because the findings arrive in a consistent format.

The fixes-versus-redesigns split is the learning objective of this module that teams most often get wrong. Mechanical fixes — adding a label, swapping an off-palette colour for the accessible token, removing a positive tabindex, rewriting an error to the three-part anatomy when the canonical term is already decided — are well within what an agent can apply, in passes, with re-verification after each pass. Anything that changes the design or the words a stakeholder owns is not: reordering a flow, redesigning how status is communicated, choosing whether the product says Transfer or Send, and any legal or regulatory wording. Routing those to the agent does not save time; it produces confident changes that get reverted.

The one-tier-at-a-time discipline is slower on paper and faster in practice. The common failure it prevents is a hundred small fixes landing at once with three of them breaking something nobody can isolate. Each tier is fixed, the scan re-runs, and only then does the next tier open. Recording exceptions matters for the same reason: an exception that is not written down resurfaces as a finding in every future sweep and erodes trust in the whole report.

Frame content review as the same discipline as the accessibility sweep applied to words. The drift mechanism is identical: designers label buttons in Figma, engineers write error strings at midnight, marketers name features, support writes macros. Each string makes sense locally. Together they call the same action three different things and explain the same error five different ways, and nobody notices because nobody ever reads the copy as a whole — except users, who learn the button says Transfer on one screen and meet Send on the next and wonder if it is a different feature.

The orchestration mirrors the accessibility sweep: the product area is split into surfaces — buttons and primary actions, empty states, error messages, onboarding, transactional emails — and each surface gets its own audit agent applying the same rules in the same reporting format. Bounded surfaces keep the reading careful; one agent reading everything gets sloppy by the third screen. A merge step then combines the per-surface findings into a terminology map, a severity-ranked fix list, and a localisation risk log.

Of the three artifacts, the terminology map is the keystone. The fix list gets worked through and forgotten; the map records the canonical term for each concept, every variant found, and where each variant lives, and it becomes the reference for every future string anyone writes. In the fintech case study from the workflow, the map showed the core money-movement action named Transfer in 14 places, Send in 9, and Pay in 6 — and support data showed the most common pre-contact search was whether send and transfer were different things.

This is the content-review equivalent of writing critique dimensions down in Module 1: the standard has to exist in a checkable form before an agent can apply it consistently. Be friendly but professional produces findings that are themselves vibes. Use Transfer, never Send or Pay, for account-to-account movement produces findings someone can accept or decline. The conversion work — turning a prose style guide into canonical terms, banned terms, voice rules with examples, error anatomy, readability ceilings, and localisation flags — is a few hours of a content designer's time, and it is the highest-leverage few hours in the whole workflow.

Get the content owner to sign off on the rules before the audit runs. The audit is only as legitimate as the standard it applies, and the fastest way to get a fix list ignored is to audit against rules nobody agreed to. Where the guide is silent or ambiguous, the agent should report the conflict rather than choose — those gaps feed the next revision of the guide.

The double-duty point is what makes the investment compound. Stored as a subagent definition, the same rules that audit the existing copy review every new string in pull requests, which catches drift one string at a time instead of 1,800 strings at a time. If a team has no style guide at all, run a lighter discovery audit first to surface the de facto conventions, write the guide from what is found, and then audit against it.

Localisation readiness is the part of content review with the clearest financial argument, so use it when making the case for the audit internally. In the workflow's B2B case study, a platform preparing to localise into German, Japanese, and Brazilian Portuguese audited its 312 error strings first: 41 percent failed the three-part anatomy, and 38 strings were assembled by concatenating fragments at runtime — a pattern that translates badly because word order changes across languages. The vendor quoted lower because the source strings were being fixed before translation rather than after, and rewriting the worst strings once in English cost a fraction of fixing them in four languages later.

The technical risks the agent flags are specific and checkable: strings built by concatenation, embedded variables whose position assumes English word order, idioms and humour, and strings whose length leaves no room for expansion. Length is a design problem as much as a writing problem — a label that barely fits its button in English is a layout bug waiting to happen in German — which is why the localisation risk log is worth reading alongside the visual QA work from Module 3.

Keep the claims conservative: the audit flags risk, it does not guarantee translatability, and it says nothing about whether the translated copy reads well. That still needs native-speaker review. What it does is hand the vendor a clean source and a known list of problem strings, which is the difference between translating a product and translating its accumulated accidents.

This quality bar applies identically to both reviews, which is why the table mixes accessibility and content rows. The anatomy of a fix-ready finding is the same in both: severity, the exact location — file and line for code, locale key or screen for copy — the criterion or rule broken, the evidence, and a concrete fix the owner can accept or decline without further research. The weak versions in the left column are not wrong; they are just unactionable, and unactionable findings are what get a report politely ignored.

The practical habit to teach is the spot-check. Before the severity gate review, read a sample of findings and ask whether each one could be handed to a developer or a writer and fixed without a follow-up question. If findings are drifting toward generalities — add more ARIA, the copy is too long — the fix is not to argue with each finding but to tighten the reviewer agent's instructions: require the criterion, require the location, require the quoted string or the measured ratio, and require the suggested fix.

There is also a trust dimension. The first sweep a team runs sets expectations for every later one. A first report full of precise, verifiable findings builds the habit of acting on the output; a first report full of vibes teaches the team that the sweep is noise. It is worth holding the first run to a higher bar than feels necessary.

These figures come from the case studies in the two workflows this module is built on — an e-commerce checkout that started failing conversion benchmarks after a rebrand to a lighter palette, and a fintech payments area audited before a brand refresh. They are traced runs from those write-ups, not benchmarks, and the numbers will vary with codebase size and how much drift has accumulated. Say that plainly.

Walk the columns in parallel because the structure is the lesson. Both runs took roughly the same agent time. Both produced findings that were precise enough to fix quickly because every finding carried its location: the contrast failures named the component and the measured ratio, the terminology variants came with their locale keys, which is why 27 strings could be renamed in two days. Both had a human gate where the actual decisions happened — confirming that the off-palette button colour was a rebrand accident rather than an intentional exception, and choosing Transfer as the canonical term while keeping Pay for bill payments, a decision informed by support data showing users searching for whether send and transfer were different things.

Also point at the re-verification row. The accessibility fix was confirmed by re-running the same scan script, not by anyone's impression that it looked better. The content fix was confirmed by a re-audit two weeks later that found four stragglers in email templates and no new variants. Closing the loop with the same instrument that found the problem is what makes either review trustworthy enough to repeat every release.

This slide protects the credibility of everything before it, so deliver it without hedging. On the accessibility side: an agent sweep plus automated checks does not make a product accessible; it makes it free of the failures those passes can detect. Real assistive technology behaviour — how an actual screen reader announces an actual widget in a particular browser — still needs hands-on testing, and usability for disabled users still needs research with disabled users. Formal conformance claims require a documented human evaluation; do not let a green sweep report be presented as one.

On the content side: the audit measures consistency against a standard, and it cannot prove the standard is right. Whether Transfer or Send is the better word is a naming decision informed by research and brand, made by humans, and only then enforced by the audit. Readability scores are rough instruments for flagging outliers, not a substitute for testing comprehension. Legal and regulatory wording, and any rewrite that might lose a nuance compliance needs, route to the owners who can decide — and their decisions get recorded as exceptions so the next audit does not relitigate them.

Finally, coverage. Both reviews only see what was put in front of them: the routes in the scan list, the strings that were exported. Hard-coded copy, third-party widgets, and flows nobody added to the route list are invisible. A team that treats the sweep as exhaustive will be surprised by exactly the things it never looked at, which is an argument for keeping the scope list visible alongside the findings.

Keep the scope deliberately small: one flow, a handful of routes, an hour or two of total effort. The point of the exercise is not to fix the product this week; it is to experience each band of the diagram once — the tool pass, the agent pass, and your own gate review — on a surface where the findings will feel real.

The step most people are tempted to skip is the manual keyboard walk, and it is the one that produces the most surprise. Recording the focus order you actually get, rather than the one you assume, is usually the moment the value of the recorded evidence lands. The disagreement note in step four matters too: where your severity call differs from the agent's, that difference is exactly the judgment that the workflow keeps human, and writing it down makes it discussable rather than implicit.

The last bullet pulls the content review in without requiring a full audit: the three worst strings are usually error messages, and rewriting them against the what happened, why, what next anatomy gives a concrete before-and-after to share with whoever owns the copy. If participants want to go further, the accessibility-sweep and content-audit workflows in the school's workflow library contain the full prompts, the scan script, and the reviewer agent definitions used in this module.

Recap by tying the two reviews back to the course's central argument: critique improves when the mechanical part becomes continuous and the human part becomes deliberate. Accessibility and content were the clearest cases of reviews that stayed rare because they were expensive; the sweeps make them cheap enough to run every release, and the severity gate keeps the decisions — what blocks, what is excepted, what the product is called — exactly where they belong.

Remind participants of the artifacts worth keeping beyond the fix lists: the scan script and reviewer definitions on the accessibility side, and the terminology map plus the rules-based voice standard on the content side. Both compound: each subsequent run is comparable with the last, and the same standards reused at review time are what Module 5 builds on.

Preview Module 5 concretely. It is the end state the course has been pointing at: every change that touches the interface gets a design review automatically — token and component checks, screenshot evidence, and checks drawn from exactly the accessibility and content rules written in this module — with severity levels deciding what blocks, what warns, and what merely notes, and clear escalation for the findings that need a human designer. The exercise findings from this module become the seed rules for that per-PR review.