Genomförda tillgänglighetsanpassningar

Från resultatet kan det först och främst konstateras att vår webbapplikation under implementa- tionens andra iteration har genomgått en stor förändring sett ur ett tillgänglighetsperspektiv. Med hjälp av tekniska verktyg lyckades vi förbättra applikationen avsevärt, något som tydligt framkom i användartesterna. Resultaten från de tekniska testerna gick från att peka på klart bristande till- gänglighet till att uppnå eller närma sig högsta möjliga betyg i de olika tekniska testerna. Resultatet från användartesterna tyder på en tydlig preferens för den version av webbapplikationen som in- kluderar våra tillgänglighetsanpassningar. En annan intressant observation är att de brister som vår

5.1. Resultat

applikation hade innan tillgänglighetsarbetet ofta förekommer som problem i den teori som tidiga- re presenterats. Exempelvis menar AlJarallah et al. [2] att kontraster är något som är ett problem för de med synnedsättning, vilket även var något som vi behövde åtgärda i vårt tillgänglighetsarbete. De förändringar som gjordes i syfte att öka webbapplikationens tillgänglighet kan läsas om i resul- tatavsnitt 4.2 och 4.3. Vi ser att de flesta förändringar är tämligen små och att de utan större problem hade kunnat göras direkt i första implementationen, givet att utvecklaren besitter viss kunskap och har tillgänglighet i åtanke under arbetets gång. Många av de problem som pekades ut av de tekniska verktyg som användes kunde lösas med hjälp av dynamiska taggar, labels och/eller ID:n, som alltså bör bli unika och beskriva vad varje element visar. Exempel på detta är de dynamiska aria-labels för unika bostadsannonser som nämns i avsnitt 4.3. De ändringar som hade allra störst påverkan på tillgängligheten var en adderad röstuppläsning vid formulär och knappar samt en justerad ta- bordning. Genom att lägga till så att skärmläsaren läste upp vad för typ av fält eller knapp som användaren var på så blev sidan oerhört mycket mer lättillgänglig. Att dessutom justera till en mer logisk tabordning gjorde att sidan blev enklare och mer förutsägbar för användaren.

De tekniska verktygen anmärkte också på ordningen som de olika nivåerna av rubriker låg i. Detta har ingen påverkan för användare som navigerar webben med hjälp av muspekaren men blir snabbt problematiskt för användare som nyttjar skärmläsaren, vilket enligt Babu et al. [6] ofta är fallet för användare med synnedsättning. Eftersom skärmläsaranvändare kan ta fram sorterade listor av vilka rubriker som finns på vyn och orientera sig efter dessa, är denna snabba förändring något som kan göra en märkbar skillnad i tillgängligheten för synnedsatta. De flesta förändringar som gjordes i tillgänglighetssyfte var av liknande komplexitet och gjordes för att förbättra upplevelsen för de användare som nyttjar olika former av automatiska skärmläsare, utan att synas för användare utan skärmläsare.

Vi fann att de brister som påpekats av Google Lighthouse överlag var tämligen enkla att åtgärda: att ge knappar tillgängliga namn, lägga till alt-taggar på bilder och aria-labels på element är alla åtgärder som vi såg som snabbfixade, och som inte krävde strukturella ändringar av webbapplika- tionen. Även korrigering av färgkontraster och heading-hierarkier kunde vi snabbt korrigera utan att det krävde omfattande arbete. Det tog oss mellan några minuter och en timme per enskild vy att åtgärda problemen och nå upp till maxbetyget 100 på alla webbapplikationens vyer.

En faktor som kan ha påverkat hur omfattande skillnaden blev i användartesterna av versionen utan tillgänglighetsåtgärder och versionen med tillgänglighetsåtgärder är att vi använde av oss av Bootstrap-element från början under implementationen. Vi upptäckte att flera av Bootstraps ko- dexempel är skrivna med tillgänglighet i åtanke, vilket innebär att användning av dessa innebär en viss tillgänglighetsanpassning utan att utvecklaren behöver vara medveten om det.

Exempel på inbyggd tillgänglighetsanpassning i Bootstrap-element såg vi i modaler och formulär. Modalerna innehåller ‘aria-labelled-by’-ID:n som gör modalens titel till en beskrivning av elemen- tet som läses upp av skärmläsaren. För formulär används label-element med ‘for’-attribut som kopplar fälten i formulären till fältbeskrivningen på liknande sätt. För att dessa ska fungera som tänkt krävs dock att attributen kopplas till rätt ID, vilket kräver viss förståelse hos utvecklaren för hur attributen fungerar. När det gäller modalerna använde vi inte dessa labels korrekt från början för att vi inte förstod funktionen av ‘aria-labelled-by’, vilket resulterade i att fel modaltitlar lästes upp på modalerna under testet på versionen utan tillgänglighetsåtgärder. I versionen utan tillgäng- lighetsåtgärder var däremot en stor del av formulären redan skrivna på korrekt sätt vilket innebar att fältetiketter lästes upp korrekt även i den versionen, varför skillnaden på just den punkten inte blev särskilt stor i användartesterna.

Resultaten från de utvärderande tester som gjordes visar en förbättring mellan versionen utan till- gänglighetsförbättringar och versionen med dessa. Det visar sig framför allt när det kommer till snittbetyget på de frågor som ställdes. På alla frågor där man ombads att svara med en siffra mellan ett och fem (kvantitativa) presterade den slutgiltiga versionen bättre. När det kommer till svar där man fick ge sin åsikt i text (kvalitativa) svarade en del testpersoner att man inte upplevde någon

5.1. Resultat

skillnad när man bytte version, och detta gällde oavsett vilken version man började med. I reste- rande textsvar var dock åsikten att den slutgiltiga versionen upplevdes som bättre. De anpassningar och förändringar som har gjorts visade sig alltså i slutändan ge en ökad tillgänglighet i praktiken och inte enbart i teorin.

Webbapplikationens hierarkiska struktur, det vill säga kopplingen mellan applikationens olika vyer, utformades för att vara relativt grund vilket enligt Hochheiser et al. underlättar navigation både för användare med och utan synnedsättningar [14]. De allra flesta av applikationens olika vyer går att nå från applikationens navbar, vilken kan ses i figur 4.1 i resultatavsnittet. Den utvecklade appli- kationen innehåller en relativt begränsad mängd olika vyer vilket gör att menyerna med länkar, till exempel navbaren, inte blir särskilt lång trots att länkstrukturen är grund. Vidare kan även applika- tionens hem-vy nås med maximalt två klick från varje ställe i applikationen, vilket uppfyller regeln om att hemvyn ska kunna nås med maximalt tre klick [10].