CHAPTER 5 OF 5
5. Check and avoid pitfalls
Your goal: verify what the interface communicates and what it actually does.
Check the working example
- Tab to the button. Its name should be Workshop details and its role should be button.
- Use Enter and Space separately. Each activation should toggle exactly once.
- Check that expanded/collapsed state matches panel visibility.
- When expanded, Tab can reach the panel’s link. When collapsed, it should not.
- Check the ID relationship and test the revealed content’s reading order.
- Review the control with a screen reader in your target browser. Exact announcements vary.
- With JavaScript unavailable, confirm that the details remain readable.
Watch for these common mistakes
- Hidden focus targets:
aria-hidden="true"does not visually hide content or remove keyboard focus. Do not apply it to focusable content or its ancestor. - Disabled in name only:
aria-disableddoes not prevent activation by itself. Use native disabled behavior where appropriate, or implement the promised behavior. - Unnecessary menu roles: ordinary site links usually do not need
role="menu", which brings different keyboard expectations. - A new label on everything: replacing existing names can conceal useful visible wording.
What about aria-live and alerts?
Live regions concern changes announced without moving focus, such as a result count. Choose timing and urgency carefully. They do not replace correct labels or keyboard behavior, and this basic disclosure does not need an alert every time it opens.