The Relationship Between WCAG 2.1 and 2.2
WCAG 2.2 is backward compatible with WCAG 2.1. Every success criterion in 2.1 exists in 2.2, with one exception: criterion 4.1.1 Parsing was removed because modern browsers have become consistent enough in handling malformed HTML that the requirement is obsolete. WCAG 2.2 adds nine new success criteria on top of 2.1 — two at Level A, four at Level AA, and three at Level AAA.
If your site conforms to WCAG 2.2 AA, it automatically conforms to WCAG 2.1 AA. The reverse is not true. A site that passed a WCAG 2.1 AA audit may fail a WCAG 2.2 AA audit on any of the six new A and AA criteria.
The numbers: WCAG 2.1 Level AA includes 50 success criteria. WCAG 2.2 Level AA includes 55 — the original 50 minus the removed Parsing criterion, plus six new ones. That is a net increase of five testable requirements at Level AA conformance.
The Legal Context: Which Version Applies to You?
Section 508 of the Rehabilitation Act currently references WCAG 2.0 Level AA — not 2.1, not 2.2. The Access Board's 2017 rule incorporated WCAG 2.0 by reference, and that has not been updated. The Section 508 Refresh Act, introduced in the Senate in July 2024, would modernize these requirements, but the bill has not yet received a vote.
ADA Title II (state and local government websites) references WCAG 2.1 Level AA under the DOJ's 2024 final rule, with compliance deadlines extended to April 2027 for larger entities and April 2028 for smaller ones.
ADA Title III (private sector, including nonprofits and membership organizations) does not specify a WCAG version, but courts and settlement agreements increasingly reference WCAG 2.1 AA as the functional standard. WCAG 2.2 AA is emerging as the target in new litigation and voluntary compliance frameworks.
For associations, the practical recommendation is straightforward: target WCAG 2.2 AA. It satisfies every current legal reference (2.0, 2.1), it positions you ahead of the next Section 508 update, and it addresses usability improvements that benefit your members regardless of legal requirements. Building to 2.1 now and upgrading to 2.2 later costs more than building to 2.2 from the start.
The Six New Criteria at Levels A and AA
Here is what WCAG 2.2 added that WCAG 2.1 did not include. Each criterion is explained in terms of what it requires, why it matters, and where association websites are most likely to fail.
2.4.11 Focus Not Obscured (Minimum) — Level AA
What it requires: When a keyboard user tabs to an interactive element (a link, button, form field, or menu item), that element must not be completely hidden behind other content on the page. At least a portion of the focused element must remain visible.
Why it matters: Keyboard-only users — including people who cannot use a mouse due to motor disabilities — navigate your site by pressing the Tab key. If the element that receives focus is hidden behind a sticky header, a cookie consent banner, a chat widget, or a fixed footer, the user has no idea where they are on the page. They are navigating blind.
Where association websites fail: This is one of the most common failures on association sites because so many use sticky navigation headers, persistent cookie banners, and fixed-position chat widgets. When a user tabs to a link or form field near the top or bottom of the viewport, the sticky element overlaps the focused item. The user cannot see what they have selected. Common culprits include sticky mega-menu headers that cover focused elements as the page scrolls, cookie consent banners fixed to the bottom of the viewport that overlap footer links, live chat widgets (Intercom, Drift, Zendesk) that sit on top of form fields, and notification bars or promotional banners fixed to the top of the page.
How to fix it: Use CSS scroll-padding to account for sticky elements so the browser scrolls focused elements clear of overlapping content. Make cookie banners modal (requiring dismissal before further navigation) or position them so they do not overlap interactive content. Ensure chat widgets can be minimized and do not cover focusable elements.
2.5.7 Dragging Movements — Level AA
What it requires: Any functionality that uses a drag-and-drop interaction must also be operable through a single pointer action (like a click or tap) without dragging, unless dragging is essential to the function.
Why it matters: Dragging requires fine motor control — holding down a pointer while moving it to a precise location. People with motor impairments, tremors, or limited dexterity often cannot perform drag operations. Mobile users on small screens also struggle with drag interactions.
Where association websites fail: Drag-and-drop is less common on association sites than on web applications, but it appears in specific places: sortable lists in member portal dashboards (drag to reorder committee preferences), interactive event agendas with drag-to-schedule functionality, Kanban-style board views in committee or project management tools, and image carousels or sliders that only respond to swipe or drag gestures.
How to fix it: Provide an alternative for every drag interaction. Sortable lists need up/down arrow buttons. Sliders need previous/next buttons. Scheduling tools need click-to-select followed by click-to-place. The drag functionality can remain — it just cannot be the only way to accomplish the task.
2.5.8 Target Size (Minimum) — Level AA
What it requires: Interactive targets (buttons, links, form controls) must be at least 24 by 24 CSS pixels in size, or must have sufficient spacing so that a 24-pixel circle centered on the target does not overlap adjacent targets. There are exceptions for inline text links, targets where the size is determined by the browser's default rendering, and targets where a conforming alternative exists elsewhere on the page.
Why it matters: Small touch targets are difficult for everyone on mobile devices and impossible for users with motor impairments. A 16-pixel icon button that works fine with a precise mouse cursor fails when tapped by a finger, a stylus, or an assistive device. This criterion sets a floor — not a ceiling — for interactive element sizing.
Where association websites fail: Association sites frequently have dense navigation menus with closely packed links, small social media icons in headers or footers, compact pagination controls on resource libraries and event listings, tiny close buttons on modal dialogs and notification banners, and icon-only action buttons in member portal tables (edit, delete, download icons that are 16 or 18 pixels). Inline text links within paragraphs are exempt, but standalone interactive elements are not.
How to fix it: Increase the clickable area of small targets to at least 24×24 pixels. This does not always mean making the visible element larger — you can increase the padding or the clickable hit area without changing the visual design. For closely spaced targets, add margin or padding between them so the 24-pixel exclusion zone does not overlap.
3.2.6 Consistent Help — Level A
What it requires: If your site provides help mechanisms (contact information, chat, FAQ links, help pages), those mechanisms must appear in the same relative order on every page where they are present. The help does not have to be on every page, but where it appears, it must be consistent.
Why it matters: Users with cognitive disabilities rely on consistency to find help when they get stuck. If the contact link is in the footer on some pages, in the header on others, and in a sidebar on a third set, users with memory or navigation difficulties may not be able to find it when they need it most.
Where association websites fail: This is common on association sites that have evolved over years with inconsistent templates. The public site may have a Contact Us link in the footer. The member portal may have a Help button in the header. The event registration flow may have support information in a sidebar. The resource library may have no help mechanism at all. The inconsistency is not intentional — it is the result of different features being built at different times by different teams.
How to fix it: Standardize the placement and order of help mechanisms across all templates. If you offer chat, phone, email, and FAQ, present them in the same order (and ideally in the same location) everywhere they appear.
3.3.7 Redundant Entry — Level A
What it requires: Information previously entered by the user in the same process must not be required to be entered again, unless it is essential to the purpose of the input, the information is security-related, or the previously entered information is no longer valid. When re-entry is not required, the information should be auto-populated or available for the user to select.
Why it matters: Requiring users to re-type information they already provided increases cognitive load and error rates, particularly for users with cognitive disabilities, memory impairments, or motor difficulties that make typing laborious.
Where association websites fail: Association sites with multi-step processes are the primary risk area. Event registration that asks for name and email on step one, then asks for the same name and email again on step three for the receipt. Membership renewal that requires re-entering address information that is already in the member profile. Conference registration that makes attendees re-type organization name and title for each session selection. Committee volunteer forms that ask for contact information the member portal already has.
How to fix it: Pre-populate form fields with data already collected in the process or available from the member profile. Use session storage to carry information between steps in multi-step forms. When information must be confirmed, display it as pre-filled and editable rather than requiring the user to re-enter it from scratch.
3.3.8 Accessible Authentication (Minimum) — Level AA
What it requires: A cognitive function test must not be required for any step in an authentication process unless an alternative method is available, a mechanism exists to assist the user, or the test involves object recognition or personal content. Cognitive function tests include remembering passwords, transcribing one-time passcodes, solving puzzles (CAPTCHAs), and performing calculations.
What this means in practice: Password-based login is still permitted — as long as the browser or a password manager can auto-fill the credentials. The criterion targets situations where the user is forced to manually remember or transcribe information without assistance. If your login form blocks password manager auto-fill (some custom-built forms do this), you may fail. If your two-factor authentication requires manually typing a six-digit code from a text message without allowing copy-paste, you may fail. If your CAPTCHA requires identifying objects in images, that is permitted at Level AA (the exception for object recognition) but prohibited at Level AAA.
Where association websites fail: The most common failures are login forms that use autocomplete='off' or custom JavaScript that blocks password manager auto-fill, two-factor authentication flows that do not allow pasting one-time codes, CAPTCHA implementations on contact forms or registration pages that rely on text transcription or puzzle-solving without alternatives, and custom SSO implementations (especially older SAML flows connecting to iMIS, Fonteva, or Nimble AMS) that introduce intermediate authentication steps blocking auto-fill.
How to fix it: Ensure login forms support browser auto-fill and password managers (use standard input types and autocomplete attributes). Allow copy-paste on all authentication fields including one-time code inputs. If you use CAPTCHA, provide an accessible alternative (email verification, audio CAPTCHA, or invisible reCAPTCHA). Test your SSO and AMS authentication flow with a password manager to verify auto-fill works end-to-end.
What Was Removed: 4.1.1 Parsing
WCAG 2.2 removed criterion 4.1.1 Parsing. This criterion required valid HTML markup — complete start and end tags, no duplicate attributes, unique IDs. It was important when assistive technologies parsed HTML directly and browser error handling was inconsistent. Modern browsers now use the HTML5 parsing algorithm, which handles malformed markup consistently across all major browsers. Assistive technologies now rely on the browser's accessibility API rather than parsing raw HTML. The requirement became redundant.
If your previous WCAG 2.1 audit flagged Parsing issues, you no longer need to remediate them specifically for WCAG 2.2 conformance. However, valid HTML is still good practice — it reduces the chance of unexpected rendering behavior and makes your site easier to maintain.
How to Prioritize If You Are Currently on WCAG 2.1 AA
If your association website currently meets WCAG 2.1 AA and you want to move to 2.2 AA, here is a practical priority order based on likelihood of failure and user impact:
1. Focus Not Obscured (2.4.11): Check immediately. If you have any sticky headers, fixed footers, persistent banners, or chat widgets, this is almost certainly an issue. It affects every keyboard user on every page.
2. Accessible Authentication (3.3.8): Test your login flow with a password manager. Test your two-factor authentication. Test any CAPTCHA on your site. Authentication failures block access entirely — a user who cannot log in cannot use any of your member-only content.
3. Target Size (2.5.8): Audit your navigation, icon buttons, and interactive controls for the 24-pixel minimum. This is a mobile usability issue as much as an accessibility issue — fixing it improves the experience for all users.
4. Redundant Entry (3.3.7): Review multi-step forms (event registration, membership renewal, committee sign-ups). Pre-populate wherever possible.
5. Consistent Help (3.2.6): Audit the placement of help and support mechanisms across all templates. Standardize.
6. Dragging Movements (2.5.7): Identify any drag-and-drop functionality. Provide click-based alternatives.
When WCAG 2.1 AA Is Enough
If your association has no federal funding relationships, no government contracts, and no near-term plans for a redesign, maintaining WCAG 2.1 AA conformance is not a crisis. The legal landscape has not yet mandated 2.2 for most private organizations. Your 2.1 AA conformance still meets the current Section 508 reference (which is only 2.0) and the ADA Title II standard (which is 2.1).
But if you are planning a redesign, building a new member portal, or updating your AMS integration in the next 12 to 18 months, build to WCAG 2.2 AA. The incremental cost of meeting the six new criteria during a build is minimal compared to retrofitting them later. And the usability improvements — better focus visibility, larger touch targets, reduced redundant data entry, accessible authentication — benefit every member, not just those with disabilities.
What You Walk Away With
If your association needs to understand the gap between your current WCAG 2.1 AA conformance and WCAG 2.2 AA, we can run a targeted gap audit focused on the six new criteria. You will get a findings report that identifies exactly where your site fails the new requirements, a prioritized remediation plan with estimated effort for each fix, and a recommendation for whether to remediate now or fold the work into your next redesign. If you are starting a new project, we build to WCAG 2.2 AA from the wireframe stage forward — so accessibility is part of the architecture, not an afterthought.