Accessibility from day one

Why this matters

Accessibility means people can use your site whatever their abilities or devices: someone who is blind and uses a screen reader, someone who cannot use a mouse and navigates by keyboard, someone with low vision zoomed to 300%, or someone on a cracked phone in bright sunlight. Around one in six people worldwide lives with a significant disability, according to the World Health Organization. In many countries, accessibility is also a legal requirement for public and commercial sites, and the shared technical standard is the Web Content Accessibility Guidelines (WCAG).

The best news for a beginner: most accessibility comes free with correct HTML. It is far cheaper to write it right the first time than to fix it later.

How assistive technology reads your page

A screen reader does not see your layout. It reads the accessibility tree, which the browser builds from your HTML. Every element contributes a role (heading, link, button, list), a name (the link text, the alt text, the label) and sometimes a state (checked, expanded). If you use a <div> where a <button> belongs, the tree just says "text", and the user has no way to know it can be pressed.

Four habits that cover most problems

1. Text alternatives for images

Every <img> needs an alt attribute: meaningful text for informative images, alt="" for decorative ones (covered in the previous lesson).

2. Labels for every form control

Placeholder text is not a label: it disappears as soon as you type and is often low-contrast. Connect a visible <label> to its control with for and id:

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

Now a screen reader announces "Email address, edit text", and clicking the label focuses the input, which gives everyone a bigger target. You can also wrap the input inside the label: <label>Email <input type="email"></label>.

3. Real buttons and links

<!-- Inaccessible: no role, not focusable, ignores the keyboard -->
<div class="btn" onclick="save()">Save</div>

<!-- Accessible: focusable, works with Enter and Space, announced as a button -->
<button type="button" onclick="save()">Save</button>

The rule of thumb: if it goes somewhere, use <a href>. If it does something on this page, use <button>. Both work with the keyboard out of the box, and you can style them to look however you like.

4. Landmarks

Landmark elements describe the regions of a page. Screen reader users can jump straight to them, like skipping to a chapter.

Within <main>, use <section> (with a heading) for thematic groups and <article> for self-contained pieces such as a blog post. If a page has more than one <nav>, give each an aria-label ("Main", "Footer") so users can tell them apart.

Language, titles and the keyboard

• <html lang="en"> makes screen readers use the right pronunciation.
• A unique, descriptive <title> is the first thing announced when a page opens.
• Try your page with only the keyboard: Tab moves forward, Shift+Tab moves back, Enter activates links and buttons, Space toggles checkboxes and presses buttons. You should always see where focus is, and you should be able to reach everything you can click.

A word about ARIA

ARIA attributes (role, aria-label, aria-expanded and others) add accessibility information when HTML has no suitable element. The first rule of ARIA, from the W3C, is: if a native HTML element does the job, use it instead. A <button> beats <div role="button" tabindex="0"> plus keyboard handlers every time. Use ARIA sparingly and for specific needs, such as labelling two <nav> elements.

Worked example: testing your own page

1. Open your page and press Tab repeatedly. Note anything you cannot reach or cannot see focus on.
2. Open developer tools, select an element, and open the Accessibility pane (Chrome and Edge) or the Accessibility tab (Firefox) to see its role and name.
3. Run Lighthouse (Chrome developer tools) with the Accessibility category, or the free WAVE checker from WebAIM. They catch missing alt text, unlabelled inputs and low contrast.
4. Turn on a real screen reader for a few minutes: VoiceOver on macOS and iOS, Narrator on Windows, TalkBack on Android, or the free NVDA on Windows.

Automated tools find only part of the problems. A quick keyboard test finds many of the rest.

Common mistakes

• Placeholder instead of a label.
• Clickable <div> or <span> elements instead of buttons and links.
• Removing the focus outline (outline: none) without adding a visible replacement.
• Several <main> elements, or none.
• Information by colour alone, such as "required fields are red". Add text or an icon too.

Quick recap

• Correct HTML gives assistive technology the roles and names it needs.
• Alt text on images, a <label> on every control, <button> for actions and <a href> for navigation.
• Landmarks: <header>, <nav>, one <main>, <footer>.
• Test with the keyboard and an automated checker; prefer native HTML over ARIA.

Try it

Open the Do tab and repair a library home page built from <div> elements, placeholders and a fake button.