Working for FAC!
Imagine a distant past…
The web has everything we know on it, and you can read it all. Nothing’s stopping you. Maybe the fact that that still blows my mind marks me as an old fogey, but honestly, how can that not?
—@seldo, npm co-founder
Something is stopping people.
Accessibility shouldn’t be a special effort
Accessibility is a part of UX.
Design for diversity, not disability
Good design is inclusive
Inclusive design is good
It benefits more people than you might think.
4.5% of the population are colour-blind (9% of men)
10m people in the UK are disabled (~17% of the population)
Half are over state pension age
Everyone benefits from accessible design.
user with poor vision or me reading my phone in bright sunlight 😎
deaf user or me when I forget my headphones at work 🎧
user with one arm or me drinking a beer 🍺
Not all users are like you or your teammates
Not everyone always has great eyesight.
Not everyone always has a powerful modern device.
Not everyone always chooses the browser they use.
Design for everyone.
May struggle to perceive the difference between certain colours.
Do not rely solely on colour
Allow customisation/colour-blind mode
May need to increase the text-size in my browser.
Do not prevent zoom
Scale UI based on font-size
May need to use a screen-magnifier.
Show things in context
Logical content flow
Need to use a screenreader.
Information isn’t solely visual
Programmatic access to structured content
May struggle to hear things.
Provide text alternatives to audio content
Transcripts and/or subtitles
Cannot hear anything. Sign language may be first language
Subtitles can be hard to follow, may prefer signed content
Option for non-phone communication
May struggle to use a mouse or touchscreen with fine control.
Large interactive targets
Lots of padding for links/buttons
Have to use a keyboard instead of a mouse.
DON’T DISABLE FOCUS OUTLINES
Logical document flow so focus doesn’t jump around
Ensure custom UI works without a mouse
Uses voice-input instead of a mouse or keyboard.
Test interface with speech-recognition software
Logical labels as they have to describe UI elements
May struggle to process written text or spell
Don’t require exact spelling
Write content in simple English
Clear subheadings to divide content
May struggle to remember previous information or get easily confused.
Don’t require memorising info from previous steps
Avoid time-limits for task-completion
The Web Content Accessibility Guidelines are a set of best practices.
To meet guidelines sites should be:
The guidelines can be quite dry, so here’s a cheatsheet:
Can all users perceive your UI?
e.g. text with sufficient size/contrast/line-height, images with alt-text, alerting screenreaders to dynamic content.
Can all users operate the UI components and navigation?
e.g. ensure keyboard functionality, no unnecessary time-limits, descriptive link text, hierarchical headings, unique & descriptive page titles.
Can all your users understand the content and how to use the interface?
e.g. use plain English, set the
lang attribute, label inputs, provide error messages in context.
Can your content be understood by different user-agents/assistive tech?
e.g. semantic HTML (and ARIA when this fails you), automated and manual testing.
Web Accessibility Initiative – Accessible Rich Internet Applications…
A spec for assigning meaning to meaningless markup.
Useful where functionality is added with JS
Turns div-soup into something a screenreader can understand.
Visually obvious content might need a text label.
<button aria-label="toggle menu">☰</button>
Signifies your custom component as a type assistive tech can recognise.
e.g. a custom
<select> using divs could use
Ensures dynamically updated content is read out.
aria-live="polite" will be read once the current info finished
aria-live="assertive" will interrupt.
Actually use your UI!
Unplug your mouse. Try browser extensions that simulate visual conditions.
Chrome Lighthouse, pa11y, aXe.
🐦 Twitter: @_oliverjam | 🐙 Github: @oliverjam | 🌐 Web: oliverjam.es