Web accessibility has gone from pleasant ambition to sharp business requirement. Since the EU's accessibility directive (European Accessibility Act) became Swedish law and began to be applied on June 28, 2025, most people who sell or inform digitally need to be able to show that their services work for people with disabilities. The technical bar isWCAG- Web Content Accessibility Guidelines - and the current version isWCAG 2.2, published as a W3C Recommendation on 5 October 2023.
This guide is written for you who are actually going to build or order an accessible website. We go through how WCAG fits together, which criteria carry the most weight, what WCAG 2.2 added, the mistakes we see over and over again – and a checklist you can act on immediately.
This is how WCAG is structured: POUR and three levels
WCAG rests on four principles which are usually abbreviatedPOUR: content should bePerceivable(possible to perceive),Operable(manageable),Understandable(understandable) andRobust(robust, i.e. work with different techniques and aids). Under the principles are guidelines, and under them the concrete onesthe success criteriawhich can actually be tested.
Each criterion has a level:A(basic),AA(the normal target) orAAA(highest ambition). In practice isAAthe level almost everyone aims for – it is also the level from which the European standard EN 301 549 and accessibility legislation are based. AAA is rarely a reasonably comprehensive requirement, but individual AAA criteria may be worth meeting where they make a significant difference.
An important feature: WCAG 2.2 is backward compatible. If you meet 2.2 on one level, you also meet 2.1 and 2.0 on the same level. So you don't have to choose between the versions - 2.2 is the one that applies going forward.
The most important success criteria in practice
There are dozens of criteria, but a handful account for a disproportionate amount of the real difference for users. Start here.
Text options and contrast (Perceivable)
1.1.1 Non-text content (A):all images, icons and graphics that carry meaning need a text option. Purely decorative images should instead be hidden from screen readers with empty alt text.
1.4.3 Contrast (minimum) (AA):normal text needs a contrast ratio of at least 4.5:1 against the background, large text at least 3:1. This is one of the most frequently failed criteria.
1.4.11 Contrast for non-text (AA):even buttons, form field borders and focus markers need at least 3:1 contrast – not just the body text.
Keyboard and navigation (Operable)
2.1.1 Keyboard (A):everything that can be done with a mouse should be done with just a keyboard. No traps where the focus gets stuck.
2.4.7 Visible focus (AA):it should always be visible where the keyboard focus is. Removing the focus ring with CSS without replacement is a classic and serious mistake.
2.4.3 Focus order (A):the tab order should follow a logical, understandable sequence that matches the visual layout.
Comprehensibility and forms (Understandable)
3.3.1 Identify faults (A) and 3.3.2 Labels or instructions (A):form fields should have clear, programmatically linked labels, and errors should be described in text – not just in red.
3.2.3/3.2.4 Consistent Navigation and Identification (AA):recurring elements must lie and behave the same on different pages.
What WCAG 2.2 added: nine new criteria
WCAG 2.2 addednine new success criteria(two at level A, four at AA and three at AAA) and at the same time removed the old criterion4.1.1 Parsing, which has become redundant as modern browsers and tools handle broken HTML markup on their own. The new criteria focus on motor skills, cognition, low visual acuity and authentication. These deserve special attention as they are often missed in older accessibility works:
2.4.11 Focus not hidden (minimum) (AA):when an element gets keyboard focus, it must not be completely hidden behind e.g. a sticky header or a cookie banner.
2.5.7 Drag movements (A):features that rely on dragging (sliders, maps, drag-and-drop) must have a simpler alternative with a single touch action, e.g. buttons.
2.5.8 Size of target (minimum) (AA):click areas must be at least 24×24 CSS pixels, or have sufficient distance to adjacent targets. Important for small links and densely packed icons.
3.2.6 Consistent help (A):help functions (contact link, chat, phone number) that return must be in the same relative order on all pages.
3.3.7 Repeated input (A):information the user already entered in a flow should not have to be re-entered - fill in automatically or let it be selected.
3.3.8 Available Authentication (Minimum) (AA):login must not require a cognitive memory test. Allow e.g. pasting passwords, password managers or a link via e-mail instead of difficult puzzles.
The three new AAA criteria are2.4.12 Focus not hidden (improved), 2.4.13 Focus Appearance(requirements for the size and contrast of the focus mark) as well as3.3.9 Accessible Authentication (Enhanced).
The most common mistakes
After many reviews, the pattern is clear. It's rarely exotic problems that bring down a website - it's the same recurring basic mistakes:
Contrast too low.Light gray text on a white background and decorative "design colors" on buttons are the single most common disapproval.
Removed focus marker. outline: nonein CSS without a replacement, visible focus style renders the site unusable for keyboard users.
Images without meaningful alt text- either completely missing, or meaningless like "bild1.jpg", or on the contrary alt-text on purely decorative images which then litters the screen reader experience.
Forms without attached labels.Placeholder text is not a label - it disappears when you start typing and often has too little contrast.
Errors that are only signaled by color.A red field means nothing to those who do not see red; the error must also be described in text.
Clickable "divs" instead of real buttons and links.It violates both keyboard and robustness requirements because accessibility doesn't understand what the element is.
Incorrect heading structure.Heading levels (h1-h6) used for appearance instead of hierarchy cause screen reader users to lose the overview.
Overconfidence in overlay.Automatic "accessibility widgets" do not solve underlying code problems and at worst can interfere with accessibility. They never replace actually available code.
Concrete checklist for an accessible website
Use this list as a practical starting point towards level AA. It doesn't replace a full review, but captures most of what really matters:
Structure:one h1 per page, logical heading hierarchy, semantic elements (nav, main, header, footer) and clear landmarks.
Keyboard:navigate the entire site using only Tab, Enter and arrow keys. Check that focus is always visible and never stuck.
Focus and 2.2:ensure that focused elements are not hidden by sticky elements or banners (2.4.11) and that the focus marker has good contrast.
Contrast:measure text (4.5:1), large text (3:1) and interface components (3:1). Also test hover and focus conditions.
Images and media:meaningful alt text on informative images, empty alt on decorative ones, subtitles on video and transcript on audio.
Form:visible labels linked with for/id, descriptive error messages in text, and no mandatory repetitions of already specified data (3.3.7).
Click surfaces:at least 24×24 px for buttons, icons and links in dense layout (2.5.8), and pointer options for all drag gestures (2.5.7).
Login:allow password manager and pasting; avoid CAPTCHAs that require memory or complex interpretation (3.3.8).
Content:clear language, descriptive link texts (not "click here") and consistently placed help on all pages (3.2.6).
Tools and people:supplement automated tests (eg ax or Lighthouse) with manual keyboard testing and, ideally, testing with real screen reader users. Automation only catches a small part of the problems.
The link to the law – short
The EU's accessibility directive was implemented in Sweden through the law on the accessibility of certain products and services, which has been applied since 28 June 2025. It affects, among other things, e-commerce, banking services, e-books and digital consumer services, while the smallest micro-enterprises for services are exempt. The practical interpretation of the requirements takes place via the European standardEN 301 549, which in its current harmonized form points to WCAG level AA. An upcoming revision of EN 301 549 is expected to refer to WCAG 2.2, and since 2.2 is backwards compatible, it is already the sensible target to build towards. Working towards WCAG 2.2 AA is therefore both future-proof and in line with the spirit of the law - but exactly what is required in your case depends on the type of service you run and which exceptions may apply.
Summary
In the end, accessibility is not a checklist you tick off once, but a quality work you build into design, code and content. What wins the most are often the least glamorous things: adequate contrast, visible focus, real buttons, linked labels and clear language. If you get these right, you will have both happier users and a website that stands firmly against the requirements.
If you want to know where your existing website stands - or build a new one with built-in accessibility from the start - ZORC helps you with everything from review to finished solution. Describe your project this springquote calculatorthen we will get back with a concrete plan, or contact you viacontact.
