WCAG 2.2 for Membership Websites, What Changed and What to Check

The Web Content Accessibility Guidelines (WCAG) moved from version 2.1 to 2.2 in October 2023. Public sector bodies in the UK are now measured against 2.2, and procurement teams at institutes and associations have started writing it into tenders. If your membership website was built or audited against 2.1, it is worth knowing what changed, because most of the new criteria land on exactly the pages your members use most.

This is a plain-English guide to the changes for people who run membership websites rather than build them, with a checklist at the end.

Why it matters more for a membership body

A membership organisation’s website is not a brochure. Members log in, renew, book events, submit CPD records and vote. Those are the interactions where accessibility failures do real harm: a member who cannot complete a renewal because the form times out, or cannot log in because the password field fights their password manager, is a member you are about to lose.

There is also an institutional angle. Professional bodies set standards for their professions, run qualifications, and often have public sector members who are themselves bound by accessibility regulations. A membership website that fails the standard the organisation expects of others is a reputational problem before it is a legal one.

What changed in 2.2

WCAG 2.2 added nine success criteria and removed one. Six of the new criteria are at level A or AA, the levels you should be aiming for. Here is what each one means in practice.

Focus not obscured (2.4.11, AA). When a member tabs through the page with a keyboard, the item they have reached must not be hidden behind a sticky header, a cookie banner or a chat widget. Sticky navigation bars are the usual offender on membership sites.

Focus appearance (2.4.13, AAA). The visible outline around the focused item must be large and high-contrast enough to see. This one is AAA, so not required for AA conformance, but it is the right thing to do and is cheap.

Dragging movements (2.5.7, AA). Anything that can be done by dragging must also be possible by clicking or tapping. Sliders, reorderable lists and map controls all fall under this. A price slider on a donation page is a common example.

Target size, minimum (2.5.8, AA). Clickable things must be at least 24 by 24 CSS pixels, or have enough space around them that a person with a tremor can hit the one they meant. Small icon buttons, dense tables of links and tightly packed footer links tend to fail.

Consistent help (3.2.6, A). If the site offers help, such as a phone number, an email address, a chat link or a help page, it must appear in the same place and order on every page. On a membership site the “contact membership services” link counts. Put it in the same place everywhere.

Redundant entry (3.3.7, A). Do not make members type the same thing twice in one process. If the join form asks for an address on step one, it must not ask again on step three, unless it is a security check. Multi-step join and event booking forms are where this fails.

Accessible authentication (3.3.8, AA). Logging in must not require remembering or transcribing something. Password fields must work with password managers and allow pasting. Cognitive tests such as “type the characters in this image” are not allowed unless an alternative is offered. This is the criterion most membership sites fail today, usually because of an anti-bot image challenge or a login form that blocks paste.

Accessible authentication, enhanced (3.3.9, AAA). The stricter version of the above. Not required for AA.

Removed: parsing (4.1.1). The old requirement for perfectly valid HTML has been dropped because modern browsers handle it. One less thing to argue about with an auditor.

The checklist

Run this on your own site. You need a keyboard, a browser and twenty minutes.

1. Tab through the homepage, the login page and the renewal page. Can you always see where you are? Does anything disappear behind the header? (2.4.11, 2.4.13)
2. Find every slider, drag-to-reorder list and map. Can each one be operated with clicks or taps alone? (2.5.7)
3. Look at the footer, the icon buttons and any table of links. Are the targets at least 24 pixels square, or well spaced? (2.5.8)
4. Check where the contact and help links sit on five different pages. Same place, same order? (3.2.6)
5. Walk through the join form and an event booking. Does anything ask for information you already gave? (3.3.7)
6. Try to log in with a password manager, and try pasting a password. Both must work. Is there an image or puzzle challenge with no alternative? (3.3.8)
7. Run an automated checker such as axe or WAVE on the five most-used templates. It will not find everything, but it finds the easy things fast.
8. Read your accessibility statement. Does it exist, is it dated, and does it list known issues honestly?

If any of these fail, you have a list of work. If all of them pass, you have a reason to be pleased, and a reason to test with real members next.

Beyond the checklist

Automated tools catch roughly a third of accessibility problems. The rest need a person: a keyboard-only pass of every template, a screen reader pass of the key journeys, and ideally a session with members who use assistive technology. Build this into the maintenance plan, not just the launch plan, because every new page and every plugin update is a chance to regress.

We build every site to WCAG 2.2 AA, test with axe and by hand before launch, and supply an accessibility statement with the handover. Our own statement is at kickassonline.com/accessibility/, and our approach to accessibility, security and data for procurement teams is on the Trust page. If you are planning a rebuild, the membership organisations page describes what we do for institutes and associations, and How we work describes the process.

If you would like a second opinion on an audit you have already had, or want to know whether a site built in 2021 is likely to pass today, that is a fifteen-minute conversation.