Audit web accessibility against WCAG 2.2

An accessibility audit is useful when each finding names who is blocked, cites the exact success criterion, and comes with a fix a developer can paste. It is harmful when it pads the report with false positives, such as an aria-label "missing" on an element whose visible text already names it, or when it implies a page conforms because code review found nothing. Automated checkers catch only a minority of WCAG failures. Judgement and assistive-technology testing cover the rest.

Audit [TARGET] against WCAG 2.2 level AA.

1. Get the material. Read the code, or fetch and inspect the rendered page if given a URL. If you can only see part of it (one component, no CSS, no scripts), say so and limit your claims to that part.
2. Work through every criterion at the target level. These are the ones most often failed, grouped the way users meet them; also check media (1.2.x), timing (2.2.x), flashing (2.3.1), resize text (1.4.4) and input purpose (1.3.5) whenever the target contains them:

• Perceivable: text alternatives (1.1.1), info and relationships (1.3.1), meaningful sequence, use of colour (1.4.1), contrast (1.4.3, 1.4.11), reflow (1.4.10), text spacing (1.4.12), content on hover or focus (1.4.13).
• Operable: keyboard (2.1.1) and no keyboard trap (2.1.2), bypass blocks (2.4.1), page titled, focus order (2.4.3), link purpose, focus visible (2.4.7), focus not obscured (2.4.11), pointer gestures, dragging movements (2.5.7), target size minimum of 24 by 24 CSS pixels (2.5.8), label in name (2.5.3).
• Understandable: language of page, on focus and on input (3.2.1, 3.2.2), consistent help (3.2.6), error identification and suggestion (3.3.1, 3.3.3), labels or instructions (3.3.2), redundant entry (3.3.7), accessible authentication (3.3.8).
• Robust: name, role, value (4.1.2) and status messages (4.1.3). Note that 4.1.1 Parsing is obsolete in WCAG 2.2.

1. Confirm each suspected issue against the code before reporting it. Check what the accessibility tree would really expose: native semantics, ARIA overrides, and hidden or inert content.
2. Rate severity by user impact:

• Blocker: some users cannot complete the task.
• Serious: the task is possible only with great effort or a workaround.
• Moderate: a confusing or tiring experience.
• Minor: polish.

1. Write the fix for each issue as code in the target's own framework. Prefer native HTML over ARIA.

• Report only criteria at or below AA. Mention higher-level wins in one line at the end, if any.
• Never state or imply that the target "is compliant" or "conforms". Say what you checked and what you found.
• Group repeats of one root cause into a single issue that lists every location.
• Leave out personal opinions on visual design unless they map to a criterion.
• Read the relevant code before making a claim about it. Do not guess what a file, function or config contains.
• If the information you need is not available, say what is missing and how to get it instead of inventing it.
• Separate what you verified from what you inferred. Mark inferences as such.
• When you do not know, say "I don't know" once and state what would settle it.

Summary

Issue counts by severity, then the three changes that unblock the most users.

Issues

Numbered, most severe first. Each one:

• SC x.x.x Name (level) — severity
• Where: path:line or selector
• Who is affected and what happens to them
• Fix: a code block

Needs manual testing

What cannot be judged from the code alone, with the assistive technology or method to use (screen reader, 400% zoom, keyboard only, voice control).

Not covered

Parts of the target you could not see or did not check.