Accessible web development

How to build websites that work for everyone, without exception

10 min

Web accessibility (a11y) is not an optional extra: it’s a technical, legal and ethical requirement. Over a billion people worldwide live with some form of disability, and a significant percentage interact with the web through assistive technologies such as screen readers, specialised keyboards or alternative input devices.

Building accessible sites does not mean sacrificing design or complexity. It means writing semantic code, respecting standard interaction patterns and verifying the experience works for all users. Accessible websites are also easier to maintain, better indexed by search engines and more usable for everyone.

Semantic HTML: the foundation of accessibility

Semantic HTML is the fundamental pillar of accessibility. Using the correct tags (<nav>, <main>, <article>, <button>, <label>) allows screen readers to understand the page structure and offer logical navigation to the user.

The most common mistake is using <div> and <span> for everything and compensating with ARIA. A <div onclick> will never be equivalent to a <button>: it lacks native focus, does not respond to the keyboard and screen readers do not announce it as an interactive element.

  • Use <button> for actions, <a> for navigation, <input> for forms
  • Structure content with <header>, <nav>, <main>, <aside>, <footer>
  • Headings (<h1>–<h6>) must follow a logical hierarchy without skipping levels
  • Informational images need descriptive alt text; decorative images use alt=""

ARIA: when and how to use it

WAI-ARIA (Accessible Rich Internet Applications) adds semantic attributes to elements that native HTML cannot fully describe. It’s essential for interactive components like modals, tabs, accordions, dropdown menus and autocompletes.

The first rule of ARIA is: don’t use ARIA if you can achieve the same result with native HTML. ARIA does not add behaviour, only semantics. A role="button" on a <div> announces the element as a button, but does not make it focusable or responsive to Enter or Space.

  • aria-label and aria-labelledby: provide accessible names for elements without visible text
  • aria-expanded, aria-selected, aria-checked: communicate the state of interactive components
  • aria-live: announces dynamic content changes (notifications, search results)
  • role: defines the purpose of an element when native HTML does not communicate it

Keyboard navigation

All website functionality must be accessible via keyboard. Many users with motor disabilities navigate exclusively with Tab, Enter, Space and arrow keys. Others use devices that emulate keyboard input.

The focus indicator (focus ring) must always be visible. Removing it with outline: none without providing an alternative style is one of the most common and most easily avoidable accessibility mistakes.

  • All interactive elements must receive focus in a logical order (natural tabindex)
  • Modals must trap focus and release it when closed
  • Menus and tabs should navigate with arrow keys, not just Tab
  • Never remove the focus outline without providing an alternative visual indicator
  • Use skip links to allow jumping directly to the main content

Screen readers and testing

Screen readers (NVDA, JAWS, VoiceOver, TalkBack) convert page content into synthesised speech or braille. They interpret the DOM, not the visual screen, so HTML structure and ARIA attributes completely determine the experience.

Testing with a real screen reader is irreplaceable. Automated tools detect between 30% and 50% of accessibility issues. The rest requires manual testing: is the purpose of each element announced correctly? Does navigation make sense without seeing the screen?

  • VoiceOver (macOS/iOS): built-in, activate with Cmd + F5
  • NVDA (Windows): free and the most widely used on the market
  • TalkBack (Android): built into Android devices
  • Test complete navigation without a mouse at least once per sprint

Automated testing tools

Automated tools are the first filter for detecting accessibility issues. They do not replace manual testing, but they catch common errors like missing alt text, insufficient contrast, absent labels or broken heading hierarchy.

  • axe DevTools: browser extension that audits the page against WCAG 2.1/2.2 rules
  • Lighthouse (Accessibility tab): included in Chrome DevTools, quick audit with a score
  • eslint-plugin-jsx-a11y: accessibility linting for React components during development
  • Pa11y: CLI tool for integrating accessibility testing into CI/CD pipelines
  • Contrast Checker: verifies colour combinations meet WCAG ratios (4.5:1 for normal text)

Key Takeaways

  • Semantic HTML is the foundation: use the correct tags before resorting to ARIA
  • All functionality must be keyboard-accessible with a visible focus indicator
  • Automated tools detect only 30–50% of issues: manual testing is essential
  • WCAG 2.2 Level AA is the recommended minimum and legally required in many jurisdictions
  • Accessibility improves SEO, overall usability and reduces legal risk

Is your website accessible to all users?

We audit your site’s accessibility, identify barriers and help you meet WCAG 2.2 with a practical improvement plan.