What you will learn

• Define accessibility without relying on "disability" as a stand-in for the whole idea
• Explain the difference between permanent, temporary, and situational access needs
• Describe the curb-cut effect, with an example of your own
• Recognize accessibility as a design quality, not a compliance checkbox

The idea

Accessibility is the practice of designing and building products that people can use regardless of ability. That includes people who are blind or have low vision, people who are deaf or hard of hearing, people with motor impairments who cannot use a mouse, people with cognitive or learning disabilities, and people with temporary or situational limitations that are not disabilities at all.

That last part is the piece most designers miss. Access needs are not a fixed list of "disabled" and "not disabled." They sit on a spectrum, and they shift with context:

• Permanent: someone who is blind uses a screen reader every day, for life.
• Temporary: someone with a broken arm cannot use a mouse for six weeks.
• Situational: someone holding a sleeping baby in one arm cannot use two hands, for the next twenty minutes.

All three people need the same thing from your interface: full keyboard operability, clear labels, sufficient contrast. Design for the permanent case, and the temporary and situational cases are solved for free.

This is the curb-cut effect. Curb cuts, the small ramps at the corner of a sidewalk, were built for wheelchair users. Parents pushing strollers use them. Travelers pulling suitcases use them. A feature designed for a specific access need ends up helping nearly everyone.

Live demo: hear the difference

Toggle between states to hear what the screen reader announces for this button.

Without the label, the screen reader announces "button" with no context. With it, the user hears "Remove Wireless Keyboard, button," a complete, actionable description.

The one-line fix

This is what the missing label looks like in the HTML the developer ships. Adding aria-label to the <button> element gives the browser a name to pass to the accessibility tree.

<button>
  <svg>...</svg>
</button>

<button aria-label=
  "Remove Wireless
  Keyboard">
  <svg>...</svg>
</button>

The screen reader reads this value when focus lands on the button, giving the user a complete description before they decide whether to activate it.

Common mistakes

• Treating accessibility as a synonym for "blind users and screen readers" and stopping there.
• Treating accessibility as something added at the end of a project, during QA.
• Assuming accessible design and good design are in tension.

Quick check