A structured audit protocol for generated pages

Why a protocol rather than a checklist

Checklists tell you what to look at. They do not necessarily tell you in what order, what values to record, or what counts as a failure. Without those rules, results from two pages or two reviewers cannot be compared cleanly.

That inconsistency may be tolerable when you are reviewing one page you wrote. It prevents a clean comparison when you want to compare pages, track whether a tool's output is improving, or make a claim about generated markup in general. Comparison requires a fixed instrument.

What follows is a candidate instrument: five ordered stages, each with a defined pass condition, observation fields, and severity rule. Its repeatability is a claim to test, not a fact already established. Independent review should measure agreement and preserve disagreements rather than assuming them away.

The ordering rule

Stages run in this order and the order is not cosmetic. Each stage's findings can invalidate work done in later stages, so running them backwards means redoing them.

Structure first, because fixing structure rewrites markup. Semantics second, because element choice determines what the accessibility tree contains. Behaviour third, because it tests the tree the first two stages produced. Responsive fourth, because layout changes can break focus order established in stage three. Deployed response last, because it tests properties that only exist once the page is served.

Stage one: structure

Disable CSS entirely and read the document top to bottom.

Pass condition: the reading order is coherent without styling, exactly one h1 names the page, heading levels descend without skipping, and the page's main regions are expressed as landmark elements rather than generic containers carrying descriptive class names.

Severity: serious by default. Mark a defect critical only when the reading order or missing structure prevents navigation or completion of the primary task. A skipped heading level is not automatically equivalent to a missing main region or an incoherent DOM order.

Record: number of h1 elements, whether heading levels skip, and which of header, nav, main, and footer are present as real landmarks.

Stage two: semantics

With styling restored, open the accessibility panel in developer tools and inspect every interactive element.

Pass condition: each control's computed role matches what it appears to be, each has a non-empty accessible name consistent with its visible label, form controls have programmatically associated labels or instructions appropriate to their type, and lists are marked as lists. Use real label elements for visible labels on labelable form controls.

Severity: critical when a control required for the primary task has no usable role or name; serious for other control and content-semantic defects. A button that is a styled div is not automatically critical if it remains operable, but it is still a semantic defect that must be recorded.

Record: count of interactive elements, count with empty accessible names, and count whose role is generic where a specific role was expected.

Stage three: behaviour

Put the mouse away. Tab from the top of the document and complete the page's primary task using only the keyboard.

Pass condition: every interactive element is reachable, focus is visibly indicated at every stop, focus order follows reading order, and no element traps focus. When a modal dialog opens, Escape closes it and focus returns to the invoking element unless the completed workflow has a documented next focus target.

Severity: critical when the primary task cannot be completed or focus becomes trapped; serious for other unreachable controls, missing focus indicators, or illogical focus order. Escape and focus-return checks apply when the page opens a modal dialog or comparable temporary layer.

Record: whether the primary task completed, the count of unreachable controls, and the count of stops with no visible focus indicator.

Stage four: responsive behaviour

Run two separate checks: present the page at a width equivalent to 320 CSS pixels, then restore the normal viewport and resize text to 200 percent. Do not compound the two settings and call the result a WCAG requirement.

Pass condition: ordinary vertically scrolling content needs no two-direction scrolling at the 320 CSS pixel equivalent; text at 200 percent loses no content or functionality; and custom pointer targets are at least 24 by 24 CSS pixels or meet a documented WCAG exception. Nothing becomes unreachable because a layout collapsed.

Severity: serious by default, critical when clipping or layout collapse prevents the primary task.

Record: whether page-level horizontal scroll appears, and the narrowest width at which the layout holds.

Stage five: the deployed response

Everything so far can be done against a local file. This stage cannot. It checks the deployed response rather than assuming the local source and hosting behavior match.

Request the deployed URL and inspect what the server actually sends.

Pass condition: the page returns 200, a deliberately missing path returns a real 404 rather than a 200, redirects resolve in one hop, the canonical URL is absolute and self-referential, and any form needed for the primary task posts to a destination that exists and responds. Record the actual Content Security Policy, X-Content-Type-Options, and referrer-policy headers for comparison; judge their values against the page's behavior rather than treating mere header presence as a pass.

Severity: critical when the requested page or primary form destination does not work; serious for a soft 404, redirect chain, conflicting canonical, or security-policy defect that does not block the primary task.

Record: status codes observed, redirect hop count, whether the canonical matches the requested URL, and whether the form's destination responded.

Scoring, and what the score is for

Each stage yields pass when no critical or serious defect is present, pass_with_defects when it has one or more serious defects but no critical defect, and fail when it has at least one critical defect. A page's grade is the worst result across the five stages, not an average, because a page that fails stage three is not rescued by passing the other four.

The purpose of scoring is comparison rather than judgement. One page graded this way tells you what to fix. A completed sample lets you calculate which stage failed most often under the recorded conditions. That result describes the sample; it does not establish a universal fact about every generated page or the internal cause of a defect.

What the protocol does not claim

It does not certify conformance. WCAG conformance is a formal assessment against the full set of success criteria, and this protocol is a bounded five-stage review rather than that assessment. Time each run during the study before claiming a typical duration. The protocol also cannot judge whether content is accurate or whether the design serves its purpose. It measures only the structure, semantics, behavior, responsive presentation, and deployed response named above.

Run it on something you shipped recently and retain the observations. A screenshot cannot exercise keyboard behavior or inspect a deployed response, so those stages need direct evidence even when the page looks correct.

Frequently asked questions

Why does a page audit need a fixed protocol?

A fixed order, field list, and grading rule make observations comparable across pages and expose exactly where reviewers disagree. That is what turns a collection of spot checks into a dataset that can be reviewed.

How long does one audit take?

The protocol has not yet been timed across a completed sample. Reserve an hour for the first run, record start and finish times, and report an observed range only after enough real audits exist.

Can this be automated?

Partly. Automation can collect structure, viewport, and response data, but a person still has to judge meaningful names, task completion, and whether an observed response matches the intended page behavior.