Accessibility — Design for Everyone
What you'll learn
- What accessibility (a11y) means and why it matters
- Color contrast, alt text, keyboard navigation
- The idea that a11y helps everyone
- You'll fix a page's accessibility issues
Design for everyone 🌍
Over 1 billion people live with some disability — vision, hearing, motor, or cognitive. Accessibility (often "a11y" — a, then 11 letters, then y) means designing so everyone can use your product, including people who are blind, have low vision, are colorblind, can't use a mouse, or use assistive technology. It's not a niche add-on; it's part of designing well. In many countries it's also a legal requirement.
The key practices (each simple, each huge for someone):
1. Color contrast. Text must stand out enough from its background to be readable. That trendy light-grey-on-white looks elegant but is invisible to many. The standard (WCAG) requires a contrast ratio of at least 4.5:1 for normal text. Free tools (WebAIM Contrast Checker) tell you instantly. This also just makes your design more readable for everyone, in sunlight or on cheap screens.
2. Alt text. Every meaningful image needs an alt attribute describing it: <img src="dog.jpg" alt="A golden retriever catching a ball">. A blind user's screen reader reads this aloud. Without alt text, they hear "image" — useless. (It also helps SEO and shows when images fail to load.)
3. Keyboard navigation. Many people can't use a mouse (motor disabilities, or power users). Everything clickable must also work with the Tab key to move and Enter to activate. Use real <button> and <a> elements (which are keyboard-friendly by default) instead of clickable <div>s.
4. Semantic HTML. Use the right tag for the job: <button> for buttons, <h1>–<h6> for headings in order, <nav> for navigation. Screen readers use this structure to let users jump around. A page of meaningless <div>s is a maze for them.
The curb-cut effect. Sidewalk ramps were built for wheelchairs — but they help everyone with strollers, luggage, and bikes. Accessibility is the same: captions help deaf users and anyone in a noisy room; high contrast helps blind users and everyone in bright sunlight; keyboard support helps motor-impaired users and fast power users. Designing for the edges improves the experience for all.
Accessibility isn't extra work bolted on at the end — it's a mark of a thoughtful, professional designer, and increasingly, a skill employers specifically look for.
Forms and focus: the parts people forget 🔎
Beyond images and buttons, two more accessibility basics quietly make or break a product for many users:
1. Labels on form fields. An <input> with only a placeholder ("Email...") is a trap: the placeholder vanishes the moment someone starts typing, and screen readers often don't announce placeholder text as a label at all. The fix is a real <label> tied to the input with for/id: <label for="email">Email</label><input id="email">. Now a screen reader announces "Email, edit text" and — as a bonus — clicking the label text focuses the input, which helps anyone with shaky motor control aim more easily.
2. Visible focus indicators. When you press Tab, the browser draws an outline around the currently focused element by default. Many designers strip this with outline: none because they think it looks messy — but without it, a keyboard user has no idea where they are on the page. It's like hiding the cursor in a text editor. If you must restyle it, replace it with an equally clear alternative (a colored ring, a background change) — never delete it outright.
3. Skip links. On a page with a long navigation menu, a sighted mouse user just clicks past it — but a keyboard user must Tab through every single link before reaching the main content, every single page load. A "Skip to main content" link (visually hidden until it receives focus) lets keyboard users jump straight past the repeated navigation.
None of these are exotic. They're small, cheap details that separate a page that merely looks accessible from one that actually is.
Fix this page's accessibility. Make three changes:
- Give the
<img>a descriptivealtattribute (any non-empty description) - Change the clickable
<div id="cta">into a real<button>(keyboard-accessible) — keep the text "Get Started" - In the
<style>, fix.lowtext so itscoloris dark enough to read — set it to#333or darker (not the current light grey)
Give a form field a real label and a visible focus ring. Make two changes:
- Add a
<label for="name">with any text right before the<input id="name">, so the label and input are properly connected - In the
<style>, giveinput:focusa visibleoutline(e.g.3px solid #2563eb) instead of the currentoutline: none
Real-world case study: the screen-reader user who couldn't checkout 🔍
A pattern reported again and again in accessibility audits and lawsuits (large retailers have been sued over exactly this) goes like this: an online store looks perfectly polished — until a blind customer using a screen reader tries to buy something. The "Add to Cart" button turns out to be a styled <div> with a click handler, invisible to keyboard navigation. The size dropdown has no associated <label>, so the screen reader just says "combo box" with no idea it means "shoe size." The checkout form's error messages appear only as a color change, silent to anyone who can't see red.
None of these are exotic bugs — each is one of the exact issues from this lesson: a fake button instead of a real one, a missing label, color-only feedback. Individually small, but stacked together they form a wall the customer cannot get past, at the exact moment they were ready to pay. The business loses a sale it never even knows it lost, silently, over and over, for every affected visitor.
The fix in every real case is the same, unglamorous checklist: real semantic elements, real labels, redundant (non-color) signals, and visible focus. None of it requires redesigning the store — it requires not skipping the basics. That's exactly why accessibility audits keep finding the same handful of issues: they're easy to overlook and cheap to fix, if you know to look.
Lab exercise 1
JavaScript (Node.js)Graded in Code LabCalculate accessible contrast. WCAG 2.2 level AA requires a contrast ratio of at least 4.5 : 1 for normal text. Each input line holds two hex colours, text then background, such as #767676 #ffffff.
For each line print RATIO VERDICT: the ratio rounded to 2 decimals and PASS when it is at least 4.5 (compare the unrounded ratio) or FAIL otherwise.
The formula: convert each sRGB channel c (0-255) to c / 255, then to linear light (c <= 0.04045 ? c / 12.92 : ((c + 0.055) / 1.055) ** 2.4). Luminance is 0.2126 R + 0.7152 G + 0.0722 B. The ratio is (lighter + 0.05) / (darker + 0.05), so the order of the two colours does not matter.
- Black on white is the maximum ratio
- #767676 on white is the lightest grey that passes
- Order of the colours does not matter
- Identical colours have a ratio of 1
Example run
- Input
#000000 #ffffff
- Expected output
21.00 PASS
const fs = require("fs");
// TODO 1: turn "#rrggbb" into [r, g, b] numbers (parseInt(hex.slice(1, 3), 16) ...)
function parseHex(hex) {
return [0, 0, 0];
}
// TODO 2: linearise each channel and weight them: 0.2126 R + 0.7152 G + 0.0722 B
function luminance([r, g, b]) {
return 0;
}
More lines in Code Lab: 8
Hints and instant feedback are in Code Lab. Optional practice: it does not block finishing the lesson.
JavaScript and Python also run in your browser without an account; other languages use the secure server runner and need a free account.
Question 1 of 5
What does 'alt text' do?
Question 2 of 5
Why prefer a real <button> over a clickable <div>?
Question 3 of 5
What is the 'curb-cut effect'?
Question 4 of 5
What's wrong with using only a placeholder instead of a <label>?
Question 5 of 5
Why should you avoid outline: none on :focus without replacing it?
Track complete! 🎓
Your UI/UX foundation is built:
- Design principles, typography & color — the fundamentals of looking good
- Figma, user research, wireframing, prototyping — the design process
- Design systems & accessibility — consistent, inclusive products at scale
- Labels, visible focus, and skip links — the form/keyboard details many designers forget
- The screen-reader checkout case study — small oversights stack into a wall users can't get past
Path to paid work: UX/UI designers are in high demand. Learn Figma deeply, rebuild 3–4 real app screens applying everything here, do one small user test, and assemble a portfolio (a personal site or Behance/Dribbble). If you also learned the Frontend track, you're a rare designer-who-codes — extremely employable and perfect for freelance. Pair it with the "Getting Paid" lesson and start landing clients. Design things people love — and that everyone can use! 🎨
Practice
Reading is not learning until you run something. Pick one.
Graded lab exercises
- Lab exercise 1JavaScript (Node.js)Not passed yet Try in Code Lab