behavioral-a11ylisted

# Behavioral Accessibility Automation Skill > **Canonical source**: `examples/BEHAVIORAL_ACCESSIBILITY_AUTOMATION.md` in `mgifford/ACCESSIBILITY.md` > This skill is derived from that file. When in doubt, the example is authoritative. Apply these rules when writing, running, or interpreting automated checks that manipulate a rendered page rather than only inspecting static markup or a single computed accessibility tree. --- ## Severity Scale (this skill) | Level | Meaning | | --- | --- | | **Critical** | A behavioral result is reported or gated as a confirmed failure without meeting the preconditions in this skill | | **Serious** | Indicator, `cantTell`, and confirmed-failure outcomes are collapsed into one pass/fail signal | | **Moderate** | Fleet-scale findings are not clustered by root cause before reporting or triage | | **Minor** | Missing documentation of a check's known false-positive/false-negative limitations | --- ## Critical: Why Behavioral Checks Exist Static analysis and single-snapshot browser rule scans (axe-core and similar) answer "is this attribute valid" or "does this element have an accessible name." They cannot answer questions that only exist while a page is being *used*: does layout still work at a narrow viewport, does a keyboard user get a visible focus signal, does content clip when resized or spaced out, does a dynamic UI state (open menu, validation error, loading indicator) preserve the same guarantees as the initial page state. A behavior