ADA and WCAG

When following website production for the US market you often see terms such as “ADA compliance” and “WCAG Level AA.” Both concern accessibility so they look similar but their roles differ. ADA is US law. WCAG is a technical standard for evaluating web content.

We work toward accessibility as far as expression and budget allow. For US-facing websites the situation is different and needs care. To reduce confusion during production this note organizes the relationship between ADA and WCAG published by W3C from an implementation viewpoint.

ADA and WCAG have different roles

ADA (Americans with Disabilities Act) is a US federal law that prohibits discrimination on the basis of disability. Titles most relevant to websites are Title II which covers state and local government and Title III which covers businesses and others that offer goods or services to the public.

WCAG (Web Content Accessibility Guidelines) is a technical standard developed by the W3C Web Accessibility Initiative. It defines success criteria under four principles:

• Perceivable
• Operable
• Understandable
• Robust

ADA addresses the legal duty of who must provide what kind of access. WCAG turns that into verifiable criteria such as color contrast keyboard operation and form labels. Conformance to WCAG is an important basis for implementing accessibility but it alone does not settle all ADA responsibility.

Title II specifies WCAG 2.1 Level AA

In 2024 the US Department of Justice updated ADA Title II rules and adopted WCAG 2.1 Level AA as the technical standard for web content and mobile apps provided by state and local governments. Content provided through contracts or licenses with external vendors is generally in scope as well. Some content has exceptions and there are provisions on undue burden and fundamental alteration of service so the scope must be checked in the rule text itself.

An interim final rule in April 2026 extended the compliance dates by one year. As of July 2026 the deadlines are:

Type of public entity	Compliance date
Population of 50,000 or more	April 26, 2027
Population of fewer than 50,000	April 26, 2028
Special district government	April 26, 2028

An extended deadline does not remove existing accessibility obligations under Title II. The rule also specifies WCAG 2.1 not WCAG 2.2. Do not assume a newer version is enough on your own. Use the specified version as the baseline for audit and delivery.

Under Title III WCAG becomes the practical implementation baseline

Title III requires that goods and services of businesses open to the public such as stores hotels banks and medical providers be usable by people with disabilities. The Department of Justice has taken the position that ADA requirements also apply when those goods or services are provided on the web.

At the same time as of July 2026 there is no detailed federal DOJ technical rule that uniformly specifies a particular WCAG version for Title III websites. DOJ guidance lists WCAG as a useful technical standard for implementing accessible web features.

So for private sites it is not accurate to conclude that meeting WCAG 2.2 Level AA means full ADA compliance. First confirm the relationship between the business and the site the services offered and applicable state law or contracts. Then use WCAG as the shared baseline for design and verification.

WCAG versions and conformance levels

WCAG 2.2 was published as a W3C Recommendation in October 2023. It adds nine success criteria to 2.1 and removes the outdated 4.1.1 Parsing. Additions include keeping keyboard focus from being hidden by fixed UI alternatives to dragging a minimum pointer target size and not requiring cognitive function tests for authentication.

W3C recommends using WCAG 2.2 for new work and updates. Content that conforms to WCAG 2.2 also conforms to 2.1 and 2.0. When law or contract names WCAG 2.1 keep records that show achievement against 2.1.

Conformance levels are A AA and AAA. AA means meeting all Level A and Level AA success criteria as a cumulative set not only a few AA items. W3C does not recommend making AAA a general requirement for an entire site.

Conformance is judged for a whole page not a fragment. Processes that complete across multiple pages such as purchase or application include the intermediate screens. A high score on the top page alone or a clean automated scan cannot stand in for site-wide conformance.

Scope of support is decided per project

Even when full conformance is not declared WCAG can still guide implementation decisions. Even if not every success criterion is met there is value in correct headings keyboard access along main paths and text for form errors.

Treat partial adoption of criteria separately from a claim of “conformance to WCAG 2.2 Level AA.” The latter requires meeting Level A and AA success criteria across the target pages and processes.

In general web production you can set priorities while balancing expression accessibility and effort. For US-facing work or contracts that list ADA or WCAG confirm scope and verification methods before production starts. The implementation examples below are not mandatory for every project. They are a baseline when considering support.

Start from the meaning of HTML

When considering support begin by using native HTML meaning not only adding ARIA attributes just before launch. Building headings links buttons and forms with their own elements lets the browser expose name role and state to assistive technology.

Clickable UI built with div requires reimplementing keyboard behavior and button role separately. Using button for actions and a for navigation keeps the implementation surface smaller.

<button type="button" aria-expanded="false" aria-controls="site-menu">
	Menu
</button>

<nav id="site-menu" aria-label="Primary navigation" hidden>
	<a href="/about/">About</a>
	<a href="/projects/">Projects</a>
</nav>

Use ARIA to fill in relationships and states that native HTML cannot express. In this example the button role is not rebuilt with ARIA. Only open/closed state and the controlled target are conveyed with aria-expanded and aria-controls. When JavaScript opens or closes the menu update hidden and aria-expanded together.

const button = document.querySelector( '[aria-controls="site-menu"]' );
const menu = document.querySelector( '#site-menu' );

button.addEventListener( 'click', () => {
	const expanded = button.getAttribute( 'aria-expanded' ) === 'true';

	button.setAttribute( 'aria-expanded', String( !expanded ) );
	menu.hidden = expanded;
} );

Also communicate form errors in text

Associating a visible label with each input is another relatively easy step. Drawing a red border on error alone does not reach people who have trouble distinguishing color or who are not looking at the screen. State which field failed and why in text and make the input reference that text.

<form id="contact-form" novalidate>
	<label for="email">Email address</label>
	<p id="email-hint">Enter an address where you can receive replies</p>
	<input
		id="email"
		name="email"
		type="email"
		autocomplete="email"
		aria-describedby="email-hint email-error"
		required
	>
	<p id="email-error" aria-live="polite"></p>
	<button type="submit">Submit</button>
</form>

const form = document.querySelector( '#contact-form' );
const email = document.querySelector( '#email' );
const error = document.querySelector( '#email-error' );

function validateEmail() {
	let message = '';

	if ( email.validity.valueMissing ) {
		message = 'Please enter your email address';
	} else if ( email.validity.typeMismatch ) {
		message = 'Please enter a valid email address';
	}

	email.setAttribute( 'aria-invalid', String( message !== '' ) );
	error.textContent = message;

	return message === '';
}

form.addEventListener( 'submit', ( event ) => {
	if ( !validateEmail() ) {
		event.preventDefault();
		email.focus();
	}
} );

email.addEventListener( 'input', () => {
	if ( email.getAttribute( 'aria-invalid' ) === 'true' ) validateEmail();
} );

aria-live announces changed error messages to assistive technology. Do not put it on every sentence. Limit it to places that update as a result of an action and that the user needs for the next decision.

Design focus and operable areas

When using WCAG as a baseline confirm that keyboard users can see the current position move in a logical order and are not trapped in any component. Avoiding outline: none that removes the browser focus indicator already helps keep basic operability.

:where(a, button, input, select, textarea):focus-visible {
	outline: 3px solid #005fcc;
	outline-offset: 3px;
}

:where(a, button, input, select, textarea) {
	scroll-margin-block: 6rem;
}

.icon-button {
	min-inline-size: 44px;
	min-block-size: 44px;
}

WCAG 2.2 Level AA target size is generally at least 24×24 CSS px with exceptions for spacing and related cases. When this is in scope do not aim only at the minimum. Consider padding that remains easy to press with a finger or hand tremor. With fixed headers or cookie banners also check that Tabbed elements are not covered.

For drag-to-reorder UI alternatives such as up/down buttons or a menu that complete the task with a single pointer become the substitute. Conformance to WCAG 2.2 Level AA needs a path to the same result even if the appearance differs.

Separate the roles of color and motion

WCAG 2.2 Level AA requires contrast of at least 4.5:1 for normal-size text and 3:1 for large text. Logos and inactive elements have exceptions so do not judge by numbers alone. Check the conditions of each success criterion.

Color can still carry brand expression while state is not conveyed by color alone. Combine text for errors shape or icons for selection and labels for charts.

Motion need not be removed wholesale. Separate roles. Stop decorative movement and parallax according to OS settings. For motion needed to understand state change reduce time or distance.

@media (prefers-reduced-motion: reduce) {
	html {
		scroll-behavior: auto;
	}

	.decorative-motion {
		animation: none;
		transform: none;
		transition: none;
	}
}

Priorities for Canvas and WebGL

On sites that use Canvas or Three.js making every expression accessible in the same way can be difficult. Separating whether 3D is decoration information or interaction makes scope easier to reason about.

If 3D is decoration you can keep it out of assistive technology readout and leave page headings and body copy as HTML. Central information and main paths can be separated from WebGL while keeping the expression.

<section class="hero" aria-labelledby="hero-title">
	<canvas class="hero__canvas" aria-hidden="true"></canvas>
	<div class="hero__content">
		<h1 id="hero-title">Garden Eight</h1>
		<p>A studio for design and development</p>
		<a href="/projects/">View projects</a>
	</div>
</section>

If labels or objects inside the 3D scene carry information hiding them with aria-hidden keeps that information from assistive technology. When this is in scope place headings and descriptions in the DOM and provide a path to object selection through HTML buttons or radio buttons as well.

Building alternatives for every 3D interaction may not fit the project conditions. Even then avoiding dependence on WebGL alone for central information and primary actions such as contact is a relatively high-priority step. For US-facing work where WCAG conformance is a requirement share difficulty and effort before production and agree on a scope that includes expression.

Separate automated and manual testing

Automated checks are useful for finding missing labels contrast issues and attribute mismatches early. They cannot alone decide whether alternative text fits the prose whether focus order is understandable or whether operation works with a screen reader. W3C also states that conformance judgment needs evaluation by people with knowledge.

When WCAG conformance is a requirement layer checks as follows. This does not mean every project runs the same suite. Set the range to the precision required.

1. Static checks of HTML and components
2. Automated accessibility tests
3. Keyboard operation with Tab Shift+Tab Enter Space Escape
4. Reflow under zoom text enlargement and narrow viewports
5. Readout and operation with representative browsers and assistive technology
6. Evaluation that includes users with disabilities where possible

When defining test scope check not only template types but also end-to-end processes such as purchase booking and contact. Stateful UI such as modals menus carousels and form errors has checkpoints beyond the initial view.

For US-facing work share scope first

Accessibility is not fixed by a single audit. CMS article additions external service updates and new campaign pages change the state. Especially for US-facing work or contracts that include WCAG conformance sharing the following before production makes judgment easier.

• Target WCAG version and level
• Target pages components and main processes
• Scope of third-party content and external services
• Methods for automated and manual testing
• Known issues and remediation approach
• Contact path for users to report problems
• Ownership of post-launch updates and retesting

The point of separating ADA and WCAG is not to demand the same response from every site. It is to clarify legal scope and technical verification methods so you can decide how far to go on that project.

References

• Guidance on Web Accessibility and the ADA – ADA.gov
• Accessibility of Web Content and Mobile Apps Provided by State and Local Government Entities – ADA.gov
• Extension of Compliance Dates for Web and Mobile Accessibility – Federal Register
• Web Content Accessibility Guidelines (WCAG) 2.2 – W3C
• What's New in WCAG 2.2 – W3C WAI
• Evaluating Web Accessibility Overview – W3C WAI