Image Description
Accessible development
Accessibility works best when it is part of development, not something bolted on five minutes before release while everybody looks worried.
I use a screen reader myself, so this section is not about ticking a mysterious accessibility box and declaring victory. It is about making software that people can actually use.
Accessibility is broader than screen readers
Screen-reader accessibility matters, but it is only one part of the subject.
People may use a keyboard without a mouse, magnification, speech input, high contrast settings, alternative pointing devices or other assistive technology. Some users benefit from clearer language and predictable interfaces.
Start with the keyboard
Can every important action be completed without a mouse? Can you tell which control currently has focus? Does Tab move through controls in a sensible order? When a dialog opens, does focus move into it?
If the keyboard experience is broken, there is a good chance some assistive technology users are going to have a bad day too.
See keyboard accessibility for developers.
Give controls useful names
A screen reader needs enough information to tell the user what a control is and what it does.
"Button" is technically information. It is not particularly useful information.
A control normally needs an accessible name, the correct role and an understandable state or value where appropriate.
Use native controls where possible
Standard controls generally come with expected keyboard and accessibility behaviour. If you build your own clever replacement, you also take responsibility for recreating the semantics and behaviour users rely on.
See accessible controls and sensible defaults.
Do not communicate by appearance alone
Colour, position, icons and animation can all be useful, but important information should not depend solely on them.
"Press the green button on the right" is not a brilliant instruction if the user cannot perceive green or cannot see where "the right" is.
Errors need to be understandable
If validation fails, tell the user what went wrong and where. Changing a border from black to red may look obvious to one user and communicate absolutely nothing to another.
Test with real assistive technology
Automated tools are useful, but they cannot tell you whether the complete experience makes sense.
Use the keyboard. Try a screen reader. Work through the actual task a user needs to complete rather than merely checking that every control produces some speech.
See introduction to screen-reader testing.
Do not test only the happy path
Try opening dialogs, cancelling them, entering invalid information, losing network access, navigating backwards and doing things in an order you did not expect.
Accessibility bugs have a remarkable ability to hide in error messages and unusual states.
Ask users
If people who use assistive technology report a problem, listen to what they were trying to achieve, not just the individual keystroke that failed.
Where do I start?
- Keyboard accessibility for developers
- Accessible controls and sensible defaults
- Introduction to screen-reader testing