ADA-Compliant Website Design: Accessible Website Design to WCAG 2.2

Updated September 2026 · Written and maintained by the Progression Agency strategy team

Progression Agency provides ADA compliant website design and accessible website design for businesses, healthcare providers, schools, nonprofits and public agencies across the United States and worldwide: new sites built to WCAG 2.2 Level AA from the first wireframe, audits and remediation of existing sites, accessibility statements written accurately, and the testing with screen readers and keyboards that a checklist alone cannot replace.

What ADA compliant website design means

ADA compliant website design is a shorthand, because the Americans with Disabilities Act does not itself contain a technical web standard. What it means in practice is a site designed and built so that people with visual, hearing, motor and cognitive disabilities can perceive, operate and understand it, measured against the Web Content Accessibility Guidelines 2.2 published by the W3C. Accessible website design and ADA compliant website design describe the same work; the first names the outcome, the second the legal reason a business asks for it.

The distinction matters for how a project is scoped. A compliance project measures a site against WCAG success criteria and fixes failures. An accessible design project starts earlier: the wireframes, the color system, the components and the content are chosen so that the failures never appear, which costs less than remediation and produces a site that is faster and better organized for every visitor. This page covers both, and the website design and development page covers the wider build.

WCAG 2.2 explained for a website owner

WCAG is organized under four principles: content must be perceivable, operable, understandable and robust. Each principle has guidelines, and each guideline has testable success criteria at three levels. Level A removes the barriers that block use altogether, Level AA is the conformance target almost every regulation and contract references, and Level AAA is a set of enhancements adopted where they fit. WCAG 2.2 added nine criteria to 2.1, most of them about focus visibility, dragging alternatives, target size, consistent help and accessible authentication.

Perceivable: text alternatives, captions and contrast

Every image carries a text alternative that says what it does, decorative images are hidden from assistive technology, video has captions and an audio description or transcript, color never carries meaning alone, and text contrast meets 4.5:1 with controls and graphics at 3:1. Text must reflow at 320 CSS pixels wide and resize to 200 percent without loss, which is why layouts are built in relative units and tested at high zoom.

Operable: keyboard, focus, time and motion

Everything a mouse can do, a keyboard can do, in a sensible order, with a visible focus indicator that is not hidden under a sticky header. Nothing flashes more than three times a second, moving content can be paused, time limits can be extended, and any action that requires dragging has a click or keyboard alternative. Headings, landmarks and a skip link let a screen reader user move through a page as quickly as a sighted one.

Understandable and robust: language, errors and clean code

The page declares its language, navigation is consistent across the site, form errors are described in text next to the field with a suggestion, help is in the same place on every page, and the code validates so that browsers and assistive technologies interpret it the same way. Native HTML elements are used before ARIA, because a real button behaves correctly in every screen reader without further work.

Accessible website design examples: what the patterns look like

People search for accessible website design examples because they want to see that accessibility does not mean a plain site. The patterns below are what an accessible site looks like in practice; each is a design decision, not a retrofit.

• A navigation menu that opens on click and on Enter, closes on Escape, and lists the same items to a screen reader as to the eye.
• A hero with real text over a photograph, with a scrim behind the text so contrast holds on every image.
• Forms with visible labels above fields, not placeholder text that vanishes, and errors announced and described.
• Cards whose whole surface is clickable but whose link name is the card’s title, not “Read more” six times.
• Carousels replaced by a grid, or built with pause, previous and next controls that a keyboard can reach.
• Data tables with header cells and captions, so a screen reader announces the column with each value.
• Video with captions and a transcript beneath it, which also gives search engines the words.
• A focus style designed with the brand, thick enough to see and never removed.
• PDFs replaced by web pages or tagged properly when they must remain PDFs.
• Charts with a text summary and a data table, so the information exists outside the image.

ADA compliant website design by sector

Healthcare providers

Patient portals, appointment forms and results pages are where lawsuits and complaints concentrate, and HHS’s 2024 Section 504 rule sets WCAG 2.1 AA for funded providers. We build the public site accessible and audit the portal vendor’s product; see healthcare website design and dental website design.

State and local government

The 2024 DOJ Title II rule sets WCAG 2.1 AA for web content and mobile apps, with the first compliance date in April 2026 for larger entities and April 2027 for smaller ones and special districts. Archived content, third-party posts and certain documents have limited exceptions that must be documented rather than assumed.

Schools, colleges and education companies

Course catalogs, learning platforms and enrollment forms serve students with a legal right to access; public institutions fall under Title II and private ones under Title III and, where funded, Section 504. See school website design and online course website design.

Retail, hospitality and ecommerce

Store, restaurant and hotel sites are the most common Title III web lawsuit targets because a purchase, reservation or menu that cannot be completed with a screen reader is an easy claim to state. Checkout, booking and menu pages are tested first; see ecommerce website design and hotel website design.

Financial services, insurance and professional firms

Account applications, statements and calculators must work with assistive technology, and regulators expect an accessibility statement with a working contact. Corporate sites with investor and careers sections carry the same duties; see corporate website design.

Nonprofits and membership organizations

Donation forms, event registration and member portals are the pages to test first, and funders increasingly ask for a conformance statement in grant applications; see nonprofit website design.

Platform choices for accessible websites

No platform makes a site accessible by itself, and every platform can produce an accessible site when the theme, the components and the content are built for it. The differences are in how much the platform’s own output helps or fights you. A custom WordPress block theme or a custom-coded site gives full control of the markup; Webflow produces clean markup but its interactions need manual attention; drag-and-drop builders and page-builder plugins generate the most failures because their widgets ship without names, roles or keyboard support. Compare the general platform trade-offs in best CMS platforms.

Accessibility overlays and why we do not install them

Overlay widgets promise compliance from a line of JavaScript that adjusts contrast, font size and reading modes on top of an inaccessible site. They do not change the underlying markup, they interfere with the assistive technology people already use, and sites running them continue to be sued. Screen reader users have publicly asked for them to be removed. The Department of Justice’s web guidance points businesses to WCAG, not to overlays. We build and remediate the site itself, and we write an accessibility statement that describes real conformance, known gaps and how to get help.

Auditing and remediating an existing site

Most projects start with a site that already exists. An audit tests a representative sample of templates and the pages where the legal and business risk sits (checkout, booking, forms, login, PDFs), with automated tools first and manual testing second, and produces a report ordered by severity with the fix for each issue. Remediation follows in priority order, and a second pass verifies the fixes with a screen reader.

What automated tools find and what they miss

Automated scanners are good at missing alt text, contrast failures, missing form labels and invalid ARIA, and they find nothing about whether the alt text is useful, whether the focus order makes sense, whether a modal traps focus, or whether an error message helps. A report that comes only from a scanner overstates conformance, which is why every audit we deliver includes manual keyboard and screen reader testing by a person.

Prioritizing fixes

• Blockers first: anything that stops a task being completed with a keyboard or a screen reader.
• Then the high-traffic templates, because one template fix repairs hundreds of pages.
• Then forms, errors and authentication, where WCAG 2.2’s new criteria concentrate.
• Then media: captions, transcripts, audio description where needed.
• Then documents: convert PDFs to pages where possible, tag the rest.
• Finally the AAA enhancements that fit the site, such as larger contrast and simpler language.

Building a new site accessible from the first wireframe

The cheapest accessible site is the one designed that way. In our process the design system is tested before a page is built, every component is keyboard-operable before it is used, and the content team is trained on headings, links, alt text and plain language. The sequence below is the one we follow on every custom website build.

1. Discovery: who uses the site, the assistive technologies they rely on, the legal context (Title II, Title III, Section 504, EU markets) and the pages where risk concentrates.
2. Audit of the current site, if one exists, to learn which failures the organization keeps producing.
3. Content structure: page outlines with a single H1, logical headings, landmarks and link text that makes sense out of context.
4. Design system: palette checked to AA ratios, focus styles, target sizes, type scale and spacing that survive 200 percent zoom.
5. Component build: navigation, forms, modals, tabs, accordions and media players built on native elements and tested with a keyboard and a screen reader before use.
6. Page build and content: templates assembled from tested components, alt text and captions written, PDFs converted or tagged.
7. Testing: automated scans, manual keyboard and screen reader passes on key journeys, and a review with users of assistive technology where the budget allows.
8. Launch and statement: accessibility statement published with a contact, editor training delivered, monitoring scheduled.

What ADA compliant website design costs

Planning figures for US projects. The drivers are the number of templates and components, the volume of media and documents, and whether the work is a new build or a remediation of code someone else wrote. See website development cost for the general breakdown.

What to gather before an accessibility project starts

• Any complaint, demand letter or lawsuit received, and its deadlines.
• The legal context: private business, public entity, federal funding, EU customers.
• A list of templates and the pages where transactions happen.
• Access to the code repository or the CMS.
• The design system or brand guidelines, including the color palette.
• The inventory of PDFs, videos and other documents on the site.
• Third-party components in use: chat, booking, payment, maps, forms, video players.
• Analytics showing the most visited pages and the browsers and devices used.
• Who edits the site and what training they have had.
• Any existing accessibility statement or previous audit.

Mistakes that keep sites inaccessible after a compliance project

• Installing an overlay and treating the site as done.
• Relying on an automated score, which covers only a minority of WCAG criteria.
• Removing the focus outline because a designer found it ugly.
• Placeholder text used as the only form label.
• Carousels, parallax and auto-playing video with no pause control.
• Alt text written as keywords or left as the file name.
• Publishing new PDFs after the audit converted the old ones.
• Page-builder widgets added by editors after launch, with no accessibility review.
• An accessibility statement that claims full conformance the site does not have.
• No contact path for a user who hits a barrier, which turns a fixable issue into a complaint.

Measuring accessibility after launch

• Automated scan results per template, tracked monthly.
• Manual keyboard and screen reader re-tests after each release.
• Issues reported through the accessibility contact, and the time to fix each.
• Editor-introduced failures caught in review: missing alt text, skipped headings, new PDFs.
• Form completion and checkout rates for keyboard and screen reader sessions where analytics can distinguish them.
• Caption and transcript coverage across published video.
• Third-party component versions and their accessibility fixes.
• The accessibility statement’s last review date.

The accessibility statement and what it should say

An accessibility statement is a page that states the standard the site targets, the current conformance status honestly, the known gaps and the plan for them, how to request content in another format, and a contact that answers. Title II entities are expected to publish one; for private businesses it is the first thing an attorney reads and the first thing a screen reader user looks for. We write it from the audit, not from a template.

Editor training

Most accessibility failures after launch are introduced by content editors. A two-hour session on headings, link text, alt text, tables, PDFs and video captions, with a checklist in the CMS, prevents most of them.

Third-party components

Chat widgets, booking engines, payment forms and video players are tested as part of the site, because a visitor does not distinguish them, and vendors are asked for their conformance reports (a VPAT or ACR) before they are embedded.

How Progression Agency builds ADA compliant websites

We design, build and remediate accessible websites from New York City for organizations across the United States and worldwide: WCAG 2.2 AA builds on WordPress and custom stacks, audits with manual screen reader testing, remediation of sites others built, accessibility statements and editor training, followed by maintenance that keeps the conformance real. Related: website design and development, corporate website design, healthcare website design and nonprofit website design.

Frequently asked questions