What WCAG 2.2 AA actually requires of a marketing site

Many organizations know they should meet WCAG 2.2 at level AA, often because a procurement requirement, a regulator or a legal letter says so. Fewer know what that means for their actual website. The standard is written to be technology-neutral, which makes it precise but abstract. After running accessibility audits on dozens of marketing sites, we see the same failures again and again. Most are not exotic, and most can be fixed within a normal development cycle once they are understood.

The four principles in plain terms

WCAG organizes its success criteria under four principles. Content must be perceivable, meaning people can see or hear it in some form. Interfaces must be operable, meaning people can use them with a keyboard, a switch device or a screen reader. Content must be understandable, meaning language and behavior are predictable. And code must be robust, meaning assistive technologies can interpret it reliably. Level AA includes 55 or so criteria across these principles. On a typical marketing site, a much smaller subset accounts for most of the issues.

The failures we find most often

Color contrast

Body text needs a contrast ratio of at least 4.5 to 1 against its background, and large text 3 to 1. Interface components and meaningful graphics, such as input borders and icon buttons, need 3 to 1. Light gray placeholder text, white text over photographs and pale brand colors used for links are the usual culprits. Contrast issues appear on almost every site we audit.

Keyboard access and visible focus

Every interactive element must be reachable and operable with a keyboard, and the focused element must be clearly visible. Custom dropdown menus, carousels, modals and cookie banners regularly fail here. Removing the browser focus outline without providing a replacement is still one of the most common single mistakes.

Images and alternative text

Informative images need text alternatives that convey their purpose. Decorative images should be hidden from assistive technology. Many content management setups make alt text optional, and editors skip it under deadline pressure.

Forms

Every input needs a programmatic label, not just placeholder text. Errors must be identified in text, linked to the field, and explained in a way that helps people fix them. Newsletter signups and contact forms are frequent failures because they are often built quickly.

Headings and structure

Screen reader users navigate by headings and landmarks. Pages that use headings for visual styling, skip levels arbitrarily or have no main landmark are far harder to use.

Most accessibility failures on marketing sites are not exotic. They are contrast, focus, labels and structure, repeated across every template.

What changed in WCAG 2.2

Version 2.2 added several criteria at levels A and AA that matter for marketing sites:

• Focus not obscured: the focused element must not be entirely hidden by sticky headers, chat widgets or cookie banners.
• Target size minimum: interactive targets should be at least 24 by 24 CSS pixels, or have enough spacing around them.
• Dragging movements: anything that requires dragging, such as a slider, needs a single-pointer alternative.
• Consistent help: if help mechanisms like contact links or chat appear on multiple pages, they should be in a consistent place.
• Redundant entry and accessible authentication: do not make people re-enter information unnecessarily, and do not rely on cognitive tests such as memorizing codes to log in.

Sticky headers obscuring focus and small tap targets in footers and navigation are the 2.2 failures we see most on marketing sites.

Motion and media deserve a quick check too. Autoplaying video or carousels need a visible way to pause them, animations triggered by scrolling should respect the reduced motion preference, and prerecorded video with speech needs captions. Marketing teams often add these elements late in a project, after the accessibility review has already happened, so they slip through.

How to prioritize the fixes

An audit will typically produce dozens of issues. Fixing them in order of appearance wastes effort. We prioritize using three factors:

1. Impact: does the issue block a task entirely, such as an inaccessible form, or make it harder?
2. Reach: is it in a global component, such as navigation or the footer, or on one page?
3. Effort: is it a token or template change, or a rebuild?

Global components and templates come first, because fixing the navigation once fixes it on every page. Color contrast problems are best fixed at the token level in the design system rather than page by page. Content issues such as missing alt text need editorial process changes, not just a one-time cleanup, or they will return within months.

Automated tools are a start, not an audit

Automated checkers are useful for catching contrast, missing labels and some structural problems, and they belong in your build pipeline. But they detect only a fraction of WCAG failures. Keyboard traps, confusing focus order, poor alt text and screen reader announcements need manual testing with real assistive technologies. A credible audit combines automated scans, manual expert review and, ideally, testing with disabled users.

Finally, write an accessibility statement that is honest about known issues and gives people a way to report problems. It signals commitment, and the reports you receive are some of the most useful testing data you will get.

Our accessibility audits deliver a prioritized issue list mapped to WCAG criteria, with code-level guidance for each fix. Where problems are systemic, we fix them at the source through design systems work so new pages are accessible by default, and we pair major changes with usability testing that includes assistive technology users.

Find out where your site stands

If you need to demonstrate WCAG 2.2 AA conformance, or simply want your site to work for everyone, we can scope an audit quickly. Ask for a fixed-price quote and you will hear back within 24 hours.