Testning av tillgänglighet: manuellt vs automatiskt
Automatiska verktyg hittar det mätbara. Tangentbordet hittar det interaktiva. Skärmläsaren hittar det upplevda. Hoppa inte över något av dem.
“Ska vi testa manuellt eller automatiskt?” Frågan dyker upp i nästan varje team som börjar ta tillgänglighet på allvar. Och svaret är alltid detsamma: ja. Båda. Men inte på samma sätt och inte i samma fas. Automatiska verktyg och manuell testning hittar olika typer av problem, och inget av dem ersätter det andra. Ett team som bara kör automatiska skanningar missar majoriteten av de verkliga hindren. Ett team som bara testar manuellt missar regressioner som smyger sig in mellan releases.
Den här artikeln handlar om hur du kombinerar dem.
Vad automatiska verktyg faktiskt hittar
Det finns en siffra som cirkulerar i branschen: att automatiska verktyg bara hittar 30 procent av alla tillgänglighetsfel. Den siffran är ungefärlig och varierar beroende på hur man räknar, men den pekar åt rätt håll. Deque, som utvecklar axe-core, har i sin analys av över 13 000 sidor visat att ungefär 57 procent av alla enskilda problemförekomster kan fångas automatiskt. Men det handlar om förekomster, inte typer av problem.
Om man tittar på WCAG 2.1 på nivå AA (nivå A och AA, totalt 50 kriterier) ser bilden ut ungefär så här: en del kriterier kan automatiskt avgöras med hög träffsäkerhet. En större del kan verktyg stötta med signaler, men kräver mänskligt beslut. Och en betydande del går inte att automatisera meningsfullt. Inget enskilt kriterium kan uppfyllas helt med enbart automatisk testning.
Det som automatiska verktyg är bra på är tydliga, programmatiskt mätbara fel. Saknar en bild alt-text? Det kan en maskin hitta. Har en knapp inget tillgängligt namn? Automatiskt. Är kontrasten mellan text och bakgrund under 4,5:1? Matematiskt mätbart. Används aria-hidden="true" på ett element som har fokus? Regelbrott som axe-core fångar direkt.
Det som automatiska verktyg inte kan bedöma är om något är meningsfullt. En bild med alt="bild" passerar den automatiska kontrollen, men är värdelös för en skärmläsaranvändare. Ett formulär kan ha etiketter på alla fält men ändå vara obegripligt om instruktionerna saknas eller är otydliga. En modal kan ha korrekt ARIA men ändå vara oanvändbar om fokus inte hanteras rätt vid öppning och stängning.
Automatiska verktyg svarar på frågan “finns det?” Manuell testning svarar på frågan “fungerar det?”
Tangentbordstestning: den enklaste manuella kontrollen
Om du bara gör en enda manuell kontroll, gör den här: lägg bort musen och navigera hela flödet med tangentbordet.
Tryck Tab för att flytta fokus framåt. Shift+Tab bakåt. Enter eller mellanslag för att aktivera knappar och länkar. Piltangenter för att navigera i dropdown-menyer, radioknappar och flikar. Escape för att stänga modaler och popups.
Det du letar efter är enkelt. Kan du nå alla interaktiva element? Ser du var fokus befinner sig? Följer tabbordningen en logisk sekvens? Fastnar fokus någonstans, till exempel i en modal som inte går att stänga med Escape? Kan du genomföra hela uppgiften, från start till slut, utan att röra musen?
Och leta specifikt efter den enskilt största synden inom webbdesign: :focus { outline: none; }. Den raden CSS, ofta tillagd för att “städa bort den fula ringen”, gör sajten oanvändbar för tangentbordsanvändare. Hitta den och förstör den.
Tangentbordstestning kräver ingen specialkompetens och inga verktyg. Det tar tio minuter per flöde. Och det fångar problem som ingen automatisk skanning kan upptäcka: fokus som hoppar oförutsägbart, element som inte går att aktivera, flöden som helt enkelt inte fungerar utan pekdon.
Skärmläsartestning: nästa steg
Skärmläsartestning går djupare. Här handlar det inte bara om att du kan nå ett element, utan om att elementet presenteras korrekt: rätt roll, rätt namn, rätt tillstånd.
Vanliga kombinationer för webbtestning är JAWS med Chrome, NVDA med Chrome, JAWS med Edge och NVDA med Firefox på Windows, samt VoiceOver med Safari på macOS. Om du bara väljer en startkombination: NVDA på Windows (gärna i Chrome eller Firefox) och VoiceOver med Safari på macOS täcker mycket.
Vad du lyssnar efter: annonseras knappar som knappar? Läses formuläretiketter upp när fältet får fokus? Kommuniceras tillståndsändringar, som att en accordion öppnas eller att ett felmeddelande dyker upp? Kan du förstå vad som händer på sidan utan att se den?
Skärmläsartestning kräver mer övning än tangentbordstestning, men du behöver inte vara expert. Redan efter en timmes träning kan du fånga de grövre problemen: knappar utan namn, bilder utan beskrivning, formulär där etiketter inte läses upp.
En viktig brasklapp: en seende utvecklare som kör skärmläsare testar teknisk efterlevnad, inte verklig användbarhet. Du kontrollerar att rätt ARIA-roller finns och att saker annonseras, men du navigerar fortfarande med ögonen som stöd. För att verkligen veta om ett flöde fungerar behövs tester med personer som använder hjälpmedel dagligen. Det är nästa nivå av mognad, och dit bör varje team sikta på sikt.
Automatiskt i CI: skyddsnätet
Om manuell testning fångar de kvalitativa problemen, är automatisk testning i CI-pipelinen skyddsnätet som förhindrar att redan lösta problem återkommer.
axe-core är branschstandarden här. Det är motorn bakom Lighthouse tillgänglighetsresultat, bakom Storybook addon-a11y, och bakom de flesta CI-integrationer för tillgänglighet. Verktyget kan köras mot enskilda komponenter i Storybook, mot hela sidor via Playwright eller Cypress, och som ett steg i build-pipelinen som blockerar deploy om nya fel introduceras.
En praktisk uppdelning fungerar i tre lager. Komponenttester körs på varje pull request och tar sekunder. De fångar saker som saknade etiketter och felaktig ARIA på komponentnivå. Integrationstester körs vid merge och testar kritiska flöden: kan en användare logga in, söka, lägga i varukorg och slutföra köp? Fullständiga skanningar körs nattligt eller veckovis och täcker hela sajten.
Poängen med den här uppdelningen är hastighet. Du vill att den snabbaste feedbacken kommer först, så att utvecklaren får besked innan koden ens har lämnat den lokala branchen.
Men var medveten om att CI-skanningar kan ge falsk trygghet. En sida kan ha noll fel i axe-core och ändå vara helt blockerad för en användare. Verktyget hittar regelbaserade fel, men det hittar inte om en rubrik är otydlig, om alt-texter är meningslösa, eller om ett flöde är kognitivt rörigt. Det är därför de andra lagren inte är valfria.
Kombinationen i praktiken
Ett team som tar tillgänglighetstest på allvar behöver inte göra allt från dag ett. Men riktningen bör vara tydlig.
Tangentbordstestning görs av utvecklaren under utveckling. Innan en pull request skapas bör utvecklaren ha tabbat igenom sitt eget flöde. Det tar minuter och fångar interaktionsproblem som ingen maskin ser.
Automatiska tester i CI fångar regressioner och uppenbara fel. De körs utan mänsklig insats och skalar med kodens storlek. De är skyddsnätet.
Skärmläsartestning görs av QA eller av en dedikerad person vid större releaser eller nya funktioner. Det är den djupaste kontrollen, men kom ihåg att en utvecklare med skärmläsare testar efterlevnad. Riktiga användartester med personer som använder hjälpmedel dagligen är det som visar om produkten verkligen fungerar.
De tre lagren kompletterar varandra. Automatiskt fångar det mätbara. Tangentbord fångar det interaktiva. Skärmläsare fångar det upplevda. Att hoppa över något av dem lämnar en blind fläck.
Börja med ett lager
Om ditt team inte testar tillgänglighet alls, börja med det som kostar noll och ger omedelbar effekt: tangentbordstestning som vana. “Har du tabbat igenom flödet?” är den enda frågan som behövs i kodgranskningen för att fånga problem som ingen maskin ser. Det bygger kultur och kompetens samtidigt.
När den vanan sitter, lägg till axe-core i CI-pipelinen. Det tar en eftermiddag att sätta upp och ger automatisk feedback på varje pull request. Då har du ett skyddsnät som fångar regressioner utan mänsklig insats.
Skärmläsartestning kommer sist, men det kommer. Kör det vid större releaser och på nyckelflöden. Ju fler tangentbords- och regelbaserade fel ni redan har eliminerat, desto mer meningsfull blir skärmläsartestningen, för den slipper fastna på grundläggande problem och kan fokusera på det som verkligen kräver mänsklig bedömning.
Tillgänglighetstestning är inte en punkt på en checklista. Det är tre lager av skydd, och varje lager du lägger till gör produkten bättre.