Zerethon IDE
Sign in

Web accessibility

Intermediate 10 min read

Build pages everyone can use — with a keyboard, a screen reader, zoom or low vision.

Why it matters

Many people use the web without a mouse or without seeing the screen, and accessibility is a legal requirement in many places. Most problems are cheap to avoid while building and expensive to fix later.

Where it fits

  1. Plan & Design
  2. ● Develop › Frontend
  3. Version control
  4. Verify
  5. Build & Package
  6. CI/CD
  7. Deploy
  8. Operate

What you will learn

  • Check a page with only the keyboard.
  • Give every control an accessible name.
  • Know what WCAG is and where to look up a rule.

Before you start

The checks that find most problems

  • Tab reaches every link, button and field, in a sensible order, and you can see where focus is.
  • Every button and field has a name: visible text, a <label>, or aria-label for an icon-only button.
  • Text has enough contrast with its background, and colour is never the only signal.
  • The page still works at 200% zoom.
  • Images that carry meaning have alt text.
Example 
<label for="email">Email</label>
<input id="email" type="email" autocomplete="email">

<button type="button" aria-label="Close dialog">×</button>
A label tied to its field, and a name for a button that only shows an icon.

Tip: Native elements first, ARIA second. A real <button> is accessible by default; a <div role="button"> needs focus handling and key handling added by hand.

WCAG (Web Content Accessibility Guidelines) is the standard most laws refer to. Level AA is the usual target.

Official documentation and references

Guides

Learn next

Related topics

Done with this topic?

Reviewed 2026-10-23. Links go to the official documentation unless marked otherwise.