complex-widget-pattern-audit

Identify the intended pattern first: an editable or select-only input with a listbox, grid, tree, or dialog popup. Then verify the popup association, autocomplete behavior, keyboard model, focus ownership, and value-commit behavior all match that one pattern, and run keyboard and screen reader tests to confirm.

Roving tabindex moves DOM focus between items, keeping exactly one item tabbable. With aria-activedescendant, DOM focus stays on the owning element while an attribute references the active item. A widget should use one coherent strategy per interaction context, not mix them.

Prefer native HTML whenever a native select, button, disclosure, or link list can meet the product requirement. Custom composite widgets should only replace native controls when a documented requirement justifies it, because they carry a significant keyboard and assistive-technology validation burden.

No. Source review can establish intended roles and event handling, but keyboard behavior, computed semantics, and spoken announcements require runtime, accessibility-tree, and assistive-technology testing. The audit outputs a validation queue with exact setups, steps, and expected results for those tests.

Not automatically. The Authoring Practices Guide is informative pattern guidance, while WCAG is the normative standard. A pattern deviation only maps to a WCAG criterion when evidence shows it causes a real failure for users.

Source code alone cannot establish computed roles, actual key behavior, focus movement, or spoken output. Without a running interface, findings on keyboard interaction, focus, and announcements must be marked as needing runtime validation rather than confirmed.