EU:s tillgänglighetsdirektiv (European Accessibility Act, EAA) gäller sedan den 28 juni 2025 i alla EU:s medlemsländer. I Sverige genomförs det genom lagen (2023:254) om vissa produkters och tjänsters tillgänglighet. För e-handelsföretag innebär det att din webbplats, kassa och kundservicekanaler måste uppfylla tillgänglighetskrav definierade i WCAG 2.2 AA och den europeiska standarden EN 301 549. Kraven gäller alla företag som säljer produkter eller tjänster till konsumenter online — med undantag enbart för mikroföretag (färre än 10 anställda och under 2 miljoner euro i årsomsattning).
De flesta guider om direktivet förklarar vad det är. Den här guiden fokuserar på vad det innebär för din e-handelsleverans: vilka delar av din sajt som behöver uppmärksamhet, hur plattformsval påverkar efterlevnad, och hur du bygger in tillgänglighet i ditt utvecklingsarbete istället för att fästa det som en engångsgranskning.
Vad direktivet kräver av e-handel
Lagen kräver att e-handelstjänster är uppfattbara, hanterbara, begripliga och robusta — de fyra WCAG-principerna. I praktiken för en e-handelssajt innebär det: alla bilder behöver meningsfulla alt-texter, videor behöver undertexter, hela sajten måste gå att navigera med enbart tangentbord, formulär och kassa måste fungera med skärmläsare, färgkontrast måste uppnå minimikrav, och felmeddelanden måste vara tydliga och programmatiskt kopplade till fälten de avser.
Kraven sträcker sig bortom butiksfronten. Kundservicekanaler måste också vara tillgängliga — erbjuder du livechatt måste den fungera med hjälpmedel. PDF-dokument som orderbestämningar och fakturor bör vara tillgängliga. E-postmeddelanden som utlöses av sajten bör följa grundläggande tillgänglighetspraxis.
Viktigt: tredjepartskomponenter på din sajt är ditt ansvar. Om din betalningsleverantörs kassawidget, ditt cookie-samtycksbanner eller ditt recensionssystem inte är tillgängligt är det en efterlevnadsbrist på din sajt.
Hur plattformsval påverkar efterlevnad
Din e-handelsplattform ger grunden, men tillgänglighet beror på hur sajten byggs ovanpå.
Shopify-teman har förbättrats avseende tillgänglighet, och Shopifys inbyggda kassa är generellt vältestad mot WCAG. Riskområdet är tredjepartsappar och anpassade temaändringar — var och en behöver tillgänglighetstestning.
Shopware erbjuder en flexibel frontend där tillgänglighet till stor del beror på temaimplementationen. Shopwares standard Storefront-tema täcker grundläggande tillgänglighet, men anpassade teman kräver explicit tillgänglighetsarbete i byggskedet.
Norce med headless frontend (via Frntkey eller egenbyggd) ger full kontroll över HTML-utdata, vilket innebär att utvecklingsteamet äger tillgängligheten helt. Det är både en möjlighet och ett ansvar — det finns ingen plattformsstandard att falla tillbaka på, men heller ingen plattformsbegränsning att arbeta runt.
Magento / Hyvä i sin Hyvä-frontendsvariant producerar ren, lättviktig HTML som ger en bra utgångspunkt för tillgänglig markup. Luma-baserade Magento-teman har ofta fler tillgänglighetsproblem på grund av komplexa JavaScript-drivna UI-komponenter.
Oavsett plattform är de vanliga riskzonerna desamma: specialbyggda navigeringsmenyéer, produktfilter, modalfonster, bildkaruseller och kassaflöden. Dessa interaktiva komponenter behöver explicita ARIA-attribut, tangentbordshantering och fokushantering.
Kassa och betalningstillgänglighet
Kassan är där tillgänglighetsbrister har störst affärspåverkan — en kund som inte kan slutföra ett köp på grund av ett otillgängligt formulär har misslyckats i det sämsta tänkbara ögonblicket.
Centrala krav: varje formulärfält behöver en synlig etikett och en programmatisk koppling (inte bara platshållartext), felmeddelanden måste identifiera problemet och visas nära relevant fält, hela kassan måste gå att genomföra med tangentbord, och val av betalningsmetod måste fungera med skärmläsare. Använder du betalningsleverantörer som Klarna eller Adyen bör deras inbäddade kassawidgets utvärderas för tillgänglighet som del av ditt efterlevnadsarbete.
Innehåll och produktdata
Produktsidor har specifika krav. Varje produktbild behöver beskrivande alt-text — inte bara produktnamnet, utan tillräcklig detalj för att någon som inte kan se bilden ska förstå vad som visas. Produktvideor behöver undertexter. Specifikationstabeller behöver korrekt rubrikmarkup. Storleksguider och jämförelseverktyg måste gå att navigera med tangentbord.
Använder du ett PIM-system bör tillgänglighetsmetadata (alt-text, undertextfält) vara en del av produktdatamodellen från start. Att i efterhand lägga till alt-texter över hundratals eller tusentals produkter är betydligt dyrare än att inkludera det i berikningsflödet från dag ett.
Testning och löpande efterlevnad
Tillgänglighet är inte ett engångsprojekt. Varje ny funktion, varje temaäuppdatering och varje ny tredjepartsintegration kan införa tillgänglighetsproblem. Det hållbara tillvägagångssättet är att bygga in tillgänglighetstestning i utvecklingsarbetet: automatiserade skanningsverktyg (som axe eller Lighthouse) fångar strukturella problem, men manuell testning med tangentbordsnavigering och skärmläsare är nödvändig för att fånga interaktions- och kontextproblem som automatiserade verktyg missar.
PTS (Post- och telestyrelsen) är tillsynsmyndighet i Sverige och kan utreda klagan om otillgängliga e-handelstjänster. Lagen möjliggör sanktioner om bristande efterlevnad inte åtgärdas efter påpekande. Produkter och tjänster som redan var på marknaden före juni 2025 har till 2030 på sig, men allt som lanserats eller väsentligt uppdaterats efter det datumet måste uppfylla kraven omedelbart.
Bygg in tillgänglighet i leveransen
Det mest kostnadseffektiva är att inkludera tillgänglighetskrav i projektet från start — i designfasen (kontrast, typografi, interaktionsmönster), i byggskedet (semantisk HTML, ARIA, tangentbordshantering), i QA (tillgänglighetstestfall parallellt med funktionstester), och i innehållsarbetsflöden (alt-text, rubrikstruktur, klart språk). Att retrofitta tillgänglighet efter lansering kostar typiskt flera gånger mer än att bygga in det, och resultaten är sällan lika bra.
För e-handelsprojekt som redan är live är den praktiska startpunkten en tillgänglighetsgranskning av de mest kritiska användarstigarna: startsida, kategorisidor, produktsidor, sök, varukorg och kassa. Åtgärda de problem med störst påverkan först — de som blockerar användare från att utföra kärnuppgifter — och bygg därifrån.
