5.2 Metod
I detta avsnitt diskuteras de metoder som vi har använt för att besvara vår frågeställning.
5.2.1 Förstudie
Med hjälp av förstudien kunde vi se vad tänkta framtida användare uppskattade och la sitt värde i vid ett införande av en ny bostadsportal. Något som vi la märke till tidigt under förstudien, när vi testade enkäten internt, var att enkäten innehöll alldeles för många frågor. En stor del av frågorna gav inte någon hjälp till den kommande implementationen av webbapplikationen och plockades därför bort inför den andra och publika versionen av enkäten.
Den största delen av enkäten bestod av frågor där svaren kunde användas för att öka förståelsen för vad fokuset för webbapplikationen borde ligga på. Som beskrivet i avsnitt 4.1 i resultatet kunde vi till exempel se att 63,6 % av respondenterna höll med helt och hållet om att det vore lättare att hitta en bostad om annonser från privatpersoner var mer samlade i en och samma webbapplikation. Vi fick även reda på vilka de vanligaste svårigheterna är vid bostadssökande; detta var information som vi kunde ta hänsyn till när vi sedan skulle implementera vår bostadsportal.
För att kunna besvara vår frågeställning togs det stor beaktning till frågor och svar med fokus på tillgänglighet. Med hjälp av svaren på dessa frågor kunde vi se att till exempel bildtexter, tydliga knappar, och textuppläsning var något som hade hög påverkan på tillgängligheten; detta var således saker som vi behövde prioritera. En brist med dessa frågor var dock, då endast personer med en upplevd synnedsättning kunde besvara dem, att vi fick in väldigt få svar. Av enkätens respondenter var det endast 4,3 % som fyllde i att de har en synnedsättning som de upplever begränsar dem när de navigerar på webben. Att man inte alltid får den andel svar man önskar från ett visst segment i målgruppen kan bero på hur enkäten har spridits [16]. Det som borde ha gjorts annorlunda är därför att enkäten borde ha publicerats på fler forum för personer med upplevd synnedsättning. Fler svar från personer med upplevd synnedsättning hade lett till ett mer säkert och nyanserat resultat.
5.2.2 Tekniska verktyg
Vår utgångspunkt med de tekniska verktygen var till en början att göra tekniska tester med de till stor del automatiserade verktygen Google Lighthouse och WebAIM WAVE (se avsnitt 2.6.2i resul- tatet) på den version av webbapplikationen där all funktionalitet var implementerad men inte till- gänglighetsanpassad. Tanken var att få en analys från Google Lighthouse med en poäng från [1..100] och en lista med fel och varningar från WebAIM WAVE att utgå från i tillgänglighetsarbetet. När till- gänglighetsarbetet var färdigt planerade vi att göra ytterligare analyser med de två verktygen för att kunna jämföra poängen mellan iterationerna.
Vi insåg dock tidigt att Google Lighthouse tillgänglighetstest inte var heltäckande på vår webbap- plikation på grund av att verktyget endast analyserade den statiska HTML-koden, vilket innebar att HTML-kod injicerades med JavaScript inte analyserades. Validiteten av resultatet från Google Lighthouse har därmed visat sig lägre än vad vi tänkt oss från början, då den inte kan analysera hela webbapplikationen. WebAIM WAVE analyserade till skillnad från Google Lighthouse HTML- kod injicerad med JavaScript, men gav å sin sida ingen heltäckande indikation på hur tillgänglig webbapplikationen faktiskt var.
Som en följd av de brister vi funnit i Google Lighthouse och WebAIM WAVE för vårt syfte landade vi i att också använda oss av Microsoft Accessibility Insights (MAI) verktyg Assessment. MAI är mer omfattande än Lighthouse och WebAIM WAVE och inkluderar i större utsträckning även delar av WCAG 2.1 som inte testas automatiskt6vilket gör att vi anser att det var det mest användbara av de tre tekniska verktygen för att utvärdera tillgängligheten på vår webbapplikation.
5.2. Metod
Vi beslöt även att luta oss mer på att manuellt läsa textdokumentationen för tillgänglighetskriterier- na i WCAG 2.1. Detta innebar mer manuellt arbete, vilket delvis har inneburit att vi fångat tillgäng- lighetsproblem som automatiska tester missat, men också att kvaliteten på vårt tillgänglighetsarbe- te blivit mer beroende av vår förståelse för kriterierna i WCAG 2.1; till följd av brister i våra tekniska färdigheter har det varit svårare att manuellt hitta alla brister i tillgängligheten.
Dessa upptäckter och de metodförändringar som följ har implikationer för replikerbarheten av me- toden. Detta innebär dels att resultaten från Google Lighthouse är beroende av hur många delar av webbapplikationen som består av HTML-kod som injicerats med JavaScript, samt att kvaliteten på de manuella testerna är beroende av nivån av tekniska färdigheter hos de som utför dem. Tillför- litligheten i metoden är på sätt och vis stark på grund av att samma relevanta WCAG 2.1-kriterier kan uppfyllas genom att replikera metoden. Enligt Power et al. [18] innebär dock inte uppfyllnad av WCAG-kriterierna att webbapplikationen har god tillgänglighet, vilket innebär att studien vi ge- nomfört kan utföras igen enligt samma metod och uppfylla samma WCAG-kriterier, men ändå re- sultera i en annan tillgänglighetsnivå.
Den ursprungliga ambitionen var alltså att till stor grad kunna luta oss på tekniska verktyg för att ut- veckla en tillgänglig webbapplikation. Som redan diskuterats i detta kapitel behövde denna strategi omvärderas och förändras under arbetets gång då det tilltänkta primära verktyget (Google Light- house) helt enkelt var otillräckligt. Det ledde med tiden till insikten att det inte är så enkelt som att enbart köra källkoden för en webbapplikation genom ett verktyg, åtgärda eventuella problem och sedan vara färdig med sitt tillgänglighetsarbete. Detta hade dock varit önskvärt för att underlätta för webbutvecklare att utan omfattande specialkunskaper kunna utforma en mer tillgänglig webb. Vi ser användandet av tillgänglighetsverktyg som en bra utgångspunkt för att skriva kod på ett så- dant format att den underlättar för personer med till exempel synnedsättning. Det största proble- met med tekniska verktyg är att de är begränsade till just tekniska faktorer. Design och utformande överlag är svårare att dela upp i rätt och fel; två olika designer av samma funktionalitet som upp- fyller samma tekniska krav enligt WCAG är inte nödvändigtvis lika tillgängliga [18]. Analysverktyg för webbapplikationer har svårt att fånga upp och utvärdera designfaktorer. Detta medför att man som utvecklare dels behöver en egen förståelse för de riktlinjer och standarder som finns gällande tillgänglighet, och dels att de enskilda användarna av den aktuella applikationen behöver involve- ras under utvecklingen för att dessa ska få en så bra upplevelse som möjligt. Detta är även något som nämns av Highsmith & Cockburn [26] som menar att man genom att utföra användartester kan hitta eventuella brister redan under utvecklingen.
Trots att resultatet visar att vi har nått 100 poäng på alla vyer i Google Lighthouse så har våra ma- nuella tester visat att två WCAG-kriterier inte är helt uppfyllda. Vidare ser vi att om vi jämför för- bättringen mellan olika utvärderingar så ser vi att resultatet med Google Lighthouse förbättrades i snitt 41,4 % mellan före och efter tillgänglighetsåtgärder, medan användartesterna visar en förbätt- ring på 25,3 %. Detta skulle kunna vara ett resultat av att Google Lighthouse krävde förhållandevis små ändringar för att uppnå full poäng; dessa ändringar fick sedan inte ett lika stort genomslag på förbättringen i användartesterna.
Vidare ser vi även att de olika verktygen vi använt oss av ger olika resultat trots att de alla säger sig utgå ifrån WCAG 2.1. De verkar alltså analysera tillgängligheten på olika sätt; med detta i åtanke skulle vi rekommendera fortsatt användning av en kombination av samtliga verktyg även framöver i syfte att fånga upp så många tillgänglighetsbrister som möjligt.
5.2.3 Användartester
En brist i den metod vi använt för att besvara vår frågeställning är att inga användartester utfördes under implementationsprocessen vars resultat sedan kunde användas i den vidare utvecklingen av applikationen. För att identifiera tillgänglighetsproblem under utvecklingen användes istället tek- niska verktyg och textdokumentationen för WCAG 2.1. Enligt Highsmith et al. [26] är användartester en viktig del av utvecklingsprocessen för en webbapplikation. Det är därför möjligt att en viktig del
5.2. Metod
i processen för att utveckla en webbapplikation som är tillgänglig för synnedsatta är att utföra an- vändartester med synnedsatta personer under utvecklingsprocessens gång. Detta är en faktor som helt har utelämnats i vår metod och som vi därför inte har möjlighet att dra slutsatser kring. En annan brist i vår metod är att användartesterna inte utfördes med personer med verkliga syn- nedsättningar. Vår ambition i början av projektet var att utföra användartester med personer som använder skärmläsare när de navigerar på webben i sin vardag. Vi sökte kontakt i några Facebook- grupper för personer med synnedsättning för att hitta deltagare till användartesterna, men svalt intresse från dessa i kombination med de snäva tidsramarna för projektet gjorde att det till slut blev orimligt att få ihop testgrupper med synnedsatta personer. En annan faktor som försvårade användartester med personer med verkliga synnedsättningar var det rådande distansläget till följd av Covid-19-pandemin. Vi ansåg att användartester med testpersoner utanför gruppens nära krets skulle behöva utföras på distans vilket dels innebar tekniska hinder som att sätta upp distansåt- komst för webbapplikationen, samt att användartest på distans ansågs bli svårare att utföra i prak- tiken.
Vid utformandet av användartesterna drog vi slutsatsen att det skulle bli för komplext för testdel- tagare utan verkliga synnedsättningar att navigera endast med hjälp av skärmläsare helt utan att se skärmen. Detta berodde på att inlärningsprocessen för att nå tillräckligt hög användarvana om skärmläsare bedömdes vara för lång. Därför valde vi att använda Silktide Disability Simulator som kan göra webbapplikationens innehåll suddigt7så att all text blev oläslig medan testpersonerna fortfarande visuellt kunde ta till sig applikationens övergripande struktur.
I och med att testpersonerna alla var helt nya till användandet av skärmläsare valde vi att begrän- sa mängden kommandon vi lärde ut. Vår bedömning var att testerna skulle bli för avancerade om mängden kommandon var för stor, och då skulle ha lidande validitet eftersom de då skulle testa hur väl testpersonerna klarade av att lära sig att använda skärmläsaren, snarare än att testa webbappli- kationens tillgänglighet. Detta ledde dock troligtvis till att testdeltagarna navigerade vår webbappli- kation på ett sätt som skiljde sig från hur vana skärmläsaranvändare navigerar webben och därmed missade en del av de anpassningar vi gjort för att öka tillgängligheten. Korrekt användande av oli- ka headingnivåer och väl utsatta aria-landmarks ska minska den tid och ansträngning det tar för en blind användare med skärmläsare att navigera på webbapplikationen, men bedömdes som för avancerade funktioner för att inkludera i användartesterna.
Att deltagarna vid våra användartester sannolikt navigerade på webbapplikationen på ett sätt som skiljer sig från webbanvändare med verkliga synnedsättningar som är vana att använda skärmläsare riskerar alltså att påverka resultatet på flera sätt. För det första kunde vi som beskrivet ovan inte testa alla de tillgänglighetsanpassningar vi gjort. Detta innebär att användartesterna inte utvärderade tillgängligheten ur ett särskilt brett perspektiv. För det andra bör man vara kritisk till om feedback på vår webbapplikation från personer utan erfarenhet av att använda skärmläsare är representativ för den feedback vi hade fått om vi frågat en grupp av vana skärmläsaranvändare; detta gör att validititen för våra användartester, och därmed studien i sin helhet, är lägre än önskat.
Vidare kan det faktum att deltagarna var nya till skärmläsare innebära att deras inlärningskurva för användadet av verktyget kan ha haft betydlig påverkan på testernas resultat genom att deltagarna med stor sannolikhet var mycket bättre på att använda skärmläsaren vid testet av den andra versio- nen de testade, jämfört med den första.
Att hälften av deltagarna fick börja med den tillgänglighetsanpassade versionen och den andra hälf- ten med den oanpassade versionen var ett sätt att motverka inlärning hos testpersonerna. Både vad gäller webbapplikationens funktioner och hur den kan navigeras samt hur de verktyg som fanns tillgängliga fungerar. På grund av att testpersonerna var helt nya till användandet av skärmläsare väntades användarvana spela en stor roll i upplevd tillgänglighet.
Detta är ytterligare ett exempel på hur en testgrupp med vana skärmläsaranvändare vore att föredra då deltagarna i så fall hade besuttit samma färdigheter vid testandet av båda versionerna.