WCAG 2.2 Changes Marketing Teams Must Act On

Nine new success criteria landed in WCAG 2.2, and several hit the pages your marketing team publishes every week: sticky headers that hide focused elements, form fields, and tap targets. Accessibility obligations now reach the landing pages, lead forms, and location finder pages you run in every market. A WCAG 2.2 update is the W3C's October 2023 revision that raises the bar for how users with motor, cognitive, and visual disabilities interact with web content. For a 40-location operator, one noncompliant template gets copied to every location at once. This article covers the criteria that matter for marketing, what each requires, and the order in which to fix them.

What You'll Learn

• The specific WCAG 2.2 changes from 2.1 and which ones were removed
• Which new success criteria apply to sticky headers, chat widgets, forms, and mobile buttons
• How to audit lead-generation pages for WCAG 2.2 without rebuilding the entire site
• How accessibility fixes at the template level reduce per-location cost across a multi-location footprint
• A practical sequence for auditing, prioritizing, and documenting compliance for procurement and legal review

What Changed in WCAG 2.2 Compared to WCAG 2.1

The Web Content Accessibility Guidelines (WCAG) define how to make web content usable by people with disabilities. The World Wide Web Consortium (W3C) publishes them. WCAG 2.2 is the current W3C Recommendation, which means it is the stable, final version of the standard.

WCAG 2.2 builds on WCAG 2.1. It does not replace it. Every rule from 2.1 still applies, and 2.2 adds to that base.

How 2.2 Builds on 2.1

WCAG 2.1 contained 78 success criteria. A success criterion is one testable rule, such as "focus is not hidden" or "targets are large enough to tap." WCAG 2.2 adds nine new criteria and removes one. That leaves 86 in total.

The new rules focus on:

• Mobile users who rely on touch and small screens
• People with low vision who zoom or enlarge content
• People with cognitive or motor limitations who need predictable, forgiving interfaces

The full list of changes is in the W3C's What's New in WCAG 2.2 overview.

The Three Conformance Levels

WCAG sorts every success criterion into one of three conformance levels. Each level sets a higher bar.

1. Level A covers the most basic barriers. A site must meet Level A to claim any conformance.
2. Level AA is the common target. Most accessibility regulations and procurement contracts reference it.
3. Level AAA is the strictest tier. The W3C does not recommend it as a site-wide requirement because some content cannot meet it.

When a vendor says a site is "WCAG compliant," ask which version and which level. A claim of WCAG 2.2 AA is specific and testable. Anything vague is not.

Why Criterion 4.1.1 Parsing Was Removed

Criterion 4.1.1 Parsing required valid HTML. It checked for problems like duplicate element IDs and incorrectly nested tags. The W3C marked it obsolete in WCAG 2.2 because modern browsers and assistive technologies now handle most markup errors consistently.

Removing 4.1.1 does not mean markup quality stopped mattering. Other criteria still test how code exposes names, roles, and values to assistive technology. Clean HTML also makes audits faster and reduces the cost of fixes.

For marketing leaders, the practical takeaway is straightforward. Your landing pages still need to pass the criteria that remain. A conversion-focused website build that is accessible from the start costs less to fix later than one retrofitted after a complaint.

Key Insight: WCAG 2.2 extends WCAG 2.1 with nine new criteria and drops Parsing, so your baseline is now 86 criteria at Level AA. Confirm the version and level in every vendor contract.

Which WCAG 2.2 Success Criteria Affect Marketing Pages

Nine new success criteria landed in WCAG 2.2. The W3C documents each one on its What's New in WCAG 2.2 page. Most of them affect the same elements marketing teams already manage, so you can sort them quickly.

Criteria that affect every page

Several new rules cover elements that sit on top of content. Sticky headers, cookie banners, and chat widgets are the usual culprits.

• 2.4.11 Focus Not Obscured (Minimum) (Level AA): A keyboard user's focused element cannot be fully hidden by a sticky header or banner.
• 2.5.8 Target Size (Minimum) (Level AA): Pointer targets must be at least 24 by 24 CSS pixels, with listed exceptions. The W3C explains the threshold and exceptions in detail.
• 3.2.6 Consistent Help (Level A): If a help link or chat button repeats across pages, it must appear in the same place each time.

Criteria that affect forms and checkout

Forms and checkout flows carry the most conversion risk. These three criteria decide whether a visitor can finish.

• 3.3.7 Redundant Entry (Level A): Do not make people retype information they already gave in the same process.
• 3.3.8 Accessible Authentication (Minimum) (Level AA): A login cannot depend on a cognitive test, such as a puzzle, unless an alternative exists. Paste and password managers must work.
• 3.3.9 Accessible Authentication (Enhanced) (Level AAA): A stricter version that removes cognitive tests entirely. It is not required for AA conformance.

Criteria that affect sliders and focus styles

• 2.5.7 Dragging Movements (Level AA): Any drag action, such as a map pin or before-and-after slider, needs a tap or click alternative.
• 2.4.12 Focus Not Obscured (Enhanced) (Level AAA): The focused element cannot be obscured at all, even partially.
• 2.4.13 Focus Appearance (Level AAA): Focus outlines need a minimum size and contrast.

Element-by-element map

A brochure page with no sticky elements, forms, or drag controls touches only the target size and focus criteria. Every lead form, pop-up, and checkout step touches several.

For a multi-location brand, fix the template once and the fix reaches every location page. Teams that want these checks built into page templates can start with our website build service.

Key Insight: Most WCAG 2.2 exposure sits in five places: sticky headers, cookie banners, pop-ups, forms, and checkout. Audit those first, then check target size on every button and icon link.

How Focus Rules Affect Sticky Headers, Chat Widgets, and Pop-Ups

WCAG 2.2 added Focus Not Obscured (Minimum), criterion 2.4.11, as a Level AA requirement. When a control receives keyboard focus, content the site owns must not hide it entirely. The W3C understanding document gives the intent: a keyboard user should always be able to see where they are.

Why Sticky Headers Hide Focus

A sticky header stays pinned to the top of the screen as visitors scroll. A keyboard user presses Tab, and the browser scrolls the focused link into view. If the header sits over that spot, the link is selected but invisible.

Common offenders on multi-location sites include:

• Tall fixed navigation bars
• Cookie banners pinned to the bottom edge
• Sticky "call now" or "book" bars on mobile
• Floating chat buttons in the lower right corner

Each one can cover a focused element. The user has no idea what they just selected.

Floating Chat Buttons and Widgets

A floating chat button is a fixed element that sits above the page content. When a keyboard user tabs into a form field near the bottom of the page, that field can slide under the widget. A mouse user scrolls past the problem, so teams rarely catch it in testing.

Chat panels also open over large areas of the screen. The panel should be fully visible when it takes focus. The user should be able to close it with the Escape key.

Modal Overlays and Pop-Ups

A modal overlay is a dialog that blocks the page behind it. When it opens, focus should move into the dialog. When it closes, focus should return to the button that opened it. Two failures appear often:

1. Focus moves into a dialog that opens below the visible area.
2. Focus stays on the page behind the overlay, so the user tabs through content they cannot see.

What a Compliant Fix Looks Like

Start with the simplest changes:

• Set scroll-padding-top on the page to match the header height, so focused targets land below the bar.
• Apply scroll-margin-top to focusable sections for the same effect.
• Keep floating widgets from covering form fields on small screens, or collapse them until clicked.
• Confirm every dialog opens inside the viewport with a visible close control.

Then test with the keyboard only. Tab through each main page template, including booking flows and location pages. Note every control you cannot see. Two related rules also apply: 2.4.7 Focus Visible requires a visible focus indicator, and 2.4.13 Focus Appearance (Level AAA) sets stricter size and contrast targets.

At scale, the risk multiplies. A 40-location group that shares one page template inherits the same header and widget bug in 40 places. Fixing the template once improves every location page together. A rebuilt site built on the right service makes this fix a one-time cost instead of a per-location expense.

Key Insight: Focus Not Obscured is a template-level fix, not a per-page cleanup. Check sticky headers, chat widgets, and modals in your shared templates first, because one fix there reaches every location.

Need help applying this to your business? Tell us about your project and we will scope it with you.

WCAG 2.2 Form Requirements for Lead Generation Pages

Redundant Entry is WCAG success criterion 3.3.7. It is a Level A requirement, so it is the floor for any compliant form. If a user already entered information earlier in the same process, the form must fill it in automatically or let the user select it. The WCAG Understanding guide for Redundant Entry lists the narrow exceptions, such as security checks and data that is no longer valid.

Multi-step quote requests break this rule most often. A user enters a name, email, phone number, and address on step one. Then the form asks for all of it again on step three.

Here is a hypothetical example, not a client result. Imagine a 40-location service group that receives 2,000 quote requests a month. If 5% of users abandon at the repeated-entry step, that is 100 lost requests. Spread across 40 locations, that is 2.5 lost leads per location every month.

What Accessible Authentication (3.3.8) Requires

Accessible Authentication is criterion 3.3.8, a Level AA requirement. It blocks login steps that depend on a cognitive function test, such as remembering a password or solving a puzzle. The exception applies only when the site offers an alternative, a helper mechanism, or object recognition. The WCAG Understanding guide for Accessible Authentication explains the details.

Login flows matter for lead generation too. Franchise owners, location managers, and partners often log in to submit leads, upload assets, or check requests.

• Fails: Requiring users to transcribe a distorted image code with no alternative
• Fails: Blocking paste into password or code fields
• Passes: Supporting password managers and autofill
• Passes: Offering passkeys, email magic links, or one-time codes

How to Audit Your Lead Forms

1. Count the fields on every landing page form and every quote flow.
2. Check whether later steps ask for data the user already gave.
3. Test each login with a password manager and with paste enabled.
4. Confirm at least one login path that avoids memory tests.

Fixing these issues is usually a build task, not a copy task. A websites build focused on conversion can address form logic, field persistence, and login design together. If you want a baseline before changing anything, start with an accessibility and conversion audit that counts the friction points on each form.

Key Insight: Redundant entry and cognitive login tests are measurable conversion losses, not just compliance items. Every repeated field and every memory test removes leads from locations that already paid to generate them.

Target Size Requirements for Mobile Landing Pages

WCAG 2.2 adds Success Criterion 2.5.8 Target Size (Minimum). It sits at Level AA, the level most procurement teams and accessibility reviewers use as the baseline. The rule is direct: a pointer target must measure at least 24 by 24 CSS pixels.

A target is anything a person can tap, click, or drag with a pointer. That includes buttons, links, form fields, icons, and map pins. The W3C's Understanding Target Size (Minimum) page explains how auditors apply the criterion.

The spacing exception

A target smaller than 24 pixels can still pass. The spacing exception applies when no other target falls inside a 24-pixel circle centered on the small target. Nearby controls need enough clear space around them.

The criterion also lists these exceptions:

1. Inline targets, such as a link inside a sentence.
2. Equivalent controls, where the same action exists at full size elsewhere on the page.
3. User agent controlled elements, such as default browser widgets.
4. Essential sizing, where a smaller size would change the meaning.

Where mobile landing pages fail

Most failures follow a few familiar patterns:

• Icon-only buttons for call, text, directions, or share, often drawn at 16 or 20 pixels.
• Phone links in headers or footers, set in small text with no padding.
• Map pins on store locator maps, packed tightly in dense metro areas.
• Close buttons on pop-ups and cookie banners, drawn as small "x" glyphs.
• Stacked checkboxes or radio buttons with little space between them.

Multi-location brands feel this most. A location finder showing 60 pins in one metro can place several targets inside the same 24-pixel circle. Each pin then fails unless the spacing exception covers it.

How to fix it

Teams can fix most failures without a redesign:

• Add invisible padding so the tappable area reaches 24 by 24 pixels, even when the icon looks smaller.
• Spread out map pins or cluster them above a set zoom level.
• Give phone links and close buttons a larger hit area in the CSS.
• Test the top ten landing pages on a real phone before each launch.

Teams that want an outside check can book a review through our website build service, where tap target sizing is part of the build checklist.

Key Insight: Criterion 2.5.8 is a size floor, not a design style. Padding a tap area costs little, and it protects every location's phone and directions buttons from failing an audit.

Does WCAG 2.2 Compliance Become a Legal Requirement?

The European Accessibility Act (EAA) became enforceable on June 28, 2025. It covers consumer-facing products and services sold in EU member states. The directive lists the covered areas, and the full text is available in Directive (EU) 2019/882 on EUR-Lex.

The EAA applies to these services when sold to EU consumers:

• E-commerce websites and apps
• Retail and consumer banking services
• Passenger transport ticketing and information
• E-books and audiovisual media services
• Telephony and emergency communication services

The directive does not name WCAG directly. It points to harmonised standards, and the European standard EN 301 549 references WCAG 2.1 Level AA. WCAG 2.2 Level AA keeps nearly all of those criteria, so a site built to 2.2 AA is well positioned.

Penalties are set by each member state. The directive requires them to be effective, proportionate, and dissuasive, so the amounts will vary by country.

How ADA Lawsuits Push Companies Toward WCAG

In the United States, the Americans with Disabilities Act (ADA) has been the main legal driver. Plaintiffs argue that commercial websites are places of public accommodation under Title III. Courts have not settled the question across every federal circuit, so outcomes differ by location.

Most demand letters and settlement agreements use WCAG as the yardstick. Teams that are sued usually face orders to fix specific failures within a set timeline. Common problem areas include:

• Checkout and booking flows that keyboard users cannot complete
• Form fields with no labels or error messages
• Images with no alt text
• Videos without captions
• PDFs and downloads that screen readers cannot parse

For a 40-location brand, a single demand letter can point to the same defect on every local landing page. A fix made once at the template level can close many issues. That is why per-location economics favor a central standard over location-by-location patches.

What Marketing Teams Should Do Now

1. Ask counsel to map obligations for every country and state where you sell or market.
2. Audit high-traffic pages first, including location pages, lead forms, pop-ups, and chat widgets.
3. Adopt WCAG 2.2 Level AA as the internal standard for all new builds and templates.
4. Keep a dated record of fixes, test results, and remaining issues.

A full accessibility audit shows which templates carry the most risk. Teams rebuilding their site can also review conversion-focused website builds that are designed to WCAG 2.2 AA from the start.

Key Insight: The EAA is already enforceable, and US ADA claims routinely cite WCAG as the benchmark. Confirm your obligations with counsel in each jurisdiction, then fix shared templates first so one repair covers every location.

How to Roll Out Accessible Templates Across Multiple Locations

Multi-location brands rarely fail accessibility on the homepage. They fail on location pages. One template gets copied across dozens of sites, and every copy carries the same defects. Fixing the shared template fixes every page at once.

Audit the shared components first

Start by listing every component that repeats across locations:

1. Navigation, skip links, and header
2. Location finder and map embeds
3. Booking and contact forms
4. Click-to-call and directions buttons
5. Footer, hours table, and review widgets

Then test each component against the WCAG 2.2 criteria that break most often on marketing sites:

• Focus Not Obscured (2.4.11): A sticky header or chat bubble must not hide the element that has keyboard focus.
• Target Size (Minimum) (2.5.8): Interactive controls need at least 24 by 24 CSS pixels, or enough spacing around them.
• Accessible Authentication (3.3.8): Forms should not force memory tests or puzzles, and should allow pasting into fields.

The full wording of each criterion is in the W3C WCAG 2.2 Recommendation.

Store design rules in one place

Keep colors, focus rings, and spacing in shared design tokens. A contrast fix then ships everywhere in one change. Body text needs a contrast ratio of at least 4.5 to 1 under criterion 1.4.3, so set that floor once, not in dozens of stylesheets.

We rebuilt DDES, an economic research and workforce development organization, on Next.js with full Search Console integration. The organization went from effectively invisible on Google to indexed and ranking for high-intent research queries. That rebuild is the same work a multi-location brand needs for its template layer: one codebase, one set of fixes, many pages. See the DDES case study and our website build service.

Roll out in waves, not all at once

A staged rollout limits damage if a fix breaks something:

1. Fix the template in a staging branch.
2. Run automated checks, then manual keyboard tests.
3. Ship to five pilot locations.
4. Compare conversion rates and support tickets for two weeks.
5. Push to the remaining locations.

For the keyboard test, tab through the full page without a mouse. Confirm you can reach every link, button, and form field, and that you can always see where focus sits.

Govern changes after launch

Accessibility drifts when local managers edit page structure. Lock the layout and let location teams edit only content blocks such as hours, photos, and offers. Add automated accessibility checks to the publish step, so a failing page cannot go live. Teams that want this enforced automatically can look at workflow automation.

Key Insight: Treat accessibility as a template property, not a page property. One fix to a shared component reaches every location, which is the only way to keep 50 or 100 sites consistent.

How to Audit an Existing Website for WCAG 2.2 Without a Full Rebuild

Start with an automated scan of every location page, not just the homepage. Automated checkers flag missing alt text, low color contrast, and unlabeled form fields within minutes. They cannot judge whether a booking flow makes sense to someone who navigates by keyboard.

Step 1: Run the Automated Scan

• Crawl every location page, service page, and contact form.
• Export results grouped by page and by rule, not by raw error count.
• Mark sticky headers and cookie banners for manual review.

Step 2: Test Keyboard and Screen Reader Paths

Manual testing catches what machines miss. WCAG 2.2 adds nine new success criteria to the standard, and most involve focus and forms. Check these three first:

1. Focus Not Obscured (2.4.11): a focused element must not hide behind a sticky header or chat widget.
2. Target Size (2.5.8): clickable controls need a minimum size of 24 by 24 CSS pixels.
3. Accessible Authentication (3.3.8): login steps should not depend on memory tests or copying characters.

Read the full list in the W3C summary of what is new in WCAG 2.2. Then tab through each lead path from start to finish. Note every point where focus disappears or a button does nothing.

Step 3: Prioritize Lead Pages

Do not audit every page at the same depth. Rank pages by lead impact:

• Quote and booking forms
• Click-to-call and location finder pages
• Pricing and service pages that drive contact requests

Fix the top tier first. A broken form on a 40-location template repeats the same failure 40 times. Fixing the template once fixes all 40 pages.

Step 4: Write Remediation Tickets

Every finding becomes a ticket with the same fields:

1. Page URL and location
2. WCAG criterion number
3. Element selector and steps to reproduce
4. Severity: blocks a lead, degrades use, or cosmetic
5. Owner and due date

Tickets with this structure let a developer fix an issue without a meeting. They also give your team an audit trail for legal and vendor reviews. Teams that need outside help can start with the right service for remediation.

Where Accessibility Meets SEO and Core Web Vitals

Accessibility and technical SEO share most of the same fixes. Descriptive headings, meaningful link text, and alt text help screen reader users and search crawlers alike. Layout stability also matters here. Google's guidance sets a "good" Cumulative Layout Shift score at 0.1 or less, and a "good" Largest Contentful Paint at 2.5 seconds or less, as described in Google's Web Vitals guide.

Schedule accessibility and performance fixes in the same sprint. Testing both at once cuts rework.

Key Insight: Audit lead paths before anything else, because one shared template fix can repair dozens of locations at once. Pair accessibility tickets with Core Web Vitals work so each release improves both usability and search visibility.

Sources and References

Primary sources cited above:

• W3C's What's New in WCAG 2.2 overview
• W3C explains the threshold and exceptions
• W3C understanding document
• WCAG Understanding guide for Redundant Entry
• WCAG Understanding guide for Accessible Authentication
• Directive (EU) 2019/882 on EUR-Lex
• W3C WCAG 2.2 Recommendation
• Google's Web Vitals guide