Accessibility Basics

Introduction

Accessibility (often shortened to a11y) means building pages that people can use regardless of ability, device, input method, or environment. Good HTML is the foundation: semantic elements, clear headings, useful alt text, real buttons, labels, and predictable structure. This chapter explains what accessibility is, why it matters, and how to run basic checks in the browser.

Prerequisites

• Semantic HTML layout
• Accessible forms
• A browser with DevTools installed

What Accessibility Means

Accessibility is not a separate feature for a small group of users. It is part of quality.

People may access your page with:

• a keyboard instead of a mouse
• a screen reader
• zoomed text or high contrast settings
• voice control
• captions instead of audio
• a phone in bright sunlight
• a slow network or broken image

HTML helps because it provides built-in meaning. A real <button> works with keyboard and screen readers before you write any JavaScript. A <label> names an input. A heading creates structure.

Common Accessibility Barriers

Most beginner accessibility wins come from using the right HTML element.

Native HTML First

Native elements already include behavior:

<button type="button">Open menu</button>

This button:

• can receive focus
• can be activated by keyboard
• has a role of "button"
• announces its text as the accessible name

Compare a custom fake button:

<!-- Avoid -->
<div class="button" onclick="openMenu()">Open menu</div>

To make the fake button equivalent, you would need ARIA roles, keyboard handlers, focus management, and testing. Use the native element instead.

Headings Create a Map

Screen reader users can navigate by headings. A page like this is easy to scan:

Bad outline:

<h1>Accessibility</h1>
<h4>Images</h4>
<h2>Forms</h2>

Do not choose heading levels by visual size. Choose them by document structure.

Images and Alternative Text

Useful images need alt text:

<img
  src="images/payment-flow.png"
  alt="Diagram showing checkout moving from cart to payment to confirmation"
>

Decorative images need empty alt:

<img src="images/decorative-wave.svg" alt="">

If an image is explained in surrounding text, keep alt concise. If it is complex (charts, diagrams), include a nearby longer explanation.

Forms and Names

Accessible form controls have clear labels:

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

Help text can be connected:

<label for="password">Password</label>
<input id="password" name="password" type="password" aria-describedby="password-help">
<p id="password-help">Use at least 8 characters.</p>

Groups use fieldset and legend:

<fieldset>
  <legend>Notification channels</legend>
  <label><input type="checkbox" name="channels" value="email"> Email</label>
  <label><input type="checkbox" name="channels" value="sms"> SMS</label>
</fieldset>

Links and Buttons

Use links for navigation. Use buttons for actions.

<!-- Navigation -->
<a href="pricing.html">View pricing</a>
 
<!-- Action -->
<button type="button">Open settings</button>

A link should go somewhere. A button should do something on the current page (often with JavaScript).

Color and Contrast

HTML cannot set contrast by itself, but content choices matter:

• Do not rely on color alone: "Fields in red are required" is not enough.
• Use text labels and icons with names.
• Keep meaningful text as real text, not baked into images.

CSS handles color contrast, but HTML must provide the text and structure that CSS can style accessibly.

Keyboard Basics

A usable page should work without a mouse:

• Tab moves through focusable controls
• Shift + Tab moves backward
• Enter activates links and submits forms
• Space activates buttons and toggles checkboxes
• Arrow keys move through many native controls

You will practice this in the next chapter. For now, remember: native controls already have keyboard behavior.

Quick Checks in DevTools

Lighthouse

In Chrome/Edge DevTools:

1. Open DevTools.
2. Choose Lighthouse.
3. Select Accessibility.
4. Run an audit.

Lighthouse can catch:

• missing image alt text
• form controls without labels
• low contrast (CSS)
• missing document title
• invalid ARIA references

It does not catch everything. A high score is not proof of full accessibility.

Elements / Accessibility Tree

In DevTools, inspect an element and look for accessibility info (browser UI varies):

• role
• name
• description
• keyboard focusability

Example: inspect a real <button>. It should have role "button" and name from its text.

A Beginner Accessibility Checklist

Before publishing a basic HTML page, check:

• One clear <h1>
• Heading levels do not jump randomly
• Links have meaningful text
• Images have meaningful alt or empty alt=""
• Form controls have labels
• Radio/checkbox groups use fieldset + legend
• Buttons are real <button> elements
• Page can be used with Tab and keyboard activation
• Main content is inside <main>
• No important content is available only by color, image, or audio

Mini Exercise

Audit one page you created earlier:

1. Run Lighthouse Accessibility.
2. Tab through the page without a mouse.
3. Inspect one link, one button, one image, and one input in DevTools.
4. Fix at least two issues you find.

FAQ

Is accessibility only for disabled users?

No. It especially protects disabled users, but it also improves usability for mobile users, keyboard users, low-bandwidth users, and people in difficult environments.

Is ARIA required for accessibility?

Often no. Good native HTML solves many problems. ARIA is for cases where native semantics cannot express a custom UI pattern.

Can automated tools find all problems?

No. Tools catch many obvious issues, but manual keyboard testing and real user testing are still important.

Does semantic HTML replace visual design?

No. Semantic HTML provides structure. CSS creates visual design. Both must work together.

What comes next?

Keyboard, focus, and ARIA — focus order, tabindex, skip links, and basic ARIA attributes.