Terminology

Inclusive design

Inclusive design is designing for the diversity of our users. It's the process of making conscious decisions to check our assumptions about who is and isn't our audience, and the abilities they have or don't have. Lots of disabilities are 'invisible', and won't show up in analytics or statistics.

Accessibility

Accessibility is the implementation of inclusive design in HTML, CSS, and JavaScript. There are two sets of guidelines worth looking up:

WCAG (Web Content Accessibility Guidelines): WCAG gives guidelines for levels of accessibility - Level A for meeting a baseline, Level AA for doing it well, Level AAA for doing it excellently
WAI-ARIA (Web Accessibility Initiative-Accessible Rich Internet Applications Suite)

WCAG principles

Designs should be:

Perceivable
Operable
Understandable
Robust

At the most basic level, users must be able to process and perceive information. They need to be able to operate websites and applications with a variety of tools. If users can perceive and operate a website, that doesn't mean they can understand it. Understandable websites use clear, concise language and offer functionality that is easy to comprehend. Additionally, users pick their own mix of technologies. Within limits, websites should be robust enough to work well enough across platforms, browsers, and devices to account for personal choice and user need.

Three lenses to consider

Cognitive lens

Example: a user reading content in their second language.

What might make things more difficult for this kind of user? Unusual words or jargon might mean they don't understand. Is the language plain and clear?

What if they...

are distracted or in a rush?
are reading something in a second (or third) language?
are tired, stressed, or depressed?
have autism, dyslexia, or a learning disability?

Physical lens

Example: a keyboard-only user. They don't use a mouse for moving around, dragging and dropping. They use the tab key to move through the page.

What might make things more difficult for this kind of user? Interactions like drag and drop will take longer. Moving through the page is more jumpy as they're moving in discrete steps rather than a continuous movement.

What if they...

are in a moving vehicle like a bus or train?
have an injury or illness?
have decreased and less precise motor control (perhaps from old age)?
have a condition like arthritis, cerebral palsy, fibromyalgia, lupus, or MS?

Visual lens

Example: a (blind) screen reader user. Not all screen reader users are blind, but for this thought experiment, let's consider a blind user. They get the text-only version.

What might make things more difficult for this kind of user? They can't see the layout or icons. What will they hear?

What if they...

are outside on a sunny day with a shiny screen?
are colour blind (colour vision deficiency)?
have low vision or poor eyesight (perhaps from old age)?
are completely blind?

Notes

Every form control needs a name (visible or not)

Example: buttons that are just icons.

Be explicit in the design! Annotate things with accessible names. We can use the word 'label' as a shorthand, but 'accessible name' is better (it's a bit more precise). See the documentation on state names for more information.

Each interactive thing on a page requires the following:

Identity
Operation
State

Operation and state are communicated by the control itself (e.g. a checkbox can be checked or unchecked, and its state is communicated to the user). Identity is the control's name. This can either come from a visible label (preferred) or from an ARIA attribute in the code.

Every group of controls needs a name (visible or not)

Example: a set of radios buttons for choosing your favourite colour: red, green, or blue.

Each radio has a name (red, green, blue), but we also need a name for the group ('Favourite colour'), so that the user knows what they're choosing red, green, or blue for. Without a group name, the user has no context for what they need to select.

Standard controls are much better for accessibility

Examples: radio buttons, checkboxes, text inputs.

They're well supported by the technology and they're well known by users. They can be combined, but don't forget the two notes listed above. There are some standard, accessible patterns for more complex things, but this requires extra work and may not be as well supported or as well known by users.

Browser not supported