← Back to articles

    WCAG 2.2 Compliance in Practice: What EU and Norwegian Rules Now Require

    October 22, 2026 · Devhuset Team

    Why accessibility moved from nice-to-have to a build requirement

    Most teams do not set out to exclude users. They ship a carousel with a three-second autoplay, a form whose error messages only appear in red, and a cookie banner that traps keyboard focus. Each decision looks small in isolation. Together they lock out a meaningful share of the people who arrive on the site.

    The World Health Organization estimates that about 1.3 billion people — roughly one in six — live with a significant disability. Add temporary impairments, bright sunlight, a broken wrist, an ageing workforce, and the number of people who benefit from accessible interfaces climbs much higher.

    What has changed is not the moral argument. It is the legal one. The European Accessibility Act has applied since 28 June 2025, and it covers e-commerce directly. Meanwhile the technical standard behind it is being revised, which means teams building now are aiming at a moving target unless they understand the sequence.

    This guide walks through what WCAG 2.2 actually asks for, which criteria online shops trip over first, and how the European and Norwegian rules fit together.

    WCAG 2.2 in one paragraph

    The Web Content Accessibility Guidelines are published by the W3C. Version 2.1 became a recommendation in June 2018; version 2.2 followed on 5 October 2023. WCAG 2.2 adds nine success criteria and removes one — 4.1.1 Parsing, which had become obsolete because modern browsers handle malformed markup.

    Each success criterion sits at level A, AA or AAA. Level A is the floor, AA is what nearly every regulation references, and AAA is rarely required in full. Conformance is all-or-nothing per page: you either meet every A and AA criterion on that page, or you do not.

    The guidelines are organised around four principles, usually shortened to POUR:

    • **Perceivable.** Content must be available to more than one sense — text alternatives, captions, sufficient contrast.
    • **Operable.** Everything must work by keyboard and by assistive technology, without timing traps.
    • **Understandable.** Language, navigation and error handling must be predictable.
    • **Robust.** Markup must be interpretable by browsers and screen readers, including ones that did not exist when the page was written.

    The new criteria a checkout will hit first

    Four of the nine additions land directly on commerce flows.

    **Target Size (Minimum), 2.5.8 (AA).** Interactive targets must be at least 24 by 24 CSS pixels, with limited exceptions for inline links and spacing. A row of icon-only quantity buttons at 18 pixels fails. So does a tiny "remove" cross next to a cart line.

    **Dragging Movements, 2.5.7 (AA).** Any function that relies on dragging must have a single-pointer alternative. Price sliders, image reordering, and swipe-to-delete all need buttons or inputs alongside the gesture.

    **Focus Not Obscured (Minimum), 2.4.11 (AA).** When a keyboard user tabs to an element, it must not be entirely hidden behind a sticky header, a chat widget or a cookie overlay. This is one of the most common failures on sites with fixed navigation.

    **Accessible Authentication (Minimum), 3.3.8 (AA).** Login must not require remembering or transcribing a password as a cognitive test. Paste must work in password fields, password managers must not be blocked, and an alternative such as a one-time code or passkey should exist.

    Two additions at level A matter for support-heavy sites: **Redundant Entry (3.3.7)**, which says information already supplied in a process should not have to be entered twice, and **Consistent Help (3.2.6)**, which says help mechanisms such as chat or a contact number should appear in the same relative place across pages.

    Contrast, focus and the visual basics

    None of this is new, and all of it is still where audits find the most problems.

    Body text needs a contrast ratio of at least 4.5:1 against its background. Large text — 18 point, or 14 point bold — needs 3:1. So do interface components and meaningful graphics such as icons and chart lines. Grey-on-white placeholder text and pale secondary buttons fail routinely.

    Focus indicators must be visible. Removing the outline because it looks untidy is the single fastest way to make a site unusable by keyboard. WCAG 2.2 asks for more than visibility at level AAA, but at AA the practical rule is simple: never ship outline: none without a replacement that is at least as clear.

    Motion deserves the same discipline. Respect prefers-reduced-motion, avoid autoplaying video with sound, and give users a way to pause anything that moves for more than five seconds.

    Semantics before ARIA

    The first rule of ARIA is not to use ARIA. A <button> element is focusable, announces itself correctly, and responds to Enter and Space without any extra work. A <div> with role="button" and a click handler is not keyboard operable until you add tab index, key handling and focus styles — and most implementations forget at least one.

    Use native elements first: button, a, label, fieldset, details, dialog. Reach for ARIA only when no native element expresses the pattern, and never to patch a structure that could simply be corrected.

    Structure carries most of the weight. One <h1> per page. Headings that nest in order. Landmarks — header, nav, main, footer — so screen reader users can jump between regions. A <main> element is what makes a "skip to content" link meaningful.

    Images need alternative text that serves the same purpose as the image. Decorative images take an empty alt="". Charts and infographics need a text summary, not a list of colours.

    Forms are where most conversions quietly leak

    Forms combine every hard accessibility problem at once: labelling, ordering, error handling and timing.

    Every input needs a programmatically associated label — a <label for> or a wrapping label, not a placeholder standing in for one. Placeholders disappear on input and are poorly supported by some assistive technology.

    Errors must be described in text, tied to the field with aria-describedby, and announced when they appear. Say what went wrong and what to do: "Enter a postcode in four digits" beats "Invalid input". Where a field expects a known format — email, phone, address — the autocomplete attribute lets browsers and password managers fill it, which helps everyone.

    Group related controls. Radio buttons for delivery options belong in a fieldset with a legend, not floating in a div.

    Testing that finds real problems

    Automated checkers are useful and insufficient. They reliably catch missing alt attributes, insufficient contrast, unlabelled inputs and duplicate IDs. They cannot judge whether alt text is meaningful, whether the reading order makes sense, or whether a flow is understandable.

    A workable routine for a small product team:

    1. **Keyboard pass.** Put the mouse away. Tab through the primary journey — search, product page, cart, checkout. Can you see where you are at every step? Can you complete the purchase?

    2. **Screen reader pass.** NVDA with Firefox on Windows is free. VoiceOver with Safari covers Apple devices, and TalkBack covers Android. Listen to one flow end to end and note where the announcement stops making sense.

    3. **Zoom and reflow.** Set browser zoom to 200% and check that content does not overlap or require horizontal scrolling.

    4. **Automated scan.** Run axe DevTools or Lighthouse on the main templates. Lighthouse scores are a rough signal, not a conformance result.

    5. **Assistive input.** Try voice control and switch access on the checkout if you can. This catches target-size and labelling issues quickly.

    Record findings per template rather than per page. Most failures repeat across every product page, and a fix in the component library resolves hundreds of instances at once.

    What the European Accessibility Act requires — and where Norway stands

    The European Accessibility Act, Directive (EU) 2019/882, has applied since 28 June 2025. It covers a defined list of products and services, and e-commerce is explicitly on it: online shops and marketplaces serving consumers in the EU fall in scope, along with banking services, e-books, transport and audiovisual media access.

    The directive sets functional requirements rather than naming a technical standard. In practice, conformity is presumed when a service meets EN 301 549, the harmonised European standard for ICT accessibility. The current version of that standard incorporates WCAG 2.1 level AA for web content. A revision expected during 2026 is widely anticipated to move to WCAG 2.2.

    There is a microenterprise exemption for services — broadly, firms with fewer than ten staff and a turnover or balance sheet total not exceeding two million euro — but it is narrower than many assume and does not cover larger operators. Penalties are set by each member state.

    Norway adds a second layer, and it is worth getting straight because the two regimes do not yet match. Norwegian private companies have been bound by the IKT regulation (FOR-2013-06-21-732) for years. It points to WCAG 2.0 levels A and AA, minus three criteria on audio description and live captions, which works out to 35 requirements. Existing sites had to comply by 1 January 2021. Public sector bodies follow EN 301 549 and therefore WCAG 2.1 AA.

    The EAA has not yet been incorporated into Norwegian law through the EEA process. That gap will close, and when it does the bar rises. Building to WCAG 2.1 AA now, with WCAG 2.2's new criteria handled where they are cheap to handle, is the pragmatic position for a Norwegian shop that also sells into the EU.

    Putting it into the delivery process

    Accessibility fails when it is treated as a final audit. It holds when it is embedded in the artefacts a team already uses.

    • **Design system.** Bake in focus states, minimum target sizes, contrast-checked colour tokens and form patterns. Designers should not have to rediscover these per screen.
    • **Definition of done.** Add three lines to the ticket template: keyboard operable, labelled, and checked at 200% zoom.
    • **Pull request checks.** Lint for missing alt attributes and enforce accessible names on interactive components. Automated rules in CI catch regressions cheaply.
    • **Procurement.** When buying a booking engine, payment widget or chat tool, ask for an accessibility conformance report — often supplied as a VPAT — and test the embedded flow yourself. Third-party components inherit none of your good intentions.

    A realistic starting point

    If you do nothing else this quarter, do these four things: restore visible focus styles everywhere, raise contrast on body text and buttons, make the checkout completable by keyboard alone, and run one screen reader session with a real user or a colleague who has never seen the page.

    Those steps fix the failures that stop people buying. The rest — the new 2.2 criteria, the documentation, the audits — is easier to sequence once the basics hold.