Accessibility

aka "The Humane League" case study

What's Accessibility? 

A11Y?

WCAG

Main kinds of disability

Visual

Hearing

Mobility

Cognitive

Tools

Headings Map

Lighthouse (Chrome devtools audit built-in)

Wave Evaluation Plugin

Keyboard

Enter - action (open link, press button)

Space - toggle action (select checkbox, open/close element)

Arrows - change value in number inputs, move cursor in text

Esc - close modals, expanded comboboxes, cancel prompts

General Practices

"Standards over custom"

  • HTML sematic tags whenever possible
    • links: <a />
    • clickable elements: <button />
    • image: <img alt="..." />, <figure/>, <caption />
    • main, nav, header, ul, li, h1-h6, p, article, aside etc.

Let's code

A menu with one togglable submenu

 

(It needs to be usable using keyboard)

Checklist

  • outline focused elements

  • don't rely on browser/device specific events (like hover, mouseover etc)

    • if you allow action on hover, need to have a fallback for keyboard

  • don't rely on keyboard key codes, use HTML interactive elements instead (buttons, links have full support out of the box)

    For example, listening to a keypress event and looking for a key code 13 (Enter key) will only catch a real keyboard's Enter key. But it won't catch a screen reader's Enter key, as pressing Enter with a screen reader running will typically fire a click event instead.

  • `tabIndex` - only use 0 (if element should be focusable) or -1 (if it shouldnt)

Screen reader

  • sits on top of browser - can't check version programatically

JAWS with IE: 24.7%

NVDA with FF: 23.6%

JAWS with FF: 15.1%

VoiceOver/macOS with Safari: 10.0%

  • 1-dimension instead of 2-dimensions (top to bottom)
  • visual attributes are ignored
    • exception: display: none, visible: hidden
    • to hide only visually - move outside the screen

Screen reader

Preferences -> Accessibility -> VoiceOver -> "Enable VoiceOver"

Control + Option + Shift + Arrow Down

To enter the website area:

Control + Option + Arrows

To navigate:

Screen Reader Support

Aria properties

  • modify default meaning / role of the element
  • additional information about the element
  • used when the desired sematics can't be achieved with HTML standard elements
​ARIA indirectly affects what is reported to a screen reader or other assistive technology.

role

  • overrides the native role semantics
  • doesn't change the behaviour
<h1 role=button>text</h1>
<button role=heading aria-level=1>text</button>
<img role=presentation>...</h1>

Announced as a button

Announced as a <h1> header

Announced without role (like <div>)

properties

defines additional information about the element, which cannot be derived from native HTML semantics

<label for="telefon">
    Numer telefonu
</label>
<input 
    type="text" 
    name="telefon" 
    id="telefon" 
    aria-required="true" 
    aria-describedby="tel_info"
>
<p id="tel_info">
    Numer telefonu nie może zawierać spacji i myślników
</p>
<button aria-label="Close" onclick="close">
    <img src='/close.png'>
</button>

states

  • aria-hidden
  • aria-expanded
  • aria-selected
  • aria-pressed

Let's code

Describe menu with aria attributes and make it usable with screen reader

Dynamic content

Alert

<p role=alert>alert</p>

Let's code

Add new message with role alert attribute after click on button and check it in your screen reader

Aria-live

<div aria-live="off">alert</div>
<div aria-live="polite">alert</div>
<div aria-live="assertive">alert</div>

Let's code

Create counter with aria-live

Links

Made with Slides.com