Image Description
Accessible controls and sensible defaults
A button should behave like a button.
Ground-breaking stuff, I know.
But a surprising number of accessibility problems begin when something that looks like a familiar control does not expose or behave like one.
Use native controls when you can
Operating systems, GUI toolkits and browsers already provide buttons, checkboxes, text fields, lists and other controls. Those controls normally come with keyboard behaviour, focus handling and accessibility information.
When you replace them with a completely custom widget, you inherit all of that work.
Name
A control needs a useful accessible name. A text field labelled "Email address" should expose that label. An icon-only delete button still needs an accessible name such as "Delete".
Role
The role tells the user what kind of thing a control is: button, checkbox, heading, link, list and so on. If something announces itself as a button, users expect button-like interaction.
State and value
A checkbox can be checked or unchecked. A toggle can be pressed or not pressed. A slider has a value. A disabled control is unavailable.
Make those states available programmatically rather than communicating them only through colour or graphics.
Descriptions and instructions
Sometimes a name is not enough. If a field has a particular format or a control has unusual consequences, provide useful instructions. Keep them concise; nobody wants every button to read them a small autobiography.
Custom does not mean inaccessible
There are valid reasons to create custom controls. When you do, study the accessibility API and interaction pattern for your platform, implement keyboard behaviour and test with actual assistive technology.
The mistake is not making something custom. The mistake is assuming appearance is the entire control.
A quick way to check
- Can I reach it?
- Can I tell what it is?
- Can I tell what it does?
- Can I tell its current state or value?
- Can I operate it using the expected keyboard interaction?
If the answer to one of those is no, you've found somewhere worth investigating.
Further reading and external resources
Previous: Keyboard accessibility for developers | Next: Introduction to screen-reader testing