WCAG 2.1 & 2.2 checklista: Så testar ni er webbplats på 15 minuter

Många webbansvariga har provat att köra sin hemsida i ett automatiskt testverktyg som Google Lighthouse, WAVE eller Webperf. När mätaren visar en grön siffra är det lätt att tro att allt är klart — eller tvärtom känna sig överväldigad när verktyget spottar ur sig femtio obegripliga engelska felkoder.

Sanningen är att automatiska verktyg bara hittar ungefär 30 procent av alla verkliga tillgänglighetsproblem. De övriga 70 procenten handlar om huruvida en människa faktiskt kan ta sig fram på sajten med tangentbord, skärmläsare och 200 procents förstoring.

Den goda nyheten är att ni inte behöver vara utvecklare för att upptäcka de viktigaste bristerna. Här är vårt 15-minuterstest i fem steg som varje kommunikatör, webbredaktör och beställare kan göra direkt vid skrivbordet.

Steg 1: Lägg undan musen i 3 minuter (”Tabb-testet”)

Det allra mest avslöjande testet kräver inga extraprogram alls. Öppna er startsida i webbläsaren, lägg handen bort från datormusen och använd bara tangentbordet:

• Tryck på Tab för att flytta framåt mellan länkar, knappar och formulärfält.
• Tryck på Shift + Tab för att backa.
• Tryck på Enter eller Mellanslag för att öppna menyer och klicka på knappar, och Esc för att stänga rutor.

Steg 2: Zooma till 200 % och 400 % (Kontrast & Omflöde)

Personer med nedsatt syn använder sällan separata förstoringsprogram om webbläsarens egen zoom räcker. Tryck Ctrl + + (eller Cmd + + på Mac) tills webbläsaren visar 200 % och sedan 400 %:

Steg 3: Kontrollera rubrikträdet och sidstrukturen

En seende besökare skummar en webbsida med ögonen. En person som använder skärmläsare trycker i stället på bokstaven H på tangentbordet för att hoppa från rubrik till rubrik och bilda sig en uppfattning om sidan.

Om en redaktör har valt Rubrik 4 (H4) direkt under H1 bara för att typsnittet råkade se snyggt ut, eller gjort en rubrik genom att bara fetmarkera en vanlig textrad, går skärmläsarens innehållsförteckning sönder.

• Varje sida ska ha exakt en H1 (sidans huvudrubrik).
• Underrubriker ska följa en logisk hierarki: H1 → H2 → H3 utan att hoppa över nivåer.
• Sidan ska ha semantiska landmärken i koden (<header>, <nav>, <main>, <footer>) så att hjälpmedel vet var menyn slutar och huvudinnehållet börjar.

Steg 4: Testa era formulär, bilder och PDF-dokument

Gå till er kontaktsida, er felanmälan eller er dokumentbank och kontrollera dessa tre punkter:

1. Formuläretiketter (<label>): Klicka med musen direkt på ledtexten ovanför ett inmatningsfält (t.ex. ordet ”E-postadress”). Om skrivmarkören hoppar in i fältet är etiketten rätt kopplad i koden. Om ingenting händer saknas kopplingen for/id, vilket gör att en skärmläsare bara säger ”Redigera text” utan att berätta vad besökaren ska fylla i. (Samma sak gäller när någon bara använder placeholder-text som försvinner så fort man börjar skriva).
2. Alt-texter på bilder och ritningar: Informationsbärande bilder ska ha en kort, beskrivande alt-text. Ren dekoration ska ha ett tomt attribut (alt="") så att skärmläsaren slipper läsa upp filnamnet. För komplexa kartor och ritningar krävs en strukturerad textbeskrivning (läs mer i vår guide om tillgänglighet för fastighetsbolag och energibolag).
3. PDF-dokumenten: Öppna er senaste årsredovisning eller en viktig blankett på mobilen. Om ni möts av en tvåspaltig A4-PDF som kräver nyp-zoom är det hög tid att bygga om de viktigaste PDF-dokumenten till sökbara webbsidor.

Steg 5: Gå inte på myten om ”tillgänglighets-widgets” (Overlays)

När lagkraven skärps ringer många säljbolag runt till svenska kommuner, bolag och e-handlare och lovar att ett enkelt JavaScript-tillägg (en liten rullstols- eller gubb-ikon i hörnet av skärmen) gör webbplatsen ”100 % WCAG-kompatibel på 5 minuter”.

DIGG:s och experternas tydliga besked: Så kallade overlays eller tillgänglighets-widgets gör inte att en webbplats uppfyller lagkraven i DOS-lagen eller Tillgänglighetsdirektivet. De reparerar inte den underliggande koden, löser inte otillgängliga PDF-filer och stör ofta de hjälpmedel som användaren redan har installerat på sin egen dator eller telefon.

Vill ni få en professionell genomgång — och få felen åtgärdade?

Om ni upptäcker brister när ni gör 15-minuterstestet ovan behöver ni inte fastna i en dyr utredning. Vi på Sörmlands Webbyrå kombinerar manuell granskning med konkret webbutveckling och rättar felen direkt i koden.

Läs mer om hur vi arbetar med tillgänglighetsanpassning av webbplats och dokument eller kontakta Lars direkt så tittar vi på er webbplats och ger er ett konkret förslag.

Källor

• Web Content Accessibility Guidelines (WCAG) 2.2 (W3C).
• Webbriktlinjer – Officiella riktlinjer för offentlig sektor (DIGG).
• Varför verktyg för automatisk anpassning (overlays) inte räcker (DIGG / Europeiska tillgänglighetsexperter).