Accessibility

Accessibility (a11y) means designing so that everyone can use your product — people who navigate by keyboard instead of mouse, people who use screen readers, people with low vision or color blindness, people on slow connections. It is not a niche concern: roughly one in four adults has some form of disability, and accessible design is simply good design.

The good news: most of the practical wins are not hard. They just require the habit of thinking about them.

Alt text for images

Screen readers announce images by reading the alt attribute. Without it, a screen reader user either hears nothing or hears a long cryptic filename.

<!-- Bad -->
<img src="hero.jpg" />

<!-- Good -->
<img src="hero.jpg" alt="A designer sketching wireframes on paper" />

Rule: describe what the image shows and why it matters in context. For decorative images (background textures, purely visual dividers), use alt="" — that tells the screen reader to skip it.

Color contrast

WCAG (Web Content Accessibility Guidelines) defines minimum contrast ratios:

4.5:1 — normal body text (below 18px or 14px bold)
3:1 — large text (18px+ regular, 14px+ bold), UI components, icons

In Figma, use the Contrast plugin or check contrast in Design > Inspect. A purple #7C3AED button with white text passes at large size but check small text carefully.

Labels for form inputs

Every form input needs a visible <label> linked to its input. Placeholder text is not a label — it disappears when the user types and has low contrast.

<!-- Bad: no label -->
<input type="email" placeholder="Email address" />

<!-- Good: proper label -->
<label for="email">Email address</label>
<input type="email" id="email" placeholder="[email protected]" />

Focus states

Users who navigate by keyboard need to see which element is currently focused. Browsers provide a default outline, but many designers remove it with outline: none — breaking keyboard navigation.

Keep focus visible. Style it to match your brand instead of removing it:

.btn:focus-visible {
  outline: 3px solid #7C3AED;
  outline-offset: 2px;
}

Semantic structure

Use heading elements (<h1> through <h6>) for hierarchy — not for their size. Screen readers use headings to let users jump around the page, like a table of contents. A page should have exactly one <h1>, and headings should nest logically.

Also use landmark elements: <main>, <nav>, <header>, <footer>, <aside>. They let screen reader users skip directly to the content they need.

A form with good accessibility

The form below demonstrates labeled inputs, proper contrast, and a styled focus ring. Tab through the fields to see the focus indicator.

<form class="contact-form">
  <div class="field">
    <label class="label" for="name">Full name</label>
    <input class="input" type="text" id="name" name="name" placeholder="Alex Chen" />
  </div>
  <div class="field">
    <label class="label" for="email">Email address</label>
    <input class="input" type="email" id="email" name="email" placeholder="you@example.com" />
  </div>
  <div class="field">
    <label class="label" for="message">Message</label>
    <textarea class="input" id="message" name="message" rows="3" placeholder="Tell me about your project..."></textarea>
  </div>
  <button class="btn" type="submit">Send message</button>
</form>

Tab through the form using only your keyboard. Each field should show a clear purple outline when focused. This is what keyboard-only users rely on.

Common mistakes designers run into

Removing the focus outline with outline: none for looks, without providing another focus style — making the page unusable by keyboard
Forgetting alt text for meaningful images
Using colors that don’t meet WCAG contrast requirements

The developer’s perspective

👨‍💻 What developers actually see

Designers see “a page that looks nice and the contrast seems fine,” but developers have to check the actual contrast ratio against WCAG, write alt text that’s actually meaningful, and test with a real keyboard and screen reader.

💡 Real-world example

UK public-sector websites are legally required to meet WCAG 2.2 AA under the Public Sector Bodies Accessibility Regulations 2018 — which is exactly why government design systems like GOV.UK’s tend to be strong accessibility references. (GOV.UK Service Manual: Accessibility)