One in five people in the UK has a disability. That is not a niche audience; it is a significant portion of your users. Yet accessibility remains an afterthought on most web projects, bolted on at the end (if at all) rather than built in from the start.
The good news is that the fundamentals of web accessibility are not complicated. In my experience, most of the work comes down to using HTML correctly, being thoughtful about design, and testing with the tools your users actually rely on.
Why Accessibility Matters Beyond Compliance
Yes, accessibility is a legal requirement in many countries. The UK Equality Act, the European Accessibility Act, and the US ADA all have provisions covering digital products. But compliance is the floor, not the ceiling.
Accessible websites are better websites for everyone. Captions help people watching videos in noisy environments. High colour contrast helps people using screens in bright sunlight. Keyboard navigation helps power users who prefer not to reach for a mouse. Good heading structure helps screen reader users and search engines alike.
When you build for accessibility, you build for resilience. According to the WebAIM Million report ↗, which analyses the top one million home pages every year, 95.9% of pages had automatically detectable accessibility errors in their most recent analysis. That represents an enormous opportunity for teams that take accessibility seriously.
Semantic HTML: Your Most Powerful Tool
The single most impactful thing you can do for accessibility is use the correct HTML elements. Browsers and assistive technologies have spent decades learning how to interpret semantic HTML. When you use a <button>, screen readers announce it as a button, keyboard users can activate it with Enter or Space, and it is focusable by default.
When you use a <div onclick="..."> instead, you get none of that for free. You have to manually add role="button", tabindex="0", keyboard event handlers, and focus styles. And you will almost certainly miss something.
Elements That Do the Heavy Lifting
Headings (<h1> through <h6>) create a document outline that screen reader users navigate by. Use them in order. Never skip from <h2> to <h4>. Never use a heading just because you want bigger text.
Landmarks (<nav>, <main>, <header>, <footer>, <aside>) let screen reader users jump between major sections of your page. A well-structured page with proper landmarks is dramatically easier to navigate than a soup of <div> elements.
Lists (<ul>, <ol>) are announced with their item count, helping users understand the scope of the content. Navigation menus, search results, and any repeated set of items should use list markup.
Forms rely on <label> elements associated with their inputs. The for attribute on a label must match the id of its input. This is non-negotiable; without it, screen reader users cannot identify what a form field is for.
<!-- Correct -->
<label for="email">Email address</label>
<input type="email" id="email" name="email" />
<!-- Incorrect: no programmatic association -->
<span>Email address</span>
<input type="email" name="email" />The Most Common Accessibility Failures
The WebAIM Million report consistently finds the same categories of failure year after year. Here is a breakdown of the most prevalent issues:
| Issue | Prevalence | Impact | Fix |
|---|---|---|---|
| Low contrast text | ~83% of pages | Text difficult or impossible to read | Ensure 4.5:1 ratio minimum |
| Missing alt text | ~55% of pages | Images invisible to screen reader users | Add descriptive alt attributes |
| Missing form labels | ~46% of pages | Form fields unidentifiable | Associate <label> with every input |
| Empty links | ~44% of pages | Links with no accessible name | Add descriptive link text |
| Missing document language | ~18% of pages | Screen readers cannot determine language | Add lang attribute to <html> |
| Empty buttons | ~27% of pages | Buttons with no accessible name | Add visible text or aria-label |
Keyboard Accessibility
Every interactive element on your page must be usable with a keyboard alone. This is not just for screen reader users; it matters for people with motor impairments, people using switch devices, and power users who prefer keyboard navigation.
The Basics
All natively interactive HTML elements (links, buttons, inputs, selects) are keyboard accessible by default. If you are building custom components, ensure they follow these principles:
- Focusable. The element can receive focus via Tab (or programmatically).
- Operable. The element can be activated with Enter, Space, or arrow keys as appropriate.
- Visible focus. The element has a clearly visible focus indicator. Never write
outline: nonewithout providing an alternative focus style.
I have found that the best approach is to always test with the Tab key before marking a component as complete. It takes 30 seconds and catches issues that no automated tool will flag.
Focus Management
When content changes dynamically, focus management becomes critical. If a user clicks a button that opens a modal, focus should move to the modal. When the modal closes, focus should return to the button that opened it. Without this, keyboard users are left stranded in the wrong part of the page.
Similarly, if an action removes an element from the DOM (deleting an item from a list, for example), you need to move focus somewhere logical. Otherwise, the focus resets to the top of the page, which is disorienting. If you are building with a JavaScript framework, check that your framework’s transition and routing logic handles focus correctly.
Colour and Contrast
WCAG 2.2 ↗ requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18px bold or 24px regular). These are minimum values; aim higher when possible.
Beyond Contrast Ratios
Never rely on colour alone to convey information. A form field with a red border to indicate an error is meaningless to someone who cannot perceive red. Add an error message in text. Use an icon. Provide multiple cues.
Similarly, charts and data visualisations should use patterns or labels in addition to colour. A pie chart with three shades of blue is inaccessible to many colour-blind users. When building CSS for large projects, establish accessible colour tokens as part of your design system from day one.
Testing Contrast
Browser DevTools include contrast checking. Chrome’s colour picker shows the contrast ratio against WCAG thresholds. Firefox’s Accessibility Inspector highlights contrast issues automatically. Use these tools as part of your regular development workflow, not as a last-minute audit.
ARIA: Use With Caution
ARIA (Accessible Rich Internet Applications) attributes bridge the gap between custom widgets and assistive technology. But the first rule of ARIA is: do not use ARIA if you can use native HTML instead.
ARIA does not add behaviour. Adding role="button" to a <div> tells screen readers it is a button, but it does not make it focusable or keyboard operable. You still need tabindex="0" and keyboard event handlers. Native <button> gives you all of this for free.
When ARIA Is Necessary
ARIA is genuinely useful for:
- Live regions (
aria-live="polite") that announce dynamic content changes, such as search results updating or a notification appearing - Describing relationships (
aria-describedby,aria-labelledby) between elements that are not programmatically associated through HTML - Custom widgets like tabs, accordions, and tree views where no native HTML equivalent exists
- States and properties (
aria-expanded,aria-selected,aria-disabled) that communicate the current state of interactive components
Learn the common ARIA patterns from the WAI-ARIA Authoring Practices Guide ↗, but always prefer semantic HTML when it can do the job.
Testing Accessibility
Automated testing catches roughly 30 to 40 percent of accessibility issues. It is a useful starting point but far from sufficient.
A Practical Testing Approach
Automated scans. Run axe DevTools or Lighthouse on every page. Integrate axe-core into your CI pipeline to catch regressions. These tools reliably detect missing alt text, contrast failures, missing form labels, and invalid ARIA usage.
Keyboard testing. Put your mouse away and navigate your application using only Tab, Shift+Tab, Enter, Space, Escape, and arrow keys. Can you reach every interactive element? Can you see where focus is? Can you operate every control? This five-minute test catches issues that no automated tool will find.
Screen reader testing. Use VoiceOver (built into macOS) or NVDA (free on Windows) to navigate your key user journeys. Does the reading order make sense? Are interactive elements announced with their role and state? Are dynamic changes communicated?
Zoom testing. Increase your browser zoom to 200%. Does the layout still work? Is text readable? Are interactive elements still usable? WCAG requires that content is functional at 200% zoom.
Building Accessibility Into Your Workflow
Accessibility is cheapest when addressed from the start. Retrofitting an inaccessible application is expensive, frustrating, and rarely thorough.
Include accessibility acceptance criteria in your tickets. Mention the expected keyboard behaviour, the required ARIA attributes, and the alt text for any images. Run automated checks in your pull request pipeline. Test with a keyboard before marking a feature complete.
It does not need to be perfect from day one. But it does need to be intentional. Every improvement makes your product usable by more people, and that is what building for the web is supposed to be about.
Frequently asked questions
What is WCAG and which version should I target?
WCAG (Web Content Accessibility Guidelines) is the international standard for web accessibility. Target WCAG 2.2 Level AA as a minimum, which covers the vast majority of accessibility requirements and is the level referenced by most accessibility legislation.
Do I need to make my site work without JavaScript for accessibility?
Not necessarily. Screen readers and assistive technologies work with JavaScript-rendered content. The key is ensuring that interactive elements are keyboard accessible, properly labelled, and that dynamic content changes are announced to assistive technology through ARIA live regions.
How do I test my site for accessibility?
Use a combination of automated tools (axe DevTools, Lighthouse), manual keyboard testing (can you use every feature with Tab, Enter, and arrow keys?), and screen reader testing (VoiceOver on Mac, NVDA on Windows). Automated tools catch roughly 30-40% of issues; manual testing is essential.
Is accessibility legally required?
In many jurisdictions, yes. The European Accessibility Act, the UK Equality Act, the US ADA, and Section 508 all include provisions for digital accessibility. Beyond legal requirements, accessible sites reach more users and typically have better SEO and usability.
What are the most common accessibility mistakes developers make?
The most frequent issues are missing alt text on images, poor colour contrast, forms without labels, non-keyboard-accessible interactive elements, and missing heading hierarchy. These five issues account for the majority of accessibility barriers on the web.
Enjoyed this article? Get more developer tips straight to your inbox.
Related articles
Choosing the Right JavaScript Framework in 2026
A practical guide to choosing the right JavaScript framework in 2026, comparing React, Vue, Svelte, Angular, and newer contenders.
Gareth Clubb 8 min read Web Performance Quick Wins for Frontend Developers
Practical web performance quick wins for frontend developers, covering images, fonts, JavaScript, CSS, and Core Web Vitals.
Gareth Clubb 8 min read CSS Architecture for Large Projects
Learn CSS architecture strategies for large projects, including BEM, utility-first approaches, and scalable file organisation.
Gareth Clubb 8 min read
Comments
Join the conversation. Share your experience or ask a question below.
No comments yet. Be the first to share your thoughts.