Web Accessibility
Notes on Udacity's Web Accessibility course.
- Don't use low constrast text.
- Don't use tiny text
- Make click areas big
- Include keyboard controls. Make them good.
- Don't rely on colours to communicate important information
- Lay things out sensibly so that related components line up
All these things help people with various kinds of impairments, but also help normal users a bit.
Some impairments people might have:
- Blindness
- Partial sightedness
- Colourblindness
- Deafness
- Inability to use a mouse
- Inability to use a keyboard
- Inability to speak
Some tools people use to assist them:
- Text to speech, including screen readers
- Brail displays
- Magnification
- Prosthesis
- Alternative colour display software
- Eye tracker
- Switch
- Voice control
Common Classifications of Impairments
- Visual
- Hearing
- Motor
- Cognitive
And also by how long they last:
- Permanent
- Temporary
- in impairment resulting from choice or cirumstances
WCAG 2.0
Web Content Accessibility Guidelines (WCAG) is a standard.
- Perceivable
- can visually and hearing impaired people see it
- Operable
- can motor impaired people navigate it
- Understandable
- are the content and possible actions clear
- Robust
- does it work on a variety of browsers
Complicated, but they also provide a checklist.
Focus
People who use assistive technology need to be able to select interactive controls on the page.
Tab order is the order in which elements on the page become focused as you hit tab. By default, this is in DOM element order (not layout order). You can use tabindex to change this.
Tabindex -1 means unfocusable by the user (you can still use JavaScript). Tabindex 0 adds it to the natural order.
Elements with positive numbers for tabindex go ahead of the natural ordering in ascending order. It's usually better to reorder the DOM instead.
However, if you have some kind of single-page application, you may need to manipulate the tabindex attributes yourself.
You can look at the focused elements using document.activeElement.
Control Focus
Look at the ARIA best practices document to work out which keys you should map for which types of control.
There is a technique called roving focus, where you set all the options inside a control except for one to have tabindex of -1. This means that, when you tab back to that control, you are also focused on the appropriate option. It also means that tab doesn't go through all the options — use the cursor keys for that.
Focus on Invisible Elements
If things are off the screen, you may not want them to come into focus.
Skip Links
Tabbing through lots of content is annoying. We can add a link to our main content ahead of our menu items. This link should only be visible on the screen on focus.
We also need to make our the content element focusable for this to work.
Modal Dialogues
When you have a modal dialogue, remember that you need to trap the tab key behaviour.
There is a dialog element to address this, but it doesn't exist in most browsers yet.
Semantics
Assistive technologies often aren't visual, so they can't take advantage of the visual layout of the page. Instead, they use the semantic tree. The semantic tree is derived from the DOM, but throws away elements which are purely visual.
The way to make this work: use the correct HTML elements for controls. Label controls properly. Put the alt attribute on images.
Similarly, getting the header hierarchy correct is quite important.
Affordances
Affordances are usability conventions. We can see them in objects in the world around us (for example, handles on different objects usually have a similar design), but also in software UI.
Standard controls like scrollbars, radio buttons, check boxes, text input fields and so on are affordances. If we use the standard HTML elements, these will be advertised to screen readers and so on.
Writing Good Alt Text
Images should have alt text. Redundant images should have blank alt text.
What's a redundant image?
- UI decoration — like a magnifying glass icon in a search box
- An image inside a link, where the link also contains the same text already
Keep alt text short. Don't use "image of", "graphic of" or "logo". The assistive technology will probably tell them that anyway.
Similarly, you don't need to write "link to" on images which are inside links.
A simpler option for UI decoration is to add it using CSS. This way, it will not be picked up by assistive technology.
Links
For assistive technology to work, links must be done right, having a sensible description and href. Again, images inside links should have alt text.
A fake link created using JavaScript won't be picked up.
A link being used to fake a button is also a bit of a mess.
You should be able to recognise what the link is for when looking at the link text out of context. Conversely, it should be as brief as possible.
ARIA
The Accessible Rich Internet Applications (ARIA) specification is for when you need to use an HTML element incorrectly. It also helps when you need to invent some new semantics that aren't included in HTML.
It does this by adding some attributes (role, state and properties) to HTML elements. These new attributes alter the accessibility tree.
For example:
<div role="checkbox" aria-checked="true">A checkbox which is checked</div>
ARIA 1.1 roles. These roles have an inheritance hierarchy where attributes come from. It's best to check in the ARIA practices for simple instructions on how to implement a particular kind of control correctly.
ARIA has no effect on behaviour. We still need to use JavaScript to implement event listeners for keyboard events, and we still need to make the element focusable.
We also need to use JavaScript to update our ARIA attributes as the state of our custom controls changes.
Properties about relationships:
- aria-labelledby
- a list of ids for label text elements
- aria-describedby
- a list of ids for help information elements
- aria-owns
- a list of ids which should be underneath this element in the accessibility tree
Properties about notifications:
- aria-live
- when should notifications be read out to the user (off/polite/assertive)?
- aria-atomic
- in conjunction with aria-live, should we notify about everything in here even if only one part of it changes (true/false)?
- arive-relevant
- which types of changes trigger notifications (additions/removals/text/all)?
- aria-busy
- ignore all the above (true/false)?
ARIA Style
We can target ARIA attributes in our CSS to avoid some duplication.
Similarly, we should aim to use landmarks, which are HTML elements representing overall page structure (main, nav, and so on) instead of CSS classes.
Colour and Contrast
We should ensure minimum differences in terms or hue (colour) and luminance (contrast), so that people can read our content with bad eyes on bad screens.
The web accessibility guidelines recommend the following:
| Recommendation | Small | Large (18pt+) or bold (14pt+ |
|---|---|---|
| Minimum | 9:2 | 3:1 |
| Enhances | 7:1 | 9:2 |
We should also avoid using colour alone to convey information. There should be extra indicators as well, such as underlining.
Automatic Audit
You can check accessibility using the Chrome dev tools lighthouse tab (this used to be called audit).
You can also look at the accessibility properties for individual elements.
You can use the NoCoffee Chrome extension to simulate colour blindness.