Så planerar du WCAG-arbetet för din webbplats

WCAG-arbete blir ofta onödigt dyrt när det hanteras som en punktinsats precis före lansering. När tillgänglighet i stället får vara en del av strategi, design, innehåll, utveckling och förvaltning blir arbetet mer förutsägbart – och resultatet bättre för både användare och verksamhet.

Börja med målbilden, inte med en checklista

WCAG, Web Content Accessibility Guidelines, är ett ramverk för digital tillgänglighet. Riktlinjerna omfattar bland annat hur innehåll ska kunna uppfattas, hur funktioner ska kunna användas och hur väl webbplatsen fungerar med hjälpmedel som tangentbord och skärmläsare.

Men en checklista säger inte automatiskt vad som är viktigast för just er. Börja därför med att koppla tillgängligheten till webbplatsens affärsmål. Vilka sidor är avgörande för att generera leads? Var sker registreringar, bokningar eller köp? Vilken information måste en besökare kunna ta till sig för att välja er?

En B2B-webbplats kan behöva prioritera kontaktvägar, formulär, tjänstesidor och nedladdningsbart material. För en e-handel är produktlistor, produktinformation, varukorg och kassa ofta mest kritiska. Det betyder inte att resten av sajten kan vänta för alltid, men det ger en klok ordning för arbetet.

För vissa verksamheter finns dessutom lagkrav att förhålla sig till. Vilka krav som gäller beror på organisation, tjänst och målgrupp. Oavsett juridisk skyldighet är god tillgänglighet ett kvalitetstecken och en investering i en webbplats som fungerar i fler situationer.

Sätt ansvar och beslut tidigt

Tillgänglighet är tvärfunktionellt. Designern ansvarar inte ensam för kontraster och komponenter. Utvecklaren ansvarar inte ensam för tekniken. Redaktören ansvarar inte ensam för begripligt innehåll. När ansvarsfördelningen är oklar uppstår lätt glapp – och glappen brukar upptäckas sent.

Utse en intern ansvarig som kan prioritera frågor, samla rätt personer och fatta beslut när mål krockar. Den rollen behöver inte kunna varje WCAG-kriterium. Däremot behöver personen förstå verksamhetens mål och säkerställa att tillgänglighet får plats i budget, tidplan och kravställning.

Besluta också vad som ska gälla vid nya publiceringar. Ska varje ny sida kvalitetssäkras innan den går live? Vem granskar alt-texter, rubrikstruktur och länkar? Vad händer när en kampanjsida behöver produceras snabbt? Tydliga arbetssätt gör det enklare att hålla nivån efter att det första förbättringsprojektet är klart.

Kartlägg nuläget innan ni prioriterar

Det är svårt att planera utifrån antaganden. En inledande tillgänglighetsgranskning ger en bild av var problemen finns, vilka delar som påverkar flest användare och vad som kräver större tekniska insatser.

En bra kartläggning kombinerar automatiska tester med manuell granskning. Automatiska verktyg är effektiva för att hitta exempelvis vissa kontrastproblem, saknade formulärfältsetiketter och fel i kodstrukturen. Men de kan inte avgöra om en länktext är begriplig i sitt sammanhang, om tangentbordsfokus följer en logisk ordning eller om en skärmläsaranvändare förstår vad som händer när ett formulär skickas.

Granska särskilt användarresan, inte bara enskilda sidor. Testa till exempel att komma från startsidan till en viktig tjänst, fylla i ett formulär och förstå bekräftelsen – helt utan mus. Gör samma sak i mobil och på större skärm. Det är i övergångarna mellan olika moduler, popup-fönster, filtreringar och formulär som många problem visar sig.

Dokumentera fel så att de går att åtgärda

En rapport som bara säger att webbplatsen har brister hjälper sällan någon. Varje identifierat problem bör beskriva var det finns, vad användaren riskerar att uppleva, vilket WCAG-område det berör och hur det kan lösas.

Ett konkret exempel är bättre än en allmän formulering. I stället för att skriva att navigeringen har problem kan rapporten ange att fokusmarkeringen saknas på menylänkar, vilket gör att personer som använder tangentbord inte ser var de befinner sig. Då blir omfattning, konsekvens och åtgärd tydliga för både beställare och utvecklare.

Så planerar du WCAG-arbetet i rätt ordning

När nuläget är kartlagt behöver ni prioritera. Allt kan vara viktigt, men allt har inte samma påverkan på användaren eller affären. En effektiv plan väger samman användarpåverkan, affärskritikalitet, risk och åtgärdskomplexitet.

Börja normalt med hinder som blockerar en viktig handling. Det kan vara en kassa som inte går att använda med tangentbord, ett formulär där felmeddelanden inte förklarar vad som behöver rättas eller en meny som inte fungerar med skärmläsare. Därefter hanterar ni återkommande fel i gemensamma komponenter, som knappar, modaler, sökfunktioner och bildblock. En förbättring i ett återanvänt block kan lösa problem på hundratals sidor samtidigt.

Dela sedan upp arbetet i hanterbara etapper. I första etappen kan ni rätta blockerande problem på affärskritiska flöden. Nästa steg kan vara att förbättra mallar, designkomponenter och redaktionella rutiner. Därefter följer fördjupade tester och förbättringar av äldre innehåll.

Det finns en tydlig avvägning här. Att rätta ett fel snabbt direkt i en enskild sida kan vara rimligt om det stoppar en viktig process. Men om samma fel kommer tillbaka gång på gång behöver grundkomponenten byggas om. Annars skapar ni ett underhållsproblem som växer för varje publicering.

Bygg tillgänglighet i design och innehåll

Många tillgänglighetsproblem går att förebygga långt innan utvecklingen startar. Designsystemet ska till exempel definiera tillräckliga kontraster, tydliga fokuslägen, klickytor som fungerar på mobil och komponenter med förutsägbara beteenden. Det räcker inte att en knapp ser bra ut i en skiss – den måste också visa när den har fokus och ha ett namn som förklarar vad som händer.

Innehållet behöver vara lika genomtänkt. Rubriker ska skapa en logisk struktur, inte bara användas för att göra text större. Länkar ska berätta vart användaren kommer. Bilder som tillför information behöver alternativtexter, medan rent dekorativa bilder ofta ska lämnas åt sidan för hjälpmedel.

Skriv också för förståelse. Korta stycken, tydliga uppmaningar och konkret språk hjälper personer med kognitiva svårigheter, men också en stressad inköpare som läser i mobilen mellan två möten. Tillgänglighet och konvertering står ofta på samma sida: båda minskar osäkerhet och gör nästa steg tydligt.

Testa i verkliga användarscenarier

En lansering är inte slutpunkten för WCAG-arbetet. Varje nytt plugin, formulär, kampanjblock eller ändring i WordPress kan påverka tillgängligheten. Därför behöver testningen vara återkommande och anpassad till hur webbplatsen faktiskt utvecklas.

Gör automatiska kontroller till en del av er kvalitetsprocess, men komplettera med manuell testning av de flöden som betyder mest. Testa tangentbordsnavigering, synlig fokusmarkering, rubrikhierarki, formulärvalidering och hur innehåll presenteras i skärmläsare. När det är möjligt ger tester med personer som använder hjälpmedel insikter som inga verktyg kan ersätta.

Se också till att förbättringar verifieras efter implementering. Ett löst problem i utvecklingsmiljön är inte löst förrän det fungerar på den publicerade webbplatsen, i rätt mall och tillsammans med övriga funktioner.

Gör WCAG till en del av förvaltningen

Den mest hållbara planen innehåller inte bara en åtgärdslista. Den beskriver också hur kvaliteten ska bevaras. Det kan innebära att redaktörer får enkla riktlinjer, att nya komponenter granskas före användning och att tillgänglighet tas upp i den löpande planeringen av webbplatsen.

För många företag är det här den verkliga utmaningen. En sajt kan vara väl genomgången vid lansering men försämras när innehåll skapas under tidspress eller när teknik uppdateras utan kontroll. Löpande webbplatsförvaltning gör det möjligt att fånga problemen tidigare, prioritera dem mot andra utvecklingsbehov och undvika att en stor tillgänglighetsskuld byggs upp.

En tydlig plan för WCAG ger er mer än färre fel. Den ger en webbplats som är lättare att använda, enklare att förvalta och bättre rustad för att omvandla intresse till nästa affär. Börja med den användarresa som betyder mest för er – och gör tillgänglighet till ett arbetssätt som håller även efter nästa publicering.