What is website accessibility compliance?
Website accessibility compliance means people with disabilities can use your site, and you can show it meets the standard that laws and contracts refer to. That standard is almost always the Web Content Accessibility Guidelines (WCAG) from the W3C, at Level AA. Compliance isn't a badge you buy; it's the state of your code, design and content on the day someone checks.
WCAG groups its rules under four ideas: content has to be perceivable, interfaces have to be operable, content and behavior have to be understandable, and the code has to work with assistive technology such as screen readers. Each idea breaks down into testable success criteria at three levels, A, AA and AAA. Level AA is the target nearly every law, procurement team and settlement agreement uses, so it's the one we design and build against.
For a startup, web accessibility matters for three reasons at once. It's a legal exposure in the US and the EU, it's a sales requirement when enterprise buyers send security and accessibility questionnaires, and it's simply better UX: clear labels, readable contrast and keyboard support help everyone. This guide covers the law on both sides of the Atlantic in one place, then links to the detailed articles in this series.
Which accessibility laws apply to a startup website?
Which accessibility laws apply depends on where your customers are and who they are, not where your company is registered. A US company selling to EU consumers can fall under the European Accessibility Act, and a European company with US customers can be sued under the ADA. Most startups should assume at least one of these applies and plan for WCAG AA.
Rule | Who it covers | Technical benchmark | How it's enforced |
|---|---|---|---|
ADA Title III (US) | Businesses open to the public, which courts often extend to websites | No formal rule; WCAG 2.1 or 2.2 AA used in practice | Private lawsuits and demand letters |
ADA Title II (US) | State and local government websites | WCAG 2.1 AA under the Justice Department's 2024 rule | Federal enforcement and lawsuits |
Section 508 (US) | Federal agencies and what they buy | WCAG 2.0 AA via the Section 508 standards | Procurement requirements |
European Accessibility Act (EU) | Covered products and services sold to EU consumers | EN 301 549, which maps to WCAG AA | National market surveillance authorities |
Enterprise contracts | Any vendor selling to large buyers | Usually WCAG 2.1 or 2.2 AA plus a conformance report | Lost deals and contract terms |
The last row is the one founders forget. Even if no regulator ever looks at your site, a procurement team will ask for a conformance report or an accessibility statement before signing. The trust pages a B2B website needs increasingly include an accessibility page next to security and status.
What does ADA website compliance mean in the US?
ADA website compliance means your site doesn't block disabled people from goods and services you offer to the public. Title III of the Americans with Disabilities Act doesn't name a technical standard for private business websites, so courts and settlements fill the gap with WCAG AA. The Justice Department's published web guidance says businesses have flexibility in how they comply, but the site must be accessible.
- Federal website accessibility lawsuits in 2025 (Seyfarth)
- 3,117
- Rise in federal filings versus 2024 (Seyfarth)
- +27%
- Suits including state courts in 2025 (UsableNet)
- ~4,900
Those numbers are why ADA risk is real for startups and not just for big retailers. Seyfarth's count covers federal courts only; UsableNet's higher figure of about 4,900 includes state courts. Many claims start as a demand letter that never becomes a filed case, so the real volume of disputes is higher than either count.
The practical priority is any flow where a person spends money or signs up: checkout, booking, demo requests and account creation. If a screen reader user can't complete those, the claim is easy to build. Our guide to ADA website compliance walks through Title III, the 2024 Title II rule and how to prioritize fixes.
Does the European Accessibility Act apply to your website?
The European Accessibility Act applies to your website if you sell covered products or services to consumers in the EU, wherever your company is based. It has applied since 28 June 2025. EAA compliance is checked by national authorities in each member state, and the technical yardstick is the harmonised standard EN 301 549, whose web section aligns with WCAG AA.
The EAA doesn't cover every website. It lists specific services, including e-commerce services sold to consumers, consumer banking, e-books, electronic communications and some passenger transport services. A B2B SaaS product sold only to companies is often outside the list, while a consumer subscription sold online is usually inside it. Two details matter for small companies:
- Microenterprise exemption. Very small service providers are exempt from the service requirements. The directive defines the size limits, so check them against your headcount and turnover.
- 2030 transition. Services already provided before June 2025 have a transition period running to 2030, but new services and new contracts are covered now.
- Statement duty. Covered service providers must explain how their service meets the requirements, usually in an accessibility statement or terms.
Our article on the European Accessibility Act for non-EU SaaS companies goes through scope tests, the exemption and EN 301 549 in detail.
What does WCAG 2.2 AA require in practice?
WCAG 2.2 Level AA requires that people can perceive your content, operate every control with a keyboard, understand what's happening and use the site with assistive technology. W3C published 2.2 in 2023, adding criteria about focus visibility, target size, dragging, consistent help, redundant entry and accessible login. Most WCAG compliance failures we see fall into a handful of areas.
Area | What AA asks for | Who usually fixes it |
|---|---|---|
Color contrast | 4.5:1 for body text, 3:1 for large text and UI parts | Design |
Keyboard access | Every action works without a mouse, with a visible focus | Development |
Focus not obscured | Sticky headers and banners don't hide the focused item | Design and development |
Target size | Click targets at least 24 by 24 CSS pixels, or enough spacing | Design |
Forms | Visible labels, clear errors, no re-typing the same data | Copy and development |
Images and media | Text alternatives, captions for video | Copy |
Motion | Moving content can be paused; no flashing | Design and development |
Structure | Real headings, landmarks, link text that makes sense | Copy and development |
The full breakdown by role lives in our WCAG 2.2 checklist for designers and developers. For the visual side, see accessible design basics: contrast, type and focus states. Forms deserve their own pass, covered in accessible forms, and so does animation, covered in accessible animation with prefers-reduced-motion.
Does an accessible website have to look plain?
No. Most AA rules constrain contrast, sizes and behavior, not style. You can keep a dark theme, custom type, motion and a strong brand color; you just pair that color with text that passes contrast, give buttons a real focus ring, and offer a reduced-motion version of heavy animation.
Where teams struggle is a brand palette chosen without contrast in mind. Fixing that early, at the brand stage, is far cheaper than patching it page by page after launch.
Do accessibility overlays make a website compliant?
No. Accessibility overlays, the toolbar widgets added with one script tag, don't make a site compliant, because they can't fix the underlying code a screen reader or keyboard relies on. In 2025 the US Federal Trade Commission finalized a $1 million order against overlay vendor accessiBe over claims that its product could make any site compliant.
Overlays can also get in the way of the assistive tools disabled users already have, and installing one isn't a recognized defense in any law we know of. The fix for an unlabeled button is a label in the HTML; no widget can guess intent reliably. We explain the FTC case and what to do instead in do accessibility overlays work?
Pros
- Quick to install and inexpensive compared with remediation
- Some settings, like larger text, are harmless for some visitors
Cons
- Doesn't fix missing labels, broken focus order or bad markup
- Can conflict with screen readers and browser settings
- Not accepted as compliance by courts or regulators
- Sends a signal to disabled users that the real site wasn't fixed
How do you make a website accessibility compliant?
You make a website compliant by finding the problems, fixing them where they live (design files, components and content), documenting the result and keeping it that way. Treat it like security: a project to reach a baseline, then a habit in every release. Here's the order we follow.
Run automated scans
Use tools like axe or Lighthouse on your key templates to catch missing alt text, contrast failures and empty links. Scans find only part of the issues, so they're a starting point. Our guide on how to test website accessibility covers the tools and a manual routine.
Test by hand on key flows
Tab through the homepage, pricing, signup and checkout with no mouse. Then try them with a screen reader. Manual checks find focus traps, unlabeled buttons and confusing order that scanners miss.
Get an audit if the stakes are high
If you sell to enterprise, the public sector or EU consumers, a structured manual audit against WCAG 2.2 AA gives you a prioritized issue list and evidence. See what an accessibility audit costs.
Fix in the source, by priority
Fix shared components first: buttons, navigation, forms and modals, because one fix repairs every page. Then work through templates and content. Our step-by-step accessibility remediation plan orders work by risk and effort.
Publish an accessibility statement
Say which standard you target, what's known to be broken and how people can get help. Our accessibility statement template includes an honest known-issues section.
Retest after every major release
Add accessibility checks to QA so new pages and features don't undo the work. A short keyboard pass before each launch catches most regressions.
How much does accessibility compliance cost?
Accessibility compliance costs depend mostly on how much has to be fixed, not on the audit. A scan is cheap or free, a manual audit is priced by how many templates and flows are tested, and remediation is design and development time that scales with the size of the problem. Building accessibly from the start costs the least, because nothing has to be rebuilt.
That's why the cheapest route for a startup about to redesign is to fold accessibility into the new build. When we design a site, contrast, focus states, target sizes and semantic markup are part of the design system and components, not a later project. Retrofitting an existing site usually means touching the same components twice.
- Designify website, up to 6 pages, fixed price
- $8,000
- Monthly retainer for ongoing design and development
- $6,000
- Trial week of design and development
- $1,000
If you're not redesigning, an existing site can be fixed in focused passes through a retainer, and our audit cost guide explains how to scope that work before you commit.
How do you keep a website accessible after launch?
You keep a site accessible by making accessibility part of how pages get made, not a yearly cleanup. Most regressions come from new content and new features: a marketing page built from scratch, an embedded form, a carousel added for a campaign or a fancy interaction nobody tested with a keyboard.
- Accessible components in the CMS. If editors build pages from tested blocks, they can't easily break contrast or headings.
- Alt text and headings as required fields. Make the CMS ask for them, so content stays accessible without a reviewer.
- Motion with an off switch. Interactions like those in our guide to micro-interactions that feel premium should respect reduced-motion settings.
- A keyboard pass in QA. A short pass on each new page catches focus and order problems before they ship.
- Vet third-party embeds. Chat widgets, schedulers and cookie banners are frequent sources of new barriers.
There's a useful overlap with search. Clean headings, real HTML and descriptive links help screen readers and AI crawlers in the same way, which is why an AI-search-ready website and an accessible one share most of their structure. Writing pages in an answer-first structure also helps people using screen readers find the point quickly.
Hypothetical example: what changes when a startup takes accessibility seriously
For example, suppose a seed-stage fintech with a 10-page marketing site and a signup flow gets an enterprise questionnaire asking for its WCAG conformance. A scan flags contrast on the brand's light green buttons and missing labels on the signup form. Manual testing finds the cookie banner traps keyboard focus.
The team darkens the button color slightly in the design system, adds visible labels and error text to the form component, swaps the cookie banner for one that handles focus, and publishes a statement listing one known issue in an embedded scheduler. None of this needed a redesign; it needed someone who owns design and code to fix the shared parts once.
Which accessibility articles should you read next?
This hub is the overview. Each article below goes deep on one part of web accessibility, grouped by what you're trying to do.
If you need to… | Read |
|---|---|
Understand US law | |
Understand EU law | |
Know the technical rules | |
Design accessibly | |
Fix forms and login | |
Make motion safe | |
Test your own site | |
Budget for an audit | |
Fix an existing site | |
Publish a statement |
Specific industries carry extra expectations. Patient-facing sites should read healthcare website accessibility, and education products should read edtech website compliance. Product teams building dashboards can continue with accessible web app UI.
