WCAG 2.2 in practice: a business guide to the new accessibility rules
Check whether your website meets WCAG 2.2 requirements. Run a quick online accessibility audit and improve visibility, conversions and user trust.
Introduction: what WCAG 2.2 really changes
WCAG 2.2 adds nine success criteria. All address the same question: can a user reach the content with a keyboard, screen reader or thumb on a phone?
For a business, that means three things at once: a wider reach, better technical SEO performance and less legal risk.
What is behind the update?
- New user habits: most interactions now happen on a phone, with a finger, on the move.
- Changes in law: the European Accessibility Act and national legislation refer directly to WCAG.
- Competitive pressure: an accessible interface works better for everyone, and that shows in search data.
Good to know: you can check most WCAG 2.2 criteria without a tool. Put the mouse aside and go through the entire purchasing journey using only the Tab key.
WCAG at a glance: what is it about?
The Web Content Accessibility Guidelines (WCAG) are standards describing how to design websites and applications so everyone can use them, regardless of limitations in vision, hearing or mobility.
WCAG 2.2 adds nine success criteria: clear focus, interactive target sizes and authentication without barriers. It is a narrow set, but it addresses the exact points where users most often drop out.
The four principles of accessibility: POUR
- Perceivable - content can be seen or heard: contrast, alternative text and video captions.
- Operable - the website works with a keyboard, and animations will not trigger an epileptic seizure.
- Understandable - navigation and language are intuitive, and error messages explain the problem clearly.
- Robust - code works with screen readers and will not break in future browsers.
Level
What does it mean?
The minimum: the service does not block essential functions for people with disabilities.
The market standard, required in most tenders and regulations, such as in the public sector.
An ambitious premium level: full accessibility in almost every usage situation.
Why is AA the market standard?
AA balances real user needs and implementation costs: contrast, visible keyboard focus, video captions and a layout that holds together when zoomed. This is the level required by tenders and regulations, and the target of most e-commerce and SaaS audits.
AA criteria help more than people with disabilities. They shorten task completion time for every user, which shows in website behaviour and in the signals Google collects.
Quick test: focus the CTA button and take a screenshot. If you cannot clearly see which element is active when you zoom in, criterion 2.4.13 is not met: the outline should be at least 2 px with 3:1 contrast against the background.
What is new in WCAG 2.2? Nine new success criteria
The nine new criteria centre on three topics: keyboard navigation, touch target sizes and sign-in without cognitive barriers. People with limited motor control and mobile users benefit most.
The nine new criteria: a quick overview
- 2.4.11 Focus Not Obscured (Minimum) - keyboard focus must not be hidden by sticky elements.
- 2.4.12 Focus Not Obscured (Enhanced) - the entire area of the focused element must remain fully visible.
- 2.4.13 Focus Appearance - focus contrast of at least 3:1 and an outline at least 2 px thick.
- 2.5.7 Dragging Movements - an alternative to drag-and-drop gestures.
- 2.5.8 Target Size (Minimum) - interactive elements at least 24x24 px, apart from exceptions.
- 3.2.6 Consistent Help - help elements such as FAQ, chat and phone details in the same place on every page.
- 3.3.7 Redundant Entry - forms do not require users to re-enter information the system already knows.
- 3.3.8 Accessible Authentication (Minimum) - sign-in without visual puzzles or memorising passwords.
- 3.3.9 Accessible Authentication (Enhanced) - an extension of the previous criterion, removing additional cognitive barriers.
How will these changes affect your website?
The biggest differences will be keyboard use and convenience on a phone. Larger touch targets and clear focus shorten the path to a goal, while an alternative to drag and drop opens functions to people using assistive technology.
There is also a technical benefit: fewer form errors, a shorter purchasing journey and better-organised semantics for search crawlers to navigate.
How to measure it: select a button in DevTools and check its actual height and width, including padding, under “Computed”. A 16 px “remove from basket” or “add to favourites” icon does not pass criterion 2.5.8.
Who the new requirements affect: online shops, portals, SaaS and mobile apps
WCAG 2.2 concerns every industry that earns money online. Regulations are already in force, and users do not negotiate: they simply leave.
The most affected sectors
- E-commerce shops: larger touch targets and clear forms reduce abandoned baskets.
- Content portals and marketplaces: better contrast and keyboard focus make long lists easier to read.
- SaaS products and web apps: alternatives to drag and drop shorten onboarding for new users.
- Mobile apps: 24x24 px targets and better touch navigation reduce interaction errors.
- FinTech and HealthTech: the European Accessibility Act has applied since 28 June 2025 and requires level AA.
What do you lose by ignoring WCAG 2.2?
- Quality signals for Google: an inaccessible interface usually also has disorganised semantics and weak Core Web Vitals.
- Mobile users who will not fight with a microscopic “Buy now” button.
- Legal compliance: inaccessibility brings a risk of sanctions and exclusion from tenders.
Which WCAG level does the law currently require?
The European Accessibility Act does not define its own technical criteria. It refers to the harmonised standard EN 301 549, whose applicable V3.2.1 version directly incorporates WCAG 2.1 at level AA. That is the current legal threshold.
The revision raises that threshold to WCAG 2.2 AA: draft V4.1.0 has been ready since November 2025, and a reference to V4.1.1 in the Official Journal of the EU is expected in October 2026. The practical conclusion: today’s minimum is 2.1 AA, but aim for 2.2 AA whenever undertaking a major website overhaul. The difference is a few criteria, and you only do the work once.
We cover deadlines, exemptions for microbusinesses and the Polish implementing law in our article on what the European Accessibility Act changes in e-commerce. The full directive is available on the European Commission website.
How can you quickly check readiness for WCAG 2.2?
- Run a basic audit with axe DevTools or Lighthouse.
- Verify that all buttons are at least 24x24 px.
- Check contrast: at least 4.5:1 for text and 3:1 for interactive elements.
- Make sure key functions work using only a keyboard.
- Commission a full audit involving real users with disabilities: automation will not catch everything.
WCAG 2.2 implementation checklist: tools and stages
Before a line of code reaches the server, we work through a seven-point checklist. The order is deliberate: each stage removes half the work from the next.
You can follow it yourself or commission us to handle the whole thing as one project.
Work stages and recommended tools
Stage
Tools / purpose
axe DevTools, Lighthouse, Pa11y - we identify critical issues: contrast, missing labels and focus.
Card sorting, FigJam - we define the key conversion paths to cover with tests.
CSS tokens checked by Stylelint - one source of colours and typography, with hit targets of at least 24x24 px.
Semantic HTML and native elements (button, dialog, details) instead of ARIA roles wherever possible: keyboard navigation and visible focus then work without a line of JavaScript.
W3C Validator - we organise h1-h6 heading hierarchy, alt descriptions and link text, with no “click here”.
We issue an accessibility statement meeting EAA requirements and set up regression alerts so the next deployment does not undo the work.
How do you use the checklist in practice?
Want to work through it yourself? Every step is above. Prefer to complete the whole thing as one project? We will audit the site and return a list of fixes ranked by their impact on users.
Business benefits of accessibility: SEO, conversions and brand trust
Digital accessibility is more than a legal duty. WCAG 2.2 improvements affect the same elements that support technical SEO and online sales.
1. Better Google rankings
Google rewards Core Web Vitals, structured data and clear semantics. Consistent contrast, an h1-h6 heading hierarchy and visible focus are the same work: done once, counted in both assessments.
That is why our SEO service in Białystok treats accessibility as part of technical work, not a separate extra on the quote.
2. Higher conversions and lower CAC
Larger hit targets, logical forms and useful alt text shorten the path to “Buy”. Mobile users do not have to aim at a pea-sized icon, and screen reader users know what is in their basket. Fewer abandonments from the same traffic mean a lower customer acquisition cost.
3. Credibility and resilience to PR crises
An accessibility statement is a public commitment that can be checked. A brand that fulfils it does not have to explain a complaint from a customer who could not place an order. That costs less than another campaign about values.
4. Less exposure to legal risk
The European Accessibility Act has applied since 28 June 2025 and requires e-commerce shops and digital services to conform at level AA: currently WCAG 2.1 AA under EN 301 549 V3.2.1, and WCAG 2.2 AA after the standard is revised. Non-compliance risks penalties and exclusion from tenders, while urgent fixes cost more than planned work.
Accessibility connects three things already on your list: legal requirements, user needs and the signals search engines look for. You do not have to choose just one.
Summary: the main lessons from WCAG 2.2
Digital accessibility is not a box to tick before an audit. Here is what matters most when implementing WCAG 2.2.
Key takeaways
- The nine new WCAG 2.2 criteria mainly concern mobile usability, touch targets and keyboard navigation.
- E-commerce, SaaS and mobile apps have the most to lose, from abandoned baskets to EAA sanctions.
- The current legal threshold is WCAG 2.1 AA (EN 301 549 V3.2.1), but plan changes around 2.2 AA from the outset.
- An audit is the first step: axe DevTools or Lighthouse can reveal critical issues in a few minutes.
- Implement the checklist in stages or let us handle it as a whole.
What next?
- Start with a quick audit of critical issues, not a layout rebuild.
- Compare the results with the checklist above and build a roadmap based on user impact.
- Monitor regressions after every deployment: accessibility can break quietly.
Accessibility is a process, not a one-off project. Every new feature, landing page and campaign should pass the same test: can someone reach it using only a keyboard or screen reader? The sooner the team makes that a habit, the fewer expensive fixes are needed later.
FAQ: common questions about WCAG 2.2
Five questions about the standard return in every audit: what version 2.2 changes, which criteria it introduces, which conformance level to choose, what accessibility contributes to SEO, and how to run a quick test yourself.
What is WCAG 2.2 and what does it add?
WCAG is a set of standards describing how to design websites and applications so everyone can use them, regardless of limitations in vision, hearing or mobility. Version 2.2 adds nine success criteria focused on clear keyboard focus, interactive target sizes and accessible authentication. It still follows the four POUR principles: perceivable, operable, understandable and robust.
Which criteria does WCAG 2.2 introduce?
Focus must not be hidden by sticky elements (2.4.11 and 2.4.12), and its contrast must be at least 3:1 with a 2 px outline (2.4.13). Dragging gestures need an alternative (2.5.7), interactive elements must be at least 24x24 px (2.5.8), help must appear in the same place on every page (3.2.6), forms must not require known data to be entered again (3.3.7), and sign-in must work without visual puzzles (3.3.8 and 3.3.9).
Which conformance level should you choose: A, AA or AAA?
AA. Level A is the minimum at which a service does not block essential functions, while AAA is a premium level rarely required. AA balances actual user needs and implementation costs: suitable contrast, visible keyboard focus, video captions and responsive layouts. Most tenders and regulations require this level. The European Accessibility Act, applicable since 28 June 2025, refers to EN 301 549, whose current V3.2.1 version incorporates WCAG 2.1 at AA. The revised standard raises the threshold to WCAG 2.2 AA: draft V4.1.0 has been ready since November 2025, and a reference to V4.1.1 in the Official Journal of the EU is expected in October 2026.
Does accessibility help SEO?
Yes, because it works on the same elements as technical SEO. Correct contrast, ordered h1-h6 headings, clear HTML semantics and visible focus improve crawlability and Core Web Vitals, while better UX reduces the time needed to complete a task and lowers bounce rates. Google treats these signals as indicators of website quality.
How can you quickly check whether a website meets WCAG 2.2?
Five steps. Run a basic audit with axe DevTools or Lighthouse. Check that buttons are at least 24x24 px. Verify contrast: at least 4.5:1 for text and 3:1 for interactive elements. Complete key functions using only a keyboard. Finally, commission a full audit involving real users with disabilities, because automation cannot find everything.
Version 2.2 does not turn the rules upside down; it closes gaps where keyboard and phone users most often drop out. Have a question we have not covered? Email biuro@digidraft.pl. We reply within 24 business hours.
