Web Accessibility Basics Every Developer Should Know

Accessibility (often shortened to a11y) means people can use your site regardless of disability: people who are blind and use screen readers, people with low vision who zoom to 200%, people who can't use a mouse, people with tremors, colour blindness or cognitive differences. It also helps everyone else: someone in bright sunlight, someone with a broken trackpad, someone holding a baby with one arm.

The good news: most accessibility comes from writing HTML the way it was designed to be written.

1. Use semantic HTML

Native elements come with accessibility built in: keyboard support, focus, roles and states that assistive technology understands.

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

<!-- Accessible by default -->
<button type="button" onclick="save()">Save</button>

The rules of thumb:

• If it performs an action, it's a <button>. If it goes somewhere, it's an <a href>.
• Use <nav>, <main>, <header>, <footer> and <section> so screen reader users can jump between regions.
• Use headings (h1 to h6) in order to outline the page. Don't pick heading levels for their font size.
• Use real lists (<ul>, <ol>) and tables (<table> with <th>) for list and tabular data.

2. Every image needs the right alt text

• Informative images: describe what matters. alt="Bar chart: sales doubled between March and June".
• Decorative images: empty alt, alt="", so screen readers skip them.
• Images that are links: describe the destination, not the picture.

Skip "image of..." at the start. Screen readers already announce that it's an image.

3. Label every form field

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

Placeholder text isn't a label: it disappears when typing and often has poor contrast. Also:

• Show errors in text next to the field, not just with a red border.
• Connect error messages with aria-describedby.
• Use autocomplete attributes. They help everyone, especially people with motor or memory difficulties.

(Validation that helps users.)

4. Make everything work with a keyboard

Put your mouse away and press Tab through your site:

• Can you reach every link, button and field?
• Can you see where focus is? Never remove focus outlines without a clear replacement. Use :focus-visible to style them nicely.
• Is the order logical?
• Can you open and close menus and modals, and does focus go somewhere sensible when they open and close?
• Are there keyboard traps you can't escape?

A "Skip to main content" link at the top helps keyboard users bypass repeated navigation.

5. Colour and contrast

• Body text needs a contrast ratio of at least 4.5:1 against its background (3:1 for large text), per WCAG AA.
• Never use colour alone to convey meaning. A red border for errors needs an icon or text too; chart lines need labels or patterns.
• Respect user preferences like prefers-reduced-motion for animations and prefers-color-scheme for themes.

6. Use ARIA sparingly

ARIA attributes add accessibility information to elements, but the first rule of ARIA is: don't use ARIA if a native element does the job. Incorrect ARIA is worse than none.

Where ARIA genuinely helps:

• aria-label on icon-only buttons: <button aria-label="Close dialog">×</button>
• aria-expanded on toggles that show or hide content
• aria-live regions to announce dynamic updates, like "Item added to cart"
• aria-current="page" on the active navigation link

7. Zoom, text size and motion

• Pages should work at 200% zoom without horizontal scrolling or overlapping text. (Responsive design helps here.)
• Use relative units so text scales with user settings.
• Avoid autoplaying video and flashing content, and allow motion to be reduced.

How to test, quickly

1. Keyboard-only pass through every key flow (sign up, checkout, contact).
2. Automated checks with Lighthouse or the axe browser extension. They catch roughly a third of issues, like missing labels and low contrast.
3. Screen reader spot check. VoiceOver on macOS and iOS, NVDA on Windows (free) and TalkBack on Android. Try navigating by headings and filling in a form.
4. Zoom to 200% and check nothing breaks.

Automated tools are a start, not a certificate. Real usage reveals what scanners can't.

Why it's worth it

• It's the right thing to do: a significant share of people live with some form of disability.
• Many countries have legal accessibility requirements for public-facing sites and services, and enforcement is increasing.
• Accessible markup tends to be cleaner, more testable and easier for search engines to understand. (Technical SEO overlaps a lot.)

FAQ

What is web accessibility?

Designing and building websites so people with disabilities can perceive, navigate and interact with them, including people using screen readers, keyboards, zoom or other assistive technology.

What is WCAG?

The Web Content Accessibility Guidelines, the international standard for web accessibility. Level AA is the common target for websites and many legal requirements.

Do automated tools find all accessibility issues?

No. Tools like Lighthouse and axe catch common issues such as missing labels and low contrast, but keyboard and screen reader testing is needed to find the rest.