Custom controls have expected keyboard interactions
Design Notes
Design an intuitive keyboard interaction
When designing controls and widgets that are covered in the ARIA authoring practices (such as non-native form controls, tabs, modals and sliders) follow the keyboard Interactions specified.
More information
- ARIA Authoring Practices (details under the 'Developing a Keyboard Interface' heading)
Developer Notes
Implement expected keyboard interactions for custom controls
Links that are given a role="button" also need to behave like a button, ie user needs to be able to activate them using the space bar.
Custom (non native) interface patterns such as tab panels and expand and collapse accordion components should be built to support expected and conventional keyboard interaction.
Refer to the authoring practices documents to ensure requirements are adhered to during build. Ideally, test keyboard interactions as pages are built, too.
Information and tools
Testing Notes
Controls have expected keyboard interactions
Standard form controls are used, or non-standard controls are properly marked up using ARIA and the expected keyboard interaction has been implemented.
Refer to the ARIA authoring practice information to check what keyboard interaction is expected by component. Test this has been implemented using e.g. Tab, Space bar, Enter and arrow keys.
- Accordions and disclosure (Show/hide)
- Buttons and Menu buttons
- Dialogs (Modal)
- Tabs
- Tooltips
Impact range: Medium-High
Test type: Manual
WCAG Reference: Understanding Success Criterion 4.1.2 Name, Role, Value
ARIA Reference: Accessibile Rich Internet Applications (WAI-ARIA) 1.1