The Users You’re Leaving Out
Approximately 15% of the world’s population has some form of disability — visual, auditory, motor, or cognitive — that affects how they interact with digital content. For websites that haven’t implemented accessibility considerations, a significant fraction of potential users encounter barriers that prevent them from completing tasks, accessing information, or using services that the site provides. These aren’t edge cases — they’re users whose business, attention, and legal protection are relevant to the organisations whose websites exclude them.
Website accessibility — designing and building websites that work for users with diverse abilities — has become both a legal requirement in many jurisdictions (the ADA in the US, EN 301 549 in the EU, and equivalent regulations in many other countries require digital accessibility for public-facing websites and services) and a user experience practice that benefits all users, not only those with disabilities. The accessible website that has properly structured content, keyboard navigation, and sufficient contrast is also the website that works better for sighted users under suboptimal conditions, for users on mobile devices, and for search engine indexing.
The WCAG Standard: What It Requires
The Web Content Accessibility Guidelines (WCAG) published by the W3C are the international standard for web accessibility, organised around four principles: Perceivable (content can be perceived through available senses — visual content must have text alternatives, audio must have captions), Operable (interface components can be operated by all users — keyboard-only navigation must work, focus states must be visible), Understandable (content and operation must be understandable — clear language, predictable behaviour, error messages that describe the problem), and Robust (content must work with assistive technologies including screen readers).
WCAG 2.1 Level AA is the target that most accessibility regulations reference as the compliance standard. It includes 50 success criteria across the four principles, each with clear testable definitions. The WCAG Quick Reference at w3.org/WAI/WCAG21/quickref provides the complete list with implementation techniques; the Web Accessibility Initiative’s tutorials provide practical implementation guidance for each criterion.
The Accessibility Audit: Starting With What Exists
An automated accessibility scan is the fastest way to identify the most obvious issues in an existing website: WAVE (wave.webaim.org) and axe DevTools (browser extension) scan any URL and identify missing alternative text, low contrast ratios, form labels that aren’t connected to their inputs, and other automatically detectable issues. Automated scanning catches approximately 30–40% of accessibility barriers — a meaningful starting point, but not a complete audit.
Manual testing covers what automated tools miss: keyboard navigation testing (Tab through the entire page using only the keyboard — can all interactive elements be reached and activated?), screen reader testing (NVDA on Windows and VoiceOver on Mac are free; test that screen reader users receive the same content and functionality as sighted users), and cognitive accessibility review (is the language clear, are instructions understandable, are error messages helpful?).
The High-Impact Fixes That Address the Most Common Barriers
Alternative text for images is the most common missing accessibility element and one of the most impactful to fix: screen reader users hear the alt text when they encounter an image. Descriptive alt text (‘Red tabby cat sitting on a windowsill looking at birds outside’) communicates image content; empty alt text (alt=”) on decorative images tells screen readers to skip the image; missing alt attributes leave screen readers announcing ‘image’ without any content information.
Form labels connected to their inputs are the second most common and most impactful fix: the HTML label element with a ‘for’ attribute matching the input’s ‘id’ attribute ensures that screen reader users hear the label when they navigate to the input. Without connected labels, form inputs announce only their type (‘text edit, combobox’) without the field name (‘Email address’). The visual label placement is irrelevant — the HTML connection is what accessibility requires.
Building Accessibility Into Development Workflow
The accessibility workflow that produces the most sustainable compliance: include accessibility requirements in design specifications (colour contrast ratios, focus indicator design, component behaviour for keyboard users), use semantic HTML as the default (heading hierarchy, button elements for buttons, link elements for navigation, list elements for lists) rather than non-semantic divs styled to look like interface elements, test with keyboard navigation before shipping any new interactive component, and include screen reader testing in the QA process for significant new features.
The cost of retrofitting accessibility into existing websites is consistently higher than building it in from the start — both in developer time and in the structural changes that semantic HTML and ARIA landmarks require when they weren’t considered in original implementation. Development teams that include basic accessibility checks in their pull request process and code review catch issues before they accumulate into the accessibility debt that requires expensive audit and remediation projects to address.