web accessibility

Accessibility is something I've wanted to better understand to improve my coding practices for. So I'm taking the Web Accessibility course on Udacity to learn and improve.

The Web Content Accessibility Guidelines (WCAG) by W3C outline 4 Principals of accessibility which are:

1. Perceivable: all users can perceive it; text alternatives for non text content, available in different forms
2. Operable: can all users use it, keyboard support , time adjustable (e.g. slower playback), navigable (focus, link content, titles, bypass, multiple ways)
3. Understandable: can all users understand (language, words, reading level, abbreviation). Consistency: navigation, error prevention & handling & display, 
4. Robust: does it work with all agents including assistive; no html errors, right use of markup 

Abbreviated to POUR

The WCAG provide a checklist to help identify and improve your apps accessibility.

1. focus

• focus determines where keyboard event go on the page) and is critical to accessibility; 
• it is the control on screen which receives input from keyboard, clipboard and screen; tabbing or clicking directly is how to give focus using keyboard (using tab, shift, arrow keys and spacebar)
• some dom elements naturally accept focus e.g. buttons, links, select but many others do not (e.g. headers, images). 
• dom order typically determines tab order
• for those that don't you can use tabindex to add to tab order; tabindex can be applied to any element
• tabindex="0". adds to natural order and will get keyboard events
• tabindex="1"  jumped to front of tab order (antipattern)
• tabindex="-1" for something offscreen that only gets focus when appears (e.g. a modal which you give focus to)
• 
  
• only give tab order if can be interacted with (an exception would be if navigating around in spa app then could give tabindex="-1" and set focus manually to jump to content on the page)
• skip link: create a link at top of dom which href links to anchor and so skips to main content e.g. href="#maincontent"

aria design patterns and authoring practices (focus)

the w3c wai-aria design patterns doc lists how controls should support a11y including role, keyboard interaction and more

its a great guide if you're building your own custom components which you could model off other existing patterns

the "roving focus" technique is a way to manage focus on custom components

2. semantics

• assistive technology is any tool/technology to help people with disabilities e.g. screen reader, magnification, voice (or even a pair of crutches)
• affordances - form and design help us understand how to use things; represent actions we can take e.g. for a ui: buttons, sliders
• semantics is about ensuring information is expressed in a way that is easy to understand
• 
  
• a screen reader provides auditory explanation of the ui and will announce elements name (label), role, state and value
• the design patterns doc tells us what roles to use for kinds of controls
• screen reader takes the dom tree and converts it into an "accessibility tree" which is essentially same as dom tree with content needed by a screen reader
• it is important to use the right html elements for what we're trying to do because by default they provide the right reader and keyboard experiences e.g. button (not div) for buttons
• labels can be visible or text alternative (e.g. img alt and title tag)
• form inputs should have labels (either using for attribute or wrap in label) e.g. checkboxes
• image: alt text used as alternative to img and used by readers; 
• you can use an empty alt text (alt="") if it's unnecessary e.g. alt text for search magnifying glass or images wrapped in links which already has text

general

use semantic tags e.g. <button> for button

• if you can't use a semantic tag then add a role e.g. role="button"

ensure controls are navigable and can be triggered by the keyboard

• for tabbing add tabindex="0" to make sure can be tabbed to

Use aria-label for buttons that don't have text e.g. if just have icon 

e.g.  

<button aria-label="Help"><i class="icon"></i></button>

you can also add an aria-label="Menu" or similar to add meaning

e.g.

 <div class="button" tabindex="0" aria-label="Menu">

forms

labels should read out

clicking on label should jump to control (input, radio etc)

• you can use explicit label (wrap form input in label) or use the label "for" attribute

group related items in a <fieldset> e.g. list of radios

tools

Safari accessability inspector

Safari voice over CMd + F5