Tillgänglighetslagen: så kontrollerar du din webbplats själv

Säljer du på nätet till konsumenter i EU gäller kraven på webbplatser i European Accessibility Act, i Sverige tillgänglighetslagen, för din butik sedan den 28 juni 2025, om inte ditt företag är ett mikroföretag. Många av de allvarliga problemen hittar du själv: lägg en testbeställning med bara tangentbordet, zooma in sidan och prova varje formulär. Det en egen kontroll inte kan göra är att bevisa att hela webbplatsen uppfyller standarden.

Kanske har en utvecklare nämnt lagen, eller så har du fått ett mejl som erbjuder en widget som gör vilken webbplats som helst ”laglig” med en enda rad kod. En kund som inte tar sig igenom din kassa med tangentbordet eller med en skärmläsare (programvara som läser upp sidan) kan gå till en annan butik utan att klaga.

Gäller tillgänglighetslagen din webbplats?

European Accessibility Act gäller om din webbplats säljer till konsumenter, alltså personer som köper för egen räkning, och ditt företag inte är ett mikroföretag. Direktiv (EU) 2019/882 räknar upp e-handelstjänster bland de tjänster det omfattar: tjänster som erbjuds via en webbplats eller en app ”i syfte att ingå ett konsumentavtal”. Länderna skulle tillämpa reglerna från den 28 juni 2025. Det här är vår läsning av direktivet; för en juridisk bedömning av just ditt fall, fråga en jurist.

• Mikroföretag som tillhandahåller tjänster är undantagna. Det är artikel 4.5. Direktivet definierar ett mikroföretag som ett företag med färre än 10 personer och en årsomsättning eller en årlig balansomslutning på högst 2 miljoner euro. Både antalet personer och ett av de två ekonomiska villkoren räknas: ett team på tio personer omfattas inte av undantaget, hur liten omsättningen än är.
• Försäljning bara till företag. Definitionen handlar om konsumentavtal. Om privatpersoner kan beställa i din kassa, utgå från att webbplatsen omfattas.
• En webbplats som inte säljer något. En företagswebbplats utan beställningar, bokningar eller betalningar är i regel inte en e-handelstjänst enligt direktivets definition. Bokningar och betalningar ändrar det.
• Datumet 2030 gäller produkter och gamla avtal. Övergångsperioden till den 28 juni 2030 i artikel 32 gäller produkter som används för att tillhandahålla en tjänst och avtal som ingåtts före juni 2025.

Varje EU-land genomdriver lagen genom sin egen lagstiftning och bestämmer sina egna sanktioner; i Tyskland är den lagen BFSG. Om ditt företag finns i Schweiz eller Storbritannien och säljer till konsumenter i EU, fråga en jurist hur de ländernas regler gäller för dig.

Varför klarar butikswebbplatser inte tillgänglighetskontroller?

Felen nedan kommer oftast från design- och formulärbeslut som fattats en gång i ett tema och upprepas på varje sida. Direktiv (EU) 2019/882 kräver webbplatser som är ”möjliga att uppfatta, hanterbara, begripliga och robusta”. Den europeiska standard som gör om detta till tester, EN 301 549, följer WCAG, riktlinjerna för tillgängligt webbinnehåll som W3C publicerar. WCAG delar in sina kriterier i tre nivåer: A (miniminivån), AA och AAA. Nivå AA är det mål standarden använder.

Fokusmarkeringen togs bort för utseendets skull. När någon rör sig genom en sida med Tab-tangenten ritar webbläsaren en ram runt den aktiva länken eller knappen. Vissa teman döljer den för att den ser rörig ut, trots att WCAG kräver en synlig fokusindikator. Ett kriterium som tillkom i WCAG 2.2 säger också att elementet med fokus inte får döljas helt av webbplatsens eget innehåll, som en fast sidhuvudlist eller en cookiebanner.

Texten är för blek. WCAG kräver ett kontrastförhållande, alltså hur mycket mörkare eller ljusare texten är än bakgrunden, på minst 4,5:1 för normal text och 3:1 för stor text. WebAIM:s genomgång 2026 av en miljon startsidor hittade text med låg kontrast på 83,9 % av dem. Ljusgrått på vitt och vitt på en pastellfärgad knapp är de vanliga fallen.

Formulären förlitar sig på platshållartext och färg. En grå ledtext i ett fält försvinner så fort du skriver, och en röd kant ensam säger inte vad som är fel. WCAG kräver etiketter eller instruktioner överallt där något ska fyllas i, och fel som beskrivs i text.

Kassan byggdes för en mus. Egenbyggda rullgardinsmenyer, pussel-CAPTCHA och inloggningar som kräver att du minns eller skriver av en kod stoppar personer som använder tangentbord eller skärmläsare. Direktivet nämner identifiering, säkerhet och betalning separat för e-handel. I mars 2026 rapporterade den nederländska konsumentmyndigheten ACM att det hos 61 % av de stora nederländska webbutiker och andra stora konsumentwebbplatser som den granskat inte gick att lägga en beställning med hjälpmedel som en skärmläsare.

En widget eller en poäng får ersätta åtgärden. Overlay-widgetar lägger ett tillgänglighetsverktygsfält ovanpå webbplatsen. Europeiska kommissionen säger att overlays och liknande verktyg som inte gör att själva webbplatsen uppfyller standarden ”inte är en lämplig lösning”. Ett automatiskt test hjälper, men med W3C:s ord: ”inget verktyg kan på egen hand avgöra om en webbplats uppfyller tillgänglighetsstandarder.”

Så gör du en tillgänglighetskontroll av din webbplats själv

En första genomgång kan du göra med en webbläsare och ett tangentbord, utan betalda verktyg. W3C, organisationen bakom WCAG, publicerar en uppsättning enkla tester, Easy Checks, som bygger på just den idén. Välj tre sidor: startsidan, en produkt- eller tjänstesida och kassan eller kontaktformuläret. Gå igenom dem i ordning och skriv ner varje ställe där du fastnar.

1. Lägg undan musen. Gå igenom varje sida med Tab och Skift+Tab, och använd Enter, mellanslag och piltangenterna. Du ska nå menyn, filtren, knappen för att lägga i varukorgen, varje formulärfält och betalknappen. Du ska hela tiden kunna se var du är. Notera var ramen försvinner bakom en fast sidhuvudlist eller en cookiebanner, och om du kan ta dig ur en meny eller ett chattfönster.
2. Zooma in. Ställ webbläsaren på 200 %. WCAG förväntar sig att texten förblir läsbar utan att innehåll klipps av eller överlappar. Gör sedan fönstret ungefär 1 280 pixlar brett och zooma till 400 %: innehållet ska rymmas på bredden utan sidledsrullning, utom sådant som kartor och datatabeller.
3. Kontrollera den bleka texten. Utvecklarverktygen i Chrome, Edge och Firefox visar kontrastförhållandet för en vald textfärg. Kontrollera brödtext, priser, knappar och den lilla grå texten under formulärfälten.
4. Skicka varje formulär tomt och sedan fel ifyllt. Varje fält behöver en synlig etikett som finns kvar när du skriver. Skicka formuläret tomt: felet ska med ord säga vad som saknas, stå vid fältet och behålla det du redan skrivit. Ett nytt kriterium i WCAG 2.2 kräver också att uppgifter du redan angett i samma process, som en adress, fylls i automatiskt eller erbjuds som val. Fler sätt ett formulär kostar dig beställningar finns i vår artikel om trafik på webbplatsen men inga förfrågningar.
5. Logga in och ta dig förbi skräppostskyddet. WCAG 2.2 säger att inloggning inte får hänga på ett test av kognitiv förmåga, som att minnas ett lösenord eller lösa ett pussel, om det inte finns ett alternativ eller hjälp, som en lösenordshanterare eller att klistra in. En pussel-CAPTCHA utan annat alternativ klarar sig inte här.
6. Titta på produktbilderna. Högerklicka på en bild och välj Inspektera. Alt-texten, den korta beskrivning som en skärmläsare läser upp, ska säga vad produkten är; rent dekorativa bilder kan ha en tom alt-text.
7. Upprepa de viktigaste stegen på mobilen. Små ikoner tätt ihop är svåra att träffa. WCAG 2.2 anger en minsta målstorlek på 24 gånger 24 CSS-pixlar (en storleksenhet i själva webbsidan), med undantag som tillräckligt med utrymme runt målet.

W3C påpekar att en sida ”kan verka klara de här kontrollerna men ändå ha betydande tillgänglighetshinder”. Nästa steg är ett test av någon som använder skärmläsare varje dag.

Vad ska du åtgärda först?

Börja med åtgärder i temat och formulärkomponenterna, från billigast till dyrast. En ändring i en mall rättar varje sida som bygger på den. Vänta med den publicerade tillgänglighetsinformationen tills du vet vad webbplatsen klarar och inte klarar.

1. Installera ingen overlay. Europeiska kommissionens råd är att åtgärda tillgänglighetsproblem ”vid källan”, vilket för en butik betyder temat, formulären och kassan.
2. Ta tillbaka fokusramen och gör texten mörkare. Båda finns oftast i temats färg- och stilinställningar. Vi börjar med att ställa in kontrasten en gång i designpaletten och kontrollera den i den ljusa och mörka versionen av webbplatsen, så att en ny sida utgår från färger som redan klarar kraven.
3. Bygg om formulären. Synliga etiketter, fel i ord vid fältet, inskrivna uppgifter som finns kvar efter ett fel, fokus som flyttas till det första fältet som behöver rättas och webbläsarens autofyll för namn, e-post och adress. I våra webbplatsprojekt börjar vi med själva formulärkomponenten, så att varje nytt formulär har de här åtgärderna från start.
4. Lägg till alt-texter och sidans språk. Beskriv produkt- och innehållsbilder och se till att varje sida anger sitt språk, så att en skärmläsare uttalar texten rätt. Sökmotorer läser samma alt-text och språkattribut, och därför hör de också hemma i teknisk SEO.
5. Åtgärda kassa, inloggning och tredjepartswidgetar. Byt ut pussel-CAPTCHA mot kontroller som inte kräver att kunden löser något, och erbjud ett sätt att logga in som inte hänger på minnet. Betal- och chattwidgetar kommer från leverantörer: be varje leverantör om dess tillgänglighetsinformation och byt ut de widgetar som inte går att nå med tangentbordet.
6. Publicera din tillgänglighetsinformation. Bilaga V till direktivet kräver att tjänsteleverantörer beskriver hur tjänsten uppfyller kraven, i de allmänna villkoren eller ett motsvarande dokument. Din nationella lag bestämmer detaljerna.
7. Arbeta mot WCAG 2.2 nivå AA. EN 301 549 version 4.1.1, publicerad i september 2026, lägger till sex krav från WCAG 2.2, rapporterar AccessibleEU. Tills kommissionen hänvisar till den i Europeiska unionens officiella tidning gäller, enligt samma källa, version 3.2.1 som referens, och den bygger på WCAG 2.1 nivå AA. Irlands National Disability Authority räknar med hänvisningen den 16 december 2026. Om du åtgärdar enligt WCAG 2.2 redan nu är de nya kraven täckta när det sker.

Direktivet tillåter ett undantag när efterlevnad skulle vara en oproportionerlig börda, men det kräver en bedömning, och skälen i direktivet anger att ”brist på prioritet, tid eller kunskap” inte är ett legitimt skäl.

Vad ska du mäta efter åtgärderna?

Mät om en person kan slutföra de viktigaste uppgifterna med tangentbord och inzoomad sida. Upprepa samma tillgänglighetskontroll på samma tre sidor och jämför var du fastnade före och efter ändringarna. Kontrollera igen varje gång temat, ett tillägg eller betalleverantören byts.

1. En testbeställning med bara tangentbordet, från produktsidan till bekräftelsen, utan att röra musen.
2. Listan med fynd från ett gratis automatiskt test, som Lighthouse i Chrome, kört på samma tre sidtyper. Gå igenom fynden och kontrollera vilka som finns kvar.
3. Formulär som skickas med fel, för att bekräfta att varje fel beskrivs i ord och att inget du skrivit försvinner.
4. Din publicerade tillgänglighetsinformation, uppdaterad efter varje ändring som påverkar hur kunder beställer.

Där vi kommer in

När vi tittar på en butiks kassa följer vi den väg en kund tar: produktsidan, varukorgen, formulären och betalsteget, först med tangentbordet, sedan på mobilen. Problem som sitter i temat eller formulärkomponenterna är billigast att åtgärda där; det en egen kontroll inte kan avgöra lämnar vi till ett test med skärmläsare. Vill du att någon tittar en gång till på din kassa, berätta om din webbplats.

← Alla artiklar