Web Accessibility: The WCAG Basics Every Team Should Ship

Web accessibility is the practice of ensuring websites, tools, and technologies are designed and developed in a way that people with disabilities can use them. When implemented correctly, it is not a feature or a compliance task, but a fundamental aspect of software quality, akin to performance, security, and maintainability. For technical teams, understanding the mechanics of accessibility is crucial for building products that are robust, inclusive, and legally sound. This means moving beyond checklists and grasping the underlying standards that make the web work for everyone.

The foundation for modern web accessibility is the Web Content Accessibility Guidelines (WCAG)^[1], a set of technical standards published by the World Wide Web Consortium (W3C)^[2]. Shipping products that conform to WCAG extends beyond avoiding lawsuits; it is about engineering excellence and reaching the broadest possible audience.

The Mechanics of Accessibility: The Accessibility Tree

To engineer accessible experiences, you must first understand the mechanism that connects your code to assistive technologies (AT) like screen readers, screen magnifiers, and voice control software. This mechanism is the accessibility tree.

When a browser loads a webpage, it parses the HTML into a Document Object Model (DOM)^[3]. The DOM represents the page's structure and content. Concurrently, it parses CSS to create the CSS Object Model (CSSOM). The browser combines these to create the render tree, which represents the visual output. A parallel process occurs where the browser uses the DOM to create an accessibility tree^[4]. This tree is a simplified representation of the user interface, filtered to contain only the information relevant to assistive technologies.

Each node in the accessibility tree exposes key properties of a UI element:

• Role: The type of element (e.g., button, link, heading).
• Name: The element's label (e.g., the text inside a button, the alt text of an image).
• State: The element's current condition (e.g., checked, disabled, expanded).
• Value: The element's value (e.g., the number in a slider, the text in an input field).

Assistive technologies do not interact with your site's visual rendering. They query this accessibility tree through platform-specific accessibility APIs. A screen reader, for instance, traverses the tree and announces the role, name, and state of each element. This is why using a <div> with a JavaScript onClick handler is not a button. A <div> has a generic role in the accessibility tree, conveying no information about its interactive nature. A proper <button> element exposes a button role, is keyboard focusable by default, and can be activated with both Enter and Space keys. Writing accessible HTML is the act of creating a useful and accurate accessibility tree.

A Brief History of Web Accessibility Standards

The web was conceived by Tim Berners-Lee^[5] with inclusivity in mind. As the web grew more complex and graphical, it became less accessible to users with disabilities. In response, the W3C launched the Web Accessibility Initiative (WAI)^[6] in 1997 to create guidelines and support materials.

The first version, WCAG 1.0^[7], was published in 1999. It was a significant first step but was tightly coupled to the HTML of its time and proved difficult to apply to new technologies.

A major overhaul came with WCAG 2.0^[8] in 2008. This version established a new foundation based on four stable, technology-agnostic principles. Instead of prescribing specific HTML fixes, it defined success criteria based on outcomes, making the guidelines applicable to any web technology, including Flash, PDF, and modern JavaScript frameworks. This principled approach is why WCAG 2.x remains relevant today.

Subsequent versions have been additive, building on the WCAG 2.0 framework:

• WCAG 2.1^[9] (2018) added success criteria addressing mobile accessibility, people with low vision, and those with cognitive and learning disabilities.
• WCAG 2.2^[10] (2023) is the current recommendation, further extending 2.1 with new criteria, such as making focus indicators more visible and interactive targets easier to activate.

These standards are more than technical recommendations. They are frequently cited in legal contexts. In the United States, websites for public accommodations are often required to be accessible under the Americans with Disabilities Act (ADA)^[11], and courts consistently use WCAG 2.x Level AA as the benchmark for compliance. Similar regulations exist globally, such as Section 508^[12] for U.S. federal agencies and EN 301 549^[13] in the European Union.

The Four Principles of WCAG: POUR

WCAG 2.x is organized around four core principles, known by the acronym POUR. For content to be accessible, it must be Perceivable, Operable, Understandable, and Robust.

Perceivable

Information and user interface components must be presentable to users in ways they can perceive. This means users must be able to perceive the information being presented; it can't be invisible to all of their senses.

• Technical Examples: Providing text alternatives (alt attribute) for non-text content like images. Offering captions and transcripts for audio and video. Ensuring color is not the only means of conveying information. Maintaining a minimum color contrast ratio between text and its background (4.5:1 for normal text at Level AA).

Operable

User interface components and navigation must be operable. This means users must be able to operate the interface; the interface cannot require interaction that a user cannot perform.

• Technical Examples: All functionality is available from a keyboard, without requiring a mouse. Users have enough time to read and use content. Content does not cause seizures or physical reactions. Users can easily navigate, find content, and determine where they are.

Understandable

Information and the operation of the user interface must be understandable. This means users must be able to understand the information as well as the operation of the user interface.

• Technical Examples: Making text content readable and understandable (e.g., by specifying the page language with lang="en"). Making web pages appear and operate in predictable ways. Helping users avoid and correct mistakes by providing clear error messages and instructions.

Robust

Content must be robust enough for interpretation by a wide variety of user agents, including assistive technologies. As technologies and user agents evolve, the content should remain accessible.

• Technical Examples: WCAG 2.2 removed the 4.1.1 Parsing criterion because modern browsers automatically correct parsing errors, meaning they no longer confuse assistive technologies. For custom components built with JavaScript, using ARIA (Accessible Rich Internet Applications)^[14] to define their roles, states, and properties. This ensures the accessibility tree is correctly populated for non-standard elements.

Conformance Levels: A, AA, AAA

WCAG defines three levels of conformance to allow for prioritization:

• Level A: The most basic level of web accessibility. Failing to meet these criteria creates significant barriers for users with disabilities. It is the minimum level of conformance.
• Level AA: This level addresses the most common and significant barriers for disabled users. Level AA is the target conformance level for most websites and is the standard referenced in most accessibility legislation and litigation.
• Level AAA: The highest level of conformance. It aims to make content accessible to the widest possible audience. It is not always possible to satisfy all Level AAA criteria for some types of content; for this reason, it is often treated as an enhancement rather than a general requirement.

For most organizations, the pragmatic and legally defensible goal is full conformance with WCAG 2.1 or 2.2 at Level AA.

Practical Application: Building an Accessible Tab Component

Let's move from theory to practice. Using semantic HTML is the first and most important step. For example, always use a <button> element for actions, not a <div> or <a>.

<!-- Bad: Not a button to assistive tech, not keyboard focusable by default -->
<div class="fake-button" onclick="doSomething()">Submit</div>

<!-- Good: Semantically correct, focusable, keyboard operable by default -->
<button onclick="doSomething()">Submit</button>

When building custom components that have no native HTML equivalent, you must use ARIA to bridge the semantic gap. Consider a common tabbed interface. A sighted user understands its function visually, but a screen reader user only has the accessibility tree. We must use ARIA to build that tree correctly.

The ARIA Authoring Practices Guide (APG)^[15] provides vetted patterns for common widgets. For a tab interface^[16], we need specific roles, states, and keyboard behaviors.

Here is a simplified structure with the necessary ARIA attributes:

<div class="tabs">
 <div role="tablist" aria-label="Account Settings">
 <button id="tab-1" type="button" role="tab" aria-selected="true" aria-controls="panel-1">
 Profile
 </button>
 <button id="tab-2" type="button" role="tab" aria-selected="false" aria-controls="panel-2" tabindex="-1">
 Billing
 </button>
 </div>
 <div id="panel-1" role="tabpanel" tabindex="0" aria-labelledby="tab-1">
 <p>Content for Profile...</p>
 </div>
 <div id="panel-2" role="tabpanel" tabindex="0" aria-labelledby="tab-2" class="hidden">
 <p>Content for Billing...</p>
 </div>
</div>

Let's break down the key ARIA roles and properties:

• role="tablist": Identifies the container for the set of tabs.
• role="tab": Identifies each tab control.
• role="tabpanel": Identifies the container for the content associated with a tab.
• aria-selected="true"/"false": Informs assistive tech which tab is currently active.
• aria-controls="panel-id": Creates a programmatic link between a tab and its corresponding panel.
• aria-labelledby="tab-id": Associates the panel with its controlling tab, providing context to screen reader users when they land in the panel.
• tabindex="-1": Removes inactive tabs from the default tab order, as they are navigated with arrow keys, not the Tab key.

This HTML structure must be paired with JavaScript to manage focus, update aria-selected states, and handle keyboard interactions (e.g., Left/Right arrow keys to switch between tabs). This example demonstrates the "Robust" principle: we've created a custom component that provides a complete and accurate representation of itself in the accessibility tree.

The Tradeoffs and Decision Lens for Leaders

Adopting accessibility is a strategic decision with clear costs and benefits.

Costs and Tradeoffs:

• Expertise and Time: Accessible development requires knowledge of WCAG, ARIA, and testing methodologies. It can increase initial development time, especially if the team is new to these practices.
• Design Constraints: Accessibility imposes constraints on design. Color palettes must meet contrast requirements, and complex, non-standard interactions may need to be simplified. This requires designers and developers to collaborate from the start.
• Testing Overhead: Ensuring conformance requires a multi-faceted testing approach. Automated tools can catch some issues, but manual testing with a keyboard and screen reader is non-negotiable for verifying operability and usability.

Benefits and ROI:

• Expanded Addressable Market: Over 1.3 billion people^[17], or 16% of the global population, experience a significant disability. An inaccessible product excludes a substantial market segment.
• Legal Risk Mitigation: Accessibility lawsuits are common and costly. Proactively conforming to WCAG AA is the most effective way to mitigate this significant business risk.
• Improved SEO and Code Quality: The practices that support accessibility, like using semantic HTML^[18], providing text alternatives, and creating a logical content structure, are likewise highly valued by search engine crawlers. This leads to better SEO and more maintainable, higher-quality code.
• Enhanced UX for All: Accessibility features often benefit all users, a phenomenon known as the curb-cut effect. For example, video captions help users in noisy environments, high-contrast text is easier to read in bright sunlight, and keyboard navigation is a powerful efficiency tool for many users.

A Decision Lens for Implementation:

1. Set a Standard: Adopt WCAG 2.1 or 2.2 Level AA as the default engineering standard for all user-facing products.
2. Prioritize Core Flows: Begin by focusing on the most critical user journeys: authentication, checkout, core product functionality. Achieve conformance there first.
3. Shift Left: Integrate accessibility into the design and definition-of-done phases. It is far cheaper to build it in than to bolt it on later.
4. Invest in Systems: Use or build an accessible component library. This amortizes the cost of accessibility across all products and ensures consistency.

Correcting Common Misconceptions

• "Accessibility is only for blind users." This statement is false. Accessibility encompasses a broad range of disabilities^[19]: auditory, cognitive, neurological, physical, speech, and visual. It includes situational limitations, like a broken arm or a slow internet connection.
• "Automated tools find all the problems." False. Automated tools can detect only about 30% to 50% of WCAG issues. They are excellent for catching things like missing alt text or color contrast failures, but they cannot determine if your tab order is logical or if an image's alt text is meaningful. Manual testing is essential.
• "Accessibility ruins the aesthetic." This reflects a lack of imagination. Accessibility is a creative constraint, similar to mobile-first design or performance budgets. Skilled designers can create beautiful and highly accessible interfaces.
• "We don't have users with disabilities." This is statistically improbable and legally perilous. Many disabilities are not visible, and you cannot assume the abilities of your user base. Building a digital world that excludes people with disabilities is discriminatory.

Where We Are Today

WCAG 2.2 became the official W3C Recommendation in October 2023. While WCAG 2.1 AA remains a common legal standard, new projects should target WCAG 2.2 AA. The tooling ecosystem is mature, with powerful automated checkers like axe, browser developer tools, and linters that can be integrated into CI/CD pipelines.

Looking ahead, the W3C is developing WCAG 3.0 (codename "Silver")^[20], a future standard that will likely introduce a new conformance model and a broader scope. It remains in an early draft stage and is years away from replacing WCAG 2.x. For the foreseeable future, WCAG 2.2 is the standard to build on.

Ultimately, web accessibility is a solvable engineering problem. It requires a firm grasp of the underlying mechanics, a commitment to established standards, and a team-wide understanding that an inclusive product is a better product.