# ACT Rules Detection Boundary

Use this reference when a finding needs an explicit machine-testable-vs-manual-only determination — i.e. when someone (a developer, a manager, a compliance owner) asks "can't a tool just catch this?" and the honest answer needs a citation, not a shrug.

## What people get wrong

The naive story is:

> "We ran the scanner and it's clean, so we're WCAG conformant."

Wrong, and documented as wrong. W3C's own Accessibility Conformance Testing (ACT) Rules Format exists precisely because only a subset of WCAG success criteria have rules that can be fully automated; many ACT rules are explicitly scoped as semi-automated (tool narrows candidates, human confirms) or cannot be automated at all. Context7-grounded testing-methodology sources (web.dev's accessibility-testing curriculum) list this as a documented pro/con of automated tooling, not a vendor limitation of any one scanner — every axe-core/Lighthouse-class tool inherits the same ceiling because the underlying criteria themselves are not all mechanically decidable.

## Officially grounded shape

ACT Rules (`https://www.w3.org/WAI/standards-guidelines/act/rules/`) each declare:

1. **Applicability** — the exact DOM/CSSOM condition the rule fires on.
2. **Expectation** — what must be true for the applicable element to pass.
3. **Accessibility Support** — known AT/browser caveats affecting the rule's validity.
4. **Test cases** — passed/failed/inapplicable examples used to validate rule implementations across tools.

Each ACT rule maps to one or more WCAG 2.x SC. A rule existing does not mean full SC coverage — most SC have partial automation at best (see the Detect column in `references/wcag22-sc-index.md`).

## Non-negotiable determination rule

For any finding, before closing it as "automated-clean" or escalating it as "needs manual review," answer:

1. Does a published ACT rule exist for this exact condition? If yes, cite its rule id/URL.
2. Does the ACT rule's *Applicability* actually match this element/pattern, or only a superficially similar one? (Common false-negative source: a rule scoped to `<img>` does not cover a CSS `background-image` used as content.)
3. Does the ACT rule's *Expectation* fully capture the SC's intent, or only a necessary-but-not-sufficient subset? (Example: a rule confirming an `alt` attribute exists does not confirm the alt text is accurate — that remains manual.)
4. If no ACT rule exists or covers only part of the SC, label the remainder explicitly `manual-required` rather than silently treating tool silence as a pass.

## Machine-testable vs manual-only quick reference

**Reliably rule-coverable (cite the ACT rule id when available):**
- Missing `alt` attribute presence (not correctness)
- Empty/duplicate `id` attributes
- `<html>` missing/invalid `lang`
- Color contrast ratio computation (given final rendered colors)
- Missing accessible name on form controls (presence, not adequacy)
- `<meta name="viewport">` blocking zoom (`user-scalable=no`, restrictive `maximum-scale`)
- Duplicate landmark of the same type with no distinguishing label (structural detection only)

**Semi-automated (tool flags candidate, human confirms):**
- Heading-level skips (tool detects the skip; human confirms whether it's a real structural break or acceptable visual-only heading)
- `tabindex` positive values (tool detects; human confirms actual focus-order impact)
- `aria-hidden` on focusable descendants (tool detects the conflict; human confirms it's not an intentional, correctly-managed dynamic pattern)
- Redundant/conflicting ARIA role vs native semantics

**Manual-only (no meaningful automation exists):**
- Whether alt text, link text, or error messages are actually meaningful/accurate
- Keyboard operability of a custom widget's full interaction model (arrow keys, Escape, Home/End per its APG pattern)
- Focus order matching visual/logical reading order
- Whether status messages are announced without stealing focus (4.1.3)
- Cognitive-load and plain-language adequacy (3.1.5-adjacent, readability)
- Actual screen-reader announcement correctness across NVDA/JAWS/VoiceOver

## When to push back

Push back if the user asks to:

- close a finding as "resolved" solely because a scanner stopped flagging it, when the underlying SC has no full-automation ACT rule for that condition,
- ship a compliance deliverable that cites "0 automated findings" as equivalent to "0 findings" — state the manual-only gap explicitly in the same sentence,
- treat every tool-flagged item as guaranteed-true without checking Applicability match — false positives are a documented characteristic of automated accessibility tooling, not an edge case.

# Legal Exposure and Severity Model

Use this reference when triaging a finding's litigation risk, prioritizing a remediation backlog under limited engineering capacity, or preparing input for a VPAT / accessibility conformance statement where severity and exposure need to be defensible, not vibes-based.

## What people get wrong

The naive story is:

> "All WCAG failures are equally 'an accessibility bug' — triage by engineering effort, not by criterion."

Wrong for two reasons. First, WCAG Level A is the floor of any recognized conformance claim (ADA Title II/III, Section 508, EN 301 549, AODA — all build on WCAG A/AA as the referenced technical standard); an unresolved Level A failure undermines the entire conformance claim, not just one page. Second, litigation pattern data (publicly tracked ADA web-accessibility lawsuit filings) skews heavily toward a small, repeatable set of criteria — the same handful of failure types recur across the large majority of filed complaints and demand letters. Triaging purely by "how hard is this to fix" ignores which failures are actually driving legal exposure.

## Non-negotiable severity framing

Every finding gets exactly one severity, derived from two independent axes — never blend them into a single fuzzy number:

1. **Conformance Level** (A > AA > AAA) — Level A failures are always at least as severe as an otherwise-similar AA/AAA failure, because A is the mandatory floor.
2. **Litigation-pattern exposure** (elevated / standard) — independent of Level, based on whether the SC is one of the criteria that recurs disproportionately in filed accessibility litigation.

## Elevated-exposure success criteria

Flag findings against these SC as **elevated** regardless of how minor the fix looks, because they are the pattern most frequently cited in demand letters and filed complaints:

| SC | Level | Why it recurs in litigation |
|---|---|---|
| 1.1.1 Non-text Content | A | Missing alt text on functional images (logos-as-links, icon buttons) is trivially detectable by a plaintiff's automated pre-filing scan |
| 1.4.3 Contrast (Minimum) | AA | Mechanically measurable — plaintiffs' own tooling flags it identically to defense tooling, leaving little room to dispute |
| 2.1.1 / 2.1.2 Keyboard / No Keyboard Trap | A | "Could not complete purchase/signup using only a keyboard" is a common, concrete injury narrative |
| 2.4.4 Link Purpose (In Context) | A | "Click here" / "read more" links with no accessible context are common and easy to demonstrate |
| 2.4.7 Focus Visible / 2.4.11 Focus Not Obscured | AA / AA | Directly demonstrable via screen recording of keyboard navigation |
| 3.3.2 Labels or Instructions | A | Unlabeled form fields on checkout/signup flows are a recurring named injury in filings |
| 4.1.2 Name, Role, Value | A | Custom widgets (fake buttons, unlabeled icon controls) with no accessible name/role are the most common root cause cited alongside 2.1.1 |

This list is a documented-pattern heuristic, not a legal opinion — verify current litigation-pattern data and consult qualified counsel before using it to size actual legal risk for a specific organization.

## Severity matrix

| Level | Elevated exposure | Standard exposure |
|---|---|---|
| A | **Critical** — blocks conformance floor + high litigation pattern match | **High** — blocks conformance floor |
| AA | **High** — typical target level + high litigation pattern match | **Medium** — typical target level |
| AAA | **Medium** (only if AAA is an explicit stated target) | **Low** (AAA is rarely a required conformance target — do not imply blocking severity unless the user has stated AAA is their target) |

## Minimal safe triage flow

1. Identify the SC and Level (from `references/wcag22-sc-index.md`).
2. Determine evidence tier — automated/semi-automated/manual (from `references/act-rules-detection-boundary.md`).
3. Check whether the SC appears in the elevated-exposure table above.
4. Assign severity from the matrix.
5. State the evidence tier and severity together in the same finding line — never report severity without also stating how confidently the finding was established.
6. For a remediation backlog, sort Critical > High > Medium > Low, then within each tier prefer the SC that unblocks the largest number of user flows (e.g. a global focus-visible regression outranks a single-page contrast issue even at the same nominal severity).

## When to push back

Push back if the user asks to:

- deprioritize a Level A finding because "it's a small visual thing" — Level A is the conformance floor regardless of perceived visual magnitude,
- treat this severity model as a legal risk quantification or substitute for counsel — it is a documented-pattern triage heuristic for engineering prioritization, not a legal opinion, and must not be presented as one,
- suppress or soften an elevated-exposure finding in a report because it's inconvenient for a release timeline — the exposure flag exists precisely so it cannot be silently dropped from the audit trail.

# WCAG 2.2 Success-Criteria Index

Use this reference when scoping which success criteria (SC) apply to a review, or when a finding needs to be anchored to the correct SC id, Level, and POUR principle before it goes into a report.

## What people get wrong

The naive story is:

> "WCAG 2.2 is basically WCAG 2.1 plus a couple of new rules."

Incomplete. WCAG 2.2 added 9 new success criteria (all Level A or AA; no new AAA additions beyond what already existed) and formally deprecated 4.1.1 Parsing (obsolete now that most user agents and AT no longer rely on strict HTML parse-error handling). Auditing against a WCAG 2.1 checklist silently misses the new SC and may still flag 4.1.1 findings that no longer matter for 2.2 conformance. Always confirm which version the conformance target actually names.

## New in WCAG 2.2 (verify against `https://www.w3.org/TR/WCAG22/` before citing)

| SC | Level | Principle | One-line scope |
|---|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Operable | Focused element must not be entirely hidden by author-created content (sticky headers, cookie banners) |
| 2.4.13 Focus Appearance | AAA | Operable | Minimum size/contrast for the focus indicator itself |
| 2.5.7 Dragging Movements | AA | Operable | Any drag-only interaction needs a single-pointer alternative |
| 2.5.8 Target Size (Minimum) | AA | Operable | Pointer targets at least 24x24 CSS px, with documented exceptions |
| 3.2.6 Consistent Help | A | Understandable | Help mechanisms (contact, chat, FAQ) must appear in the same relative order across pages |
| 3.3.7 Redundant Entry | A | Understandable | Don't force re-entry of information already provided in the same process |
| 3.3.8 Accessible Authentication (Minimum) | AA | Understandable | No cognitive-function test (e.g. puzzle solving) required for auth, unless an alternative exists |
| 3.3.9 Accessible Authentication (Enhanced) | AAA | Understandable | Stricter version of 3.3.8 — no object recognition/personal-content exception |
| 1.4.13 (carried from 2.1 but frequently missed) | AA | Perceivable | Content on hover/focus must be dismissible, hoverable, persistent |

Deprecated: 4.1.1 Parsing is removed as a 2.2-conformance requirement — do not cite it as a blocking finding for a WCAG 2.2 target, note that duplicate-ID/malformed-markup issues instead usually surface as 1.3.1 or 4.1.2 failures.

## Full A/AA index by principle (automated-vs-manual detectability)

Detectability legend: **A** = reliably automated-detectable by static/DOM analysis; **M** = requires manual judgment or live AT verification; **P** = partially automatable (tool flags candidates, human must confirm).

### Perceivable

| SC | Level | Detect |
|---|---|---|
| 1.1.1 Non-text Content | A | P — missing `alt` is automatable; *correctness* of alt text is manual |
| 1.2.1–1.2.5 Time-based Media (captions, audio description) | A/AA | M |
| 1.3.1 Info and Relationships | A | P — heading/landmark presence automatable; semantic *correctness* manual |
| 1.3.2 Meaningful Sequence | A | M |
| 1.3.3 Sensory Characteristics | A | M |
| 1.3.4 Orientation | AA | M |
| 1.3.5 Identify Input Purpose | AA | P — `autocomplete` attribute presence automatable |
| 1.4.1 Use of Color | A | M |
| 1.4.2 Audio Control | A | M |
| 1.4.3 Contrast (Minimum) | AA | A — contrast ratio is fully computable from rendered color values |
| 1.4.4 Resize Text | AA | M (requires zoom/reflow testing) |
| 1.4.5 Images of Text | AA | M |
| 1.4.10 Reflow | AA | M |
| 1.4.11 Non-text Contrast | AA | A — computable for UI-component/graphical-object boundaries |
| 1.4.12 Text Spacing | AA | M |
| 1.4.13 Content on Hover or Focus | AA | M |

### Operable

| SC | Level | Detect |
|---|---|---|
| 2.1.1 Keyboard | A | M |
| 2.1.2 No Keyboard Trap | A | M |
| 2.1.4 Character Key Shortcuts | A | M |
| 2.2.1 Timing Adjustable | A | M |
| 2.2.2 Pause, Stop, Hide | A | M |
| 2.3.1 Three Flashes or Below Threshold | A | M |
| 2.4.1 Bypass Blocks | A | P — skip-link/landmark presence automatable; effectiveness manual |
| 2.4.2 Page Titled | A | A — `<title>` presence/non-empty is automatable |
| 2.4.3 Focus Order | A | M |
| 2.4.4 Link Purpose (In Context) | A | P — empty/ambiguous link text flaggable; true purpose manual |
| 2.4.5 Multiple Ways | AA | M |
| 2.4.6 Headings and Labels | AA | M |
| 2.4.7 Focus Visible | AA | P — `outline: none` without replacement is flaggable; adequacy manual |
| 2.4.11 Focus Not Obscured (Minimum) | AA | M |
| 2.5.1 Pointer Gestures | A | M |
| 2.5.2 Pointer Cancellation | A | M |
| 2.5.3 Label in Name | A | P — accessible-name-vs-visible-label mismatch is automatable |
| 2.5.4 Motion Actuation | A | M |
| 2.5.7 Dragging Movements | AA | M |
| 2.5.8 Target Size (Minimum) | AA | A — computed target box size is measurable |

### Understandable

| SC | Level | Detect |
|---|---|---|
| 3.1.1 Language of Page | A | A — `<html lang>` presence/validity is automatable |
| 3.1.2 Language of Parts | AA | P — `lang` attribute presence automatable; correctness manual |
| 3.2.1 On Focus | A | M |
| 3.2.2 On Input | A | M |
| 3.2.3 Consistent Navigation | AA | M |
| 3.2.4 Consistent Identification | AA | M |
| 3.2.6 Consistent Help | A | M |
| 3.3.1 Error Identification | A | M |
| 3.3.2 Labels or Instructions | A | P — unlabeled-input detection automatable |
| 3.3.3 Error Suggestion | AA | M |
| 3.3.4 Error Prevention (Legal, Financial, Data) | AA | M |
| 3.3.7 Redundant Entry | A | M |
| 3.3.8 Accessible Authentication (Minimum) | AA | M |

### Robust

| SC | Level | Detect |
|---|---|---|
| 4.1.2 Name, Role, Value | A | P — missing role/name on custom widgets flaggable; full correctness manual |
| 4.1.3 Status Messages | AA | M |

## Non-negotiable rule for compliance-facing output

Never present an SC citation without its Level attached. Never mark a **P** (partial) or **M** (manual) row as fully resolved because an automated scanner reported zero findings for it — state explicitly which portion the scan covered and which portion still needs manual/AT verification.

## When to push back

Push back if the user asks to:

- treat a "0 issues" Lighthouse/axe report as WCAG 2.2 conformance — automated tools document their own coverage limits (see the Context7 Documentation Protocol grounding on automated-testing pros/cons); a clean scan is a floor, not a ceiling,
- skip the new 2.2 criteria because "we already did a WCAG 2.1 audit" — 2.2 added 9 new SC that a 2.1-era audit never evaluated,
- cite 4.1.1 Parsing as a blocking WCAG 2.2 finding — it is deprecated for 2.2 conformance targets.