Tue 24 Apr 2018 — Thu 03 May 2018

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 audit tab.

You can also look at the accessibility properties for individual elements.

You can use the NoCoffee Chrome extension to simulate colour blindness.