Vad innebär EAA och WCAG 2.2 för svenska webbplatser?

European Accessibility Act (EAA) är EU-lagen som sedan 28 juni 2025 kräver att företags digitala tjänster är tillgängliga för personer med funktionsnedsättning, mätt mot WCAG-kriterierna i standarden EN 301 549.

I Sverige heter den lagen om vissa produkters och tjänsters tillgänglighet. Den är inte längre en framtidsfråga. Lagen gäller, tillsynen pågår, och Post- och telestyrelsen har redan namngett de e-handelsbolag den granskar. För er som ansvarar för en webbplats, en app eller en e-handel har frågan flyttat från “vad kommer att hända” till “vad gör vi nu så att vi inte hamnar i nästa tillsynsbatch”.

Varför det spelar roll

De gamla texterna om EAA, våra egna inkluderade, skrev om lagen i framtid. “EAA träder i kraft 2025”, “företag kommer att behöva”. Den vinkeln är överspelad. Lagen trädde i kraft 28 juni 2025, och PTS inledde sin första e-handelstillsyn redan samma höst (källa: PTS, PTS inleder en tillsyn av e-handelstjänster, 2025).

Under 2026 utökade PTS granskningen med ytterligare elva e-handelstjänster, till totalt 28 bolag under planerad tillsyn, bland dem Ellos, Biltema, KappAhl, Apotea, Åhléns, Mathem, Apotek Hjärtat, Kronans Apotek, Hemköp och Coop (källa: PTS, PTS granskar ytterligare 11 e-handelstjänsters tillgänglighet, 2026). Det gör risken konkret. Om de bolagen granskas finns ingen självklar anledning att tro att andra går fria.

Bakom lagkravet finns en marknad. Runt en av fem personer lever med någon form av funktionsnedsättning, och en e-handelskassa som faller på en omöjlig klickyta eller en inloggning med kognitivt pussel tappar de kunderna helt. Tillgänglighet är ett lagkrav, men det är samtidigt en konverterings- och kvalitetsfråga. De två sammanfaller i WCAG 2.2.

För en IT-chef eller webbansvarig är det också en planeringsfråga. Tidigare guider strukturerade EAA runt fem krav på företag: tillgänglig frontend enligt WCAG, tillgänglig produktinformation, tillgänglig kundtjänst och support, en tillgänglighetsredogörelse, och utbildning av personal så att tillgängligheten håller över tid. De kraven gäller fortfarande. Det som har ändrats är att de inte längre är något att förbereda sig inför, utan något att kunna visa upp på begäran. Tillgänglighet har blivit en löpande driftfråga, på samma sätt som informationssäkerhet.

Hur det fungerar

Innan kraven blir konkreta behöver ni veta vilken lag som gäller er, för de två förväxlas ofta. Skillnaden mellan EAA och DOS-lagen är att de träffar olika aktörer trots samma tekniska grund. DOS-lagen, lagen om tillgänglighet till digital offentlig service, gäller offentlig sektor sedan 1 januari 2019 och granskas av DIGG (källa: DIGG, DOS-lagen). EAA-genomförandet gäller privat sektor och vissa konsumenttjänster sedan 28 juni 2025 och granskas av bland andra PTS. En myndighet eller kommun följer alltså DOS-lagen, ett privat bolag följer EAA, men båda mäts mot samma WCAG-kriterier i standarden EN 301 549. Den som driver både offentlig och kommersiell verksamhet behöver hålla reda på båda spåren.

EAA anger funktionella krav men inga tekniska detaljer. Den säger att en tjänst ska vara möjlig att uppfatta, hanterbar, begriplig och robust, men inte exakt hur. Bryggan mellan lagtext och kod är den harmoniserade standarden EN 301 549. Den som uppfyller standarden får presumtion om överensstämmelse: man antas följa lagen tills motsatsen visas (källa: Europeiska kommissionen, Web Accessibility Directive, Standards and harmonisation, 2024–2026).

EN 301 549 i nuvarande version 3.2.1 (mars 2021) bygger på WCAG 2.1 nivå AA, plus krav som går utöver WCAG, exempelvis på hårdvara. Nästa version, 4.1.1, tas fram under standardiseringsmandat M/587 och för in WCAG 2.2. Den väntas under 2026 men är ännu inte publicerad i juni 2026. Det betyder en sak i praktiken: den som bygger mot WCAG 2.1 idag bygger mot en baslinje som är på väg att bytas ut.

Skillnaden mellan WCAG 2.1 och 2.2 är liten i antal men träffsäker i innehåll. WCAG 2.2 lägger till nio nya framgångskriterier ovanpå 2.1 och tar bort ett gammalt, 4.1.1 Parsing, som blivit obsolet (källa: W3C/WAI, What’s New in WCAG 2.2, 5 oktober 2023). De nya kriterierna handlar om precis det som fäller verkliga flöden.

Fem av de nya kriterierna är värda att kunna utan att slå upp dem:

• Target Size (Minimum), 2.5.8, AA. Klickbara ytor ska vara minst 24 gånger 24 pixlar, med undantag när det finns tillräckligt mellanrum runt dem. Det räddar den som klickar på en pekskärm eller med darrig hand.
• Dragging Movements, 2.5.7, AA. Allt som görs med en dra-rörelse ska gå att göra på ett annat sätt också. Reglage och kartor får inte kräva exakt drag.
• Accessible Authentication (Minimum), 3.3.8, AA. Inloggning får inte kräva ett kognitivt test, som att minnas ett lösenord utan hjälpmedel eller lösa ett pussel. Lösenordshanterare och klistra-in måste tillåtas.
• Focus Not Obscured (Minimum), 2.4.11, AA. Det element som har tangentbordsfokus får inte helt döljas av sticky-rubriker eller cookie-banners.
• Consistent Help, 3.2.6, A. Hjälp, kontaktuppgifter och chatt ska ligga på samma ställe på varje sida, inte hoppa runt.

De övriga fyra (2.4.12, 2.4.13 Focus Appearance, 3.3.7 Redundant Entry och 3.3.9) följer samma logik: mindre friktion för den som navigerar med tangentbord, skärmläsare eller begränsat minne.

Så testar och dokumenterar ni

Att hävda att en webbplats är tillgänglig räcker inte. PTS granskar mot WCAG-principerna, och presumtionen om överensstämmelse vilar på att ni faktiskt kan visa att kraven uppfylls. Testningen sker i tre lager.

1. Automatiserad skanning. Verktyg som axe, WAVE eller Lighthouse körs över sajten och fångar kontrastfel, saknade alt-texter, felaktiga rubriknivåer och trasig kodstruktur. Det är snabbt, men automatik fångar bara en del av kriterierna: den vedertagna branschsiffran är att automatiserad testning täcker omkring 20–30 procent av WCAG:s framgångskriterier (källa: Deque, automated-testing-study, 10 mars 2021, som refererar den allmänt vedertagna nivån innan bolaget lanserade sitt eget volymmått på 57 procent). Mätt på antal kriterier ligger alltså taket runt en tredjedel.
2. Manuell granskning. En person går igenom sajten med enbart tangentbord, kontrollerar fokusordning och fokusmarkering, och prövar de nya 2.2-kriterierna för hand: går klickytorna att träffa, fungerar inloggningen utan kognitivt test, döljs fokus av en sticky header. Det här lagret är det som automatiken missar.
3. Test med riktiga hjälpmedel. Sajten används med skärmläsare som NVDA eller VoiceOver, med förstoring och med rösstyrning. Det visar hur tjänsten faktiskt upplevs, inte bara om koden är formellt korrekt.

Resultatet dokumenteras kriterium för kriterium mot EN 301 549. Den dokumentationen är både ert interna åtgärdsunderlag och det ni visar om PTS frågar. Bygg in granskningen i utvecklingsflödet i stället för att lägga den som en slutbesiktning, en brist som fångas i en pull request kostar minuter, samma brist i produktion kostar en åtgärdscykel.

Till dokumentationen hör också en tillgänglighetsredogörelse: en publik beskrivning av hur tjänsten uppfyller kraven, var den eventuellt brister och hur en användare anmäler problem. För offentlig sektor är redogörelsen ett uttalat krav under DOS-lagen, och under EAA förväntas privata aktörer kunna lämna motsvarande information om hur tjänsten fungerar. Att skriva redogörelsen tvingar dessutom fram en ärlig genomgång, det går inte att beskriva en tillgänglighet man inte har testat.

När det passar

Att bygga mot WCAG 2.2 redan nu passar de flesta som äger en publik digital tjänst i Sverige. Det gäller särskilt:

• E-handel och konsumenttjänster som omfattas direkt av EAA och riskerar PTS-tillsyn. Här är 2.2-kriterierna dessutom rena konverteringsfrågor.
• Offentlig sektor, som lyder under DOS-lagen men mäts mot samma standard. Att gå direkt på 2.2 betyder att man slipper en omtagning när EN 301 549 uppdateras.
• Nya plattformsbyggen. När en sajt ändå byggs om är tillgänglighet billigast att få med från grunden, i designsystemet, i komponenterna, i koden, i stället för att klistras på efteråt.

I de fallen är frågan inte om utan hur tidigt. Tillgänglighet inbyggt i designsystemet betyder att varje knapp och formulärfält ärver rätt klickyta, kontrast och fokusmarkering utan att någon behöver komma ihåg det per sida.

När det inte passar

Att jaga full WCAG 2.2 AAA är fel mål för nästan alla. Nivå AAA är W3C:s egen uttalade ambitionsnivå, inte ett rättsligt krav, och flera AAA-kriterier är omöjliga att uppfylla för allt innehåll. EAA och EN 301 549 mäter mot nivå AA. Den som lägger budget på AAA-kriterier innan AA är i hamn lägger den på fel ställe.

Det passar heller inte att behandla en engångsaudit som en slutpunkt. En tillgänglig sajt som får ny funktionalitet varje sprint blir otillgänglig igen om granskningen inte är löpande. Ett grönt testresultat i juni säger lite om läget i december. Tillgänglighet är ett tillstånd man förvaltar, inte en stämpel man får.

Och mikroföretag bör läsa undantaget rätt innan de lutar sig mot det. Undantaget för tjänster gäller företag med under två miljoner euro i omsättning och färre än tio anställda, men det gäller inte produkter, och tröskeln är lägre än många tror (källa: PTS, frågor och svar om tillgänglighetslagen, 2025–2026). Undantaget för oproportionerligt stor börda kräver dessutom en dokumenterad bedömning, inte ett antagande.

Konkret exempel

En svensk e-handel med tusentals artiklar i sortimentet ville veta var den stod inför PTS tillsyn. En granskning mot EN 301 549 visade ett typiskt mönster: kodstrukturen var i grunden god, men de nya 2.2-kriterierna föll. Filtreringen i produktlistan byggde på en dra-reglage utan alternativ, flera “lägg i varukorg”-knappar på mobil var under 24 pixlar, och inloggningen krävde att man manuellt skrev av en kod, ett kognitivt test som 3.3.8 underkänner.

Inget av det var dramatiskt att rätta var för sig. Det dramatiska var att alla tre satt i kassaflödet, där varje brist kostar i både compliance och konvertering. Åtgärderna gjordes i designsystemets komponenter, vilket innebar att rättningen slog igenom på hela sajten samtidigt, inte sida för sida.

Vi bygger tillgänglighet in i processen i stället för att granska in den efteråt: kunskap förs löpande från designers till utvecklare, och tillgänglighetskraven står med i briefen från start i stället för att granskas in på slutet. Mönstret som granskningar mot EN 301 549 brukar visa är att det inte är kodstrukturen som fäller en sajt, utan de nya 2.2-kriterierna kring klickytor, dra-rörelser, inloggning och fokus, precis de krav som är lätta att missa utan en manuell genomgång. Som generell kvalitetsmarkör mäter vi oss i resultat: NPS 61, och en ISO 42001-certifierad ledningsprocess där tillgänglighet är del av kvalitetsarbetet, inte en sidoaktivitet.

Vanliga missförstånd

“WCAG 2.2 är en helt ny standard vi måste lära om.” WCAG 2.2 är ett påbyggnadssteg på 2.1, inte en omskrivning. Allt som redan uppfyller 2.1 ligger kvar, ni lägger till nio kriterier och tar bort ett. Den som redan arbetar mot 2.1 har det mesta gjort och behöver fokusera på de nya kraven kring klickytor, drag, inloggning och fokus.

“Vi klarar oss eftersom ett automatiskt verktyg ger grönt.” Automatiska verktyg fångar bara en del av kriterierna och kan aldrig avgöra om en bild har meningsfull alt-text eller om tangentbordsordningen är logisk. Ett grönt resultat i axe eller Lighthouse är en bra start, inte ett bevis på överensstämmelse. Den manuella granskningen och testet med hjälpmedel är det som avgör.

“EAA gäller bara stora bolag.” Lagen utgår från vilken typ av produkt eller tjänst ni erbjuder konsumenter, inte i första hand från storlek. Undantaget för tjänster gäller mikroföretag, men tröskeln är låg och undantaget täcker inte produkter. En liten e-handel kan mycket väl omfattas fullt ut.

Tillgänglighet mäts till sist inte i en stämpel utan i om en människa med skärmläsare kan slutföra köpet, och det är samma sak som avgör om er kassa konverterar för alla andra.