Website Accessibility (WCAG) Guide for Business Owners

Website accessibility means building your site so people with disabilities can find information, use features and complete tasks as easily as everyone else. For business owners, it is also a legal, commercial and reputational issue. This guide explains the WCAG standard in plain English, walks through its four POUR principles with quick wins for each, and covers testing methods and the main laws you should know.

Quick answer: Website accessibility is the practice of making your site usable by people with visual, hearing, motor and cognitive disabilities. Most businesses aim for WCAG 2.2 Level AA, organized around four principles: Perceivable, Operable, Understandable and Robust. Start with contrast, alt text, keyboard access, form labels and clean HTML, then test manually.

What is website accessibility?

Website accessibility is the practice of designing and coding a website so that people with disabilities can perceive, navigate and interact with it, including people who use screen readers, keyboards, voice control, magnification or captions. It removes barriers that block someone from reading content, filling in a form or completing a purchase.

Accessibility helps a wider group than many owners expect:

• Permanent disabilities, such as blindness, deafness, limited dexterity or cognitive impairments.
• Temporary impairments, such as a broken wrist or recovery from eye surgery.
• Situational limitations, such as bright sunlight on a phone screen, a noisy train or holding a baby in one arm.
• Older users, whose vision, hearing and motor control may change over time.

For a business, the payoff is practical. An accessible checkout, booking form or contact page loses fewer customers. Clear structure and text alternatives also overlap with good SEO, and the same clarity that helps screen reader users helps everyone avoid the common UX design mistakes that quietly cost conversions.

What is WCAG, and which version should you follow?

WCAG is a set of testable success criteria for accessible web content published by the World Wide Web Consortium (W3C) through its Web Accessibility Initiative. It is the standard referenced by most accessibility laws, procurement rules and audits worldwide.

The W3C designed WCAG 2.2 to be backward compatible, so a site that meets 2.2 Level AA generally also meets 2.1 and 2.0 Level AA. If you are building or redesigning now, target WCAG 2.2 AA.

What do WCAG levels A, AA and AAA mean?

WCAG levels are three tiers of conformance, from the essential minimum (A) to the most demanding (AAA). Each level includes all criteria from the levels below it. According to the W3C specification, WCAG 2.2 contains 86 success criteria: 31 at Level A, 24 at Level AA and 31 at Level AAA.

The W3C itself does not recommend requiring AAA for entire sites, because some content types cannot meet every AAA criterion.

What changed in WCAG 2.2?

WCAG 2.2 added nine success criteria and removed one obsolete criterion, 4.1.1 Parsing. The additions focus on keyboard users, people with motor impairments and people with cognitive disabilities:

• Focus Not Obscured (Minimum), AA: a focused element must not be completely hidden by sticky headers, chat widgets or cookie banners.
• Focus Not Obscured (Enhanced), AAA: no part of the focused element is hidden.
• Focus Appearance, AAA: focus indicators meet size and contrast requirements.
• Dragging Movements, AA: anything done by dragging can also be done with a simple click or tap.
• Target Size (Minimum), AA: clickable targets are at least 24 by 24 CSS pixels, with some exceptions.
• Consistent Help, A: help options such as contact links appear in the same relative place across pages.
• Redundant Entry, A: users are not forced to re-enter information they already provided in the same process.
• Accessible Authentication (Minimum), AA: logging in does not require a cognitive test such as memorizing or transcribing, unless an alternative is offered.
• Accessible Authentication (Enhanced), AAA: a stricter version with fewer exceptions.

What is the POUR framework?

The POUR framework is the four-principle structure behind WCAG: content must be Perceivable, Operable, Understandable and Robust. Every success criterion belongs to one of these principles, which makes POUR a useful mental checklist for anyone reviewing a website, even without memorizing criterion numbers.

The next four sections take each principle in turn, with quick wins your team can act on this month.

Perceivable: can everyone take in your content?

Perceivable means information and interface elements must be presented in ways users can sense, whether by sight, hearing or touch through a braille display. If a blind visitor’s screen reader finds an unlabeled image, or a deaf visitor meets an uncaptioned video, that content does not exist for them.

Quick wins:

• Write useful alt text. Describe the purpose of each meaningful image (“Red trail running shoe, side view”), and mark purely decorative images so screen readers skip them.
• Check color contrast. WCAG AA requires at least 4.5:1 for normal text and 3:1 for large text, plus 3:1 for icons, input borders and other essential interface graphics.
• Don’t rely on color alone. Pair red error states with icons or text, and underline links in body copy.
• Caption your videos. Prerecorded video with audio needs captions; provide transcripts for podcasts and audio clips.
• Avoid text baked into images. Promotional banners with text inside the image can’t be resized, translated or read aloud reliably.
• Support zoom and reflow. Content should remain usable when text is enlarged to 200% and, at a width of 320 CSS pixels, should reflow without horizontal scrolling.

How to write alt text in one minute

Ask what the image does on the page. If it shows a product, name the key visual details a shopper needs. If it’s a chart, summarize the takeaway. If it’s a linked logo, describe the destination (“Home”). If it adds nothing, leave the alt attribute empty so it is ignored.

Operable: can everyone use your interface?

Operable means every function on your site can be used by people who navigate with a keyboard, switch device, voice control or screen reader, not only with a mouse. Many operability failures come from custom menus, sliders and pop-ups built without keyboard support.

Quick wins:

• Do a keyboard-only test. Press Tab through each key page. Every link, button and form field should be reachable, in a logical order, and usable with Enter, Space or arrow keys.
• Keep focus visible. Never remove the browser’s focus outline without replacing it with a clear custom style.
• Add a skip link. A “Skip to main content” link lets keyboard users bypass long navigation menus.
• Eliminate keyboard traps. Users must be able to move into and out of every widget, including modals and embedded maps.
• Size targets generously. Make buttons and links at least 24 by 24 CSS pixels, or space smaller ones apart, as WCAG 2.2 requires.
• Watch sticky elements. Make sure fixed headers, chat bubbles and cookie banners don’t completely cover the focused element.
• Let users pause motion. Auto-playing carousels and animations need a pause or stop control.
• Offer alternatives to dragging. Sliders and drag-to-reorder lists should also work with simple clicks.

Operability problems hit revenue hardest in forms and checkouts. If you are working to reduce cart abandonment, test the whole checkout with a keyboard first.

Understandable: is your content and behavior predictable?

Understandable means users can comprehend both the content and how the interface behaves. Confusing forms, unexpected changes and unclear error messages affect people with cognitive disabilities most, but they frustrate every visitor.

Quick wins:

• Set the page language in your HTML so screen readers pronounce text correctly.
• Label every form field with visible text, not just placeholder text that disappears when typing starts.
• Write helpful error messages. Identify the field and explain how to fix the problem (“Enter a date in MM/DD/YYYY format”), not just “Invalid input.”
• Keep navigation consistent. Menus, search and help links should appear in the same place on every page.
• Don’t make people repeat themselves. Prefill or offer to reuse information already entered, such as a shipping address used for billing.
• Make logins accessible. Allow pasting and password managers, and avoid puzzle-style challenges without an alternative.
• Write plainly. Short sentences, familiar words and descriptive headings help everyone scan.

Clear labels and predictable behavior are also proven usability principles, so these fixes often double as conversion rate optimization tips.

Robust: does your site work with assistive technology?

Robust means your code is clean and standard enough that browsers and assistive technologies, now and in the future, can interpret it correctly. In practice, it means using proper HTML elements and giving every interactive component an accessible name, role and state.

Quick wins:

• Use semantic HTML first. Real buttons, links, headings, lists and form controls come with built-in accessibility that custom div-based widgets lack.
• Use ARIA sparingly and correctly. ARIA attributes can fix gaps, but incorrect ARIA often makes things worse than none at all.
• Name your controls. Icon-only buttons (search, close, menu) need an accessible name a screen reader can announce.
• Announce status messages. Messages such as “Added to cart” or “Form submitted” should be announced without moving focus.
• Audit third-party tools. Chat widgets, booking engines, payment forms and cookie banners are frequent sources of barriers you didn’t build but are still responsible for.
• Check your platform’s output. Themes, page builders and components vary widely in quality, a factor worth weighing when choosing a website platform.

How do you test website accessibility?

You test website accessibility by combining automated scans with manual checks and, ideally, feedback from people with disabilities. Automated tools are fast and free, but they cannot judge whether alt text makes sense or whether a page is usable by keyboard, so manual testing is essential.

A 30-minute self-check for owners

1. Run a free automated scanner on your home page, a key service or product page and your contact or checkout page.
2. Unplug your mouse and complete your most important task using only the keyboard.
3. Zoom your browser to 200% and check that nothing overlaps or disappears.
4. Turn on your phone’s built-in screen reader and listen to your home page for two minutes.
5. Write down every barrier, then rank by how badly it blocks a task.

Do accessibility overlays make a website compliant?

No tool can make a website fully compliant on its own. Overlays and widgets add a toolbar on top of your site, but they don’t repair the underlying code that assistive technologies rely on. In 2025, the US Federal Trade Commission finalized an order requiring overlay vendor accessiBe to pay $1 million over claims that its tool could make any website WCAG compliant. Fix the code instead.

What are the legal requirements for website accessibility?

Legal requirements depend on where you operate, who your customers are and what sector you’re in. The summary below is general information as of October 2026, not legal advice; ask a qualified lawyer about your specific obligations.

United States: the Americans with Disabilities Act (ADA)

The ADA prohibits disability discrimination by businesses open to the public (Title III) and by state and local governments (Title II). For private businesses, the Department of Justice’s 2022 web guidance states that the ADA covers goods and services offered online, but no regulation sets a specific technical standard; the guidance points to WCAG as helpful. Lawsuits and settlements frequently use WCAG Level AA as the benchmark.

For state and local governments, the DOJ’s 2024 Title II rule requires WCAG 2.1 Level AA. An interim final rule issued in April 2026 extended the compliance dates to April 2027 for entities serving 50,000 or more people and April 2028 for smaller entities and special districts. Federal agencies follow Section 508 of the Rehabilitation Act.

European Union: the European Accessibility Act (EAA)

The European Accessibility Act, Directive (EU) 2019/882, has applied since June 28, 2025. It covers specific products and services, including e-commerce, consumer banking, e-books, electronic communications and parts of passenger transport services. It can apply to businesses outside the EU that sell these services to EU consumers.

Key points for business owners:

• Microenterprises providing services (fewer than 10 employees and annual turnover or balance sheet total of no more than €2 million) are exempt from the service requirements.
• The harmonised European standard, EN 301 549, references WCAG 2.1 Level AA for web content.
• Each EU member state enforces the act through national law, so penalties and procedures differ by country.
• Transitional periods apply in some situations, such as certain services already in use before the act applied.

Other countries

The UK’s Equality Act 2010 requires service providers to make reasonable adjustments for disabled people, and public sector bodies have specific accessibility regulations. Canada has federal and provincial rules, including Ontario’s AODA, which requires many organizations to meet WCAG 2.0 AA. Australia, Israel, Japan and others have their own frameworks.

Should you publish an accessibility statement?

Yes, in most cases. An accessibility statement explains your target standard, known limitations, how users can report problems and how quickly you respond. Some laws and public sector rules require one, and it gives frustrated users a route to you instead of a complaint elsewhere. Add it to your footer alongside the other must-have pages on a small business website.

How should you prioritize accessibility fixes?

Prioritize by user impact on your most important journeys, not by the order a scanner lists issues. A missing label on your checkout field matters more than a decorative image on a five-year-old blog post.

1. Fix barriers that block key tasks: contact forms, booking, checkout, login and navigation.
2. Fix site-wide template issues (header, footer, menus), because one fix repairs every page.
3. Fix high-traffic page content: home, top landing pages and top products or services.
4. Build accessibility into your design system, content guidelines and QA so new pages stay compliant.

If a rebuild is on the horizon, add WCAG 2.2 AA as a requirement in your website redesign checklist. Building it in costs far less than retrofitting later. Performance work helps too: fast, stable pages are easier for everyone to use, so pair this guide with our Core Web Vitals guide.

Keep reading

Web Design & DevelopmentHow Much Does a Website Cost in 2026? Full Price BreakdownRead articleWeb Design & DevelopmentWebsite Redesign SEO Checklist: Relaunch Without Losing RankingsRead articleWeb Design & DevelopmentWebflow vs WordPress vs Custom Code: Which Should You Choose?Read article