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

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 understand 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

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). Color contrast is the most frequently failed WCAG criterion, according to WebAIM's annual analysis. The fix is almost always a one-line CSS change and takes minutes once you know what to look for.

The 4.5:1 Rule Explained

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.

Where Contrast Failures Hide

Most teams check body text and call it done. The failures that actually get missed are everywhere else:

• Placeholder text in form fields, almost always too light
• Text overlaid on images, gradients, or video backgrounds
• Icon-only buttons where the icon carries meaning without a label
• Heading text set in brand colors against white or near-white backgrounds

How to Check Your Site's Contrast

The tool to use 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. Following WCAG 2.2 guidelines on contrast pays off in readability for everyone, not just screen reader users. This is one of the cheapest WCAG wins available.

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 has a different correct answer.

Meaningful Images

Product photos, team headshots, and location shots need descriptive alt text that tells the story. 'Portland marketing team in a strategy session' is useful. 'Team photo' is not. The description should convey the content and purpose of the image, not just acknowledge that an image exists.

Functional Images

A search button with only an icon, for example, needs alt text that describes the function ('Search'), not the appearance ('magnifying glass icon'). The alt text for a functional image should match what the button or link does, not what it looks like.

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. The distinction matters: unnecessary alt text on decorative images interrupts the reading flow for screen reader users just as much as missing alt text on meaningful ones.

The Purpose Test for Alt Text

Here's a named framework we find genuinely useful: The Sproutbox Purpose Test. Before writing any alt attribute, ask three questions: What does this image mean on this page? Would removing it change the meaning of the content? Is its job informational, functional, or decorative? The answer determines the correct alt text pattern. Informational images get descriptions. Functional images get action labels. Decorative images get empty alt attributes. Keep those three questions in your head while uploading images and you'll handle every edge case without memorizing the spec.

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 move through a page entirely with the Tab key. People with motor impairments, power users, and plenty of people who just don't use a trackpad all depend on it. Every interactive element on a page has to be reachable and usable that way, including links, buttons, form fields, dropdowns, and modal dialogs.

New in WCAG 2.2: Focus Appearance and Target Size

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. 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.

How to Test Keyboard Navigation 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.

Fixing Missing Focus Styles and Skip Navigation

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 is to style a custom focus indicator using CSS that meets the 3:1 contrast requirement against adjacent colors.

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. This is exactly the kind of thing a solid web accessibility checklist should flag before launch, not after.

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.

Missing Labels and Placeholder-Only Fields

A form field with placeholder text ('Enter your email') but no `<label>` element is one of the most common failures we see. 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>`. This is non-negotiable under WCAG 2.2 guidelines and genuinely confusing for every user when it's missing.

Error Identification and Autocomplete

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. Color-only error identification is a failure.

Two more requirements worth building into every form: instructions that arrive before the user hits submit (not only in the error message afterward), and autocomplete attributes per WCAG SC 1.3.5. Telling browsers what kind of data a field expects (name, email, phone) makes autofill work correctly and genuinely helps users with cognitive disabilities. It's one line of HTML per field.

Why Most Form Plugins Aren't Accessible by Default

Most website builders and form plugins have accessible options available. 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.

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. Heading hierarchy is foundational, not cosmetic.

HTML Landmarks and Skip Navigation

Elements like `<header>`, `<nav>`, `<main>`, `<footer>`, and `<aside>` create navigable regions that assistive technology can jump between directly. 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 and Why CSS Can Break It

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 strategy and accessibility for the same reason: search engines and screen readers both rely on semantic markup to understand what a page means. Fixing one tends to improve the other.

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

Two very common usability problems with very clear fixes. Both affect keyboard users, screen reader users, and every mobile visitor at the same time.

Descriptive 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' with 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.

Icon-Only Buttons and ARIA Labels

Hamburger menus, trash icons, share buttons: icon-only buttons need ARIA labels that describe the action, not the icon. 'Open navigation menu' is right. 'Three horizontal lines' is not. This is one of the most commonly skipped requirements in custom-designed sites, and it's also one of the easiest to add.

Touch Target Size on Mobile

SC 2.5.8 requires interactive targets be at least 24x24 CSS pixels. Small close buttons on modal dialogs fail this constantly. The counterintuitive thing about target size is that it's not really an accessibility-only concern. Undersized tap targets frustrate every mobile user. Knowing how to make a 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.

• Audit all link text for 'click here,' 'read more,' and 'learn more' patterns and replace with descriptive text
• Check icon-only buttons for ARIA labels with action-oriented accessible names
• Measure touch targets on mobile and flag anything under 24x24 CSS pixels
• Verify links are visually distinguishable from surrounding text by more than color alone

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.

Captions, Transcripts, and Audio Descriptions

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 or a silent animation, requires a text alternative or audio description explaining what's happening visually.

Autoplay: A Level A Failure You Don't Want

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.

Where to Start If You're Starting from Zero

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.

How to Test Your Site With This WCAG 2.2 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.'

Run This WCAG 2.2 Checklist in Four Steps

1. Automated tools first. 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.
2. 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.
3. 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.
4. 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.

What Automated Tools Miss

Automated tools catch the easy stuff. They won't tell you that your heading hierarchy is semantically broken, that your focus order jumps from the nav to the footer and back, or that your modal dialog traps keyboard focus in a way that's unusable. For a fuller look at compliance context, the ADA compliance guide covers the legal and technical landscape together. Manual testing with a real screen reader is the only way to catch what scanners leave behind.

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 is 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. 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.

What WCAG 2.2 requirements should a small business website prioritize first?

For WCAG compliance for small business websites, start with the four fixes that have the widest impact and the lowest implementation cost: color contrast, alt text, form labels, and focus styles. These cover the majority of failures that show up in automated audits and affect the largest number of users. Contrast and alt text are almost always content or CSS fixes, no custom development required. Form labels and focus styles typically take a developer a day or less on a standard site.

After those four, move to heading hierarchy, skip navigation links, and keyboard-accessible interactive elements. If your site has video content, add captions. That order of operations gets you to a meaningful Level AA baseline faster than trying to tackle everything at once. If you want a team to prioritize and handle the remediation for you, our Portland web design team can assess where you stand and work through it systematically.

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.