Konkreta arbetssteg för tillgänglighetsanpassning enligt WCAG

2022-03-24

Nyligen gick jag en certifieringsgrundande kurs inom tillgänglighet (WCAG, ACAG, WAI-ARIA, WCAG-EM osv) med företaget Funka. Kursen var mycket bra och gav mig mycket att reflektera över och många nya insikter. Tillgänglighetsaspekten har länge vagt funnits i mitt bakhuvud, men kursen tydliggjorde det hela och gav många konkreta råd som var lätta att applicera.

Direkt efter kursen gick jag hem och skrev om en sajt jag var ansvarig för.

Denna artikel handlar om hur jag konkret gick till väga för att tillgänglighetsanpassa denna specifika webbplats, i hopp om att det kan komma andra till gagn.

Så här gick det till:

Arbetsgång

Följande semantiska (betydelsebärande) HTML-element infördes på studs på sajten överallt där det saknades:

Många av dessa fick ersätta de tidigare, och mycket flummigare, <div>-taggar för att hjälpa skärmläsare och andra tillgänglighetshjälpmedel att förstå innehållet och agera korrekt.

Dessutom gick jag igenom hela sajten och letade efter, och åtgärdade följande:

Steg Företeelse Åtgärd
1 Klickbara element som inte var av typen <a> eller <button> Ersattes med korrekta semantiska HTML-taggar (<a> eller <button>)
2 Textelement med annat språk än dokumentets angivna språk (typ lang="sv") Tillägg av lang-attribut på HTML-elementen med avvikande språk
3 Förtydliga vad som egentligen är citat i texter Omge dessa med <q>-taggar för att underlätta för screen-readers
4 Gå igenom kvarvarande icke-semantiska element (som t.ex. <div>-element) Ge dessa lämpliga WAI-ARIA role-attribut där så är applicerbart
5 Dynamiskt innehåll som laddas/genereras/renderas efter det statiska innehållet Se till att dessa har lämplig aria-live-attribut och beteende när de laddats (med avseende på focus och liknande)
6 Tangentbordsstyrning Provar att navigera varje sida och varje dialog med tangentbordet - och korrigerar beteendet när så behövs (med t.ex. tabindex-attribut)
7 Modala dialoger Säkerställer att det inte går att tabba sig utanför modala dialoger om man har en sådan öppen (med tabindex="-1")
8 Identifierar styling som försvunnit i ovanstående korrigeringar Snyggar till den styling (CSS) som påverkades av tag-ändringar och liknande från ovanstående steg

Avslutande kontroller

För att bli mer trygg med att dessa ändringar faktiskt har avsedd kontrollerades sedan:

  1. Skalningsförmågan på sajten (webbläsar-zoom upp till minst 200% utan förvrängning)
  2. Möjligheten att ändra radavståndet (webbläsarens inställningar)
  3. Färgval och kontrast (med hjälp av extern webbtjänst, se nedan)
  4. Uppläsningsordning (webbläsarens developer tools -> Tillgänglighet)
  5. Prova att få sidan uppläst (aktivera NVDA)

Självklart är inte detta ett heltäckande tillgänglighetsarbete, men det är förmodligen några av de lättaste och viktigaste stegen till att göra webbtjänster tillgängliga och det är bättre än att inte genomföra dessa steg.
Dessutom tog det inte så lång tid heller, och var väldigt lärorikt.

Länkar

Efter allt detta (som dock blott tog en kväll) så körde jag sajten genom några av de vanliga webbtjänsterna för att säkerställa att inget har gått fel. Exempel på sådana jag använde var:

Sammanfattning

För att sammanfatta så var detta en lärorik upplevelse och som snabbt gjorde att jag nu ser icke-semantiska HTML-element (som t.ex. <div> som fula, lata, icke-funktionella, opraktiska och flummiga. Varje gång jag nu ser en div-tag funderar jag på vad det egentligen borde vara för element. Visst går det att förklara för tillgänglighetsverktyg som skärmläsare och liknande vad det är för typ av element genom aria-attribut, men det känns ofta helt onödigt när det finns betydelsebärande typer av HTML-element för i det närmaste allt man behöver.