Linköpings universitet SE–581 83 Linköping
Linköpings universitet | Institutionen för datavetenskap
Examensarbete på grundnivå, 18hp | Datateknik
21 | LIU-IDA/LITH-EX-G--21/010--SE
Subbo: Uthyrning av bostäder på
nätet med fokus på tillgänglighet
Housing rentals online with a focus on accessibility
Linus Bergström
Isak Berntsson
Vincent Bring
Ludvig Eriksson-Knast
Anton Jervebo
Victor Jonsson
Cecilia Persson
Alva Ringi
Handledare : Hanna Müller Examinator : Aseel Berglund
Upphovsrätt
Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publice-ringsdatum under förutsättning att inga extraordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Över-föring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och till-gängligheten finns lösningar av teknisk och administrativ art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet änd-ras eller presenteänd-ras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.
The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.
For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/. © Linus Bergström Isak Berntsson Vincent Bring Ludvig Eriksson-Knast Anton Jervebo Victor Jonsson Cecilia Persson Alva Ringi
Sammanfattning
Studier visar att en majoritet av alla webbapplikationer inte är tillgängliga för användare med synnedsättning och det råder delade meningar om hur mycket extra arbete som krävs för att en webbapplikation ska bli tillgänglig för dessa användare. Vårt syfte är att utreda hur en webbap-plikation för uthyrning av bostäder kan utformas för att vara tillgänglig för personer med synned-sättning.
Vi delade in vår utveckling i två iterationer där den första iterationen gick ut på att utveckla web-bapplikationen utan fokus på tillgänglighet. Målet med den andra iterationen var att uppnå nivån AA enligt WCAG 2.1-riktlinjerna framtagna av World Wide Web Consortium (W3C). AA är den ni-vå som all webb-baserad information rekommenderas uppfylla. Under ni-vårt tillgänglighetsarbete användes textdokumentation för WCAG 2.1 tillsammans med tre populära verktyg för att identi-fiera tillgänglighetsproblem och bedöma webbapplikationens tillgänglighetsnivå.
Efter den andra iterationen genomfördes användartester med simulerad synnedsättning. Test-personerna genomförde ett antal uppgifter i vår webbapplikation, både i en version med och en utan våra tillgänglighetsanpassningar. Resultatet av dessa tester samt den nådda följsamheten av WCAG 2.1-riktlinjerna utgör grunden för våra resultat.
Efter tillgänglighetsarbetet i den andra iterationen uppfyller webbapplikationen 48 av 50 krav för att uppnå nivån AA; klart fler än innan tillgänglighetsanpassningarna. Våra användartester indikerade tydliga förbättringar och testpersonerna upplevde en högre grad av tillgänglighet i den anpassade versionen av webbapplikationen.
Studien mynnade ut i slutsatsen att bland annat kontrasten mellan bakgrund och förgrund, kor-rekt användning av heading-element, och logisk tab-ordning hade inverkan på hur tillgänglig vår webbapplikation bedömdes vara.
Abstract
Studies show that a majority of all web applications are not accessible for users with visual im-pairments and opinions differ on how much extra work is required in order to make a web appli-cation accessible for these users. Our purpose is investigating how a web appliappli-cation for housing rentals can be developed in order to be accessible for visually impaired users.
We split our development into two iterations where the first one was about developing the web application without focus on accessibility. The goal of the second iteration was to achieve level AA according to the WCAG 2.1 guidelines developed by the World Wide Web Consortium (W3C). AA is the level that all web based information is recommended to achieve. During our accessibi-lity work, text documentation for WCAG 2.1 was used along with three popular tools to identify accessibility issues and judge the accessibility level of the web application.
After the second iteration, user tests were conducted with simulated visual impairments. The test persons carried out a number of tasks in our web application, both in a version with and one without our accessibility adjustments. The result of these tests as well as the achieved level of compliance with the WCAG 2.1 guidelines make up the basis of our results.
After the accessibility work in the last iteration the web application achieves 48 out of 50 require-ments to reach the level AA; unequivocally more than before the accessibility adjustrequire-ments. Our user tests indicated clear improvements and the test persons experienced a higher degree of ac-cessibility in the adjusted version of the web application.
The study resulted in the conclusion that among other things the contrast between background and foreground, correct usage of heading elements, and logical tab order had an impact on how accessible the web applicationed was deemed to be.
Författarnas tack
Först och främst vill vi tacka vår handledare Hanna Müller som varit en stor tillgång för oss under arbetets alla faser och kunnat svara på alla de frågor som dykt upp under arbetets gång. Vidare vill vi även tacka vår examinator, Aseel Berglund, som gav oss både idé och uppmuntran att arbeta med tillgänglighetsperspektivet för webbutveckling. Detta är något som vi i slutändan lärt oss långt myc-ket mer om än vi hade kunnat föreställa oss. Slutligen vill vi tacka de grupper vi haft kontakt med under arbetets gång. Om dessa har vi endast bra saker att säga och deras synpunkter och konstruk-tiva kritik är en bidragande faktor till varför vår slutprodukt ser ut som den gör.
Innehåll
Sammanfattning iii Abstract iii Författarnas tack iv Innehåll v Figurer viii Tabeller x 1 Introduktion 1 1.1 Motivering . . . 1 1.2 Syfte . . . 2 1.3 Frågeställning . . . 2 1.4 Avgränsningar . . . 2 2 Teori 4 2.1 Tillgänglighet på webben idag . . . 42.2 Hinder för webbanvändare med nedsatt syn . . . 5
2.3 Tillgänglighet . . . 6
2.4 Navigerbarhet och tillgänglighet . . . 6
2.5 Web Content Accessibility Guidelines . . . 7
2.5.1 Principer och riktlinjer . . . 8
2.5.2 Framgångskriterier och tekniker . . . 9
2.5.2.1 Nivå A . . . 9 2.5.2.2 Nivå AA . . . 9 2.5.2.3 Nivå AAA . . . 10 2.6 Metodteori . . . 10 2.6.1 Enkätmetodik . . . 10 2.6.2 Verktyg för tillgänglighetsanalys . . . 11 2.6.2.1 Google Lighthouse . . . 11 2.6.2.2 WebAIM WAVE . . . 11
2.6.2.3 Microsoft Accessibility Insights . . . 12
2.6.2.4 Silktide Disability Simulator . . . 12
2.6.3 Användartester . . . 12 2.6.3.1 Think-aloud-tester . . . 13 2.6.3.2 Retrospective probing . . . 13 2.6.3.3 Sammansättning av testgrupper . . . 14 3 Metod 15 3.1 Förstudie . . . 15
3.2 Implementation . . . 15
3.2.1 Google Lighthouse . . . 16
3.2.2 WebAIM WAVE . . . 17
3.2.3 Microsoft Accessibility Insights . . . 18
3.2.4 Webbtekniker . . . 19 3.3 Utvärdering . . . 19 3.3.1 Tekniska verktyg . . . 20 3.3.2 Användartester . . . 20 3.3.2.1 Uppdelning av testgrupper . . . 20 3.3.2.2 Genomförande . . . 21 4 Resultat 24 4.1 Förstudie . . . 24 4.2 Implementation . . . 26
4.2.1 Den utvecklade webbapplikationen . . . 26
4.2.1.1 Hem-vyn . . . 26 4.2.1.2 Lägg upp annons-vyn . . . 26 4.2.1.3 Bostäder-vyn . . . 27 4.2.1.4 Annons-vyn . . . 27 4.2.1.5 Mina sidor-vyn . . . 28 4.2.1.6 Chatt-vyn . . . 29 4.2.2 Webbtekniker . . . 29
4.2.3 Tillgänglighetsarbete med Google Lighthouse . . . 30
4.2.3.1 Språk . . . 30
4.2.3.2 Kontraster . . . 30
4.2.3.3 Headinganvändning . . . 31
4.2.4 Tillgänglighetsarbete med WebAIM WAVE . . . 32
4.2.4.1 Fältetiketter . . . 32
4.2.4.2 Aria-etiketter . . . 32
4.2.4.3 Kontraster . . . 33
4.2.5 Tillgänglighetsarbete med Microsoft Accessibility Insights . . . 33
4.2.5.1 Dynamiska aria-labels . . . 33
4.2.5.2 Skip-links och landmarks . . . 34
4.2.5.3 Tillgängliga bilder . . . 35
4.2.5.4 Nåbara knappar . . . 36
4.2.5.5 Sidtitlar . . . 37
4.2.5.6 Formvalidering . . . 37
4.3 Utvärdering . . . 38
4.3.1 Tillgänglighetsarbete med Google Lighthouse . . . 38
4.3.2 Tillgänglighetsarbete med Microsoft Accessibility Insights . . . 39
4.3.3 Uppfyllande av WCAG 2.1 . . . 41
4.3.4 Användartester . . . 41
4.3.4.1 Concurrent think-aloud (CTA) . . . 42
4.3.4.2 Retrospective probing . . . 43
5 Diskussion 45 5.1 Resultat . . . 45
5.1.1 Genomförda tillgänglighetsanpassningar . . . 45
5.1.2 Vidare tillgänglighetsanpassningar . . . 47
5.1.3 Verktyg för analys av tillgänglighet . . . 48
5.1.4 Tillgänglighet och användare utan funktionsnedsättning . . . 48
5.2 Metod . . . 49
5.2.2 Tekniska verktyg . . . 49
5.2.3 Användartester . . . 50
5.2.4 Källkritik . . . 52
5.3 Arbetet i ett vidare sammanhang . . . 52
6 Slutsats 54 Litteratur 56 A Appendix A: Marknadsundersökning 58 B Appendix B: Marknadsföringsplan 73 B.1 Inledning . . . 74 B.1.1 NABC-analys . . . 74 B.2 Omvärldsanalys . . . 75 B.2.1 PEST-analys . . . 75 B.2.2 Porters femkraftsmodell . . . 77 B.3 SWOT-analys . . . 78 B.4 Marknadsmål . . . 79 B.5 Marknadsstrategi . . . 80 B.6 STP . . . 80 B.7 Marknadsmix . . . 83 Referenser . . . 90
C Appendix C: Data från användartester 91 C.1 Data från concurrent think-aloud-tester . . . 92
C.1.1 Testgrupp 1, version utan tillgänglighetsanpassningar först . . . 92
C.1.1.1 Uppgift 1.1, skapa ett konto och logga in . . . 92
C.1.1.2 Uppgift 1.2, Skapa en annons . . . 93
C.1.1.3 Uppgift 1.3, Redigera din profil (t.ex. förnamn) . . . 95
C.1.1.4 Uppgift 1.4, Intresseanmäl dig på Bygdegatan 301 . . . 95
C.1.1.5 Uppgift 2.1, skapa ett konto och logga in . . . 96
C.1.1.6 Uppgift 2.2, Skapa en annons . . . 96
C.1.1.7 Uppgift 2.3, Redigera din annons på Mina Sidor . . . 97
C.1.1.8 Uppgift 2.4, Intresseanmäl dig på Bygdegatan 301 . . . 98
C.1.2 Testgrupp 2, . . . 98
C.1.2.1 Uppgift 1.1, skapa ett konto och logga in . . . 98
C.1.2.2 Uppgift 1.2, Skapa en annons . . . 99
C.1.2.3 Uppgift 1.3, Redigera din profil (t.ex. förnamn) . . . 100
C.1.2.4 Uppgift 1.4, Intresseanmäl dig på Bygdegatan 301 . . . 101
C.1.2.5 Uppgift 2.1, skapa ett konto och logga in . . . 101
C.1.2.6 Uppgift 2.2, Skapa en annons . . . 102
C.1.2.7 Uppgift 2.3, Redigera din annons på Mina Sidor . . . 103
C.1.2.8 Uppgift 2.4, Intresseanmäl dig på Skomakaregatan 11 . . . 103
Figurer
2.1 Exempel på hur text kan se ut med tre olika kontrastförhållanden mellan text och bak-grund. För att uppfylla framgångskriterium 1.4.3 från WCAG 2.1 krävs att
konstrastför-hållandet är minst 4,5:1. . . 10
3.1 Exempel på en rapport genererad på hem-vyn med Google Lighthouse. . . 17
3.2 Exempel på hur WebAIM WAVE användes. . . 18
3.3 Exempel på hur Microsoft Accessibility Insights användes för att utvärdera tab-ordningen. 19 3.4 Processen som följdes vid användartesterna för testgrupp 1. . . 21
3.5 Processen som följdes vid användartesterna för testgrupp 2. . . 21
3.6 Startvyn på subbo.se med 100 % suddighet i Silktide Disability Simulator. . . 22
4.1 Hem-vyn. . . 26
4.2 Vy för att lägga upp en annons. . . 27
4.3 Vyn för att se vilka bostäder som finns tillgängliga att hyra. . . 27
4.4 Vyn för att se mer information om en specifik bostad. . . 28
4.5 Mina sidor-vyn. . . 29
4.6 Chatt-vyn. . . 29
4.7 Kontraster innan tillgänglighetsarbete. . . 30
4.8 Kontraster efter tillgänglighetsarbete. . . 30
4.9 De rubriker som fanns innan tillgänglighetsanpassningen och deras nivåer. . . 31
4.10 De rubriker som finns efter tillgänglighetsanpassningen och deras nivåer. . . 32
4.11 Asteriskens ljusare röda färg innan tillgänglighetsarbetet. . . 33
4.12 Asteriskens mörkare röda färg efter tillgänglighetsarbetet. . . 33
4.13 Knappen för mer info efter implementation av dynamiska aria-labels. . . 34
4.14 Vad skärmläsaren läser upp för användaren när bilden för Skomakaregatan 11 är i fokus. 35 4.15 Vad skärmläsaren läser upp för användaren när en bild utan alt-tagg är i fokus. . . 36
4.16 Sidtitel för hem-vyn efter tillgänglighetsarbete. . . 37
4.17 Hur användaren uppmärksammas på att inmatningen har fel format. . . 38
4.18 Microsoft Accessibiliy Insights rapport innan tillgänglighetsarbetet genomförts. . . 40
4.19 Microsoft Accessibility Insights rapport efter att tillgänglighetsarbetet genomförts. . . 40
A.1 Medverkandes ålder. . . 59
A.2 Medverkandes sysselsättning. . . 59
A.3 Medverkandes bostadstyp idag. . . 60
A.4 Medverkandes erfarenhet med bostadsuthyrning, andel. . . 60
A.5 Typ av hyresvärd. . . 61
A.6 Upplevda svårigheter med att söka bostad. . . 61
A.7 Intresse av att hyra bostad i framtiden. . . 62
A.8 Åsikt om en samlad hyresplattform (som hyresgäst). . . 62
A.9 Erfarenhet av att hyra ut en bostad. . . 63
A.10 Svårigheter med att hyra ut bostad. . . 63
A.11 Intresse av att hyra ut en bostad i framtiden. . . 64
A.13 Inställning till annonsavgift. . . 65
A.14 Betalningsvilja för annonsavgift. . . 65
A.15 Inställning till månadsavgift. . . 66
A.16 Betalningsvilja för månadsavgift. . . 66
A.17 Andel medverkande med begränsande synnedsättning. . . 67
A.18 Typ av synnedsättning. . . 67
A.19 Begränsningens omfattning. . . 68
A.20 Önskad funktionalitet för webapplikationer. . . 68
B.1 SWOT-analys för Subbo. . . 78
B.2 Positioneringskarta för Subbos erbjudande jämför med några andra aktörer . . . 82
B.3 Startvyn på subbo.se. . . 84
B.4 Vy för att registrera ny användare. . . 85
B.5 Vy för att skapa ny annons. . . 86
B.6 Vy med tillgängliga bostäder. . . 87
B.7 Mina sidormed information om bland annat hyrda och uthyrda lägenheter. . . 88
D.1 Vy för startvyn. . . 106
D.2 Vy för tillgängliga bostäder. . . 106
D.3 Vy för en annons. . . 107
D.4 Se intresseanmälda användare och hyresvärdens omdömen på annons-vyn. . . 107
D.5 Vy för FAQ. . . 108
D.6 Vy för Bli medlem. . . 108
D.7 Vy för Logga in. . . 109
D.8 Vy för Skapa annons. . . 109
D.9 Modal för bilduppladdning. . . 110
D.10 Modal för betalning med Stripe. . . 110
D.11 Vy för Betalningsbekräftelse. . . 111
D.12 Vy för Mina sidor. . . 111
D.13 Vy för Lämna omdöme. . . 112
D.14 Vy för Betalningshistorik. . . 112
Tabeller
4.1 Viktiga funktioner för personer med synnedsättning. . . 25
4.2 Resultat från Google Lighthouse utifrån versionen utan tillgänglighetsanpassning. . . 39
4.3 Jämförelse av de första och de slutgiltiga Google Lighthouse-resultaten. . . 39
4.4 Jämförelse av de första och de slutgiltiga MAI-resultaten för [= * . . . 41
4.5 Hur lätt var det att hitta det du sökte i webbapplikationen med skärmläsare (till exempel hitta rätt bostad)? . . . 44
4.6 Skärmläsaren läste upp text på knappar och i formulär. Hur hjälpsam var informationen som skärmläsaren läste upp på knappar och i formulär? . . . 44
4.7 Upplevde du att det var lättare eller svårare att använda webbapplikationen nu? 3 är ingen skillnad. . . 44
4.8 Var informationen på knapparna eller formulären som skärmläsaren läste upp sämre eller bättre nu? 3 är ingen skillnad. . . 44
A.1 Intresse för hyresrätt per åldersgrupp. . . 69
A.2 Intresse för hyresrätt per sysselsättning. . . 69
A.3 Hyresvärdar och fördelning. . . 69
A.4 Upplevda problem för hyresgäster. . . 69
A.5 Intresse för bosstadsuthyrning per åldersgrupp. . . 70
A.6 Intresse för bosstadsuthyrning per sysselsättning. . . 70
A.7 Upplevda problem för hyresvärdar. . . 70
A.8 Betalningsvilja annonsavgift som hyresvärd, per åldersgrupp. . . 71
1
Introduktion
Varje svensk flyttar i genomsnitt 10 gånger under sin livstid1. Det finns många anledningar till att flytta från en bostad till en annan, till exempel att flytta ut ur barndomshemmet, flytta ihop med en partner, eller flytta till en studentstad för att studera. En av de mest utmanande delarna i flyttpro-cessen är ofta att det är svårt att hitta boende.
I Sverige finns ett flertal stora bolag som förmedlar hyresbostäder, exempelvis HSB och Riksbyggen. Bostäderna som hyrs ut av dessa bolag förmedlas vanligtvis genom en bostadskö där den person som har stått i kö längst av de som är intresserade av en viss lägenhet erbjuds att hyra den. Dessa bostadsköer är ofta långa och det kan krävas många år i kö för att bli erbjuden en bostad2. Utöver etablerade bostadssidor är det även möjligt för personer att söka boenden i till exempel Facebook-grupper eller på Blocket, vilka båda sker utan ett kösystem. Många personer har dock, trots tillgång till flera plattformar, svårt att hitta bostad3.
1.1 Motivering
Projektet som ligger till grund för detta kandidatarbete går ut på att skapa en ny och samlad web-bapplikation där privatpersoner kan hyra ut sina lägenheter i både första och andra hand. Tanken är att skapa en webbapplikation som liknar de nuvarande bostadsgrupperna på Facebook eller an-nonssidorna på Blocket, men där allt kommer att vara samlat på ett och samma ställe. Webbapplika-tionen ska vara enkelt strukturerad med god navigerbarhet, där användare kan hyra ut sin lägenhet till valfri sökande. Ett stort fokus ligger på den smidighet och enkelhet som webbapplikationen ska generera, både för uthyrning av förstahandslägenheter för lång tid framöver och för andrahands-boenden över kortare tid.
Med utgångspunkt i ovanstående idé kommer webbapplikationen att utformas med avseende på tillgänglighet i allmänhet och för synskadade i synnerhet. Tillgång till webbapplikationers innehåll är viktigt för alla. På internet finns allt från arbeten och studier till information och nyheter. Då innehållet som kan hittas på internet berör alla människor är det angeläget att också göra det an-passat och tillgängligt för alla, oavsett funktionsnedsättning [1]. En utvärdering av tillgängligheten
1Svensk fastighetsförmedling. URL:
https://www.mynewsdesk.com/se/svenskfastighetsformedling/pressreleases/svensken-flyttar-10-gaanger-under-sin-livstid-265625. (hämtad 2021-05-21)
2Fastighetstidningen. URL: https://fastighetstidningen.se/hsb-soker-fler-hyresratter/. (hämtad 2021-05-20). 3Sveriges Radio. URL: https://sverigesradio.se/artikel/7261808. (hämtad 2021-05-21)
1.2. Syfte
på webben från WebAIM visade att webbapplikationer för förmedling av bostäder var sämre än ap-plikationer i andra segment gällande tillgänglighet4.
Sannolikheten att en icke seende användare slutför en webb-baserad aktivitet är ungefär hälften så stor som sannolikheten att en användare med full syn gör det [2]. Detta beror med stor sannolikhet på att mycket information på webben förmedlas med hjälp av grafiska element och därmed inte kan tolkas väl med hjälp av de ljud- eller blindskriftshjälpmedel som ofta används av webbanvändare med synnedsättning. Även visuella element som inte bidrar med information utan enbart är design-mässiga kan göra webbanvändandet mer utmanande för en webbanvändare med synnedsättning, i och med den ökade komplexiteten de bidrar till. Den feedback som ges av skärmläsar-hjälpmedel blir lätt tvetydig om webbapplikationen är dåligt anpassad. En följd av låg tillgänglighet på web-ben är således att personer med synnedsättning inte bara är mindre web-benägna att fullfölja uppgifter på webben, utan även att det kräver mer tid och energi att utföra uppgifter som användare utan synnedsättning kan utföra utan ansträngning [2].
I oktober 2016 publicerades EU-direktivet (2016/2102) om tillgänglighet avseende offentliga myn-digheters webbplatser och mobila applikationer5. Mot bakgrund av detta har Sverige tagit fram la-gen om tillgänglighet till digital offentlig service som började gälla den 1:a januari 20196. Lagen omfattar offentligrättsliga organ samt privata aktörer med offentlig finansiering. Innebörden av la-gen är att webbplatser och mobila applikationer från de organisationer som omfattas ska uppnå minst nivå AA från Web Content Accessibility Guidelines, WCAG (se avsnitt 2.5) och därtill några yt-terligare krav7. Bland annat finns krav på att publicera en tillgänglighetsredogörelse som redovisar hur de digitala tjänsterna är anpassade för att uppfylla de tekniska kraven på tillgänglighet. I sam-band med redogörelsen ska användare också ges möjlighet att rapportera brister i tillgängligheten. Med avsikt att fortsätta denna positiva trend ska vår bostadsportal utvecklas med stort fokus på dess tillgänglighet för användare med synnedsättning.
1.2 Syfte
Syftet med detta arbete är att undersöka hur en webbapplikation för uthyrning av bostäder mellan privatpersoner kan utformas för att vara så tillgänglig som möjligt, med fokus på användare med synnedsättning.
1.3 Frågeställning
Hur kan en webbapplikation för uthyrning av bostäder, privatpersoner emellan, utformas för att vara tillgänglig för personer med synnedsättning?
1.4 Avgränsningar
Detta kandidatarbete ämnar att utveckla en webbapplikation för andrahandsuthyrning av bostäder. Fokus för arbetet ligger primärt på utformningen av webbapplikationen, snarare än affärsidén. Då webbapplikationen inte kommer att tas i bruk kommer resultaten i stället att baseras på svaren från ett begränsat antal testpersoner. Detta beskrivs vidare i del 2.6.3 och 2.6.
I denna rapport används ordet synnedsättning, och olika böjningar av ordet, frekvent och det är även en del av själva frågeställningen. Synnedsättning är en samlingsterm för alla typer av sjukdo-mar, ärftliga åkommor, och skador som påverkar synen. Majoriteten av de med synnedsättning har
4WebAIM. URL: https://webaim.org/projects/million/. (hämtad 2021-05-20).
5EU Direktiv. URL: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016L2102 (hämtad 2021-05-21) 6Sveriges Riksdag. URL:
https://www.riksdagen.se/sv/dokument-lagar/dokument/svensk-forfattningssamling/lag-20181937 (hämtad 2021-05-21)
7Webbriktlinjer. URL: https://webbriktlinjer.se/lagkrav/webbdirektivet/krav-en-301549-utover-wcag-2-1-aa/ (hämtad
1.4. Avgränsningar
en lättare sådan där man har stor delar av synen kvar men ändå har svårigheter att orientera sig och/eller att läsa texter. Dessa personer kan ofta använda synkorrektion, med hjälp av exempelvis glasögon, för att avhjälpa dessa svårigheter och därmed använda en webbapplikation på ett liknan-de sätt som användare med fullgod syn. Rapporten riktar inte in sig på liknan-dessa personer i huvudsak. När det talas om synnedsättning menas de personer som behöver andra hjälpmedel än synkorrek-tion när det kommer till att navigera på internet, till exempel en skärmläsare.
Då fokus ligger på tillgänglighet har projektet utformats med hjälp av riktlinjerna WCAG, som har sammanställts av World Wide Web Consortium (och beskrivs genomgående i avsnitt 2.5). WCAG behandlar många olika funktionsnedsättningar, men i och med arbetets fokus på synnedsättning så har vi valt att enbart ta hänsyn till att implementera webbapplikationen efter de riktlinjer som är relevanta för just detta. Vi har även valt att fokusera på att utveckla webbapplikationen så att en skärmläsarfunktion kan användas på bästa möjliga sätt. Vi har dock inte tagit speciell hänsyn till andra hjälpmedel för webbanvändare med synnedsättning, så som brailleöversättare.
I förstudien publicerade vi en enkät på sociala medier och diverse Facebook-grupper för personer med synnedsättning. I denna enkät ställs vissa frågor enbart till de respondenter som upplever att deras synnedsättning stör eller begränsar dem i deras webbanvändande. Denna bedömning låter vi respondenterna själva göra, vilket alltså innebär att vi inte gjort någon strikt gränsdragning för vilka synnedsättningar respondenter ska ha för att inkluderas i denna del av enkäten.
Frågeställningen för detta kandidatarbete fokuserar på uthyrning av bostäder där både hyresvärd och hyresgäst är privatpersoner. En situation som ligger väldigt nära detta är då att samma per-son hyr ut flera bostäder och uthyrningen går genom ett bolag, vilket gör att hyresvärden inte räk-nas som en privatperson. Ett exempel på detta är en privatperson som äger en fastighet med 10 lägenheter som hyrs ut genom ett aktiebolag som endast omfattar uthyrningen av dessa 10 lägen-heter. Sättet som denna typ av mindre hyresvärd skulle använda vår webbapplikation skiljer sig inte nämnvärt från en privatpersons användande, vilket är varför vi i detta arbete inkluderar dessa mindre hyresvärdar i begreppet ‘privatpersoner’ då vi besvarar vår frågeställning.
När det gäller marknadsföring av vår affärsidé och webbapplikation finns det dock vissa skillnader beroende på om det är en privatperson eller ett mindre bolag som hyr ut en bostad. Därför lyfts dis-kussioner om ‘mindre hyresvärdar’ fram i marknadsplanen (Appendix B), trots att det inte betraktas som en separat kundgrupp i övriga delar av arbetet.
2
Teori
I detta kapitel presenterar vi tidigare forskning som ligger till grund för utvecklingen av vår webbap-plikation. Först presenteras läget för tillgänglighet på webben idag, och vilka hinder och riktlinjer som finns för användare och utvecklare. I kapitlet presenterar vi också olika tekniska verktyg för utvärdering av tillgänglighet på webbapplikationer, vilka ligger till grund för den metod vi har an-vänt för att besvara frågeställningen. Slutligen presenteras teori om metoder för användartester och sammansättning av testgrupper.
2.1 Tillgänglighet på webben idag
Webben innefattar 1,7 miljarder existerande webbplatser varav knappt 200 miljoner är aktiva. Webbplatser är ett begrepp som innefattar både webbapplikationer och domäner på webben som inte är interaktiva. Till följd av den enorma omfattningen är det svårt att skapa en övergripande bild av webbplatsernas tillgänglighetsanpassning. Istället görs forskning på enskilda segment av web-ben för att finna data som kan representera webweb-ben i sin helhet [3].
Ett av de mest ambitiösa forskningsprojekten på detta område är WebAIM:s årliga tillgänglighets-rapport där de en miljon topprankade webbplatsernas startsidor samt 100,000 ytterligare webbplat-ser granskas och utvärderas ur ett tillgänglighetsperspektiv1. Utvärderingarna sker huvudsakligen med hjälp av mjukvaran WAVE Stand-alone API2, men även med diverse andra kompletterande verktyg. Nämnvärt är även att WebAIM:s forskning enbart tar hänsyn till fel som kan upptäckas automatiskt, vilket innebär att vissa tillgänglighetsaspekter inte testas och den övergripande till-gängligheten på webben därmed troligtvis är sämre än vad rapporten framställer. Nedan redovisas ett urval av relevanta resultat från 2020 års tillgänglighetsrapport8:
• Totalt sett upptäcktes 60 909 278 enskilda tillgänglighetsfel på de 1 000 000 startvyer som granskades. Detta innebär 60,9 fel per startvy i genomsnitt, vilket motsvarar en ökning med 2,1 % från 2019.
• Vykomplexiteten ökade med 10,4 % mellan 2019 och 2020, från 782 element per vy i genom-snitt till 864.
1WebAIM. URL: http://webaim.org/projects/million/%5C. (hämtad 2021-05-20) 2WebAIM. URL: https://wave.webaim.org/standalone. (hämtad 2021-05-23).
2.2. Hinder för webbanvändare med nedsatt syn
• En användare kan förvänta sig ett tillgänglighetsfel hos 1 av 14 element de interagerar med. • 98,1 % av startvyerna hade upptäckbara fel enligt WCAG 2.0.
• De vanligast förekommande felen (uttryckt i andel av webbplatser där felet kunde upptäckas) var: Lågkontrast i text (86,3 %), Avsaknad av alternativ text för bild (66,0 %), Tomma länkar (59,9 %)
• Webbplatser för förmedlande av bostäder var ett av de sämsta segmenten och hade i genom-snitt 94,8 fel per vy (jämför med 60,9 för alla undersökta webbapplikationer och hemsidor) I nuläget finns det ingen trovärdig forskning eller utvärdering som specifikt har undersökt tillgäng-ligheten på svenska bostadsplattformar. Däremot finns det relevant data från liknande segment på den svenska webben. Till exempel visar en rapport från 2018, där 32 svenska webbplatser som ver-kar inom telekommunikation- och försörjningssektorn undersöktes, att svenska webbplatser visar på liknande utsträckning av tillgänglighetsproblematik som de webbplatser WebAIM undersökt [4]. Till skillnad från WebAIM som undersöker antal fel per vy, undersöktes det i denna rapport hur många kriterier (baserade på WCAG:s riktlinjer) som varje vy överträdde. Resultatet visade bland annat på att de följande fyra kriterierna var de som mest frekvent blev överträdda (antal sidor där
kriteriet överträddes/antal undersökta sidor):
• Lämpliga alternativtexter/textbeskrivningar till bilder, knappar, kontroller och videoklipp
(29/32).
• Möjlighet att förstora text till 200 % utan att förlora innehåll eller funktionalitet hos elementet i fråga (28/32).
• Fokuserade element eller fält är tydligt markerade (26/32).
• Grammatiska och syntaktiska regler för HTML och CSS följs (25/32).
2.2 Hinder för webbanvändare med nedsatt syn
Webbapplikationer för e-handel har, jämfört med fysiska butiker, enklare att erbjuda den informa-tion som söks vilket resulterar i att personer med synnedsättning i en större utsträckning kan hitta de produkter som de söker [5]. I takt med att företag ämnar öka lönsamheten hos webbapplika-tioner för e-handel fylls dessa med ökande mängder information för att locka kunder till att köpa mer. Den ökande informationsmängden gör dock att det tar längre tid för skärmläsare att läsa upp allt innehåll på vyn, vilket försvårar användningen för de synnedsatta användare som förlitar sig på dessa. Detta skiljer sig från upplevelsen för användare utan synnedsättning, som lätt kan få en överblick av all information på vyn och därmed inte påverkas negativt [5].
Sättet att navigera på webben skiljer sig mellan personer med god syn och de som har nedsatt syn. Personer som kan se väl navigerar genom att direkt klicka på hyperlänkar för att ta sig mellan olika sidor på en webbapplikation, medan det för synnedsatta användare krävs att en skärmläsare först läser upp vilka objekt som finns innan personen kan välja en hyperlänk [5]. Till skillnad från perso-ner med god syn som övervägande använder mus eller styrplatta för att navigera använder många synnedsatta istället tangentbordet, samtidigt som kontinuerlig hjälp fås av skärmläsaren som upp-repar vad som angetts på tangentbordet [6]. I ett experiment genomfört av Takagi et al. [5] för att undersöka skillnaden i tidsåtgång mellan synnedsatta och personer med god syn vad gäller att ge-nomföra ett köp på webben framkom det att det för synnedsatta tar mer än 10 gånger så lång tid som för personer med god syn.
En vanlig missuppfattning är att det som gör det svårt för synnedsatta att ta del av information på webben är att skärmläsaren inte fungerar med grafiska element och därmed inte kan förmedla den information som delges i dessa [6]. Istället ligger mycket av problematiken i att en synnedsatt användare inte kan interagera med användargränssnittet på samma sätt som en person med god
2.3. Tillgänglighet
syn. Mycket forskning som bedrivs inom området handlar om att förbättra användarvänligheten för den typiska användaren utan att fokusera på de problem som finns för användare med nedsatt syn. Detta utelämnande av användare med synnedsättning betyder att webbapplikationer som ut-vecklas för att vara användarvänliga ofta enbart är det för de med god syn, medan samma problem kvarstår för övriga [6].
2.3 Tillgänglighet
Tillgänglighet på webben beskrivs av World Wide Web Consortium3, W3C, som möjligheten för funktionsnedsatta användare att nyttja webben lika väl som andra. Som ett exempel på till-gänglighet på webben nämns undertext i videor. Tilltill-gänglighet på webben underlättar naviga-tionen för människor med funktionsnedsättning men dessa hjälpmedel kan ibland även icke-funktionsnedsatta användare ha nytta av, som till exempel högre färgkontraster [2]. Hög kontrast kan vara användbart även för de utan synnedsättningar, till exempel om användaren befinner sig i en miljö där mycket ljus riktas mot skärmen och gör den svårare att avläsa. Detsamma gäller även för undertexter i videor, som även användare utan hörselnedsättning kan ha nytta av om de till ex-empel befinner sig i en högljudd miljö. Strategier för att öka tillgänglighet på webben för funktions-nedsatta användare kan alltså innebära fördelar som ökad navigerbarhet och användarupplevelse, även för användare utan funktionsnedsättning [2].
Ökad tillgänglighet för synnedsatta webbanvändare kan inte bara uppnås med högre kontrast mel-lan olika element eller undertexter i videor, utan även med saker som ökad textstorlek, simplare design, minimering av andelen information som förmedlas genom grafiska element, och genom att ge klienten textbeskrivningar av bilder som kan läsas upp av en skärmläsare [7].
Webbapplikationer är generellt sett resurser med hög komplexitet, vilket gör effektiviteten för webb-baserad interaktion för personer med synnedsättningar viktig för god tillgänglighet [8]. Komplexi-teten följer av att webbapplikationer tenderar att förmedla flera informationsflöden parallellt. Ex-empel på informationsflöden innefattar bland annat vilka förhållanden och länkningar som finns mellan olika sidor på en webbapplikation, reklam- och inforutor, och bilder som bryter av texter. Till följd av den synförmåga som krävs för att kunna nyttja dessa parallella informationsflöden finns det ofta skillnader mellan hur användare med och utan synnedsättning kan navigera på webben [9]. Till exempel kan användare med god syn navigera med muspekaren och med hjälp av olika visuella genvägar, som att söka på webbapplikationen efter nyckelord eller andra ledtrådar. Eftersom dessa strukturer till stor del förlitar sig på användarens syn är det vanligt för användare med synnedsätt-ning att till större del förlita sig på tangentbordet. Användare med synnedsättsynnedsätt-ning har även tillgång till speciella genvägar på tangentbordet som bistår vid navigation på webben [2].
2.4 Navigerbarhet och tillgänglighet
Enligt Farkas & Farkas [10] är ordet navigation en metafor som beskriver hur vi tänker oss att vi an-vänder internet. Människan får till exempel uppfattningen att man lämnar en plats och går till en annan när man går mellan olika vyer i en webbapplikation. Vidare menar de att vi kan se en web-bapplikation som uppbyggd av ett antal noder sammankopplade med hjälp av elektroniska vägar, vilka kallas länkar. Det finns flera olika sätt att koppla samman webbapplikationers olika delar, men vanligtvis är de uppbyggda på ett hierarkiskt sätt [10].
Högst upp bland alla noder i hierarkin är startvyn, och det är viktigt att denna ger användaren en överblick över hur webbapplikationen är uppbyggd [10]. Alla länkar på startvyn leder djupare ner i hierarkin och här ska användaren förstå vad som kan hittas under varje länk. Det kan även finnas länkar som inte leder till en nod direkt under sig själv; dessa kan kräva mer beskrivande texter för att användaren ändå ska förstå vart de leder [10].
2.5. Web Content Accessibility Guidelines
En vanlig regel för webbutveckling är att vilken vy som helst på applikationen ska kunna nås från startvyn med maximalt tre klick [11]. Ett av de vanligaste sätten att navigera en webbapplikation är genom att klicka på en hyperlänk på en vy för att komma till en annan. Ju mer sammankopplade olika sidor är, desto större är risken att användaren tappar bort sig bland all information som finns tillgänglig och att navigerbarheten därför försämras [11]. För att uppnå god navigerbarhet är det alltså viktigt att användaren vid alla tillfällen förstår vilken vy denne är inne på. För att uppnå denna förståelse är det därmed viktigt att designen tydligt förmedlar vilken funktion vyn har, samt hur den är sammankopplad med vyerna högre upp i hierarkin [10].
Länkar som leder till andra sidor på en webbapplikation kan vara en källa till förvirring om det saknas lämpliga förklaringstexter till dem. Exempelvis kan en länk vara märkt på ett sätt som är mycket likt det användaren söker, men inte ge den information som söks. Om en länk har ett otydligt eller tvetydigt namn kan detta i värsta fall leda till att användaren drar slutsatsen att informationen som söks inte finns tillgänglig [12]. En studie genomförd av Ceaparu & Shneiderman [13] visar att andelen användare som upplevde att de lade för mycket tid på varje uppgift minskade när länkar delades in i olika kategorier som sorterades efter alfabetisk ordning. Detta ledde även till minskad frustration hos testgruppen överlag.
Även för webbanvändare som använder skärmläsare har länkstrukturen på en webbapplikaton stor betydelse. Enligt Hochheiser et al. är en bred och grund länkstruktur att föredra både för webban-vändare med och utan synnedsättning [14]. En risk med en bred och grund länkstruktur är att det blir många länkar på varje nivå i den hierarkiska menystrukturen, vilket gör att det tar lång tid för en skärmläsare att läsa upp alla alternativ. Studien av Hochheiser et al. visade dock att många länkar på samma nivå inte hade negativ inverkan på hur enkelt det var för användare av skärmläsare att navigera på webben [14].
2.5 Web Content Accessibility Guidelines
World Wide Web Consortium4, W3C, är en internationell sammanslutning av olika aktörer som in-kluderar regeringar, standardiseringsorgan, och företag. W3C utvecklar webbstandarder med målet att leda webben till sin fulla potential genom att göra den tillgänglig för alla individer oberoende av hårdvara, funktionsnedsättningar och språk. W3C har publicerat Web Content Accessibility
Gui-delines, WCAG, som är en samling riktlinjer och rekommendationer för att göra webbinnehåll mer
tillgängligt för individer med olika funktionsnedsättningar som exempelvis synnedsättning, hör-selnedsättning samt begränsad rörelseförmåga. WCAG är avsedda att användas av utvecklare av webbinnehåll och webbverktyg, samt utvecklare av utvärderingsverktyg för tillgänglighet på web-ben. WCAG innehåller utförliga beskrivningar av tillvägagångssätt för att uppnå tillgänglighet på en webbapplikation. Det kan till exempel handla om kodningstekniker, som att märkspråket HTML:s olika element ska användas för att information ska presenteras korrekt av skärmläsare5.
WCAG uppdateras och utökas kontinuerligt; den senaste versionen är WCAG 2.16. WCAG 2.1 består av fyra lager av vägledning:
1. Principer: Det översta lagret består av fyra övergripande principer: Uppfattningsbarhet,
Ma-növrerbarhet, Förståelighet och Robusthet som bygger grunden för tillgänglighet på webben.
2. Riktlinjer: Under principerna finns totalt 13 stycken generella riktlinjer. Riktlinjerna är for-mulerade som mål som utvecklare bör arbeta mot för att göra webbinnehåll tillgängligt för alla.
4W3C. URL: https://www.w3.org/Consortium/. (hämtad 2021-05-20)
5Webbriktlinjer. URL: https://webbriktlinjer.se/riktlinjer/121-ange-i-kod-vad-sidans-olika-delar-har-for-roll/. (hämtad
2021-05-20)
2.5. Web Content Accessibility Guidelines
3. Framgångskriterier: Riktlinjerna är i sin tur uppdelade i totalt 78 stycken mätbara fram-gångskriterier. Dessa beskriver mer specifikt vad som behöver uppnås för att uppfylla de olika riktlinjerna. Riktlinjerna är indelade i tre olika nivåer A (lägsta nivån), AA och AAA (högsta ni-vån).
4. Tillräckliga och rekommenderade tekniker: Det understa lagret består av en stor mängd till-räckliga och rekommenderade tekniker som kan användas för att uppnå varje framgångskri-terium.
2.5.1 Principer och riktlinjer
Det översta vägledningslagret, principer, delar in tillgänglighetsbegreppet i fyra underkategorier. Principerna bör ses som en vision för allt innehåll på webben, om principerna inte är uppfyllda är risken stor att webbinnehållet är otillgängligt för användare med funktionsnedsättningar. Under varje princip finns sedan riktlinjer, formulerade som mål som webbutvecklare bör arbeta mot för att göra webbinnehåll tillgängligt. Riktlinjerna är inte mätbara utan fungerar som ett ramverk för att det ska vara lättare för utvecklare att förstå de tillhörande framgångskriterierna och teknikerna. Syftet med riktlinjerna är att göra innehållet tillgängligt för så många personer som möjligt, till exempel genom att innehåll presenteras på olika former för att tillgodose olika funktionshinder.
De fyra principerna med underliggande riktlinjer presenteras nedan:
1. Uppfattningsbarhet: Användaren måste kunna uppfatta innehållet som presenteras på web-bapplikationen.
1.1 Textalternativ: “Tillhandahåll alternativ i form av text till allt icke-textbaserat innehåll så att det kan konverteras till format som användarna behöver, till exempel stor stil, punktskrift, tal, symboler eller enklare språk.”7
1.2 Tidsberoende media: “Tillhandahåll alternativ till tidsberoende media.”7
1.3 Anpassningsbarhet: “Skapa innehåll som kan presenteras på olika sätt (exempelvis med enklare layout) utan att information eller struktur går förlorad.”7
1.4 Urskiljbarhet: “Gör det enklare för användare att se och höra innehåll, bland annat ge-nom att skilja förgrund från bakgrund.”7
2. Manövrerbarhet: Navigering och komponenter i användargränssnittet måste kunna hante-ras. Gränssnittet får inte kräva interaktion som inte är möjlig för en viss användare att utföra. 2.1 Tillgänglighet via tangentbord: “All funktionalitet ska vara åtkomlig med ett
tangent-bord.”8
2.2 Tillräckligt med tid: “Ge användaren tillräckligt med tid för att läsa och använda inne-hållet.”8
2.3 Krampanfall: “Designa inte innehåll på ett sätt som kan orsaka krampanfall.”8
2.4 Navigerbarhet: “Tillhandahåll sätt att hjälpa användarna att navigera, hitta innehåll och avgöra var de är.”8
2.5 Inmatningsmetoder: “Gör det lättare för användare att använda funktioner med olika former av inmatningar.”8
3. Förståelighet: Innehållet på webbapplikationen måste vara förståeligt, liksom andvändning-en av dandvändning-en. Gränssnittet ska inte innehålla interaktioner som överstiger användarandvändning-ens förståel-se.
7W3C. Perceivable. URL: https://www.w3.org/Translations/WCAG20-sv/WCAG20-sv-20121023/perceivable (hämtad
2021-05-20)
8W3C. Operable. URL: https://www.w3.org/Translations/WCAG20-sv/WCAG20-sv-20121023/operable (hämtad
2.5. Web Content Accessibility Guidelines
3.1 Läsbarhet: “Gör textinnehåll läsbart och begripligt.”9
3.2 Förutsägbarhet: “Säkerställ att webbsidor presenteras och fungerar på ett förutsägbart sätt.”9
3.3 Inmatningsstöd: “Hjälp användare att undvika misstag och rätta till misstag.”9
4. Robusthet: Innehållet måste kunna tolkas av ett stort antal användaragenter och hjälptekni-ker, även framtida användaragenter och hjälptekniker ska kunna tolka innehållet på webbap-plikationen.
4.1 Kompatibilitet: “Maximera kompatibiliteten med nuvarande och framtida användar-program, inklusive hjälpmedel”10
2.5.2 Framgångskriterier och tekniker
Under riktlinjerna i avsnitt 2.5.1 finns det i sin tur mätbara framgångskriterier som mer specifikt anger vad som måste uppnås för att uppfylla varje riktlinje11. Varje framgångskriterium är skrivet som ett uttalande som antingen blir sant eller falskt vid testning. Under varje framgångskriterium beskrivs tillräckliga tekniker för att kriteriet ska kunna uppfyllas, samt även frivilliga rekommende-rade tekniker och en beskrivning av syftet. Det finns inga krav på att använda de specifika tekniker-na, utan de är endast informativa förslag på sätt att uppfylla framgångskriterierna på ett tillförlitligt sätt.
Framgångskriterierna är graderade på tre olika nivåer: A, AA och AAA. För att nå upp till en viss nivå måste framgångskriterierna för den nivån vara uppfyllda på alla webbapplikationens vyer, samt i alla dess processer.
2.5.2.1 Nivå A
Nivå A är den lägsta nivån, framgångskriterierna på den här nivån är de som är mest grundläggande för en webbapplikations tillgänglighet. För att nå upp till nivå A måste samtliga framgångskriterier på nivån vara uppfyllda. Webbapplikationer som inte når upp till nivå A kan vara omöjliga eller extremt svåra för personer med funktionsnedsättningar att använda.
Ett exempel på ett framgångskriterium på nivå A, som hör till riktlinjen ‘1.4 Urskiljbarhet’ ovan, är kriterium 1.4.112som handlar om användningen av färger. Riktlinjen säger att information inte får förmedlas med enbart färg. En tänkbar situation är ett formulär som innehåller både obligatoriska och frivilliga fält, där det enda sättet som det framgår vilka fält som är obligatoriska är genom att rubrikerna till dessa fält är skrivna med röd text istället för svart. I det här fallet är det omöjligt för personer som saknar färgseende eller är helt blinda och navigerar med skärmläsare att avgöra vilka fält i formuläret som är obligatoriska respektive frivilliga.
En tillräcklig teknik som kan användas för att uppfylla framgångskriterium 1.4.1. är att även för-medla informationen med en symbol13, till exempel genom att markera obligatoriska fält med en asterisk.
2.5.2.2 Nivå AA
Nivå AA är den nivå som den svenska lagen om tillgänglighet till digital offentlig service6kräver att digitala information från de organisationer som omfattas av lagen når upp till. För att uppnå nivå AA måste samtliga framgångskriterier på nivå A, samt AA uppnås.
9W3C. Understandable. URL: https://www.w3.org/Translations/WCAG20-sv/WCAG20-sv-20121023/understandable
(hämtad 2021-05-20)
10W3C. Robust. URL: https://www.w3.org/Translations/WCAG20-sv/WCAG20-sv-20121023/robust (hämtad 2021-05-20) 11W3C. URL: https://www.w3.org/TR/WCAG21/. (hämtad 2021-05-06).
12W3C. URL: https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html. (hämtad 2021-05-21). 13W3C. URL: https://www.w3.org/WAI/WCAG21/Techniques/general/G182. (hämtad 2021-05-21).
2.6. Metodteori
Ett exempel på ett framgångskriterium på nivå AA, som hör till riktlinjen ‘1.4 Urskiljbarhet’, ovan är kriterium 1.4.314som handlar om att det ska vara tillräcklig kontrast mellan text och bakgrund. Tillräcklig kontrast innebär att kontrastförhållandet mellan text och bakgrund ska vara minst 4,5:1. Figur 2.1 visualiserar hur text kan ser ut med olika kontrastförhållanden.
Det finns många gratis, digitala verktyg för att mäta kontrastförhållanden. Att säkerställa att kon-trasten är tillräcklig med hjälp av ett sådant verktyg är en tillräcklig teknik för att uppfylla det här framgångskriteriet15.
Figur 2.1: Exempel på hur text kan se ut med tre olika kontrastförhållanden mellan text och bak-grund. För att uppfylla framgångskriterium 1.4.3 från WCAG 2.1 krävs att konstrastförhållandet är minst 4,5:1.
2.5.2.3 Nivå AAA
Nivå AAA är den högsta nivån för tillgänglighet i WCAG 2.1. För att uppnå nivå AAA måste samtliga framgångskriterier på nivå A, AA, samt AAA vara uppnådda. W3C rekommenderar att webbutveck-lare inte ska sträva efter att alltid uppnå alla framgångskriterier på AAA-nivå då det inte är möjligt att uppfylla dessa kriterium för alla former av webbinnehåll16. AAA-kriterierna är främst användbara vid utveckling mot specifika grupper och kan väljas selektivt om nödvändigt.
Ett exempel på ett framgångskriterium på nivå AAA som hör till riktlinjen ‘2.5 Inmatningsmeto-der’ ovan är kriterium 2.5.517som säger att alla klickbara element på en webbapplikation ska vara minst 44x44 CSS-pixlar stora. Genom att uppfylla detta kriterium hjälper man till exempel webban-vändare med synnedsättningar som har svårt att urskilja allt för små element och anwebban-vändare med motoriska nedsättningar som har svårt att hålla muspekaren tillräckligt stilla för att kunna klicka på mindre element. En tillräcklig teknik som hör till framgångskriterium 2.5.5 är att manuellt kontrol-lera att alla klickbara element uppfyller storlekskravet17.
2.6 Metodteori
I detta avsnitt presenteras teori kring de metoder vi har använt för att utvärdera den webbapplika-tion som vi har utvecklat, med syfte att besvara frågeställningen.
2.6.1 Enkätmetodik
En enkätundersökning definieras som ‘insamlingen av information från ett urval av individer ge-nom deras besvarande av frågor’ [15]. Med denna metod är det möjligt att göra både kvantitativa och kvalitativa undersökningar, eller både och samtidigt [16]. Enkäter kan utformas för att urskilja
14W3C. URL: https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html. (hämtad 2021-05-21). 15W3C. URL: https://www.w3.org/WAI/WCAG21/Techniques/general/G18. (hämtad 2021-05-21).
16W3C. URL: https://www.w3.org/TR/WCAG21/conformance. (hämtad 2021-05-21)
2.6. Metodteori
olika grupper inom urvalet av svarande personer och på så sätt dra slutsatser om dessa grupper. En väldigt övergripande sådan gruppindelning skulle kunna vara att dela upp grupper efter till exempel ålder och kön. Huruvida relevanta slutsatser kan dras från en sådan grupp behöver dock motiveras på ett tillfredsställande sätt utifrån varje undersökning.
Grundtanken med dessa uppdelningar är att ifall ett helt slumpmässigt urval görs inom en viss mål-grupp, så borde urvalsgruppens svar spegla denna målgrupps åsikter kring det som undersöks [16]. En fördel med enkäter är att de i regel når ut till fler personer än intervjuer som görs med samma frågor, speciellt om enkäten görs online. Enkäter kan dock ge upphov till över- eller underrepre-sentation av delsegment inom målgruppen. Detta beror på att de kanaler som enkäten sprids på online inte nödvändigtvis innehåller de fördelningar av personer man vill komma åt, vilket måste tas hänsyn till vid diskussioner och slutsatser.
Enkäter utformas ofta enligt ett format som kallas för Likertskalan. Likertskalor kännetecknas av att olika påståenden framförs, och den som svarar på enkäten ska välja ett alternativ på en skala för varje påstående. Likertskalor består ofta av siffrorna 1 till och med 5 [17]. Att svara ‘1’ på en femgradig Likertskala ska innebära att man inte håller med alls och ‘5’ innebära att man håller med helt. Att svara ‘3’, som är det alternativ som då ligger i mitten, ska innebära att den svarande är neutral inför påståendet. Med dessa Likert-frågor kan skalan ändras till att ha till exempel 7 eller 9 steg istället, men 5 är det absolut vanligaste [17]. Dessa skalor som har ett ojämnt antal steg kallas
balanserade eftersom de innehåller en mittpunkt. Mittpunkten är dock inte nödvändig om den inte
anses behövas för frågan som ska utredas.
2.6.2 Verktyg för tillgänglighetsanalys
Det finns ett flertal hel- och halvautomatiska verktyg för att på ett opartiskt sätt utvärdera en web-bapplikations tillgänglighet. Dessa verktyg analyserar applikationens struktur så som den presen-teras för användaren och jämför denna med någon uppsättning regler eller riktlinjer som valts, ofta WCAG 2.1. I det här avsnittet presenteras de tre utvärderingsverktygen Google Lighthouse, WAVE och Microsoft Accessibility Insights. Vidare presenteras även Silktide Disability Simulator som är ett verktyg för att simulera olika former av synnedsättningar.
2.6.2.1 Google Lighthouse
Google Lighthouse är ett gratis open-source-program för utvärdering av webbapplikationer18. Verk-tyget utvärderar en webbapplikations prestanda i ett antal kategorier; en av dessa kategorier är till-gänglighet och det är endast denna som åsyftas framöver. Google Lighthouse presenterar ett om-döme för utvecklaren i skalan [1..100]. Detta omom-döme är ett viktat genomsnitt av alla de tillgänglig-hetstester som körts. Vikterna är baserade på Axe user impact assessments19. Dessa grundar sig i sin tur på WCAG 2.0 och WCAG 2.1 på A- och AA-nivå20. Efter slutförd analys presenteras en rapport för utvecklaren som förklarar vilka brott mot riklinjerna som identifierats. Rapporten preciserar de felande elementen, samt vilka konsekvenser dessa får för webapplikationens användare. Rapporten länkar även till användbara artiklar för hjälp att förstå och rätta de funna tillgänglighetsbristerna.
2.6.2.2 WebAIM WAVE
Web Accessibility Evaluation Tool, WAVE, är utvecklat av WebAIM, en ideell organisation baserad på
Utah State University21. Verktyget finns tillgängligt som en egen webbapplikation eller som plug-ins till Chrome och Firefox. För att använda verktyget navigerar utvecklaren helt enkelt till webbappli-kationen och aktiverar WAVE.
18Google Developers. URL:https://developers.google.com/web/ tools/lighthouse. (hämtad 24/2-21). 19Lighthouse accessibility scoring. URL: https://web.dev/accessibility-scoring/. (hämtad 25/2-21).
20GitHub. Rule Descriptions. URL: https://github.com/dequelabs/axe-core/blob/develop/doc/rule-descriptions.md
(hämtad 2021-05-20)
2.6. Metodteori
WAVE analyserar alla element, både synliga och osynliga, och utgår från riktlinjerna i WCAG 2.1 och Section 50822. Section 508 är ett tillägg till den amerikanska lagen om rehabilitering (Rehabili-tation Act), som kräver att federala myndigheter utvecklar, upphandlar, underhåller och använder informations- och kommunikationsteknoliger som är tillgängliga för personer med funktionsned-sättningar22.
Om WAVE hittar misstänkta brister i något element i webbapplikationen, läggs en ikon över ele-mentet i fråga23. Ikonen ger utvecklaren information om vilken typ av fel som misstänks: genom att klicka på ikonen får användaren information om var i HTML-koden detta element finns, en förkla-ring av felet, en förklaförkla-ring av varför WAVE misstänker ett fel, samt en referens till vilken eller vilka WCAG-riktlinjer som ligger till grund för den potentiella bristen23. WAVE gör även en sammanställ-ning av vyns struktur, samt tillhandahåller skjutreglerare med hjälp av vilka utvecklaren kan justera färger på text och element för att uppnå tillräckliga konstraster23.
2.6.2.3 Microsoft Accessibility Insights
Microsoft Accessibility Insights, MAI, är ett kostnadsfritt desktop-verktyg som utvärderar hemsidor
efter med hjälp av både automatiserade och manuella tester24. MAI består av tre huvudverktyg:
FastPass, Assessment och Ad hoc tools23. För våra ändamål lämpade sig Assessment-funktionen, så det är endast den som kommer att beskrivas i denna rapport.
MAI:s Assessment-funktion innehåller en uppsättning av 141 tillgänglighetstester, uppdelade i 24 kategorier. 53 av dessa tester är helt automatiserade, och övriga 88 är helt eller delvis manuella. De manuella testerna inkluderar instruktioner för vad som krävs för att klara testet, kombinerat med visuella hjälpmedel för att peka ut relevanta element i webbapplikationen. Efter att ha utfört testet på sin webbapplikation, kan användaren indikera till MAI huruvida testet är avklarat eller inte. Den-na bedömning räkDen-nas sedan in i den slutgiltiga, sammanfattande aDen-nalysen av webbapplikationens tillgänglighet24.
2.6.2.4 Silktide Disability Simulator
Silktide Disability Simulator, SDS, är ett webbläsartillägg till Google Chrome som kan simulera olika
synnedsättningar för seende användare25. En av funktionerna i SDS är simulering av närsynthet, vilket är ett synfel som gör att man ser sämre på långt håll. Detta uppnås genom att simulera en suddig syn; när funktionen aktiveras blir hela skärmen suddig i webbapplikationen25. Med SDS kan suddigheten ställas in till allt från från 0 % till 100 %. Vid 100 % suddighet är en övervägande del av webbapplikationens text oläslig även för användare utan synnedsättning. Då användare navigerar genom att flytta fokus med hjälp av tangentbordet så kan de fortfarande urskilja viss information om var i webbapplikationen de befinner sig, men kan inte läsa information som står på knappar, i formulär och i text.
2.6.3 Användartester
Även om det finns många tekniska standarder för att utvärdera en webbapplikations tillgänglig-het, ger inte dessa hela bilden av huruvida en webbapplikation upplevs som tillgänglig eller ej. Att WCAG:s riktlinjer är uppfyllda innebär till exempel inte nödvändigtvis att synnedsatta användare stöter på färre problem vid användandet av webbapplikationen [18]. Det är därför nödvändigt att utföra tester med verkliga användare för att få en tillförlitlig helhetsbild av en applikations tillgäng-lighet.
22U.S. General Services Administration. URL: https://www.section508.gov/manage/laws-and-policies (hämtad
2021-05-20)
23Wave. URL: https://wave.webaim.org/report%5C/https://www.ecb.europa.eu/home/html/index.en.html (hämtad
2021-05-20)
24Microsoft Accessibility Insights. URL: https://accessibilityinsights.io/ (hämtad 2021-05-20) 25Silktide. URL: https://silktide.com/resources/toolbar/ (hämtad 2021-05-20)
2.6. Metodteori
2.6.3.1 Think-aloud-tester
Enligt W3C är think-aloud-tester lämpliga för att utvärdera tillgänglighet26. Metoden innebär att testdeltagare tilldelas specifika uppgifter att utföra på en webbapplikation och sedan verbaliserar sina tankar och upplevelser. Det finns två huvudsakliga varianter av metoden: concurrent
think-aloud, CTA, och retrospective think-think-aloud, RTA. Vid CTA återger testdeltagarna sina upplevelser
un-der tiden som uppgifterna utförs. Vid RTA utförs istället uppgifterna i egen takt och upplevelserna återges i efterhand genom en intervju26.
En nackdel med CTA är att testdeltagarnas prestation på uppgifterna riskerar att påverkas i större utsträckning än vid RTA. Eventuell påverkan kan å ena sidan vara positiv då testpersonernas pro-blemlösningsförmåga gynnas av att de tvingas tänka högt och strukturera sina tankar, å andra sidan negativ då det kan vara distraherande för testpersonerna att samtidigt hålla fokus på både uppgif-terna och att verbalisera sina tankar [19]. Vidare är en fördel med CTA är att resultatet inte litar till testpersonernas minne. Alhadreti och Mayhaw [20] menar att CTA är att föredra framför RTA då fler användbarhetsproblem detekterades med CTA i deras studie. Dessutom var tiden det tog för testledarna att utföra testerna och utvärdera resultatet avsevärt kortare jämfört med RTA.
Eftersom det inte är ett naturligt beteende att tänka högt under en problemlösningsprocess bör test-deltagarna få öva på en uppvärmningsuppgift innan det faktiska testet påbörjas när CTA-metoden används. Traditionellt sett bör testledaren sedan undvika att kommunicera med testdeltagarna un-der testets gång för att prestationen ska påverkas så lite som möjligt [21]. Boren och Ramey [22] argumenterar dock för att en viss grad av kommunikation, där testledaren kan styra deltagaren mot att hålla sig till relevanta resonemang och vidareutveckla om det behövs, ger ett mer användbart resultat. Detta gäller särskilt vid utvärdering av användbarhet. I deras artikel presenteras riktlinjer för hur testledaren bör agera i olika situationer.
Vid utvärdering av tillgänglighet specifikt, till skillnad från generell användbarhet, bör uppgifter-na som testdeltagaruppgifter-na tilldelas vid think-aloud-tester fokusera på specifika delar i användandet av applikationen där tillgängligheten kan vara ett problem, snarare än generell användning av appli-kationen27.
2.6.3.2 Retrospective probing
Retrospective probing är en utvärderingsmetod där testdeltagare svarar på ett antal frågor direkt efter att ha utfört testuppgifter i det system som är under utveckling [23]. Frågorna kan vara av både öppen och sluten karaktär. Slutna frågor kan antingen vara formulerade så att ett ja- eller nej-svar förväntas eller utgå från en flergradig skala, som till exempel Likertskalan (se avsnitt 2.6.1) [24]. Enligt Birns et al. [23] ger retrospective probing en bra bild av tesdeltagarnas helhetsupplevelse av ett system. Vidare har metoden fördelar som att den ger ett kvantifierbart resultat som är enkelt att jämföra mellan olika testdeltagare eller testomgångar, i alla fall om slutna frågor används.
Användande av Likertskalan har också nackdelar, som att deltagarnas svar baseras på en subjektiv bedömning av skalans olika steg [24]. Detta innebär en risk för att testdeltagare som har haft en likvärdig användarupplevelse svarar med olika siffror på Likertskalan, vilket påverkar hur resultatet tolkas. Vid slutna frågor kan det vara relevant att ställa följdfrågor för att undersöka varför en person svarat på ett viss sätt, då detta ger mer användbar feedback för vidareutveckling av ett system än en-bart en siffra eller ett ja- eller nej-svar [23]. En annan nackdel är att metoden litar till testdeltagarnas minne av sina upplevelser [25].
Slutligen drar Birns et al. [23] slutsatsen att retrospecitive probing och CTA-metoden är lämpliga att använda i kombination med varandra för att utvärdera användbarhet. De skriver att metoder-na tillsammans täcker en stor del av testdeltagarmetoder-nas interaktion med ett system och fångar både
26W3C. URL: https://www.w3.org/WAI/test-evaluate/involving-users/ (hämtad 2021-05-20) 27W3C. URL: https://www.w3.org/WAI/test-evaluate/involving-users/ (hämtad 2021-05-21)
2.6. Metodteori
användbarhetsproblem kopplade till specifik funktionalitet, samt ger en god bild av helhetsupple-velsen.
2.6.3.3 Sammansättning av testgrupper
Syftet med användartester är att upptäcka brister i en utvecklad produkt så att dessa kan åtgärdas tidigt, vilket minskar den totala utvecklingskostnaden [26]. Vid sammansättningen av testgrupper uppstår en balansgång mellan antalet testdeltagare (och därmed hur stor andel av användbarhets-problemen på en webbapplikation som kan antas upptäckas), och den mängd resurser som krävs för att genomföra testerna och utvärdera resultatet.
Enligt Faulkner [27] upptäcker en testgrupp på fem personer i snitt 85 % av användbarhetsproble-men på en webbapplikation; dock är spridningen för hur stor andel av probleanvändbarhetsproble-men som detekteras vid olika tester betydligt högre med ett litet deltagarantal jämfört med ett större. En liten mängd testdeltagare innebär även att mindre hänsyn tas till olika människors erfarenhetsnivåer och olika sätt att tänka. Vidare menar Faulkner att tester som utgår från mindre omfattande och mer välde-finierade uppgifter kräver ett lägre antal testdeltagare för att uppnå ett tillförlitligt resultat än tester av mer komplex karaktär.
3
Metod
I detta kapitel beskriver vi det tillvägagångssätt som vi har använt för att besvara frågeställning-en. Kapitlet är indelat i arbetets tre delar: förstudie, implementation, och utvärdering. I stycket om implementation beskriver vi hur vi har delat upp arbetet i iterationer, samt hur olika tekniska verk-tyg användes under implementationens gång för att utvärdera och åtgärdera tillgänglighetsbrister i webbapplikationen. I stycket om utvärdering beskriver vi hur slutgiltig utvärdering med de tekniska verktygen gick till och hur användertesterna genomförts.
3.1 Förstudie
För att få en bild av huruvida produkten vi utvecklade faktiskt täcker ett behov genomförde vi en marknadsundersökning med hjälp av en enkät som spreds online; främst via personer i projekt-gruppens Facebook-cirklar. Syftet med enkäten var att göra en kvantitativ analys av behovet. Enkä-ten bestod av en blandning av frågor i olika format enligt teorin i avsnitt 2.6.3 och 2.6.1 och kan läsas i sin helhet i Appendix A. Enkäten fanns tillgänglig att svara på under tre dagar och är uppdelad i två delar: den första delen visas för alla respondenter och består av frågor gällande vår produktidé, och den andra delen visas enbart ifall respondenten anger att denne har en synnedsättning som denne upplever som begränsande i sitt webbanvändande. I och med denna uppdelning hade enkäten i sin första version många frågor och detta ansågs inom gruppen kunna få undersökningen att framstå som krånglig. Ett förbättringsarbete gjordes och vissa frågor togs bort helt eller integrerades i andra frågor.
3.2 Implementation
Implementationsprocessen delades in i två iterationer. Under den första iterationen var målet att utveckla applikationens funktionalitet, och under den andra iterationen var fokus att förbättra till-gängligheten för befintlig produkt.
Under den första iterationen, där målet var att sätta upp all funktionalitet för webbapplikationen, genomfördes utvecklingen utan särskilt fokus på tillgänglighet. Under den andra iterationen var till-gänglighet ett huvudfokus, och vi arbetade mot målet att nå nivå AA från riktlinjerna WCAG 2.1 som beskrivs i avsnitt 2.5. Verktygen WebAIM WAVE, Google Lighthouse och Microsoft Accessibility In-sights, vilka beskrivs i avsnitt 2.6.2, användes kontinuerligt under utvecklingsprocessen i den sista
3.2. Implementation
iterationen. Varje vy i applikationen utvärderades med de tre verktygen och de tillgänglighetspro-blem som identifierades åtgärdades i största möjliga mån. Förutom de tre verktygen, som alla tre bygger på WCAG 2.1, använde vi också textdokumentationen för WCAG 2.1 för att identifiera och åtgärda tillgänglighetsproblem.
3.2.1 Google Lighthouse
När funktionaliteten var implementerad i första iterationen genererades en Google Lighthouse-rapport för tillgänglighet på vyerna Startsida, FAQ, Bli medlem, Mina sidor, Bostäder, Skapa annons, och Chatt (vilket är webbapplikationes samtliga vyer). Rapporten genererades genom att öppna ‘Developer tools’ i webbläsaren Google Chrome, navigera till fliken ‘Lighthouse’, markera rutan för ‘Accessibility’, och klicka på knappen ‘Generate report’. Rapporterna bestod av en lista av tillgäng-lighetsbrister som verktyget identifierat; figur 3.1 visar ett exempel på en sådan rapport. Under ite-ration två åtgärdades dessa brister. Efter att vi arbetat med att åtgärda en brist på en viss vy genere-rades en ny Google Lighthouse-rapport för vyn för att säkerställa att bristen verkligen var åtgärdad (och därmed inte dök upp i den nya rapporten). Detta upprepades tills dess att alla tillgänglighets-brister som Google Lighthouse kunde identifiera var åtgärdade och alla de vyer som nämns ovan hade 100 av 100 möjliga poäng. Detta arbetssätt, där applikationens vyer kontinuerligt utvärdera-des med hjälp av Google Lighthouse, gjorde att det totala antalet Google Lighthouse-rapporter som genererades under arbetets gång var stort.
3.2. Implementation
Figur 3.1: Exempel på en rapport genererad på hem-vyn med Google Lighthouse.
3.2.2 WebAIM WAVE
Webbläsartillägget WebAIM WAVE användes, likt Google Lighthouse, kontinuerligt under arbetet i den andra iterationen för att upptäcka tillgänglighetsbrister. Även WebAIM WAVE användes på ap-plikationens samtliga vyer: Startsida, FAQ, Bli medlem, Mina sidor, Bostäder, Skapa annons, och Chatt. Vyn som skulle analyseras laddades in innan tillägget startades. Tillägget startades i webb-läsaren och producerade en lista med potentiella tillgänglighetsbrister; figur 3.2 visar ett exempel på detta. Tillsammans med denna lista presenterade WebAIM WAVE också en förklaring till varför varje potentiell brist var betydelsefull, tillsammans med exempel på åtgärder. Alla de brister som WebAIM WAVE identifierade åtgärdades under iteration två. Efter att vi hade arbetat med en brist på en viss vy gjordes en ny utvärdering av vyn i fråga med WebAIM WAVE för att bekräfta att bristen verkligen var åtgärdad. Detta upprepades tills dess att alla tillgänglighetsbrister som WebAIM WA-VE kunde identifiera var åtgärdade. Det här arbetssättet, där WebAIM WAWA-VE användes kontinuerligt för att utvärdera webbapplikationens olika vyer, gjorde att det totala antalet gånger som WebAIM WAVE användes var stort.
