Website Accessibility Standards Every Business Should Follow

If you run a business website, the question is no longer whether accessibility matters.

The question is which standard to follow, how much of it applies to you, and what to fix first. The short answer is that WCAG, the Web Content Accessibility Guidelines, is the standard that laws, courts, and procurement teams point to. For most businesses, aiming for WCAG 2.2 Level AA is the practical target. The rest of this guide explains what that means in plain terms, which laws make it more than a nice idea, and how to get there without wasting money on shortcuts.

Why Accessibility Is Now a Business Issue, Not Just a Design Preference

Website accessibility means building a site so that people with disabilities can perceive it, operate it, and understand it. That includes people who use screen readers, people who navigate with a keyboard or voice control instead of a mouse, people with low vision or color blindness, people who are deaf or hard of hearing, and people with cognitive or learning differences. It also helps people with temporary or situational limits, such as a broken wrist or a phone screen in bright sunlight.

The gap between what is needed and what exists is large. WebAIM's annual analysis of the top one million home pages found that 95.9% had detectable WCAG 2 failures in 2026, up from 94.8% in 2025, with an average of 56.1 errors per page. WebAIM also calculated that users with disabilities should expect to meet a barrier on roughly one in every 26 page elements. These counts come from automated testing, so they understate the real situation. They still show that the typical commercial website has barriers that would stop or frustrate some customers.

For a business, that translates into three practical risks. You lose customers who cannot complete a purchase or a form. You face growing legal exposure. And you may fail procurement checks, since larger buyers increasingly ask for evidence of accessibility before signing. The opportunity runs the other way: fixing accessibility problems tends to improve usability, search visibility, and mobile performance for everyone.

The Standard Behind Everything: WCAG

Most accessibility laws around the world do not write their own technical rules. They refer to WCAG, published by the World Wide Web Consortium (W3C). Knowing how WCAG is organized makes every other decision easier.

The four principles

WCAG groups its requirements under four principles, often abbreviated POUR. Content must be perceivable, meaning users can detect it through at least one of their senses. It must be operable, meaning users can navigate and interact with it using different input methods. It must be understandable, meaning the content and the way the interface behaves are clear. And it must be robust, meaning it works reliably with browsers and assistive technologies, including ones that do not exist yet.

[IMAGE PLACEHOLDER 01]

Image Type:

Image Brief:

Purpose:

Suggested Alt Text: Diagram of the four WCAG principles (perceivable, operable, understandable, robust) with plain-language examples

Suggested File Name: wcag-four-principles-pour-framework.png

Conformance levels: A, AA, and AAA

Each WCAG requirement, called a success criterion, is assigned to Level A, AA, or AAA. Level A covers the most basic barriers. Level AA adds requirements that address the most common obstacles for a wide range of users. Level AAA is the most demanding and is not expected for entire sites, since some AAA criteria cannot be met for all kinds of content.

Level AA is the benchmark that laws and contracts almost always require. That is why you will see "WCAG 2.1 AA" or "WCAG 2.2 AA" written into regulations, settlements, and vendor questionnaires.

Which version: 2.1 or 2.2?

This is a frequent point of confusion. WCAG 2.1 is the version most current laws name explicitly. WCAG 2.2 is newer and builds on it. One summary notes that WCAG 2.2 became a W3C Recommendation on 5 October 2023, corresponds to ISO/IEC 40500:2025, and that WCAG 3.0 remains a Working Draft. The same source counts 50 Level A and AA success criteria under WCAG 2.1 and 55 under WCAG 2.2.

Because WCAG 2.2 is backward compatible, a site that meets 2.2 AA also meets 2.1 AA. For a business building or rebuilding a site now, targeting 2.2 AA is the sensible choice. You satisfy today's legal references and you are ready for the likely update of those references. Advice from one accessibility consultancy puts it the same way: remediating to WCAG 2.2 AA now is the pragmatic move, since it is backwards compatible with 2.1.

The criteria added in 2.2 are practical ones. Focus indicators must not be hidden behind other content, such as a sticky header. Interactive targets need a minimum size so they are easy to tap. Anything that relies on dragging needs a simple alternative. Help links should appear in a consistent place. Forms should not make people retype information they already entered. And login steps should not depend on a memory test or puzzle without an alternative. If your site has a cookie banner, a sticky navigation bar, or a multi-step checkout, these changes affect you directly.

The Laws and Regulations That Point to WCAG

You do not need to be a lawyer to understand where the pressure comes from, but you should know the main frameworks. The following is general information and not legal advice, so confirm specifics for your situation with qualified counsel.

United States: ADA Title III and Title II

In the United States, private businesses that serve the public are covered by Title III of the Americans with Disabilities Act. The statute does not spell out technical website rules, so courts and settlements have filled the gap, and WCAG is the benchmark that keeps appearing. Litigation volume is significant. According to Seyfarth Shaw's tracking, plaintiffs filed 3,117 federal website accessibility lawsuits in 2025, a 27% increase over 2024. Other compilations indicate that e-commerce accounts for about 70% of cases, which makes online retailers the most frequent targets. Treat the exact percentages with some caution, since they come from varying trackers, but the direction is consistent.

Title II covers state and local governments, and here the rule is explicit. The Department of Justice's 2024 rule names WCAG 2.1 AA as the standard. In April 2026, the DOJ pushed back the deadlines, and local governments serving populations of 50,000 or more now have until April 26, 2027. Private businesses are not covered by that rule: private businesses and nonprofits fall under Title III of the ADA rather than Title II. Even so, the Title II rule matters to business owners. If you sell to, or build for, public sector clients, you will be asked to meet it.

European Union: the European Accessibility Act

The European Accessibility Act (EAA) has changed the picture for any business selling to consumers in Europe. Its requirements became applicable on 28 June 2025. It is not limited to companies based in the EU: it reaches any business selling covered services such as e-commerce to EU consumers, including US companies.

There is a relief valve for the smallest firms. Microenterprises, defined as employing fewer than 10 persons with annual turnover or balance sheet total not exceeding EUR 2 million, are generally exempt from the accessibility requirements for services. That exemption applies to services only, not to products, so a very small business that sells physical goods may not be fully excused. If you rely on the exemption, keep records showing why it applies.

Technically, the EAA points to the European standard EN 301 549, which incorporates WCAG 2.1 Level AA for web content. A draft update is expected to move the web reference to WCAG 2.2, and, as one guide notes, no harmonised standard has yet been published specifically for the EAA, though meeting WCAG AA gives you a sensible route to the presumption of conformity. Enforcement is also becoming visible. One compliance guide reports that in France, four national retailers were summoned in November 2025 over inaccessible websites and apps.

Other places to check

Canada, the United Kingdom, Australia, and many other countries have their own accessibility laws, and most of them lean on WCAG as well. If you operate internationally, the practical approach is to meet WCAG 2.2 AA and then check any local additions, such as requirements to publish an accessibility statement.

What Fails Most Often (and What That Tells You)

If you want a realistic picture of where to start, the WebAIM data is the best guide. It shows that the same few problems account for almost all detected errors. As one commentator put it, six types of errors, low contrast text, missing alt text, missing labels, empty links, empty buttons, and missing document language, still account for 96% of all detected failures.

Here is what each of the leading problems means in practice and how to fix it.

Low color contrast

Low contrast text appeared on 83.9% of pages, up from 79.1% in 2025, with an average of 34 instances per home page. WCAG AA asks for a contrast ratio of at least 4.5 to 1 for normal text and 3 to 1 for large text and for the visual parts of interface controls. Light gray text on white, placeholder text that barely shows, and white text over a busy photo are the usual culprits. The fix is usually a design token change: darken the gray, lighten the background, or place text on a solid overlay. Contrast checkers built into design tools and browser developer tools make this a five-minute job per color pair.

Missing or poor alternative text

Images that convey information need a text alternative so screen reader users get the same information. About 53.1% of home pages had missing alternative text. Good alt text describes the purpose of the image in context, not just its appearance. A product photo might need the product name and key visible details. A decorative flourish should have an empty alt attribute so screen readers skip it. Avoid file names and generic words like "image," and do not stuff keywords in. Images used as links or buttons need text that describes the destination or action.

Unlabeled form fields

Forms are where sales happen, so this failure is costly. Missing form input labels appeared on 51.0% of pages. Every field needs a visible, programmatically connected label. Placeholder text is not a substitute, because it disappears as soon as someone starts typing and is often low in contrast. Error messages should identify the field, explain the problem, and suggest how to fix it, rather than just turning a border red.

Empty links and buttons

A button that shows only an icon, such as a magnifying glass or a shopping cart, needs an accessible name so a screen reader can announce what it does. The same applies to links that contain only an image. These are quick fixes in the code, but they are easy to miss because they look fine visually.

Missing page language

The page's language must be declared in the HTML so that screen readers pronounce text correctly. It is a one-line fix and one of the cheapest wins available.

The pattern in this list is useful. Most of the top failures are visible to a developer or editor once they know to look for them, and none require advanced engineering. Still, home pages are becoming more complex. One analysis noted that the average home page grew to 1,437 elements in 2026, a 22.5% year-over-year increase. More elements and more scripts mean more places for errors to creep in unless accessibility is part of the build process.

Standards Beyond the Top Six: What Else a Business Should Cover

Fixing the common failures will remove many barriers, but a site that is genuinely usable needs attention in several other areas.

Keyboard access. Everything that can be done with a mouse must be possible with a keyboard alone. That includes menus, modals, carousels, date pickers, and custom dropdowns. Users should be able to see where focus is at all times, and focus should move logically. Keyboard traps, where you can tab into a widget but cannot leave, are serious failures. A quick test costs nothing: unplug your mouse and try to complete your own checkout.

Headings and structure. Headings should reflect the real outline of the page, because screen reader users often navigate by heading. Use one main heading, then nested subheadings in order. Choose heading levels for structure and style them with CSS, not the other way around. Landmarks such as header, navigation, main, and footer help users jump to the right region. A "skip to main content" link lets keyboard users bypass repeated navigation.

Media. Videos need captions, and audio-only content needs a transcript. Where visuals carry meaning that the audio does not describe, audio description may be needed. Auto-playing media should be avoidable or pausable.

Responsive design and zoom. Content should remain usable when text is enlarged and when the page is viewed on a small screen. Do not block pinch zoom. Avoid layouts that force two-directional scrolling for ordinary content.

Motion and timing. Animation that moves, blinks, or scrolls automatically should be stoppable, and flashing content must stay within safe limits. If sessions time out, users need warning and a way to extend the time.

Custom components and ARIA. ARIA is a set of attributes that help communicate the role and state of custom controls to assistive technology. It is useful when native HTML elements cannot do the job, but it is easy to misuse. The WebAIM report found that pages with ARIA present averaged 59.1 errors, compared with 42 on pages without it. The standard guidance is to use native HTML elements first, such as real buttons and links, and add ARIA only when necessary and with testing.

Documents. PDFs, spreadsheets, and slide decks published on your site need to be accessible too. Tag PDFs properly, supply real text instead of scans of text, and consider offering an HTML version of important documents.

Third-party tools. Chat widgets, booking systems, payment forms, and embedded maps become part of your site in the eyes of users and regulators. Ask vendors for accessibility conformance information, test their components in your own pages, and write accessibility requirements into contracts.

Why Overlays Are Not a Shortcut

Many business owners first encounter accessibility through an advertisement: add one line of code and your site becomes compliant. These products, usually called accessibility overlays, add a toolbar that lets visitors change font size or contrast and sometimes attempt to fix code issues automatically. The marketing promises are tempting, and the evidence does not support them as a compliance strategy.

In April 2025, the FTC approved a final order requiring one overlay vendor, accessiBe, to pay $1 million under a 20-year consent order over its advertising claims. The order was narrow. It addressed that company's marketing and did not rule on overlay technology generally or interpret the ADA. But it did establish that unsupported claims of automatic compliance can be treated as deceptive. Separately, an open letter known as the Overlay Fact Sheet, signed by more than 800 accessibility practitioners, recommends against overlays as a compliance strategy.

The litigation record points the same way. One analysis of court records found that 456 lawsuits, or 22.6% of filings in the first half of 2025, targeted sites that had accessibility widgets installed. The analyst who compiled these figures is a vendor that sells accessibility remediation, and the same source cautions that the filings show widgets did not prevent suits, not that widgets caused them. The sensible reading is modest: an overlay does not protect you, and the underlying code problems still need to be fixed.

That does not mean every tool is useless. Automated scanners are valuable for catching repeatable errors, and user-preference toolbars can help some visitors. They just cannot replace fixing the source code, the design, and the content.

How to Audit Your Website

An audit does not have to start with a big budget. A layered approach works well.

Begin with automated testing. Free and paid scanners can check every page template for missing labels, contrast failures, empty links, and structural problems quickly. Be aware of their limits: one accessibility vendor estimates that automated tools detect roughly 60 to 70% of WCAG issues, with the remainder requiring human testing. Treat that as an approximate guide, since the proportion depends on the site and the tool, but the principle is well accepted. Scanners cannot judge whether alt text is meaningful, whether focus order makes sense, or whether an error message is helpful.

Next, test manually with a keyboard. Move through your key journeys, such as home page to product to checkout, or contact form submission, using only Tab, Shift+Tab, Enter, Space, and the arrow keys. Note anything you cannot reach, cannot see, or cannot exit.

Then test with a screen reader. NVDA is free on Windows, VoiceOver is built into Apple devices, and TalkBack is available on Android. You do not need to become an expert. Listening to your own checkout read aloud for ten minutes will reveal problems no scanner shows.

Finally, if the stakes are high, bring in specialists. A professional audit by people who test against WCAG and with disabled users gives you a prioritized list and, where needed, a formal conformance report. Involving people with disabilities in usability testing adds insight that checklists alone cannot provide.

Prioritizing the Work

Audits tend to produce long lists, and long lists get ignored. Prioritize by combining three factors: how severe the barrier is, how many people it affects, and how important the page or task is to your business.

Start with the journeys that earn or lose money and carry legal risk: navigation, search, product pages, cart, checkout, account creation, login, contact forms, and booking flows. Within those, fix blockers first. A checkout that cannot be completed by keyboard is a blocker. A decorative image with imperfect alt text is not. Next, fix issues that appear in shared components, since a single repair in a header, footer, or form component fixes the problem on every page that uses it. Finally, work down through lower-severity items on a schedule.

Document what you do. Keep a log of audits, fixes, and decisions. If you receive a complaint or demand letter, a record showing a good-faith program, a published accessibility statement, and a way for users to report problems puts you in a far stronger position than silence.

Building Accessibility Into How You Work

Fixing a finished site is slower and costlier than building it correctly. For businesses commissioning websites or software, the most effective step is to make accessibility part of the brief, the contract, and the acceptance criteria.

In design, set accessible color palettes, type sizes, and component states from the start, including focus and error states. In development, use semantic HTML and a component library that has been tested with assistive technology. In content, train editors to write alt text, use headings properly, and caption videos. In quality assurance, add accessibility checks to your test plan and automated pipeline so regressions are caught when code changes. After launch, schedule recurring scans and periodic manual reviews, because new pages, plugins, and theme updates can reintroduce failures. One industry perspective on the WebAIM results argues that ownership without expertise and capability often fails to achieve the necessary level of compliance, with agencies that care about accessibility still shipping sites with WCAG violations. The lesson is that intent is not enough. You need skills, process, and verification.

Platform choice matters too.

WebAIM's data found differences between content management systems: WordPress home pages averaged 52.8 errors, below the overall average, while Shopify pages averaged 75.1 and Magento pages 75.8. A platform does not determine accessibility by itself, since themes, plugins, and content decide much of the outcome, but it affects how much effort you will need. When choosing a theme or app, ask for accessibility documentation and test a demo before buying.

If you work with an external web or software development partner, ask direct questions. Which WCAG version and level do they build to? How do they test? Can they show accessibility conformance documentation from past projects? Who fixes problems found after launch, and how quickly? Vague answers are a warning sign. (This is a natural place to link to your own pages on custom website development, web design, QA testing, and website maintenance services.)

Publish an Accessibility Statement and a Way to Report Problems

An accessibility statement is a short page that tells visitors what standard you aim for, what you have done, any known limitations, and how to contact you if they hit a barrier. In some jurisdictions it is required for certain organizations, and in others it is simply good practice. One guide on the EAA suggests the statement should cover what it applies to, the standard targeted, how requirements are met, known limitations, a feedback channel, and a last reviewed date. Be honest. Overstating compliance is riskier than admitting that work is in progress.

Make sure the contact method works and that someone reads the messages. A customer who reports a problem and gets a helpful reply is far more likely to stay than one who finds a dead end.

Common Mistakes to Avoid

Several errors repeat across businesses of all sizes.

Treating accessibility as a one-time project is the most common. Sites change constantly, and each new campaign page, plugin, or redesign can break things that worked.

Relying only on automated scores is another. A scanner reporting zero errors does not mean the site is usable. It means it passed the checks a machine can run.

Making fixes only on the home page misses where most problems cost you: forms, checkout, account areas, and PDFs.

Assuming a template or platform handles it leads to surprises. Customization and third-party add-ons often introduce new problems.

Overusing ARIA or custom widgets instead of native elements adds risk. The simplest markup is usually the most accessible.

Ignoring mobile apps and documents leaves gaps. If you offer an app, a PDF price list, or an emailed invoice, they count as part of the customer experience.

Finally, waiting for a legal threat before acting is both expensive and stressful. Remediation done under deadline pressure costs more, and settlements typically require fixes anyway.

Where to Start This Month

If you are not sure where to begin, a simple plan will carry you through the first month.

Pick WCAG 2.2 AA as your target and tell your team and vendors. Run an automated scan of your main page templates and fix the cheap, widespread errors, especially contrast, labels, empty links, and language. Test your top three customer journeys by keyboard and with a screen reader. Add accessibility requirements to your design system, content guidelines, and development checklist. Publish an accessibility statement with a working contact method. Then schedule your next review, because this is a program you maintain, not a project you finish.

Accessibility standards are not a mysterious legal puzzle. They describe, in detail, how to make a website work for more people. Businesses that treat them as part of building and running a site, rather than a last-minute fix, spend less, reach more customers, and carry less risk.