Tillgänglighet är inte längre valfritt: EAA och din e-handel

European Accessibility Act började tillämpas den 28 juni 2025 — och din webbutik är med på listan. Här är vad som faktiskt krävs, var det oftast brister, och varför en modulär frontend gör jobbet enklare.

Du har byggt en e-handel som konverterar. Snabb kassa, snygga produktbilder, ett flöde som teamet finslipat i åren. Och så kommer en regulatorisk deadline och frågar något som sällan stått på roadmappen: fungerar allt detta för en kund som navigerar med tangentbord, skärmläsare eller hög kontrast?

För de flesta nordiska webbutiker är svaret idag delvis nej. Och sedan den 28 juni 2025 är det inte längre en kvalitetsfråga utan en lagfråga.

Vad EAA faktiskt kräver — och från när

European Accessibility Act, i Sverige implementerad genom lagen om vissa produkters och tjänsters tillgänglighet, började tillämpas den 28 juni 2025 [källa: https://pts.se/digital-inkludering/lagen-om-vissa-produkters-och-tjansters-tillganglighet/]. Direktivet omfattar uttryckligen e-handel — alltså webbplatser och appar där du säljer varor eller tjänster till konsument [källa: https://www.appli.se/news/sa-paverkas-din-e-handel-av-det-nya-eu-direktivet-om-tillgaenglighet-n202].

Den tekniska ribban är inte ny. Lagen lutar sig mot den europeiska standarden EN 301 549, som i sin tur bygger på WCAG 2.1 nivå AA [källa: https://en.wikipedia.org/wiki/European_Accessibility_Act]. WCAG har funnits i åratal. Det nya är att efterlevnad nu är skarp, med tillsyn och sanktionsmöjligheter snarare än goodwill.

Två saker är värda att vara exakt med:

• Undantaget för mikroföretag gäller tjänster, inte allt. Företag med färre än 10 anställda och en årsomsättning under 2 miljoner euro kan undantas vad gäller tjänster [källa: https://en.wikipedia.org/wiki/European_Accessibility_Act]. Exakt hur det landar för just ditt bolag — och om din verksamhet räknas som tjänst eller produkt i lagens mening — är en bedömning du bör verifiera. [BEKRÄFTA]

• Den exakta sanktionsnivån och tillsynsupplägget styrs av svensk lag och tillsynsmyndigheter, med PTS som marknadskontrollmyndighet [källa: https://pts.se/digital-inkludering/lagen-om-vissa-produkters-och-tjansters-tillganglighet/]. Det kringgår inte teknikfrågan, men avgör konsekvensen av att inte agera. [BEKRÄFTA]

Poängen är enkel. Kravet finns redan. Frågan är hur långt din butik är från det.

De brister vi ser oftast i webbutiker

Tillgänglighet låter abstrakt tills man öppnar konsolen. I praktiken handlar det om en handfull återkommande problem som sällan syns för en seende musanvändare men stoppar någon annan helt.

• Otillräcklig kontrast. Ljusgrå text på vit bakgrund, eller en CTA-knapp vars färg ser fin ut i designsystemet men faller under WCAG:s kontrastkrav.

• Tangentbordsnavigering som inte fungerar. Kassan går inte att slutföra utan mus. Fokusringen är bortstylad. Tab-ordningen hoppar oförutsägbart mellan element.

• Saknad eller meningslös alt-text. Produktbilder utan beskrivning, eller alt-text som lyder "image_4823.jpg". En skärmläsaranvändare får då ingen aning om vad produkten är.

• Formulär utan kopplade etiketter. Fält där placeholder används istället för label, valideringsfel som bara visas med röd färg, och inget som annonseras till hjälpmedel.

• Dynamiskt innehåll som är tyst. Lägg-i-varukorg-bekräftelser, filterresultat och felmeddelanden som uppdateras i DOM:en utan att meddelas via ARIA.

Det fina — och det jobbiga — är att inget av detta kräver en omdesign. Det kräver disciplin i komponenterna. Vilket leder oss till arkitekturen.

Varför en modulär frontend gör WCAG enklare att nå

Här blir det tekniskt intressant. På en monolitisk plattform är frontend ofta sammanvävd med affärslogik och tema. Vill du fixa fokushantering i kassan får du röra vid kod som också styr betalning, och varje ändring är en risk. Tillgänglighet blir då ett projekt, inte en egenskap.

En modulär, headless frontend vänder på det. När presentationslagret är frikopplat från Norce Commerce och du bygger gränssnittet i komponenter, kan tillgänglighet byggas in en gång — på rätt nivå — och sedan återanvändas.

• En knapp-komponent som är korrekt fokuserbar och kontrastsäker gör varje knapp i butiken compliant.

• Ett formulärfält med kopplad label och annonserad validering gör varje formulär compliant.

• Innehåll från Storyblok kan struktureras så att redaktörer tvingas fylla i alt-text — tillgänglighet flyttas uppströms, in i redigeringsflödet, istället för att lappas i efterhand.

Det är precis den separationen Callisto bygger på: Norce Commerce som handelsmotor, Voyado för kunddata och lojalitet, Storyblok som innehållslager, och en frontend där tillgänglighet är en egenskap hos komponentbiblioteket snarare än en eftertanke. När ribban höjs igen — och WCAG 2.2 ligger redan och väntar — uppdaterar du komponenten, inte hela butiken.

Tillgänglighet är affärsnytta, inte bara compliance

Det vore lätt att behandla EAA som en kostnad att minimera. Det vore ett misstag.

Allt som gör en butik tillgänglig gör den också bättre för alla. Tydligare kontrast hjälper kunden som handlar i solljus på mobilen. En kassa som fungerar med tangentbord är en kassa med färre buggar. Strukturerad, semantisk HTML som skärmläsare förstår är samma HTML som Google läser — tillgänglighet och teknisk SEO drar åt samma håll.

Och så finns det marknaden. En betydande andel av befolkningen har någon form av funktionsnedsättning som påverkar hur de använder webben. Det är kunder med köpkraft som idag lämnar butiker som inte fungerar för dem, oftast utan att höra av sig. Du ser bortfallet som en konverteringssiffra, aldrig som ett klagomål.

Vi har sett hos kunder som Nordiska Galleriet och Elcykelpunkten att en frontend byggd på rena, återanvändbara komponenter inte bara klarar regelverk lättare utan presterar bättre i vardagen. Compliance blir en biprodukt av att bygga rätt. [BEKRÄFTA: kundspecifik formulering]

Checklista: kom igång före nästa tillsyn

Du behöver inte lösa allt på en gång. Du behöver en ordning.

1. Gör en baslinjemätning. Kör en automatiserad granskning mot WCAG 2.1 AA och komplettera med ett manuellt tangentbords- och skärmläsartest av dina viktigaste flöden.

2. Prioritera köpresan. Produktsida, varukorg och kassa först. Det är där bristerna kostar pengar och där tillsyn tittar.

3. Fixa i komponenten, inte i sidan. Åtgärda kontrast, fokus och etiketter på komponentnivå så att rättningen sprider sig av sig själv.

4. Flytta alt-text uppströms. Gör beskrivande alt-text till ett obligatoriskt fält i Storyblok så att problemet inte återuppstår med nästa kampanj.

5. Verifiera din juridiska omfattning. Stäm av undantag, klassning och sanktionsrisk för just ditt bolag med någon som kan svensk implementering. [BEKRÄFTA]

6. Bygg in regression. Lägg tillgänglighetstester i din CI så att en framtida deploy inte tyst river det du nyss fixat.

Den verkligt obekväma frågan är inte om din butik klarar en granskning idag. Det är hur dyr varje framtida ändring blir om tillgängligheten sitter inbakad i en monolit istället för i ett komponentbibliotek du faktiskt äger. Regelverket kommer att skärpas igen. Arkitekturen avgör om det blir en patch eller ett projekt.

Vill du veta var din e-handel står mot EAA — och hur en pre-composed frontend gör nästa höjning av ribban till en uppdatering istället för en ombyggnad? Vi tittar gärna på det med dig.