Accessibility

Web accessibility (often shortened to "a11y") is the practice of building pages that everyone can use, including people who rely on keyboards, screen readers, or magnification, by using semantic HTML, descriptive text alternatives, and sufficient colour contrast.

Part of the free HTML & CSS course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

By the end of this lesson you'll be able to build pages that work for keyboard users, screen-reader users, and people with low vision — and you'll be able to spot and fix inaccessible markup on sight.

What You'll Learn

💡 Think of It Like This

Accessibility is like a building with ramps, lifts, and braille signs. A staircase works fine if you can walk — but a ramp lets everyone in, including the person in a wheelchair, the parent with a pushchair, and the courier with a heavy trolley.

Your webpage is the building. A screen reader is a blind visitor who can only "see" the page through the labels and structure you provide. If your "button" is really a styled < div > , it's like a door with no handle — some visitors simply can't open it. Over 1 billion people worldwide live with a disability, so these ramps are not an edge case.

1. Why Accessibility Matters

Accessibility (often shortened to a11y — "a", then 11 letters, then "y") means building pages that work for people who use assistive technology: screen readers, keyboard-only navigation, screen magnifiers, and more. It is not a nice-to-have bolted on at the end; it is part of writing correct HTML.

Reason

Why you should care

🧑‍🤝‍🧑 Ethical

Around 15% of the world lives with a disability. The web should work for them too.

⚖️ Legal

Many countries require WCAG compliance (ADA in the US, EAA in the EU). Lawsuits are real.

📈 SEO

Semantic HTML and alt text are exactly what search engines read to rank you.

👥 UX

Accessible sites are clearer and faster for everyone , not just disabled users.

2. Semantic HTML — The Foundation

The single most important thing for accessibility is to use the right HTML element for the job . A screen reader knows that < button > is clickable, that < nav > is navigation, and that < main > is the main content — but a < div > is meaningless furniture it has to skip past. "Semantic" just means the tag describes what the thing is , not how it looks.

❌ Inaccessible

✅ Accessible

< div onclick="..." >

< button >

< div class="nav" >

< nav >

< div class="header" >

< header >

< b > Title < /b >

< h1 > Title < /h1 >

Run the worked example below. The same visual layout is built twice — once from < div > s and once from real elements. They look identical, but only the second one tells a screen reader what each part is .

3. Heading Order & Alt Text

Screen-reader users often jump heading to heading to scan a page, the way a sighted reader skims bold titles. That only works if your headings form a logical outline: one < h1 > per page, then < h2 > for each section, then < h3 > under those. Never skip a level just to get a smaller font — that's a job for CSS, not for picking the wrong tag.

For images, the alt attribute is the text a screen reader speaks in place of the picture. Get it right by image type:

Image type

Rule

Example

Informative

Describe what it shows

alt="Golden retriever catching a ball"

Decorative

Empty alt (present, not missing!)

alt=""

Functional (logo/icon link)

Describe the action/destination

alt="Acme home page"

4. Keyboard Navigation & Visible Focus

Many people never touch a mouse. They move through a page with Tab (next control), Shift+Tab (previous), Enter / Space (activate), and Escape (close). For this to work, every interactive element must be reachable and must show a visible focus indicator — the ring that tells you where you are. Native elements ( < a > , < button > , < input > ) are focusable for free; that's another reason to use them.

The demo below is a full accessible page: a skip link, semantic landmarks, a labelled form, and a bright focus ring. Open it and press Tab repeatedly — watch the skip link appear first, then the focus ring jump from control to control.

5. Colour Contrast (WCAG AA)

Low-contrast text — pale grey on white, light blue on teal — is hard to read for everyone and impossible for many people with low vision. WCAG sets a measurable target called a contrast ratio , from 1:1 (invisible) to 21:1 (black on white). To pass AA , the level most laws require, hit these numbers:

Level

Normal text

Large text (18pt+/24px)

AA (required)

4.5:1

3:1

AAA (best practice)

7:1

💡 Pro tip: Don't guess. Open browser DevTools, inspect a text element, and the colour picker shows the live contrast ratio with a pass/fail tick against AA and AAA.

And never rely on colour alone to convey meaning — a red/green status dot is invisible to colour-blind users. Add an icon, a word, or a shape as well.

🎯 Your Turn #1 — Fix the fake button

This "card" uses a < div > as a button and an image with no alt text. Replace the blanks so it becomes accessible, then run it and check the expected screen-reader behaviour written in the comments.

🎯 Your Turn #2 — Label the form

These inputs only have placeholder text — which vanishes when you type and is not a label. Connect each input to a < label > using matching for / id values, then verify the expected screen-reader behaviour in the comments.

🧩 Mini-Challenge — Build an accessible mini-page

Support is faded now — only an outline is given. Build a small page from scratch that ties the whole lesson together. Use the worked page in section 4 as your reference if you get stuck.

⚠️ Common Errors (and the fix)

• Missing alt text. Screen reader reads the file name out loud: "headphones-final-v2.png". Fix: add alt="..." describing the image, or alt="" if it's purely decorative.
• Div-buttons. < div onclick="..." > can't be reached by Tab, doesn't respond to Enter/Space, and isn't announced as a button. Fix: use < button > (or < a > if it navigates).
• Low contrast. Pale grey text on white reads at ~1.6:1 and fails WCAG AA. Fix: darken the text (or lighten the background) until DevTools shows at least 4.5:1 for normal text.
• No labels. Inputs with only placeholder text are announced as an unnamed "edit text". Fix: add a < label > with for matching the input's id .
• outline: none. Removing the focus ring with no replacement leaves keyboard users unable to see where they are. Fix: style :focus-visible with a high-contrast outline instead.

📋 Quick Reference

Goal

Use this

A clickable action

< button > … < /button >

Navigation region

< nav aria-label="Main" >

Main content landmark

< main id="main" >

Informative image

< img src="…" alt="what it shows" >

Decorative image

< img src="…" alt="" >

Labelled input

< label for="x" > … < /label > < input id="x" >

Skip link

< a href="#main" > Skip to main content < /a >

Visible focus ring

:focus-visible { outline: 3px solid #3b82f6 }

Contrast (AA, normal text)

at least 4.5:1

❓ Frequently Asked Questions

🎉 Lesson Complete

You can now build pages that work for everyone. The essentials:

• ✅ Reach for semantic HTML first — it's the #1 accessibility win
• ✅ Give images real alt text (or alt="" when decorative)
• ✅ Keep headings in order — one h1, then h2, then h3
• ✅ Make every control keyboard-operable with a visible focus ring
• ✅ Meet WCAG AA contrast — 4.5:1 for normal text
• ✅ Label every form control and add a skip link

Next up: HTML5 Semantic Architecture , where you'll structure whole pages with these landmark elements.

Practice quiz

Continue this course

• Previous: CSS Custom Properties
• Next: HTML5 Semantic Architecture

Related lessons

• CSS Basics & Selectors