Skip to main content

HTML Accessibility: Building for Everyone

Think of a building with a grand staircase and no ramp. A lot of people can enter easily. But someone using a wheelchair cannot, a parent with a pushchair struggles, and a delivery worker with a heavy trolley is stuck at the bottom. Nobody planned to exclude them. The designer simply did not think about them.

Websites are the same. A page can look beautiful and still lock people out: a button that works only with a mouse, a picture with no description, a form that never says what went wrong. Web accessibility is the practice of building pages so that as many people as possible can use them, whatever their abilities, devices, or circumstances.

The good news: HTML was designed with accessibility in mind. Most of the work is choosing the right element and writing clear content. This section teaches you how.


What You Will Learn in This Section​

  • Why accessibility matters, and who it helps
  • The four principles of the Web Content Accessibility Guidelines (WCAG)
  • How people really use the web: screen readers, keyboards, magnifiers, voice, and switches
  • Building with semantic HTML, the foundation of accessible pages
  • Writing accessible names, images, links, buttons, forms, and tables
  • ARIA: what it is, when to use it, and when not to
  • Keyboard use and focus management
  • Testing your work

The Big Idea​

index.html
<main>
  <h1>Join The Bread Bin</h1>

  <form>
    <label for="email">Email address</label>
    <input id="email" type="email" autocomplete="email" required>

    <button type="submit">Subscribe</button>
  </form>

  <img src="loaf.jpg" alt="A golden sourdough loaf on a wooden board">
</main>

Try each option, one at a time. Turn on "No mouse" and press Tab. Turn on "Hide the focus outline" and try again. Then switch to a colour-vision option, and look at the two buttons. Small choices in HTML and CSS make a very big difference for real people.

Who Benefits?​

Accessibility is often pictured as helping a small group. In fact, the numbers are large. The World Health Organization estimates that roughly one in six people in the world lives with a significant disability. And everyone is sometimes limited:

Kind of barrierPermanentTemporarySituational
SeeingBlindness, low vision, colour blindnessEye surgery, a lost pair of glassesBright sunlight on a phone
HearingDeafness, hearing lossAn ear infectionA noisy train, or a silent office
MovementParalysis, tremor, limb differenceA broken armHolding a baby in one arm
Thinking and learningDyslexia, autism, memory differencesA concussionTiredness, stress, a second language

Features built for disabled people often help everyone. Captions help in a noisy café. A keyboard-friendly form is faster for power users. Good contrast helps outdoors. Clear writing helps people reading in a second language. This is called the curb-cut effect: ramps cut into pavements for wheelchairs are used by cyclists, parents, and travellers with suitcases every day.

How People Use the Web​

Not everyone uses a mouse and a screen the way you do. Some of the ways people use the web:

Tool or methodWho uses itWhat it needs from your HTML
Screen readerPeople who are blind or have low visionReal headings, landmarks, labels, text alternatives
Keyboard onlyPeople who cannot use a mouse, and many who prefer not toEverything reachable and usable with Tab, Enter, Space, and arrows. A visible focus
Switch devices and voice controlPeople with limited movementReal buttons and links with clear names, so that "click Subscribe" works
Screen magnifier or zoomPeople with low visionLayouts that stay usable at 200 percent and more
High-contrast or custom coloursPeople with low vision, light sensitivity, or dyslexiaDo not depend on your own colours alone
Captions and transcriptsPeople who are deaf or hard of hearing, and many othersText versions of audio and video
Reduced motion settingsPeople with vestibular disorders or motion sensitivityRespecting prefers-reduced-motion
Simple, predictable pagesPeople with cognitive or learning disabilitiesPlain language, consistent layout, clear errors

The Four Principles: POUR​

The Web Content Accessibility Guidelines, known as WCAG, are the international standard. They are built on four principles, remembered by the word POUR:

PrincipleThe question it asksExample
PerceivableCan people sense the content?Text alternatives for images, captions for video, enough contrast
OperableCan people use the controls?Everything works with a keyboard, no traps, enough time
UnderstandableCan people make sense of it?Clear language, predictable behaviour, helpful error messages
RobustDoes it work with many tools, now and later?Valid, semantic HTML, with names, roles, and states that assistive technology can read

Sort a few real barriers into the four principles:

pour-examples.html
<!-- Perceivable: a text alternative -->
<img src="chart.png" alt="Sales rose 20 percent in 2026">

<!-- Operable: a real button works with Enter and Space -->
<button type="button">Open menu</button>

<!-- Understandable: an error that says what to do -->
<p id="err" role="alert">Enter an email address, such as name@example.com.</p>

<!-- Robust: a native element, with a role and state built in -->
<input type="checkbox" id="news"> <label for="news">Send me the newsletter</label>

WCAG organises its rules into three levels: A (the minimum), AA (the usual target, and the level most laws and policies ask for), and AAA (the highest, and not possible for every kind of content). The current published version is WCAG 2.2, and newer versions may appear, so check the W3C for the latest.

Contrast: Your First Measurable Rule​

One accessibility rule is easy to measure: the contrast between text and its background. WCAG asks for at least 4.5 to 1 for normal text at level AA, 3 to 1 for large text, and 3 to 1 for important icons and the borders of form fields. Try the checker below with your own colours:

styles.css
/* A light grey on white often fails. This passes at 4.5 to 1 */
body {
  background: #ffffff;
  color: #595959;
}

/* Never remove the focus outline without replacing it */
:focus-visible {
  outline: 3px solid #1d4ed8;
  outline-offset: 2px;
}

The First Rule of ARIA​

You will meet ARIA later in this section. It is a set of attributes that can add accessibility information to elements. It is powerful, but the most important thing to know is its first rule:

No ARIA is better than bad ARIA

If a native HTML element already does the job, use it. A real <button> is already focusable, works with Enter and Space, and tells assistive technology it is a button. A <div role="button"> has none of that until you build it yourself. ARIA changes only what is announced. It does not add behaviour.

What Is in This Section​

Five Habits to Start Today​

  1. Use the right element. A button for actions, a link for navigation, a heading for a heading.
  2. Label everything. Every input, every icon button, every image that carries meaning.
  3. Try your keyboard. Put the mouse aside, and use Tab, Shift+Tab, Enter, Space, and Escape.
  4. Check contrast and zoom. Enlarge your page to 200 percent, and check the colours.
  5. Write clearly. Plain words, short sentences, and error messages that say how to fix the problem.

Accessibility Checklist for Any Page​

  • The page has a lang attribute and a unique <title>.
  • Headings form a logical outline, and landmarks (header, nav, main, footer) are used.
  • Every image has the right alt, and decorative images have alt="".
  • Every form control has a visible <label>.
  • Links make sense out of context, and buttons say what they do.
  • Everything works with the keyboard, and the focus is always visible.
  • Text has enough contrast, and information is never shown by colour alone.
  • The page works at 200 percent zoom and on small screens.
  • Video has captions, and audio has a transcript.
  • Animations can be stopped, and respect reduced motion.
  • Errors are described in text, and are announced.

Security and Privacy Notes​

  • Do not ask people to prove their disability to use your site, and never store disability information without a clear need and consent. It is sensitive personal data.
  • Be careful with accessibility detection. Using a visitor's settings (such as screen reader use, reduced motion, or contrast) to track or profile them can reveal private information. Respond to their preferences in your styles, and do not collect them.
  • Accessible does not mean unprotected. CAPTCHAs that rely only on images or sounds shut out many people. Offer an alternative that is both secure and accessible.
  • Session timeouts need warnings and a way to extend the time, which is both an accessibility and a security issue.
  • Do not put sensitive details in labels and error messages that are read aloud, because others nearby may hear them.

Global Audience Notes​

  • Disability is global, and so are the tools. Many people in lower-income regions use older phones, slower networks, and free screen readers. Lean, semantic HTML serves them best.
  • Set lang correctly, and mark passages in other languages, so screen readers pronounce them properly.
  • Right-to-left languages need dir="rtl" and testing with assistive technology.
  • Write in plain language, which helps translators, people reading in a second language, and people with cognitive disabilities.
  • Laws differ, but many countries now require accessible websites, for example the Americans with Disabilities Act and Section 508 in the United States, the European Accessibility Act in the European Union, and similar rules elsewhere. They often point to WCAG. This is not legal advice, so check the rules for your region and your audience.
  • Avoid idioms and cultural shortcuts in icons and instructions.

Common Mistakes to Avoid​

  1. Treating accessibility as a last-minute extra.
  2. Building controls from div and span instead of real elements.
  3. Removing the focus outline.
  4. Using colour alone to show errors, status, or required fields.
  5. Missing or meaningless alt text, such as "image" or a file name.
  6. Placeholder text used as a label.
  7. Link text such as "click here".
  8. Adding ARIA by default, and creating wrong or conflicting information.
  9. Relying only on automatic tools. They find only part of the problems.
  10. Never testing with a keyboard or a screen reader.
  11. Auto-playing media, and moving content with no pause.
  12. Assuming "it looks fine to me" means it is fine.

Practice Time​

Try these in your editor and your browser:

  1. Use the simulator above with each option, and write down what became harder.
  2. Put your mouse away, and complete a form on a site you use, with the keyboard only.
  3. Press Tab through your own page, and note every place where you lose track of the focus.
  4. Check the contrast of three colour pairs on your site, using the checker.
  5. Zoom a page to 200 percent, and note anything that breaks.
  6. Turn on a built-in screen reader for five minutes, and listen to a page you built.
  7. List every image on a page, and write its alt text, or mark it as decorative.
  8. Replace one div that acts as a button with a real <button>.
  9. Run an automatic accessibility checker (such as the one built into your browser's developer tools), and fix the first three issues.
  10. Bonus: ask a friend who uses assistive technology, if they are happy to help, how they find your site.

Quick Recap​

Click a question to check your answer.

1. What is web accessibility?

Building websites so that as many people as possible can use them, whatever their abilities, devices, or situations.

2. What does POUR stand for?

Perceivable, Operable, Understandable, and Robust: the four principles of the Web Content Accessibility Guidelines.

3. What is the first rule of ARIA?

If a native HTML element already does the job, use it instead of adding ARIA. ARIA changes what is announced, but it does not add behaviour.

4. What contrast does WCAG level AA require for normal text?

At least 4.5 to 1 between the text and its background. Large text and important non-text parts need at least 3 to 1.

5. Why is the keyboard such an important test?

Many people cannot use a mouse, and screen readers, switch devices, and voice control all depend on keyboard-style navigation. If it works with the keyboard, it is likely to work with other tools.

6. What is the curb-cut effect?

Features built for disabled people, such as ramps or captions, often benefit everyone, including cyclists, parents with pushchairs, and people in noisy places.

Key Takeaways​

  • Accessibility means building for as many people as possible. Roughly one in six people has a significant disability, and everyone is sometimes limited.
  • WCAG rests on four principles: Perceivable, Operable, Understandable, Robust. Level AA is the usual target.
  • Semantic HTML is the foundation. Use the right element before you reach for ARIA.
  • Test with the keyboard, zoom, contrast checks, and a screen reader, and with real people when you can.
  • Never rely on colour alone, never remove the focus outline, and always label controls.
  • Protect people's privacy, including information about their disabilities and settings.
  • Plain language, lean pages, and correct lang help people everywhere.

Ready to begin? Start with Introduction to A11y.