Accessibility is quality
Accessibility means people with different abilities, devices, environments, and preferences can use your site effectively. It is not an optional extra. Accessible design often improves the experience for everyone: captions help in noisy places, visible focus helps keyboard users, and clear labels reduce mistakes.
Semantic HTML first
The simplest accessibility improvement is using the right HTML element. A real button already supports keyboard activation. A real label already connects text to an input.
Keyboard navigation
Users should be able to move through interactive controls, see focus, open menus, close panels, and submit forms without a mouse.
Alt text
Alt text should describe the purpose of an image in context. Decorative images can use empty alt text so assistive technology skips them.
Colour and contrast
Text must be readable against its background. Do not use colour alone to communicate meaning. An error field can have a red border, but it also needs text that explains what happened. Links should remain identifiable, and focus indicators should be visible against the surrounding surface.
Names, descriptions, and ARIA
Every interactive control needs an accessible name that explains its purpose. Visible text often provides the best name. Use ARIA when native HTML does not communicate a necessary state or relationship, such as aria-expanded on a menu toggle. Do not add ARIA as decoration: incorrect ARIA can make an interface more confusing.
A repeatable manual review
Use the keyboard to move through the page in order. Confirm that focus remains visible, controls have clear labels, menus can open and close, and the page still works at 200% zoom. Then review headings, image alternatives, field labels, and status messages. Automated tools are useful, but they do not replace this manual pass.
Example code
<button
type="button"
aria-expanded="false"
aria-controls="mobile-menu">
Menu
</button>
<nav id="mobile-menu" hidden>
<a href="/courses">Courses</a>
<a href="/contact">Contact</a>
</nav>
<label for="search">Search courses</label>
<input id="search" name="search" type="search">Applied example: a useful form error
The input is connected to its error text, and the message explains the correction without relying on colour alone.
<label for="email">Email address</label>
<input
id="email"
name="email"
type="email"
aria-describedby="email-error"
aria-invalid="true">
<p id="email-error">
Enter an email address in the format name@example.com.
</p>Guided example: how to approach this lesson
Use these steps as a practical build process. The goal is not just to read the concept, but to know exactly how to apply it in your own page.
Step 1: Use native elements
Use real buttons, links, labels, headings, lists, and form controls before adding custom behaviour.
Step 2: Test keyboard navigation
Use Tab, Shift+Tab, Enter, Space, and Escape to check whether the page can be operated without a mouse.
Step 3: Check meaning and contrast
Make sure headings are logical, alt text is useful, labels are connected, and text is readable.
More examples
Compare these examples carefully. The improved version shows the kind of code pattern you should aim for when building your own project.
Poor accessible control
<div onclick="openMenu()">Menu</div>A div does not automatically behave like a button. It lacks native keyboard behaviour and semantic meaning.
Better accessible control
<button type="button" aria-expanded="false" aria-controls="menu">
Menu
</button>
<nav id="menu" hidden>
<a href="/courses">Courses</a>
</nav>A button is keyboard-accessible by default and can expose its expanded state.
Before moving on
Use this checklist to make sure you understand the lesson well enough to apply it without copying blindly.
- Can all controls be reached with Tab?
- Is focus clearly visible?
- Do images have appropriate alt text?
- Does text have enough contrast?
Common mistakes to avoid
- Removing focus outlines.
- Using low-contrast text.
- Adding incorrect ARIA.
- Using clickable divs instead of buttons.
Practice task
Run an accessibility review on the homepage and contact form you built in the earlier lessons.
Required outcome
- Use only the keyboard to reach and operate every interactive control.
- Review heading order, form labels, image alt text, visible focus styles, and status messages.
- Check that errors include explanatory text instead of relying on colour alone.
- Test the page at 200% browser zoom and fix any content that becomes hidden or unusable.
Stretch goal: Write a short audit note listing the issue, the affected user, and the change you made.