dynamic-interface-accessibility-audit

Audit dynamic interfaces by testing state transitions rather than settled end states: trigger loading, error, success, and dismissal states, record focus before and after each change, and verify live-region announcements with a named browser and screen reader. This Skill structures that workflow into a repeatable evidence-based process.

Test live regions by triggering one update at a time, then rapid, repeated, and out-of-order updates, recording the actual spoken output for a named browser and assistive-technology combination. Check for silent updates, duplicates, stale messages, and overuse of assertive interruption.

No. Automated tools only cover the rules they implement in the scanned state and cannot establish focus behavior, announcement quality, or interaction usability. Runtime browser testing and assistive-technology passes are required, and untested areas must be recorded as coverage gaps.

No. The audit maps findings to specific WCAG 2.2 criteria with rationale, but it is a focused review of dynamic behavior and explicitly does not establish page or product conformance. Conformance level is never used as a severity measure.

Source review confirms intended DOM structure, declared ARIA, event and focus code paths, and test coverage, but it cannot establish computed names, actual focus order, timing, or spoken output. Those claims remain provisional until runtime or assistive-technology evidence exists.

Avoid it for static-only concerns like visual contrast or document structure with no changing behavior, for future test planning without existing evidence, and for legal advice or certification requests. It reports findings and recommendations but does not modify product files.