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
Accessibility
By Michał Przyszczypkowski
Accessibility
- 270