Räcker det med automatiska tester?
Att testa tillgängligheten för personer med funktionsnedsättning när man utvecklar digitala tjänster bör vara en självklarhet efter flera år med DOS-lagen och med lagen om digital tillgänglighet till produkter och tjänster runt hörnet. Men hur testar vi lämpligast – med automatiska verktyg, eller manuellt? Och när ska vi testa?
Låt oss börja med att definiera vad vi menar med ”digitala tjänster”. I den här artikeln använder vi begreppet på samma sätt som i de ovannämnda lagarna: en digital tjänst är en webbplats eller en mobil applikation (”app”). En webbplats kan vara såväl en informationswebbplats som en interaktiv e-tjänst, och den kan vara publik, privat (intranät) eller ha begränsad åtkomst (extranät).
Det tre huvudtyperna av tester av digital tillgänglighet är
- automatiska testverktyg
- manuella tester
- användartester.
Typerna överlappar varandra till viss del: manuell testning kan till exempel kombineras med testverktyg.
Vi kommer nu att titta på de tre typerna i tur och ordning, för att så småningom försöka sammanfatta hur vi lämpligen kan kombinera dem för bästa effektivitet.
Automatiska testverktyg
Det finns olika typer av mer eller mindre automatiska testverktyg för tillgänglighet:
- Webbaserade verktyg (externa eller interna).
- Serverbaserade verktyg (vanligen interna).
- Lokalt installerade verktyg.
- Tillägg för webbläsare.
Tillägg för webbläsare används främst i kombination med manuella tester, så vi behandlar dem i nästa avsnitt.
Webbaserade tjänster för test av tillgänglighet
Webbaserade testningstjänster tillhandahålls vanligen av någon leverantör och bor på leverantörens servrar, men det finns också varianter som går att installera på egna servrar för att slippa skicka känsliga data utanför organisationen. Vissa tjänster erbjuds kostnadsfritt, eventuellt med volymbegränsningar, medan andra är prenumerationsbaserade.
Av praktiska skäl går webbaserade testverktyg normalt bara att använda för att testa webbplatser; ofta bara publika sådana utan inloggning. Appar kräver andra lösningar.
Dessa tjänster fungerar vanligen så att en användare initierar testet genom att fylla i sökvägen till en sida att granska eller en hel webbplats där verktyget testar ett urval av sidor. Verktyget visar resultatet direkt på skärmen eller genererar en rapport som användaren kan ladda ned.
Den här typen av testverktyg lämpar sig bäst för stickprovstestning vid enstaka tillfällen.
Serverbaserade verktyg
Serverbaserade testverktyg är vanligen installerade på servrar inom organisationen, men det finns också externa prenumerationstjänster. Det finns verktyg som är fri, öppen programvara, liksom kommersiella produkter i varierande prisklasser. I likhet med webbaserade verktyg är de normalt begränsade till att testa webbplatser.
Serverbaserade verktyg är väl lämpade för kontinuerlig testning, men går ofta att använda även för sporadiska tester. De kan ha funktioner för att regelbundet övervaka alla sidor på en hel webbplats. Vissa kan ingå i leveranskedjan vid continuous delivery för att kvalitetssäkra allt innehåll innan det levereras till produktionsmiljö. Vid övervakning eller leveranskontroll genererar verktygen rapporter som till exempel skickas automatiskt till berörda personer via e-post.
Vissa verktyg i den här kategorin kontrollerar även kvalitet utöver tillgänglighet, såsom rättstavning, brutna länkar och svarstider.
Lokalt installerade verktyg
Vissa verktyg vars funktion liknar de serverbaserades är möjliga att installera lokalt på exempelvis utvecklares datorer. I den här kategorin ingår testfunktioner för tillgänglighet som finns i integrerade utvecklingsmiljöer för appar.
Lokala verktyg lämpar sig främst för testning under utvecklingsfasen, särskilt för appar.
Fördelar och nackdelar med automatiska testverktyg
Den stora fördelen med automatiska verktyg är att de är snabba och kan granska stora mängder av webbsidor och dokument, exempelvis kontinuerlig övervakning av en hel webbplats. Det krävs ingen speciell kompetens för att köra verktygen, men däremot för att förstå de genererade rapporterna. Verktyg är också bra på att hitta fel i koden som bygger upp sidan (vanligen HTML, CSS och JavaScript). Sådana fel har en tendens att drunkna i mängden av data och missas därför lätt av mänskliga testare.
Nackdelen är främst att bara en liten bråkdel av tillgänglighetskraven är möjliga att testa helt automatiskt. Och tillgänglighetskraven täcker i sin tur bara den del av behoven som är möjlig att verifiera någotsånär objektivt. Många verktyg indikerar misstänkta brister som behöver verifieras manuellt. Automatiska verktyg kan alltså varna för troliga brister, men kan aldrig ”godkänna” något. Ett nollresultat från en automatisk granskning innebär inte att tjänsten är tillgänglig, utan att bara de svåra bristerna återstår…
Artificiell intelligens (AI) kan komma att förändra den här bilden så småningom.
Manuell testning av tillgänglighet
Att manuellt testa tillgängligheten hos webbsidor, e-tjänster och appar kan vara ett hantverk som kräver kompetens, noggrannhet och tålamod. Väldefinierade rutiner är till stor hjälp och kan göra det möjligt även för personer utan expertkompetens att utföra de flesta tester.
Grunden för strukturerad manuell testning är någon form av testmanual eller checklista att följa. För att verifiera överensstämmelse med lagkraven kan det handla om närmare hundra kontroller per sida i extrema fall, och för att verifiera att det faktiskt fungerar för riktiga användare krävs ännu mer. Det är ogörligt att täcka in allt om man testar på måfå: det krävs struktur.
Det kan vara fördelaktigt att kombinera manuell testning med viss automatik i form av tillägg för webbläsaren som kan göra en första analys av en webbsida och flagga för vissa typer av fel. Resultatet kan gå att använda för att avgränsa den manuella testningen till de mest problematiska delarna av innehållet.
Andra typer av tillägg assisterar testaren på olika sätt, till exempel genom funktioner för att stänga av JavaScript eller CSS, visa bilders alt-texter, utöka textavstånden till vad lagen kräver, och så vidare.
Det finns också tillägg och program som kan beräkna kontrastförhållandet mellan två färger, eller utföra andra typer av komplexa beräkningar som krävs för att kunna verifiera vissa av de mer tekniska kraven.
Webbläsarnas inbyggda utvecklarverktyg är en annan ovärderlig hjälp för testare. De kan till exempel visualisera den information som webbläsaren förmedlar till hjälpmedel, såsom skärmläsare. Viss kompetens krävs oundvikligen för att kunna tolka resultatet.
Manuell testning bör ske i olika faser av utvecklingen. Utvecklarna som bygger koden behöver göra vissa kontroller för att säkerställa att resultatet fungerar med hjälpmedel, liksom grundläggande verifiering av att alla funktioner går att använda via tangentbordet. När utvecklarna levererat behöver systemtestare ta vid och kontrollera att de olika komponenterna fungerar tillsammans på ett konsekvent sätt. De bör helst kunna göra en del tester även med hjälpmedel.
När det gäller vanliga statiska webbsidor är det ofta kommunikatörer eller webbredaktörer som står för produktionen och det finns sällan avdelade testare. Den som skapar innehållet behöver därför kunna göra elementära tester själv. Tester av innehåll är inte så krävande som tester av interaktiva funktioner, men är minst lika viktiga.
Tjänster och icke-trivialt innehåll behöver vi testa med olika typer av hjälpmedel, exempelvis skärmläsare (för synskadade liksom för personer med lässvårigheter), punktskriftsdisplay, förstorande hjälpmedel och röststyrning. Vissa av de här hjälpmedlen kräver mycket tid och ansträngning att lära sig behärska och det kan vara svårt att uppnå, och bibehålla, den kompetensen om man inte använder verktyget i vardagen. Därför bör vi helst låta dagliganvändare av hjälpmedel utföra den här typen av tester. Om de inte finns inom den egna organisationen kan vi ta hjälp av externa användare. Det handlar emellertid fortfarande om samma typer av detaljerade tester, inte om användartester som vi strax ska titta på.
Fördelar och nackdelar med manuella tester
Den viktigaste fördelen är att manuella tester kan hitta alla typer av tillgänglighetsproblem, inte bara de som går att verifiera maskinellt. Ett talesätt säger att det som ska förstås av maskiner ska testas av maskiner, men det som rör människor behöver testas av människor.
Nackdelar med manuella tester är att de kräver god kompetens hos dem som testar och att testerna är tidskrävande och mentalt tröttande. En människa orkar knappast tillgänglighetstesta åtta timmar per dag. Det är också lätt för en mänsklig testare att missa små fel, särskilt i innehåll som inte alltid är synligt, till exempel utfällbara avsnitt. En annan nackdel just nu är att det råder skriande brist på kompetenta tillgänglighetstestare i Sverige.
Användartester
Automatiska och manuella tester har ofta ett fokus på detaljer, och detaljer är viktiga, men vi får inte glömma helheten, och här kommer användartester in i bilden.
Användartester innebär att vi tar hjälp av ”vanliga” användare för att kontrollera om det vi producerat faktiskt fungerar för målgruppen. Testarna bör vara representativa för målgruppen, och det inkluderar förstås personer med olika typer av funktionsnedsättning – fysiska som kognitiva.
Vid användartester finns fokus på detaljer, som att en viss komponent fungerar med ett visst hjälpmedel, men också på mer övergripande frågor i det som brukar kallas användarupplevelsen. Uppfattar användarna intuitivt hur de ska göra, eller behöver de instruktioner?Förstår de instruktionerna? Känner de sig trygga eller osäkra i användandet av tjänsten?
Det är vanligt att filma användarna medan de utför testerna, för att kunna analysera interaktionsmönster och användningsstrategier i efterhand samtidigt som användarna får testa ostörda. Användarna ombeds att ”tänka högt” för att de som studerar filmen lättare ska förstå varför användaren agerade på ett annat sätt än formgivare och utvecklare avsett.
Fördelar och nackdelar med användartester
Användartester har den uppenbara fördelen att de faktiskt testar vad som fungerar för riktiga, levande människor med individuella variationer, i stället för att verifiera teoretiska lagkrav.
En nackdel är att praktiska användartester inte går att utföra förrän det finns något att testa, vilket ibland kan vara sent i utvecklingsprocessen. Följden blir att brister som uppdagas kan bli dyra att åtgärda. Användartester är också resursintensiva: det behövs dels användare som utför testerna, dels handledare som instruerar och hjälper, dels uppföljning och analys. Sätter vi ihop grupperna inför varje testtillfälle medför det administration och långa ledtider. Det kan dessutom vara svårt att få ihop representativa grupper, särskilt på mindre orter.
