Sök Logga in

Automatiska tillgänglighetstester är inte tillräckligt – så här börjar du testa manuellt

Marcus Österberg Skapad 2024-08-30, uppdaterad 2024-10-05 18 minuters läsning DOS-lagen Tillgänglighet WCAG LPTT
Illustration med en mängd människor som alla har olika funktionsnedsättningar

Automatiserade tester kan inte fånga upp alla aspekter av tillgänglighet. Därför är manuella tester, där mänskliga insikter spelar en central roll, en nödvändighet. I denna guide får du veta varför och hur du kan komma igång.

Sammanfattning:

  1. Automatiska tillgänglighetstester är viktiga men otillräckliga: Webperf fokuserar på automatiska tester och kan avslöja många tillgänglighetsbrister, men för att få en komplett bild krävs även manuella granskningar. Automatiska tester kan upptäcka cirka hälften av vanliga problem, men de kan inte identifiera alla typer av tillgänglighetsproblem.
  2. Bygg upp intern kompetens inom tillgänglighet: Istället för att enbart förlita sig på externa experter eller diverse verktyg, bör organisationer själva börja med enkla, manuella tester och utbilda sin personal inom tillgänglighet. Verktyg som axe DevTools eller ARC Toolkit tillsammans med testprotokollet WCAG-EM hjälper till att identifiera tillgänglighetsproblem tidigt.

Avsnitt:

Bakgrund till Webperfs (mestadels) automatiska tester

De tillgänglighetstester du hittar här på Webperf är i regel av den automatiska sorten. Ofta hittar du i dessa texter ett förbehåll om att automatiska tester inte riktigt räcker till. Samtidigt är de saker som även automatiska tillgänglighetstester kan upptäcka ofta så pass eftersatt, eller obefintligt efterlevt, att nära på varje test som publiceras på Webperf kommer fram till att mer än 90% av undersökta webbplatser har minst en brist. Det är på tok för enkelt att hitta uppenbara problem med de mest simpla av metoder för tillgänglighetsutvärdering!

Det räcker med att man kör de automatiska tillgänglighetstesterna som i princip alla IT-kunniga kan köra på egen hand om de bara investerar som absolut mest en halvdag av sin arbetstid. Många av organisationerna vars webbplatser listas på Webperf har verktyg som Siteimprove, Monsido eller Silktide för bl.a. tillgänglighetstester. Frågan är om de agerar på det verktygen berättar för dem?
Majoriteten av offentlig sektor listas på Webperf i någon kategori och majoriteten fortsätter att ha ganska enkelt funna problem med tillgänglighet utan någon djupare analys. Något är skumt här. Att betala för verktyg verkar faktiskt inte leda till insikter som är tillräckligt övertygande att man åtgärdar det som felar.

Gör dina automatiska tillgänglighetstester på egen hand om du vill!

För de organisationer som är i början av sin förbättring av webbtillgängligheten finns ingen särskilt bra anledning att betala någon utomstående. De mest uppenbara problemen är av den automatiska sorten. De hittar du eller dina webbutvecklare med ett fåtal stickprov via:

Det utomstående testare kan göra för dig med automatiska verktyg är att ge dig perspektiv, prioritering och annat som har med erfarenhet att göra.

Vad är axe-core?

De flesta av dessa tillgänglighetstester drar nytta av axe-core på ett eller annat sätt. Vill du eller dina utvecklare göra det lite mer storskaligt? Då kan ni köra Axe-testerna via Webperf Core för att vara helt oberoende. Vad som nu passar dig bäst. Gör din egen grej!

Axe DevTools är baserat på Deques öppna motor för tillgänglighetstest, axe-core. Axe-core är både öppen källkod, branschpraxis och vad många av oss återanvänder för automatiska tillgänglighetstester (även flertalet av de verktyg du behöver betala för).

Här på Webperf kompletteras emellanåt dessa automatiska tillgänglighetstester med mer manuella granskningar av aspekter som påverkar hur pass tillgänglig en webbplats, eller etjänst, eller app, faktiskt är i realiteten.
Men det är bra att komma ihåg att en brist som upptäckts med manuella tillgänglighetsgranskningar, alldeles oavsett om de görs av en tillgänglighetsexpert, ibland är ganska subjektiva. Att ”det beror på” vilka de här användarna är som vi vill skapa en tillgänglig digital tjänst för. Samtidigt ska du inte avfärda den expertis du har för kvalitativ och mer manuell tillgänglighetsutvärdering, om du nu inte har väldigt goda skäl.

Vem är en tillgänglighetsexpert?

Som med det mesta annat är det för en person som ganska nyligen börjat sin karriär inom UX eller tillgänglighet ganska enkelt att lite pinsamt identifieras med Dunning–Kruger-effekten. Det är en ny värld som öppnar sig och inledningsvis har vi alla våra enkla svar.

Ett kännetecken för de som varit aktiva i många år som tillgänglighetsexperter är att de ställer ganska många motfrågor för att klargöra detaljer. En tillgänglighetsexpert ger inte särskilt många enkla besked på frågor och de är sällan tvärsäkra på något alls. Vilket är ett kännetecken på experter generellt. Om du nu inte redan är aktiv i den svenska t12t-communityn så är din väg in att börja på t12t.se som webbplats och anslut till gruppens Slack för diverse frågor till oss andra engagerade.

För ganska många av oss som vurmar för en specifik del av digitalisering är det lätt att fastna i att man känner sig som en bluff (impostor syndrome). Trots att man faktiskt kan ha de erfarenheter som krävs för att göra ett bra jobb på området det handlar om.

Den optimala tillgänglighetsgranskaren är du som…

Det finns en mängd tillgänglighetsspecialister i Sverige! Men det är värt att minnas att ingen av oss kan precis allt inom samtliga delområden av tillgänglighet. Men, det jag oftast tänker på som en ”tillgänglighetsspecialist” är en person som är certifierad av International Association of Accessibility Professionals (IAAP). Jag är själv inte certifierad inom tillgänglighet. Men det händer att andra tillskriver mig en sorts auktoritet på området, trots att jag inte är certifierad eller någonsin jobbat uteslutande med tillgänglighet. Det här är lite otydligt! Och ändå inte. Om du behöver expertis inom manuell tillgänglighetstestning är någon som är certifierad av IAAP ett enkelt val för då kan du läsa på vad de certifierat sig på och om det matchar ditt behov!

Men det finns många fler roller inom tillgänglighet och ett helt gäng med bakgrunder som gör en person ytterst relevant. Något som nämns redan i förordet av boken Web Accessibility Cookbook (2024).

"To make accessible websites, you need a core knowledge of user interface (UI) design, user experience (UX), usability, performance, content strategy, search-engine optimization (SEO), and security. A website with poor performance is inaccessible, bad UX usually means bad UX for everyone, poorly written HTML is bad for SE0 and accessibility, and so on."
– Manuel Matuzovic, Web Accessibility Cookbook (2024)

Att jobba med tillgänglighet kan också handla om att skapa förståelse och acceptans att tillgänglighet inte är oväsentligt. Då är det snarare en rådgivare, eller digital strateg, som behövs för att bädda in tillgänglighetsperspektivet i det övriga arbetet.

Certifierad expert på tillgänglighet

En certifiering är CPACC (Certified Professional in Accessibility Core Competencies), men det finns två ytterligare certifieringar du behöver ha koll på. Web Accessibility Specialist, WAS, och Certified Professional in Web Accessibility, CPWA. Dessa förkortningar förekommer ibland utan närmare förklaring.

Ofta är de här certifierade personerna grymma på expertgranskningar av webbplatser, appar och annat digitalt. Manuella granskningar alltså. Det där som tar nästa logiska steg efter att någon kört Webperf-, Siteimprove-, Monsido-, Silktide-, eller Accessibility Clouds tester på egen hand.
SaaS-, och molntjänster tar, som tidigare nämnt, dig en bit på vägen, men definitivt inte i mål. Du behöver antingen intern testkompetens eller anlita extern kompetens.

Vilken kompetens? Jo, UX-, eller tillgänglighetskompetens som kör en manuell granskning. Senare i denna skrivelse kommer metoden WCAG-EM beskrivas. Men först lite mer bakgrund om vem och vilka som kan bidra till helheten.

Att vara en tillgänglighetsspecialist på det sätt jag definierar här innebär att du behärskar en eller ett flertal roller, exempelvis:

  1. Användbarhet och UX är din specialitet.
  2. Du har koll på lagstiftningen, prejudikat och strategisk regelefterlevnad.
  3. Du kan kommunicera med alla berörda och intressenter som en expert för att få till bestående förändring.
  4. Frontendutvecklare? HTML, CSS och Javascript? Ja, det har du stenkoll på och då om hur kod påverkar tillgängligheten och vad olika användare upplever vid sin användning.

Japp! För ganska många byråer och IT-företag är det ett smart affärsbeslut att anställa tillgänglighetspersonal. Det är också det rätta att göra. Så man kan fråga sig vilken specialisering av dessa man är mest intresserad av.

En lite privat anekdot var när en person, som jag själv betraktar som expert inom tillgänglighetstestning, hörde av sig och skrockade över ett konsultavrop från offentlig sektor. Hen skrev Såg att du ska jobba med [organisation xyz]. Har nog aldrig sett en så skräddarsydd upphandlingsbeskrivning.

I det här fallet var det nog inte en riggad upphandling, åtminstone inte med mig som tilltänkt konsult. Jag var helt ovetande. Tydligen hade organisationen krävt minst 12 års erfarenhet. Min kontakt kommenterade det som Hur många i Sverige har 12 år?
Jo, jag skulle faktiskt kunna matcha de kraven rent formellt och möjligen överleva en eventuell intervju med beställaren. Sen har jag definitivt inte lagt 12 år fokuserat på just tillgänglighet utan mer i strategiska och analytiska roller som involverar en hel del annat än enbart tillgänglighet.

Men jag känner igen det här från min roll som konsultköpare på Västra Götalandsregionen under drygt tiotalet år. För vissa organisationers upphandlingsregler måste man kunna påvisa ett visst antal års erfarenhet. Jag lärde mig ganska snabbt att det var ”erfarna experter” vi ville ha när resultatet var särskilt viktigt. Men antalet år sedan man gjorde något för första gången är ett trubbigt sätt att kvalificeras.
Exempelvis, min ”specialitet” inom tillgänglighet är automatiserade tester, kodgranskning och kravställning. Som expertgranskare med mer manuella metoder skulle jag få det kämpigt och om någon ber mig berätta detaljerna bakom SC 3.1.2 har jag ingen aning på rak arm.

Det finns väldigt olika erfarenheter man får beroende på vad man sysselsätter sig med. Det är värt att ta med sig.

Varför ska jag komplettera med manuella tester?

En avgörande fråga för den som inte intuitivt förstår nyttan med att komplettera de (i sammanhanget ganska billiga) automatiska testerna, med de av mer manuell sort, är vad man får ut av det. Det finns säkert många sätt att förklara det, men faktum är att allt inte kan testas automatiskt! Ungefär hälften av tillgänglighetsbristerna går att upptäcka enligt en rapport Deque släppte 2021.

“57 percent of accessibility issues were completely covered by this automated testing.”
– Automated Testing Identifies 57% Digital Accessibility (Deque, 2021)

Nu beror det förstås på vad din webbplats innehåller. Om den är enklast tänkbara HTML-dokument med en rubrik, textstycke och inga fler undersidor är chansen god att den är tillgänglig utan att du berhöver kolla efter. Men så är inte webbplatser utformade sedan millenieskiftet.

Google Pagespeed Insights, som kör Axe-Core i grunden, lyfter fram flera saker för webbsidor som de inte kan ge återkoppling på. Saker där vi med automatiska metoder inte kan hitta tillgänglighetsproblem och det behövs manuella tester för att verkligen veta. Följande nämns:

  1. Interaktiva kontroller kan fokuseras på via ett tangentbord.
  2. Interaktiva element berättar som sitt syfte och status
  3. Webbsidan har en logisk tabbordning
  4. Visuell ordning följer ordningen i webbsidan DOM
  5. Användarens fokus fastnar inte i en region
  6. Användarens fokus förflyttas till nytt innehåll som ges till sidan
  7. Finns landmärken inom HTML5 för att underlätta navigation
  8. Innehåll utanför skärm döljs för hjälpmedel
  9. Anpassade kontroller har nödvändiga etiketter
  10. Anpassade kontroller har ARIA-attribut

Exakt hur denna manuella kontroll ska göras finns det tips runt från samma källa.
→ How to review for accessibility (web.dev)

HTML är i grunden tillgängligt

Laura Kalbag, som skrev den utmärkta boken Accessibility for Everyone för många år sedan, påpekar att HTML är tillgängligt ända fram tills dess att en utvecklare tar ett dåligt beslut.

”…when we write well-structured HTML, without altering the default behaviors, it is innately accessible. It’s that easy—job done.”
– Laura Kalbag, i boken Accessibility for Everyone

Men, att få sina egna utvecklare eller webbkonsulter att undvika dåliga beslut är inte så enkelt. Om de inte redan vet hur man gör ett bra jobb eller satt upp lösningar för att uppmärksammas på när det uppstår problem har du större problem än de detaljer som tillgänglighet ofta innebär. Innan du börjat bemästra den automatiska delen av tillgänglighetstestning är det rätt svårt att lyfta blicken till att testa allt det här andra.

Vissa organisationer har förvisso en något trist syn på tillgänglighet, med den primära motivationen att undvika tillsyn eller behöva betala eventuella viten. Samtidigt börjar UX-gurun Jakob Nielsens law of the Internet User Experience närma sig ett kvartssekel då han formulerade dem år 2000.

“Users spend most of their time on other websites, so they expect your site to work like all the other sites they already know."
– Jakob Nielsen

Nielsen har haft många goda, och några få mindre vettiga, idéer sedan jag började följa honom 1999 i och med hans bok Designing Web Usability: The Practice of Simplicity som jag fick av min kund Onsala församling då på forntiden. På den tiden var det fortfarande innovativt att förespråka CSS för att ”skilja på presentation från innehåll”.
→ History of CSS: The Evolution of Web Design

Men även 2024, när denna bloggpost skrivs, har jag tillgänglighetsuppdrag där en designer skapat något som bryter mot de konventioner som är inarbetade och inlärda via alla de här webbplatserna vi listat ut hur de fungerar.

Börja med manuella tillgänglighetstester själv - även om du är osäker på vad du gör!

Innan du vänder dig till de här människorna som gjort tillgänglighetstester sedan länge så är det nyttigt att du möter dessa personer på halva vägen. Var nyfiken! Börja gör lite av det här mer manuella jobbet på egen hand och bygg upp din erfarenhet!

Nu kommer det vara svårt att helt undvika att läsa och granska kod. Det behöver inte vara så märkvärdigt men inledningsvis kan det vara lite knepigt att lista ut vad man tittar på och om det är korrekt. Ett sätt att mjukstarta är att leta rätt på webbläsarens utvecklarverktyg. På en Mac får du fram dem genom tangentkombinationen Option+CMD+i och på Windows är det Ctrl+Shift+i.
Och till din hjälp har du webbläsartilläggen:

Inne i webbläsarens utvecklarverktyg hittar du dessa tillägg och när du kör dem kommer du få viss hjälp med vilken kod som tycks vara felaktig. Så du behöver inte läsa tusentals rader med kod utan kan fokusera på det som verkar vara bristande.

ARC Toolkit och axe DevTools hittar du i webbläsarens utvecklarverktyg.
Bild: ARC Toolkit och axe DevTools hittar du i webbläsarens utvecklarverktyg.

Utöver stödet från tillägg i webbläsaren kan du också vid behov högerklicka på en del av en webbsida och välja Inspektera. Då kommer du få se hur det elementets kod ser ut. Det här med att veta grunderna i kodgranskning har du nytta av även om du ska göra kvalitativa tester.

Nedan följer några saker du kan testa att komma igång med för manuell granskning av tillgänglighet.

Navigera med tangentbordet

Att en webbplats går att navigera med tangentbordet är viktigt för många olika användare. En grupp är de som inte kan se en muspekare på en skärm och därför behöver ett annat sätt att använda interaktiva element som länkar, knappar, etc. Sen kan det handla om att man har nedsatt finmotorik på grund av skada eller ålder. Men det finns också användare som kan hantera en mus som ändå ibland föredrar att navigera via tangentbordet, kanske för att man ändå mestadels har händerna på tangentbordet och det vore en ansträngning att sträcka sig efter musen.

Grunden i att navigera med tangentbordet är ganska enkel:

  • Du hoppar mellan olika aktiva element på sidan med tabbtangenten. Vill du backa är det Shift-Tab.
  • Piltangenterna är ofta användbara inne i element som innehåller flera val.
  • Enter-tangenten motsvarar att man klickar med en mus på det som är aktivt.
  • Mellanslag är att skrolla på sidan. För att skrolla uppåt använder du Shift-mellanslag.

Det du ska kolla efter vid tangentbordsnavigering är:

  1. Ser du klart och tydligt vilket element som är aktivt?
  2. Hoppar du mellan elementen i en logisk ordning?
  3. Hamnar ditt fokus på ett element som verkar döljas?
  4. Går alla element på sidan att nå via tangentbordet?

Särskilt viktigt att testa är webbplatsens navigation och där det finns formulär.

Lyssna på webbsidan med en skärmläsare

Det är inte bara blinda användare som har nytta av att lyssna på en webbplats, det gynnar också din SEO. Som blind användare kan man välja att lyssna på webbplatser men det finns även hjälpmedel som en punktskriftsdisplay för att få det på skärmen översatt till punktskrift, vilket är praktiskt om man är dövblind.

För oss seende kan man pröva att lyssna på webbplatsen genom att aktivera sin dators eller mobils talsyntes. För dig på Mac, Ipad eller Iphone heter den funktionen VoiceOver. VoiceOver hittar du bland Systeminställningar → Hjälpmedel → VoiceOver. För dig på Mac är det smidigaste att i Systeminställningar → Kontrollcenter aktivera ”Hjälpmedelsgenvägar” och antingen visa i menyrad eller i kontrollcenter. Då har du enkel åtkomst uppe till höger på skärmen till att aktivera och inaktivera VoiceOver när du vill testa.
→ Learn to Use VoiceOver on your Mac

Om du använder Windows finns ett antal skärmläsare att välja på. Microsoft har verktyget Narrator som du kan pröva. Bland de som faktiskt behöver en skärmläsare är NVDA (Non-Visual Desktop Access) och JAWS (Job Access With Speech) vanligast.
Eftersom NVDA och JAWS är så dominerande bland de med behov tenderar professionella tillgänglighetstestare att även använda dessa två skärmläsare. Det beror på att verktygen fungerar lite olika.
Men för dig som börjat doppa tårna i manuella tillgänglighetstester räcker det gott med att välja det verktyg du tycker är enklast att hantera.

Nu blundar du och försöker navigera via tangentbordet. Förstår du var du är? Kan du använda webbsidan på ett likvärdigt sätt som en seende?

Utvärdera alternativtexter och tabellsammanfattningar

Alla kan inte ta del av en bild som publicerats eller tolka en tabell full av information.

För bilder är det första du behöver göra att begrunda vilka bilder som är dekorativa. För om de inte bör beskrivas anger du alt="". För bilder som behöver beskrivas anger du alternativtexter som förmedlar det bilden föreställer eller kommunicerar för en seende. Digg har skrivit lite tips om hur en bra alternativtext skrivs.
→ Textalternativ för bilder – information när inte bilden kan visas (Digg)

När det gäller tabeller kan de vara så pass omfattande att de blir påfrestande att läsa ut och tolka. För detta finns en tagg som heter <caption /> där du direkt efter <table> inleder med att beskriva på ett tillgängligt sätt vad tabellen visar.
→ <caption>: The Table Caption element (MDN)

Simulera vid tillgänglighetstestning

Simulatorer kan också ge stöd i det egna testandet, helst redan i designskedet för att tidigt identifiera problem. Notera att simulering inte är en komplett lösning och riskerar att sprida förenklade uppfattningar (läs gärna I Won't Pretend That Disability Simulation Works), samtidigt som de kan vara en startpunkt för många av oss att få insyn i andras upplevelse.

Simulera i designstadiet i Figma

Väldigt många designar appar och webbplatser i Figma. Men oavsett vilket verktyg man har för design, färg och form är det klart bäst att fånga potentiella tillgänglighetsbrister redan under skapandeprocessen eftersom man då kan ta välavvägda beslut. I Figma finns mängder av tillägg för att simulera och granska en design ur tillgänglighetsperspektiv.
→ Free Accessibility Tools & Plugins to Empower Users (Figma)

Men även för oss som inte jobbar med Figma, eller ens i designstadiet, finns verktyg till hjälp.

  • Coblis — Color Blindness Simulator - ladda upp en bild och se hur den ser ut med vanliga varianter av färgblindhet
  • Funkify - är gratis för att direkt i webbläsaren simulera vissa funktionsnedsättningar, men kostar 5 dollar per månad om du vill komma åt alla funktioner
  • Web Disability Simulator - testa färgblindhet, nedsatt syn, dyslexi, m.m. direkt i Chrome
  • Synsimulator - app från Synskadades Riksförbund för att simulera ögonsjukdomar

Ett annat sätt att börja med tillgänglighetstestning är att dra nytta av Accessibility Clouds verktyg som assisterar dig i det manuella testandet. Relativt billigt för automatisk testning och de har ett rätt pedagogiskt sätt att vägleda genom en WCAG-EM-testning, det vill säga det standardiserade testprotokollet tillgänglighetsproffs följer.

Lära av experterna? En svensk gemenskap inom webbtillgänglighet!

Om du vill se och lära från mer erfarna personerna inom tillgänglighet är t12t-communityt en bra plats att ansluta till. Där finner du ett utmärkt nyhetsbrev, en meetup-grupp om tillgänglighet för diverse träffar och en Slack-kanal där du får nyanserade svar på dina frågor runt tillgänglighet - ofta av folk som verkligen kan tillgänglighet.

Är webbtillgänglighet mitt eller webbyråns problem?

Nu är vi lite tillbaka på beställarens perspektiv. Men ja, det är en bra fråga! En sak som förenar tillgänglighet med många andra områden är att webbplatsens avsändare inte kan svära sig fri från ansvar. Om ni är en organisation som träffas av DOS-lagen eller LPTT kan ni hamna under tillsyn av myndigheter. I en sådan situation blir det väldigt tydligt hos vem ansvaret ligger och att det är ni som får ta konsekvenserna om det brister. Redan innan eventuella brister upptäcks av myndigheterna kommer en förenklad tillsyn att leda till arbete och intern administration. Enklast är förstås att inte bli tagen på sängen för att man har tillgänglighet ständigt aktivt i sin utveckling och förvaltning. Och håller sig med åtminstone viss intern kompetens.

Om du har rollen som beställare behöver du kompetens inom många områden. För tillgänglighet är det WCAG (Web Content Accessibility Guidelines) du behöver ha åtminstone lite koll på.
WCAG har fyra fundament som ibland förkortas till POUR. Att material ska vara perceivable, operable, understandable och robust. Alltså gå att uppfatta, manövrera, förstå och vara robust.

Men varför borde varje beställare ha någon som har lite koll på WCAG? Här kommer några argument:

  1. Säkra kvalitet: Förståelse för WCAG gör att du kan ställa rätt krav på utvecklarna och säkerställa att de levererar en tillgänglig produkt som uppfyller lagkrav och standarder. Även om nu inte lagkraven gäller dig är det ändå en bra idé att så många som möjligt inkluderas.
  2. Förstå resultatet: Du kan bättre bedöma resultatet av både automatiska och manuella tillgänglighetstester, vilket gör att du kan identifiera och åtgärda potentiella problem så tidigt som möjligt i processen.
  3. Kostnadseffektivitet: Genom att inkludera tillgänglighet från början kan du undvika dyra och tidskrävande omarbetningar senare i projektet. I tillgänglighetskretsar är det välkänt hur dyrt det tenderar att vara att laga bristerna i efterhand.
  4. Användarcentrerat tänkande: Genom att förstå de faktiska användarnas tillgänglighetsbehov kan du bättre sätta dig in i olika användargruppers perspektiv och krav. Det leder till en mer inkluderande design och förbättrad användarupplevelse för alla du vill kommunicera med.
  5. Uppfyllande av lagkrav: I Sverige, i EU och delar av nordamerika, finns det lagar och förordningar som kräver att webbplatser och digitala tjänster är tillgängliga. Kompetens inom WCAG hjälper dig att säkerställa att ditt projekt och webbplats uppfyller dessa krav, vilket minskar risken för juridiska problem.

Genom att vara kompetent inom WCAG, app- och webbtillgänglighet kan du bättre styra projektet mot en produkt som är både laglig, användbar och inkluderande för alla.

För de som lyder under DOS-lagen eller LPTT finns utöver riktlinjer som WCAG också formaliakrav som att man behöver en tillgänglighetsredogörelse och beroende på din bransch kan det finnas ytterligare krav du behöver ha koll på.

Vad är tillräckligt bra tillgänglighetstestning?

Tillgänglighetstestning är som fysisk motion - det viktigaste är att det blir gjort över huvud taget. Att utan egen tillgänglighetsexpertis ändå börja göra manuella tillgänglighetstester är inte särskilt svårt.

Det som är svårt är att bemästra tillgänglighetsområdet eftersom det tar tid att bygga upp sin erfarenhet om lämpliga lösningar och den intuition man behöver för alla bedömningar man hamnar i. Men det viktiga är att börja i någon ände.

Ambitiös inom tillgänglighet?

Så vad göra om man siktar på att bli bra på webbtillgänglighet och göra en mer ordentlig och metodisk undersökning? Det korta svaret är att följa testprotokollet WCAG-EM. ”EM” står för Evaluation Methodology. Det här kommer från webbstandardorganisationen W3C så det får väl sägas vara extremt etablerat.

För WCAG-EM finns ett rapportverktyg som underlättar för dig som ska göra en mer komplett tillgänglighetsgranskning.
→ WCAG-EM-Report-Tool

WCAG-EM - en metod och standard för manuella tillgänglighetstester!

WCAG-EM är en förkortning av Web Content Accessibility Guidelines Evaluation Methodology.
Det svenska företaget Accessibility Cloud hjälper dig som är nybörjare med dessa kvalitativa tester för att hitta de här mer ovanliga eller svårbedömda bristerna.

WCAG-EM är en standardiserad metod för att utvärdera en webbplats tillgänglighet enligt WCAG. Här är några anledningar till varför WCAG-EM är bra:

  1. Strukturerad process: WCAG-EM erbjuder en tydlig och strukturerad process för hur man systematiskt kan bedöma en webbplats tillgänglighet. Detta säkerställer att inga viktiga aspekter missas, ger en mer pålitlig utvärdering och täcker in WCAG:s fyra fundament.
  2. Flexibilitet: Metodologin är flexibel och kan anpassas efter olika typer av webbplatser och utvärderingsbehov. Den kan användas för allt från små webbplatser till stora, komplexa system.
  3. Konsekvent: Genom att följa WCAG-EM säkerställs att utvärderingar görs på ett konsekvent sätt, vilket gör det lättare att jämföra resultat över tid eller mellan olika utvärderare.
  4. Dokumentation: WCAG-EM uppmuntrar noggrann dokumentation av varje steg i utvärderingen. Detta ger insyn och transparens i processen och gör det enklare att förstå och granska resultaten.
  5. Anpassning till WCAG: Eftersom WCAG-EM är utformad specifikt för att utvärdera följsamhet till WCAG-kriterierna, hjälper den till att säkerställa att alla relevanta WCAG-kriterier beaktas.
  6. Stöd för kontinuerlig förbättring: WCAG-EM kan användas återkommande för att övervaka och förbättra en webbplats tillgänglighet över tid, vilket hjälper organisationer att upprätthålla och förbättra sin tillgänglighetsstandard.
  7. Tydliga resultat: Genom att använda WCAG-EM får du tydliga, verifierbara resultat som kan användas för att ta informerade beslut, prioritera åtgärder och rapportera till ledning eller externa intressenter.

WCAG-EM är ett kraftfullt verktyg för att verkligen reda ut hur bra tillgängligheten är.

Vem ansvarar för vad inom tillgänglighetsområdet? Mognadsmätning och RACI-modellen!

Ett annat verktyg, släppt sommaren 2024 som utkast, från W3C är en mognadsmätning man kan göra på organisationsnivå.
→ Accessibility Maturity Model (W3C)

Tillgänglighetsprofilen Karl Groves har en bra artikel om hur man tar fram en RACI-matris för att ansvaret ska tydliggöras. RACI är en förkortning som står för Responsible (Ansvarig), Accountable (Ansvarstagande), Consulted (Konsulterad) och Informed (Informerad). Den här matrisen hjälper team att klargöra vem som gör vad i ett projekt och hur de är involverade i att få tillgänglighet att hända.
→ Developing a RACI matrix for accessibility

Vill du börja köra automatiska tillgänglighetstester?

Om du nu inte kommit igång med automatiska tester så är det också viktigt. Det är inte jättekomplicerat att köra Webperfs tillgänglighetstester ifall du är utvecklare eller lite tekniskt lagd. Det finns en virtuell Webperf-server för dig som gillar sånt. Webperf-testerna är open source och finns på Github - webperf_core - inklusive en version att köra med Docker.

Ifall du vill testa igenom säg 30 sidor på din egen eller någon annans webbplats är det inte konstigare än att installera någon variant av ovanstående alternativ. Sen letar du upp webbplatsens sitemap och skickar följande kommando till Webperf Core:

python default.py -t 10 -i https://webbplatsen.se/sitemap.xml --input-take 30 --output mitt-resultat.csv

Ifall du kör fast brukar vi i Webperf-communityt hjälpas åt på Slack, så kom dit med din fråga.

Mer om tillgänglighet

Bildkredd: Digital Accessibility Vectors by Vecteezy

Relaterat innehåll

Ironisk illustration över etikett till flaska med fejkad medicin, så kallad ormolja. (Bild av armageddon på deviantart, licens CC BY-NC-ND 3.0))

Fungerar tillgänglighets­lager? Nej!

I veckan uppmärksammades det förmodligen första företaget som säljer ”accessibility overlays” på den svenska marknaden. Så vad är då detta, och funkar de?

Foto på Pajala kyrka, från Wiklimedia

Pajalabostäders tillgänglighet fortsatt under granskning

Pajalabostäder och Ockelbo kommun blev först ut att hotas med vite av Digg på grund av deras dåliga följsamhet till DOS-lagen. Ockelbo fick slutligt besked att det faktiskt blir ett vite, vilket besvarades med att de tyckte det var orättvist. Men, hur går det för Pajalabostäder?