Checklista för webbtillgänglighet: små företag och webbutiker

Tänk dig en kund som använder skärmläsare. Hen hittar löparskorna hen vill ha, väljer storlek och trycker på det hen tror är knappen för varukorgen. Skärmläsaren säger ”knapp”. Inget mer. Det finns tre sådana på sidan och ingen av dem har något namn, så kunden lämnar, och du får aldrig veta varför.

De flesta tillgänglighetsproblem på små företags webbplatser ser ut så: osynliga för ägaren, en återvändsgränd för kunden. Den här checklistan är för dig som driver en webbplats i Shopify, WooCommerce, Wix eller Squarespace utan en utvecklare i personalen.

Måste mitt lilla företags webbplats vara tillgänglig?

Säljer du till konsumenter i EU är svaret troligen ja. Tillgänglighetsdirektivet (öppnas i en ny flik) har omfattat e-handelstjänster sedan den 28 juni 2025. Det viktigaste undantaget gäller mikroföretag som tillhandahåller tjänster: företag med färre än 10 anställda och en årsomsättning eller balansomslutning på högst 2 miljoner euro. I Sverige finns undantaget i 10 § lag (2023:254).

E-handel betyder här försäljning på distans, via en webbplats eller app, ”på individuell begäran av en konsument i syfte att ingå ett konsumentavtal” (artikel 3.30). En webbutik eller en bokningsmotor passar in. Undantaget gäller bara tjänster: den som säljer produkter som omfattas, till exempel läsplattor, har fortfarande krav på produkterna (artikel 4.5). Att ligga utanför EU hjälper inte heller, eftersom en brittisk butik som säljer till kunder i Frankrike omfattas när det gäller de kunderna (artikel 3.4). Vår guide till tillgänglighetsdirektivet tar upp nationella lagar och sanktioner.

Storbritanniens Equality Act 2010 (öppnas i en ny flik) kräver skäliga anpassningar för personer med funktionsnedsättning men anger ingen teknisk standard för webbplatser. I USA säger justitiedepartementets vägledning från mars 2022 (öppnas i en ny flik) att företag som är öppna för allmänheten måste göra det de erbjuder på nätet tillgängligt, och att standarder som WCAG ”ger användbar vägledning”. Oavsett vad lagen säger köper inte en kund som inte kan slutföra köpet i din kassa.

Vilka är de vanligaste tillgänglighetsproblemen på webbplatser?

Sex fel dominerar. I WebAIM Million 2026 (öppnas i en ny flik), en automatisk skanning av startsidorna hos de en miljon största webbplatserna i februari 2026, hade 95,9 % av sidorna upptäckta WCAG-fel, i genomsnitt 56,1 fel per sida. Text med låg kontrast var det vanligaste problemet och fanns på 83,9 % av startsidorna.

WCAG, riktlinjerna för tillgängligt webbinnehåll, är standarden bakom de här kontrollerna; de flesta lagar hänvisar till nivå AA, och vår guide till WCAG 2.2 förklarar den senaste versionen. Flera av kontrollerna nedan kan ingen skanner bedöma.

Kan alla läsa din text och förstå dina bilder?

Börja här, eftersom åtgärderna är billiga och oftast sådana som du själv gör i redigeringsverktyget. Text behöver tillräcklig kontrast, bilder som bär information behöver alternativtext och ingenting får bygga enbart på färg. Ungefär 1 av 12 män och 1 av 200 kvinnor har nedsatt färgseende, enligt Colour Blind Awareness (öppnas i en ny flik).

• Kontrast. Vanlig text behöver ett kontrastvärde på minst 4,5:1 (öppnas i en ny flik) mot bakgrunden, stor text minst 3:1. Testa dina färger i ett gratis verktyg, även text ovanpå bilder i banners. Vår guide om färgkontrast visar lösningar som behåller din grafiska profil.
• Alternativtext till produktbilder. Beskriv det en kund behöver veta: ”Marinblå ylletröja med ribbstickad polokrage, framifrån” är bättre än ”produktbild 1”. Börja med dina tio mest sålda produkter.
• Dekorativa bilder. En slinga i bakgrunden ska ha tom alternativtext så att skärmläsare hoppar över den. Vissa plattformar fyller ett tomt alt-fält med filnamnet, så kontrollera din.
• Bara färg. ”Slut i lager” som bara visas med en grå färgruta, eller ett obligatoriskt fält som bara är markerat i rött, når inte alla. Titta på sidan med mobilens gråskalefilter och lägg till ett ord eller en ikon överallt där betydelsen försvinner.
• Zoom. Med 200 % zoom i webbläsaren ska texten växa utan att överlappa eller klippas av, och menyn ska fortfarande fungera.
• Sidspråk. Alla gratisverktyg flaggar en saknad språkangivelse. Det är en inställning i temat eller en ändring på en rad i mallen.

Går webbplatsen att använda med tangentbord?

Många surfar utan mus: skärmläsaranvändare, personer med tremor eller begränsad handrörlighet och alla vars styrplatta precis har slutat fungera. Lägg undan musen och tryck på Tab. Du ska nå varje länk, knapp och formulärfält i en rimlig ordning, alltid se var du är och aldrig fastna.

• Synligt fokus. En ram ska visa vilket element som är aktivt, och ett fast sidhuvud eller en chattbubbla får inte täcka det (kriterium 2.4.11 Focus Not Obscured i WCAG 2.2). Många teman tar bort ramen av estetiska skäl; en utvecklare kan lägga tillbaka den.
• Inga fällor. Öppna menyn, storleksväljaren, popup-fönstren och bildgalleriet med tangentbordet, välj något och försök sedan ta dig ut. Escape ska stänga popup-fönster.
• Namn på ikoner. Varje ikonlänk och ikonknapp behöver ett namn som en skärmläsare kan läsa upp, till exempel ”Varukorg, 2 varor”. Byt ut ”Klicka här” mot ord som säger vart länken leder.
• Hopplänk och rubriker. Första trycket på Tab bör helst visa en länk som ”Hoppa till innehållet”. I WebAIMs skärmläsarenkät från 2024 (öppnas i en ny flik) svarade 71,6 % att de först navigerar en lång sida via rubrikerna, så använd riktiga rubriknivåer och inte fetstil.
• Tryckytor. WCAG 2.2 kräver ytor på minst 24 × 24 CSS-pixlar, eller tillräckligt med utrymme runt dem (framgångskriterium 2.5.8 (öppnas i en ny flik)).

Tar sig alla igenom dina formulär, din varukorg och din kassa?

Det är i kassan som tillgänglighetsproblem kostar dig pengar direkt, så testa den från början till slut, också vad som händer när något går fel. Varje fält behöver en synlig etikett, felmeddelanden ska förklara problemet i ord och inloggningen får inte hänga på minnestester eller pussel. Betalleverantörens sidor räknas också.

• Etiketter, inte platshållare. Platshållartext försvinner så fort någon börjar skriva och är ofta för blek för att läsas. Varje fält behöver en etikett som förblir synlig.
• Felmeddelanden. Skicka formuläret tomt. Varje fel ska vara utskrivet i ord (”Ange ett postnummer, till exempel 113 51”), stå intill sitt fält och läsas upp, inte bara göra en ram röd.
• Fråga inte två gånger. Erbjud ”Fakturaadressen är samma som leveransadressen” i stället för att låta folk skriva in sin leveransadress igen. WCAG 2.2 gjorde detta till ett krav på nivå A, 3.3.7 Redundant Entry.
• Inloggning. Låt folk klistra in lösenord och engångskoder och använda lösenordshanterare. Att blockera inklistring underkänns enligt kriteriet Accessible Authentication (öppnas i en ny flik) i WCAG 2.2, om du inte erbjuder ett annat sätt att logga in.
• CAPTCHA. Skärmläsaranvändare rankade CAPTCHA som det mest problematiska på webben i WebAIMs enkät från 2024. Behöver du skydd mot robotar, undvik visuella pussel och erbjud alltid ett alternativ som inte är visuellt.
• Tidsgränser. Om en reserverad varukorg eller bokning löper ut ska du varna i förväg och låta folk förlänga tiden.

Tillhör delar av kassan din plattform eller betalleverantör ska du ändå testa dem, rapportera problemen och lista dem som kända brister.

Hur är det med cookiebanners, popup-fönster och chattwidgetar?

För dina kunder är skript från tredje part en del av din webbplats. En cookiebanner som inte går att stänga med tangentbordet blockerar varje sida, och en popup för nyhetsbrevet som tar fokus mitt i kassan kan stoppa ett köp. Testa varje skript du har lagt till, och fråga leverantörer om tillgänglighet innan du installerar något nytt.

• Cookiebanner. Når du knapparna för att godkänna och avvisa med Tab, kan du läsa dem med 200 % zoom och fortsätta där du var efteråt?
• Popup-fönster. Fokus ska flyttas in i fönstret, stanna där tills det stängs och sedan återvända. Escape ska stänga det.
• Chattwidgetar. Knappen behöver ett namn, fönstret ska gå att öppna och stänga med tangentbordet och på mobilen ska det inte ligga ovanpå ”Betala nu”.
• Karuseller. Allt som rör sig automatiskt i mer än fem sekunder behöver ett sätt att pausa, stoppa eller dölja det (WCAG 2.2 (öppnas i en ny flik), framgångskriterium 2.2.2).
• Inbäddningar. Recensionswidgetar, kartor och bokningsverktyg finns också på din sida. Ta upp felen med leverantören.

Fungerar dina videor, pdf-filer och menyer för alla?

Video behöver undertexter, ljud behöver en transkription och viktig information ska inte bara finnas i en pdf eller en bild. En restaurang vars meny är en inskannad pdf, eller en butik vars storleksguide är ett foto av en tabell, stänger ute skärmläsaranvändare och alla som behöver zooma in på mobilen.

• Undertexter och transkriptioner. Rätta automatiska undertexter innan du publicerar. Poddar behöver en textversion.
• Bilder av text. Lägg menyer, prislistor, storleksguider och öppettider på en vanlig webbsida. Måste du använda pdf, exportera den med rubriker och taggar från ordbehandlaren i stället för att skanna en utskrift.
• Äldre filer. Tillgänglighetsdirektivet kräver inte att du åtgärdar kontorsdokument eller förinspelat ljud och video som publicerades före den 28 juni 2025, eller arkiv som du inte längre uppdaterar (artikel 2.4). Nya filer omfattas.

Vad kan jag åtgärda själv, och när behöver jag en utvecklare eller en granskning?

De flesta problem med innehållet kan du åtgärda själv i publiceringssystemet: alternativtexter, rubriker, länktexter, färger, undertexter och många formuläretiketter. Problem i temat, som saknade fokusmarkeringar, tangentbordsfällor och specialbyggda rullgardinsmenyer, kräver en utvecklare. En granskning gör mest nytta när grunderna är åtgärdade, eller innan en ny design går live.

Var passar en widget som vår in? En panel för besökare som SiteAccessible låter folk höja kontrasten, förstora texten eller slå på en läslinjal. Det hjälper vissa besökare, men det bockar inte av något på den här listan: en knapp utan namn förblir utan namn och en tangentbordsfälla förblir en fälla. Åtgärda webbplatsen först och se en widget som ett tillägg.

Hur dokumenterar jag det jag har gjort?

För en enkel logg över vad du har testat, när, vad du har åtgärdat och vad som fortfarande inte fungerar, och publicera sedan en ärlig sammanfattning i en tillgänglighetsredogörelse. Gäller tillgänglighetsdirektivet dig måste du också publicera information om hur tjänsten uppfyller tillgänglighetskraven, oftast i dina allmänna villkor eller ett motsvarande dokument.

Den andra skyldigheten kommer från direktivets bilaga V; formen bestäms av den nationella lagen. Vår guide om hur du skriver en tillgänglighetsredogörelse innehåller en mall som du kan anpassa. Håll sedan rutinen igång:

1. Gå igenom checklistan på dina tre viktigaste sidor och ta en skärmbild av varje fel.
2. Åtgärda innehållspunkterna själv den här veckan.
3. Ge en utvecklare en beskrivning av punkterna i temat och kassan, de värsta först.
4. Testa varje åtgärd igen med tangentbordet och inte bara med ett verktyg.
5. Publicera eller uppdatera din redogörelse, med datum.
6. Upprepa när du lägger till ett tillägg, byter tema eller lanserar en ny landningssida.