The term “accessibility”, when applied to the web, means providing services and products that everyone can use, no matter who they are, what they do, or where they come from.
It means everyone should be able to use and consume a website content regardless of gender, gender identity and expression, age, sexual orientation, disability, physical appearance, body size, race, ethnicity, religion (or lack thereof), or technology choices.
In other words, it means having a bit of empathy and caring about the users we are building these products and services for.
Let’s get something out of the way right away: designing and building with accessibility in mind literally always results in better products, and is not necessarily harder, more expensive or longer.
“Accessibility and good UX are about doing the right work, not doing more work.”
— Heydon Pickering
Long story short: accessibility is not the cherry on top of the cake. This is what we do. Making a product fundamentally unaccessible has virtually no point whatsoever.
“1. Accessibility is not an edge case.
2. Hire and work with disabled people: they will make you innovate.”
— Alice Boxhall
The truth is that “people with disability” is the only minority group that anyone can join at any time.
“Most people with a disability weren't born with it. As we age the likelihood increases that we'll experience.”
— Neil Milliken
Statistics vary a lot from country to country, but we evaluate the amount of people with a limiting long term illness, impairment or disabilitty to be around 15 to 20%. [1]
In some countries, the amount of adult with a disability or long-term health condition could be as high as 40%, ranking up to over 50% for seniors. [2] [3]
Of those disabled people, more than a third of them experience difficulties related to their impairment in accessing public, commercial and leisure goods and services. [4]
They are also significantly more likely to experience unfair treatment (at work) than non-disabled people. [5]
Further readings: Disability facts and figures.
For the most part, working with accessibility in mind means not being a bigot so we’ll skip to the most complex part directly: designing and building for disabled people.
When we mention “disability” on the web, we often think of visually impaired or blind people. Actually, there are 4 types of disabilities we should concern ourselves with:
- Vision disabilities
- Mobility & physical impairments
- Cognitive & learning disabilities
- Hearing impairments
This is probably one of the most common form of disability we have to care for as it concerns anyone ranging from low vision to no vision at all, as well as anyone with any form of color blindness such as red/green (protanomaly, protanopia, deuteranomaly, deuteranopia), blue/yellow (tritanomaly, tritanopia) or complete color blindness (monochromacy, achromatopsia). Note that color blind people represent up to 10% of the global population[6]. Here are a few things we can do to help.
Further readings: Designing for low vision by gov.uk.
Using large font size or providing a way to adjust it. The lack of space has always and will always be somewhat a problem on small screens, but some people can’t deal with very small text. Serving content in a big enough size is important, or at least there should be a way to adjust that. The browser usually handles this natively; not disabling this feature is a good start.
Who: designers, front-end developers.
Providing meaningful text alternative to anything strictly visual such as images and graphics. A lot of people with low visions and people with complete absence of vision are using screen-readers, that are programs which allow them to use and browse the (correctly built) web. These tools will rely on alternative text and meaningful document structure to function properly and empower their users. Along the same lines, make sure links contain enough information on their own as they are listed without their surrounding by screen-readers; therefore avoid links like “click here” or “please”.
Who: copy-writers.
Further readings: WebAim, Smashing Magazine.
Making sure contrast ratios are high enough. When in doubt, use this helpful contrast ratio checker (aim between 3 and 4.5:1). This accessible color palette builder also comes in super handy. For instance, this is not okay (both grey and blue are too light):
Who: designers.
Further readings: WACG guidelines on contrast, Salesforce UX accessibility design tips.
Never conveying information through color only. There is a reason why links are natively underlined on the web, it’s so that color blind people can distinguish them from copy text. As an example, this is what someone with a severe protanomaly would see for labels on Trello and how they leverage that with a color-blind-friendly mode (screenshot taken with the “See” Chrome extension):
Who: designers.
Further readings: Salesforce UX accessibility design tips, UCLA, On link underlines.
Test with a screen-reader, such as VoiceOver, JAWS or ChromeVox. Even without being an efficient screen-reader user, the amount of low hanging fruits to be found by browsing around is astonishing.
Who: developers, QA engineers.
Further readings: How screen readers read elements from HTML.
Any people with limited dexterity or upper limb disability can have problem browsing the web (amongst other things). We should even consider people using the web on mobile and with large fingers. Here is what we can do about it.
“My disability exists not because I use a wheelchair, but because the broader environment isn't accessible.”
— Stella Young
Further readings: Designing for physical or motor disabilities by gov.uk.
Being forgiving with finger/mouse interactions. Controls should be big enough so they are easily tappable / clickable, and mouseover interactions should not be tricky to achieve (dropdown menus, tooltips, etc.).
Who: designers, front-end developers.
Further readings: Dropdown Menus with More Forgiving Mouse Movement Paths.
Designing with keyboard in mind. For people browsing with the keyboard exclusively, the tab-order should be sensible, and all focusable elements should have a clear focused state. It’s fine to remove the native focus outline as long as an alternative styling is provided.
Who: designers, front-end developers.
Further readings: Salesforce UX accessibility design tips, W3C, WebAim.
The naming “cognitive & learning disabilities” regroups people with attention deficit disorder (ADD), all forms of autism, dyslexia and to a lesser extent dementia. It turns out there is a lot we can do to make these users’ experience much easier.
Further readings: Designing for dyslexia by gov.uk, Designing for dyslexia - part 1/2, How to design for dyslexia, Designing for autism, Designing for the autistic spectrum by gov.uk.
Polishing font settings. People with dyslexia and reading disorders usually struggle with justified text and all caps content so make sure to use side-aligned and proper capitalisation. Large and consistent spacing and line-height also helps. A dyslexia-friendly feature could be providing a “night mode”, or an alternative font such as OpenDyslexic or Comic Sans.
Who: designers, front-end developers.
Simplifying the language use and focusing on clarity. For a lot of people with cognitive disabilities, the lack of clarity can be a big issue. By simplifying the language and reducing the amount of text we can make sure they are able to consume our content seamlessly. Iconography matters but it should always come with associated text, especially when used in a non-conventional way (e.g. not universally recognised icon).
Who: designers, copy-writers.
Further readings: Viget.
Using invisible animations. Some people deal very poorly with heavy animations and on-screen motion; these can go from triggering motion sickness to spacial loss. Animations should serve a purpose and should feel invisible. They should be fast and snappy, to the point where the transition from an initial state to a final state seems nice and transparent.
Who: designers, front-end developers.
Further readings: Invisible animations, The importance of Context-shifting in UX patterns.
Hearing impairment is usually not so much of a problem on the web as this is mostly a visual medium but there are still things we can do for people having full or partial hearing loss.
Provide captions and/or transcripts for audio and video content. All videos should be subtitled. The nice side-effect from this is that it also helps perfectly hearing non-native speakers.
Who: content providers, copy-writers.
Further readings: Designing for for low or absence of hearing by gov.uk.
Your role as a designer is to consider all users from the ground-up. Design around content rather than aesthetics, and make sure everything is clear and obvious. The rest should come quite naturally.
“Designing for accessibility means considering all users from the start.”
— Alistair Duggin
- Make sure color contrasts are sufficient.
- Never convey information through color only.
- Design focus states to help users navigate and understand where they are.
- Help users understand inputs, and help them avoid and correct mistakes.
- Create another route for users to get information if an experience cannot be made accessible.
- Be as consistent and clear as possible in layout and copy.
Source: Vox Media accessibility guidelines — Designers.
As a developer, most of your role is not to screw up what’s already up. The web is inherently accessible in the first place. Browsers are incredibly good tools, and screen-readers are for the most part excellent pieces of software.
Build things in the correct way: HTML first, then CSS and enhance with JavaScript and ARIA when relevant. Clean and semantic HTML is the foundation of an accessible web.
- Use valid and semantic HTML:
- Add a valid
langattribute to<html> - Don’t disable zooming
- Use appropriate HTML5 elements
- Maintain consistent heading hierarcy
- Use native browser controls where possible
- Make sure only
<a>and<button>are “clickable” - Label all form elements
- Don’t use placeholders as labels
- Add a valid
- Understand the impact of CSS:
- Test without CSS to ensure logical order
- Make content big enough and contrasted enough
- Ensure pseudo content is meaningful as it’s read out loud
- Hide decorative elements from screen screen-readers
- Don’t remove focus styles or provide alternatives
- Consider ARIA when applicable
- Use HTML landmarks
- Enhance with JavaScript powered ARIA
- Make SVGs accessible to assistive technology.
- Create alternate routes for users to access information.
- Give users a way to skip top level navigation to access main content.
“A very easy way to improve accessibility is to look at a page without CSS and consider if it makes sense.”
— Hidde
Source: Vox Media accessibility guidelines — Engineers.
- Familiarize yourself with the work associated with making content accessible.
- Build in time for accessibility during project planning and sprint planning.
- When sharing good work done by your team, praise efforts to increase accessibility.
- Be an advocate for accessibility.
Source: Vox Media accessibility guidelines — Project Manager.
- Write good alt text for images and visual content.
- Think about how custom experiences can be made accessible.
- Be as consistent and clear as possible.
- Write descriptive links.
- Make sure to provide alternative text for important information that is shared through images, color, or sensory characteristics alone.
Source: Vox Media accessibility guidelines — Editorial.
- Run through each page with the WAVE Chrome extension or Chrome DevTools Accessibility Audit.
- Try using the page with the keyboard exclusively.
- Try using the page with a screen-reader, such as VoiceOver (VoiceOver cheatsheet) or ChromeVox.
- Make sure the general architecture and hierarchy of the content make sense.
- Make sure all charts and images have alternative text.
- Make sure decorative images is not visible to screen readers.
Source: Vox Media accessibility guidelines — QA.
- Web Content Accessibility Guidelines (WCAG) 2.0
- Web Accessibility in Mind - WebAim
- Interactive WCAG 2.0 - Viget
- A List Apart Accessibility - A List Apart
- Accessibility posters - UK Gov
- ARIA examples
- ARIA patterns
- Short note on improving usability of scrollable regions – Pacellio Group
- Clarity Conf: Baking Accessibility In
- HTML5 Accessibility browser support
- Tabs – a 3-step journey from HTML to ARIA
- Tab Panel, the right way…
- How screen readers read elements from HTML
- Aural UI of the Elements of HTML
- On link underlines
- ARIA Bookmarklet for Accessibility Testing
- Considerations for Testing with Speech Recognition Software
- Designing for Accessibility: The Ultimate in UX
- Digital accessibility resources
- Good design is accessible
- Using zero-width spaces and hidden full-stops to improve screen reader output
- Beware smushed off-screen accessible text
- Game accessibility guidelines
- Accessible UI Components For The Web
- Why innovation should be accessible for all
- Patterns for accessible webchats
- Building a better, accessible web
- Rules for Using ARIA in HTML
- Is it Accessible?
- When we design for disability, we all benefit
- CSS Hide-and-seek
- Accessible footnotes with CSS
Also find a very complete list of developer tools and browser extensions around accessibility on GitHub.
- Source: Family Resources Survey 2011/12 ↩
- Source: Australian Bureau of Statistics, September 2011 ↩
- Victorian Health Promotion Foundation (VicHealth), 2012 ↩
- Source: ONS Opinions Survey 2010 ↩
- Source: Fair Treatment at Work Survey 2008 ↩
- Source: Facts About Color Blindness. NEI. February 2015. Retrieved 29 July 2016 ↩