Why Web Accessibility Matters
Web accessibility is the practice of building websites and web applications that can be used by people with disabilities — including visual impairments, hearing impairments, motor impairments, and cognitive disabilities. The argument for accessibility that most resonates with development teams who have not previously considered it: the same accessibility improvements that serve users with disabilities also improve the experience for all users in specific contexts. The website that is navigable by keyboard serves the power user who prefers keyboard navigation and the user whose mouse has stopped working. The video with captions serves the deaf user and the user watching on a plane without headphones. The high-contrast text that serves the visually impaired user also serves the user reading in bright sunlight on a phone screen.
The accessibility legal requirement that most motivates organisations that might not act on ethical grounds alone: the litigation risk from accessibility failures, particularly in the US where the Americans with Disabilities Act (ADA) has been applied to websites through court decisions that have found web accessibility required by the same standards as physical accessibility. The pattern of ADA accessibility lawsuits against businesses with inaccessible websites has been growing, with thousands of cases filed annually — creating legal risk proportionate to the organisation’s public profile and the severity of the accessibility failures on its website.
The WCAG Guidelines Framework
The Web Content Accessibility Guidelines (WCAG), developed by the W3C Web Accessibility Initiative, provide the international standard for web accessibility organised around four principles: Perceivable (information and user interface components must be presentable to users in ways they can perceive — including text alternatives for non-text content, captions for audio, and sufficient colour contrast), Operable (user interface components and navigation must be operable — including keyboard accessibility for all functionality, sufficient time to complete tasks, and avoidance of content that triggers seizures), Understandable (information and the operation of user interface must be understandable — including readable text, predictable page behaviour, and input assistance that helps users avoid and correct mistakes), and Robust (content must be robust enough to be interpreted reliably by assistive technologies — including valid HTML that assistive technology can parse correctly).
The WCAG conformance level that most organisations should target: WCAG 2.1 Level AA, which is the conformance level required by most accessibility regulations and legal frameworks including the European Accessibility Act, Section 508 in the US federal government, and the standards referenced in most ADA settlement agreements. WCAG 2.1 Level AA builds on Level A (the minimum accessibility requirements) with additional criteria that address colour contrast, text resizing, captions for live audio, and navigability — the criteria that have the most impact on the usability of websites for users with disabilities in real-world usage.
The Most Common Accessibility Failures
The accessibility failures that appear most frequently in website accessibility audits and that affect the largest number of users with disabilities: the missing or inadequate text alternatives for images (the alt text that describes the image’s content to screen reader users, without which visually impaired users receive no information about the image), insufficient colour contrast between text and background (the light grey text on white background that meets aesthetic preferences but fails the WCAG 4.5:1 contrast ratio requirement for normal text, making the text difficult or impossible to read for users with low vision), missing form labels (the input field without an associated label that screen readers cannot announce to visually impaired users), keyboard navigation failures (the interactive elements that can be activated with a mouse but cannot be reached or activated by keyboard navigation alone, excluding users who cannot use a mouse), and missing focus indicators (the keyboard focus outline that is suppressed by CSS to avoid the visual interruption it creates, removing the navigation indicator that keyboard users rely on to know which element is currently focused).
The accessibility failure that most affects the usability of dynamic web applications for screen reader users: the missing ARIA attributes that communicate the dynamic state changes of interactive components to assistive technology. The custom dropdown that expands when clicked but that does not communicate its expanded state to the screen reader through aria-expanded, the modal that appears on top of the page content but that does not receive focus automatically and does not trap focus within the modal, and the alert that appears to provide feedback but that does not use role=alert to trigger announcement by the screen reader are all patterns that visual users can navigate by seeing but that screen reader users cannot navigate without the ARIA communication layer.
Accessibility Testing Methods
The accessibility testing approach that most completely identifies accessibility issues: the combination of automated testing (which identifies the accessibility failures that can be detected algorithmically — colour contrast failures, missing alt text, missing form labels, invalid HTML that affects assistive technology parsing) with manual testing (which identifies the accessibility failures that require human judgment — whether alt text accurately describes the image’s content, whether the page’s reading order makes logical sense when navigated linearly, whether the form’s error messages are clear and useful) and user testing with assistive technology users (which reveals the real-world impact of accessibility issues on users who have adapted their technology use to the specific assistive technologies they rely on).
The automated accessibility testing tool that most efficiently integrates into the development workflow: the axe-core library (available as a browser extension, a JavaScript testing library, and as the engine behind many accessibility testing tools) that runs accessibility checks against the live DOM and reports violations with their WCAG criteria references and suggested remediation. The axe-core browser extension that enables developers to run accessibility checks on any page they can view in the browser requires no test infrastructure setup and provides immediate feedback during development — the most accessible (appropriately) entry point for developers beginning to incorporate accessibility testing into their workflow.
Building Accessibility Into the Development Process
The development process integration that most effectively prevents accessibility failures from reaching production: the shift-left approach that introduces accessibility consideration at the design and development phases rather than the testing and remediation phase. The design review that evaluates colour contrast, focus states, and interactive component behaviour before development begins prevents the accessibility failures that are cheapest to fix at the design phase but expensive to retrofit after development is complete. The development-phase accessibility check that verifies keyboard navigation, screen reader announcement, and ARIA attribute correctness during feature development catches failures before they accumulate in the codebase.
The team accessibility knowledge investment that most improves the accessibility quality of code produced by developers who have not previously focused on accessibility: the screen reader familiarisation exercise, in which each developer spends thirty to sixty minutes navigating a website using only a screen reader (with the monitor off or the screen covered) to experience firsthand what the website sounds like rather than looks like. The developer who has experienced the disorienting sequence of link announcements without context, the form that provides no feedback about which fields have errors, and the image that is announced as image with no alt text has a visceral motivation to fix these issues that the abstract WCAG criterion does not provide — and the intuition for how content needs to be structured to make sense when navigated linearly and heard rather than seen.
