WCAG 2.2 Checklist for Business Websites: What to Fix, What to Test, and How to Get There

Most Business Websites Fail Accessibility Basics, Here's What to Do About It

Ninety-six percent of the top one million home pages have detectable WCAG failures, according to WebAIM's annual accessibility analysis. That number sounds alarming until you realize what it actually means: WCAG failures are the norm, not the exception. They don't mean a site was built carelessly, they usually mean accessibility wasn't on the checklist at all. This WCAG 2.2 checklist is built to fix that, written in plain English for business owners and marketing managers who don't have a developer on speed dial.

The goal here isn't to scare you into compliance. It's to give you a working web accessibility checklist organized around the issues that actually show up most often, so you know what to look for, what to fix first, and what good looks like. Quick note before we get into it: this post is educational and not legal advice. If your business has specific compliance concerns, a qualified attorney is the right call. For the broader compliance picture, start with how to make your website ADA compliant.

WCAG, the Web Content Accessibility Guidelines, is organized around four principles known as POUR: Perceivable, Operable, Understandable, and Robust. Everything in this checklist maps back to one of those four. Think of POUR as the logic behind why each item matters, not just a box to tick.

1. Color Contrast, The Most Frequently Failed WCAG Criterion

Color contrast is the single most common WCAG failure in WebAIM's annual findings, year after year, it tops the list. WCAG 2.2 Level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). A contrast ratio is a mathematical measure of how much a foreground color stands out from its background. You don't have to understand the math, you just need to know that humans perceive low-contrast text as hard to read, even when they'd never describe it as an accessibility problem.

Two failures we see constantly: light gray text on a white background, and white text sitting on a medium-toned button. Both look clean in a design tool. Both fail under real-world viewing conditions, especially on phone screens in sunlight.

The tool to use here is the WebAIM Contrast Checker at webaim.org/resources/contrastchecker. Plug in your foreground and background hex codes and it tells you instantly whether you pass. Browser DevTools and extensions like Colour Contrast Analyser work too. The fix is almost always a one-line CSS change, this is one of the cheapest WCAG wins available. Following WCAG 2.2 guidelines on contrast pays off in readability for everyone, not just screen reader users.

• Check all body text and heading text against their backgrounds
• Check placeholder text in form fields, it's almost always too light
• Check text overlaid on images, gradients, or video backgrounds
• Check icon-only buttons if the icon carries meaning without a label

2. Alt Text for Images, Icons, and Decorative Elements

Alt text is the semantic description attached to an image so screen readers can convey its meaning to users who can't see it. WCAG 2.2 Success Criterion 1.1.1 requires that all non-decorative images have a text alternative. Simple rule, harder to get right than it sounds, because there are three different scenarios and each one has a different answer.

• Meaningful images, product photos, team headshots, location shots, need descriptive alt text that tells the story. 'Portland marketing team in a strategy session' is useful. 'Team photo' is not.
• Functional images, a search button with only an icon, for example, need alt text that describes the function ('Search'), not the appearance ('magnifying glass icon').
• Decorative images, purely aesthetic dividers or background textures, should have an empty alt attribute (alt='') so screen readers skip them entirely. Adding alt text here creates noise, not clarity.

A framework we find useful: the Purpose Test. Ask yourself, 'Would removing this image change the meaning of the page?' If yes, write descriptive alt text. If no, use alt='' and move on. Keeping that question in your head while uploading images is more practical than remembering every edge case.

The good news is you don't need a developer to fix most of this. WordPress, Squarespace, and Shopify all have alt text fields built into their media upload interfaces. It's a content task, not a code task. That said, when accessibility best practices are built into a website design from the ground up, these fields don't get skipped in the first place.

3. Keyboard Navigation and Visible Focus Indicators

Keyboard navigation means exactly what it sounds like: some users, people with motor impairments, power users, plenty of people who just don't use a trackpad, move through a page entirely with the Tab key. Every interactive element on a page has to be reachable and usable that way. Links, buttons, form fields, dropdowns, modal dialogs, all of it.

WCAG 2.2 added two criteria that weren't in 2.1. Focus Appearance (SC 2.4.11) requires that the focus indicator, the visible highlight showing which element is currently active, meets a minimum size and contrast threshold. And Target Size Minimum (SC 2.5.8) requires interactive targets be at least 24x24 CSS pixels. That last one matters for small close buttons and mobile icon links that designers often shrink down to look tidy.

Here's a quick test you can do right now: open your website, click into the address bar, then press Tab and keep pressing it. Watch what happens. Can you see exactly where you are on the page at every step? If the focus indicator disappears or blurs out, that's a WCAG failure. And honestly, it's also just a broken experience.

The culprit is almost always a line of CSS that says `outline: none`. Designers remove the browser's default focus ring because it's visually disruptive, and that's a legitimate aesthetic concern. But removing it without replacing it leaves keyboard-only users with no way to orient themselves. The fix: style a custom focus indicator using CSS that meets the 3:1 contrast requirement against adjacent colors. This is exactly the kind of thing a solid web accessibility checklist should flag before launch, not after.

Skip navigation links are worth mentioning here too: a visually hidden 'Skip to main content' link as the first focusable element on the page lets keyboard users bypass the header and nav on every page load. Low effort, high payoff.

4. Form Labels, Error Messages, and Input Assistance

Forms are where accessibility failures get expensive fast. Contact forms, quote requests, checkout flows, these are the conversion points. A form that's inaccessible isn't just a compliance problem, it's a lost lead.

Three failures dominate:

• Missing labels. A form field with placeholder text ('Enter your email') but no `<label>` element. Placeholder text vanishes the moment a user starts typing, leaving screen reader users with no persistent description of what the field is for. Every input needs a programmatically associated `<label>`.
• Color-only error identification. WCAG SC 3.3.1 says when an error occurs, it must be described in text, not just signaled by a red border. 'Email address is required' next to the field. That's the standard.
• Instructions that arrive too late. If a phone field requires a specific format, that instruction has to be visible before the user hits submit, not only in the error message afterward.
• Autocomplete attributes. WCAG SC 1.3.5 asks you to tell browsers what kind of data a field expects (name, email, phone). This makes autofill work correctly and genuinely helps users with cognitive disabilities, and it's one line of HTML per field.

Most website builders and form plugins have accessible options. The problem is they're usually not turned on by default, or a custom design has overridden the semantic HTML underneath. Worth checking before you assume it's covered.

5. Page Structure: Headings, Landmarks, and Reading Order

Screen readers and assistive technologies use the structural markup of a page to help users navigate without seeing the visual layout. If that structure is broken, the page is effectively unusable, even if it looks fine on screen. A website accessibility audit almost always surfaces structural problems, and they're often the ones nobody knew existed.

Three things to check:

Heading hierarchy. One H1 per page, the page title. H2 for major sections. H3 for subsections within those. The most common mistake is choosing heading levels based on how they look rather than what they mean in the document structure. Skipping from H1 to H4 because 'it's the right size' creates a broken outline that screen readers have to guess at.

HTML landmarks. Elements like `<header>`, `<nav>`, `<main>`, `<footer>`, and `<aside>` create navigable regions. A page with no `<main>` landmark means a keyboard user has to Tab through the entire navigation every single time they land on a page. Add a skip navigation link, a visually hidden 'Skip to main content' link as the first focusable element, and that problem mostly disappears.

Reading order. The order elements appear in the HTML should match the order they should be read. CSS grid and absolute positioning can create a visual layout that looks right but is read in the wrong sequence by screen readers. Use the browser's Accessibility panel in DevTools to see your page's structure without visual styling. It's eye-opening. Site structure affects SEO and accessibility for the same reason: search engines and screen readers both rely on semantic markup to understand what a page means.

6. Links and Buttons: Clear Labels and Sufficient Target Size

Two very common usability problems with very clear fixes.

Link text. WCAG SC 2.4.4 requires that link purpose be determinable from the link text alone. The failure: links that say 'click here,' 'read more,' or 'learn more' with no surrounding context. A screen reader user navigating by links hears a list of 'read more, read more, read more', there's no way to know where any of them go. The fix is simple: make the link text descriptive. 'Download our web design pricing guide' tells you exactly what you're getting.

• Audit all link text for 'click here,' 'read more,' and 'learn more' patterns, replace with descriptive text
• Check icon-only buttons (hamburger menu, trash, share) for ARIA labels, the accessible name should describe the action, not the icon
• Measure touch targets on mobile, SC 2.5.8 requires at least 24x24 CSS pixels. Small close buttons on modal dialogs fail this constantly.
• Verify links are visually distinguishable from surrounding text by more than color alone, an underline or other visual cue is required

The counterintuitive thing about target size: it's not really an accessibility-only concern. Undersized tap targets frustrate every mobile user. Knowing how to make website accessible and knowing how to make a mobile-friendly website are more overlapping than most people expect. Fixing this one item improves the experience for everyone.

7. Video, Audio, and Time-Based Media

Brand videos, product demos, testimonial reels, podcast clips, a lot of business websites now carry this kind of content. WCAG 2.2 has specific requirements depending on what the media is and whether it autoplays.

Pre-recorded video with audio, your brand video, a product walkthrough, requires synchronized captions and either an audio description or a transcript for content that's conveyed only visually. YouTube auto-generates captions, but they need review before they're usable. Auto-captions for proper nouns, technical terms, and anything with background noise are often wrong. Pre-recorded audio-only content, like a podcast clip, requires a text transcript. Video-only content with no audio, a background loop, a silent animation, requires a text alternative or audio description explaining what's happening visually.

Autoplay is its own issue. WCAG 2.2 SC 2.2.2 says that if a video or animation autoplays, users must be able to pause, stop, or hide it. Autoplay with audio is a Level A failure, the most critical tier. If you're autoplaying a video with sound on your homepage, that's not a gray area.

If you're starting from zero with video accessibility, caption everything first. It has the widest impact, it helps SEO (search engines can index captions), and it helps everyone watching in a library, an office, or a noisy coffee shop. YouTube Studio, Vimeo, and most hosted video platforms have caption upload tools built in, this doesn't require custom development.

One more time, because it matters: this isn't legal advice. If you're unsure how these requirements apply to your specific situation, a qualified attorney can advise you.

How to Test Your Website Against This Checklist

A WCAG 2.2 checklist is only useful if you can actually measure where you stand. Here are four ways to do that, ranging from zero cost to 'set aside an afternoon.'

Automated tools. axe DevTools (browser extension, free tier), WAVE at wave.webaim.org, and the Google Lighthouse Accessibility audit are the three to know. They catch roughly 30-40% of WCAG issues automatically, contrast failures, missing alt text, unlabeled form inputs. Start here. But automated tools are a starting point, not a complete audit, a real accessibility review requires human judgment.

Manual keyboard test. The Tab test from Section 3 above. Five minutes, zero cost, immediate feedback. We run this on every site we build before we hand it off.

Screen reader test. VoiceOver is built into Mac and iPhone. NVDA is free on Windows. TalkBack covers Android. Even a 10-minute walkthrough of your homepage with a screen reader running will surface structural issues that automated tools miss entirely, heading hierarchy problems, unlabeled regions, focus order that jumps around unexpectedly.

Color contrast check. Run every text and background color combination through the WebAIM Contrast Checker. If your brand palette includes any light grays or pastels, expect to find at least one failure. For a fuller look at compliance context, the ADA compliance guide covers the legal and technical landscape together.

Frequently Asked Questions

What is WCAG 2.2 and how is it different from WCAG 2.1?

WCAG 2.2 is the current version of the Web Content Accessibility Guidelines, published by the W3C in October 2023. It includes all the requirements from WCAG 2.1, plus nine new or updated success criteria, most notably stronger rules for focus indicators (Focus Appearance, SC 2.4.11) and minimum touch and click target sizes (Target Size Minimum, SC 2.5.8).

WCAG 2.0 was the original standard. WCAG 2.1 added 17 new criteria with particular attention to mobile users and people with cognitive and low-vision disabilities. WCAG 2.2 builds further, tightening the focus and motor-impairment requirements that 2.1 left somewhat underspecified. If you're already at WCAG 2.1 AA, the gap to 2.2 AA is small in practice, mostly the new focus appearance and target size criteria. If you're starting a new build, aim for 2.2 AA from the start. There's no reason to target a version you know is already superseded.

Does my small business website legally have to be WCAG 2.2 compliant?

Whether WCAG 2.2 compliance is legally required depends on your business type, location, and the applicable law. In the United States, the ADA and Section 508 reference WCAG standards for certain organizations, and courts have increasingly found that inaccessible websites violate the ADA, but legal obligations vary by business type and case law continues to evolve.

This post explains the technical standard, not legal obligations. Businesses that receive federal funding, operate as public accommodations under the ADA, or have received a demand letter should talk to a qualified attorney. That said, meeting WCAG 2.2 AA is widely considered the best-practice baseline regardless of legal exposure, because accessibility improvements benefit all users, not just those using assistive technology. For more context on the compliance side, see our ADA compliance guidance.

What's the difference between WCAG Level A, Level AA, and Level AAA?

WCAG organizes its success criteria into three conformance levels. Level A covers the most critical barriers, failures that make content completely inaccessible for some users. Level AA addresses the broader range of barriers most users encounter and is the standard referenced by most laws, policies, and procurement requirements. Level AAA is the highest tier, important in specialized contexts but not expected of most general-purpose websites.

Target Level AA. Level AAA includes requirements that are genuinely difficult or impossible to meet for all content types, sign language video for all audio content is one example. When people talk about 'WCAG compliance' in a legal or procurement context, they almost always mean Level AA. Start there, get it right, and revisit AAA criteria if you have specific use cases that warrant it.

How long does it take to fix accessibility issues on a business website?

The timeline depends on the site's current state, its size, and whether accessibility is being added to an existing site or built in from the start. A small business website with five to ten pages can often address the most critical WCAG failures, contrast, alt text, label fixes, focus styles, in a few days of development work. Larger or more complex sites take longer.

The biggest factor isn't page count, it's the structural foundation. A site built on a well-coded theme with semantic HTML starts with fewer problems. A site with a heavily customized visual layout, missing semantic structure, or third-party plugins that inject inaccessible components takes real remediation work. We tell our clients this early and often: building accessibility in from the start of a new build costs far less than retrofitting it later. It's not a theoretical future problem, it shows up in the first audit, every time. If you're starting a new project, bring this up on day one. Our Portland web design team builds accessibility-aware sites, it's part of the process, not an add-on.

Accessible Websites Aren't an Edge Case, They're Just Good Websites

Every item on this checklist is a usability improvement, not just an accommodation. High-contrast text is easier for everyone to read. Keyboard navigation benefits power users, mobile users, and people with motor impairments alike. Descriptive alt text helps SEO and assistive technology at the same time. Clear form labels reduce abandonment across the board. The businesses that treat accessibility as a quality standard, not a compliance checkbox, end up with faster, cleaner, better-structured sites. That's not a coincidence. The practices overlap because they're all pointing at the same thing: a page that works for real people.

Sproutbox is a Portland-based full-service digital marketing agency specializing in website design, development, and accessibility-aware builds for small and mid-sized businesses.

If working through this checklist surfaced issues you're not sure how to fix, that's exactly the kind of conversation worth having. Schedule a quick call and we'll take a look at where your site stands.