Examensarbete
Dataingenjör
Webbtillgänglighet för synskadade på webben
Examensarbete 15 hp
Halmstad 2021-04-21
Abstract 3
Sammanfattning 4
Introduktion 5
1.1 Problembeskrivning 5
1.2 Syftet med projektet 7
1.3 Mål 7
1.4 Frågeställningar 7
1.5 Avgränsningar 7
Bakgrund 8
2.1 WCAG 2.0 8
2.2 Tillvägagångssätt för att undersöka webbtillgänglighet 9
2.3 Skärmläsare 9
2.3.1 Strukturerad HTML 10
2.4 Webbtekniker 10
2.4.1 Hibernate 10
2.4.2 AJAX 11
2.5 Automatiska tillgänglighetsverktyg 12
2.5.1 Deque - Axe DevTools Pro 12
2.5.2 WAVE 13
2.6 Modeller för mätning och utvärdering av webbtillgänglighet. 14
2.7 Relaterade arbeten 15
Metod 17
3.1 Tillvägagångssätt för att identifiera skillnader sett till webbtillgänglighet mellan
webbsidor. 17
3.1.1 Metod för intervjuer 17
3.1.2 Metod för mätning med automatiska tillgänglighetsverktyg 19 3.2 Metoder och verktyg vid skapande av teknisk lösning 20
3.2.1 ASP.NET (Backend) 20
3.2.2 Microsoft SQL 20
3.2.3 HTML, CSS och Javascript/JQuery 21
3.2.4 REST API 21
3.2.5 Hibernate 21
3.2.6 AJAX 22
3.3 Tillvägagångssätt vid skapande av teknisk lösning till webbsida 22 3.3.1 Hämta rätt data utifrån vald graf/bild från databas 22 3.3.2 Hantera datat och anpassa till textformat/JSON 22
3.3.3 Front-end och Ajax anrop 22
3.4 Metod för att kvantitativt mäta resultat av den optimerade webbsidan 23
Resultat 24
4.1 Skillnader mellan en vanlig hemsida jämfört mot en optimerad hemsida sett till
webbtillgänglighet för synskadade webbsidorna 24
4.1.1 Mätning med automatiskt mätningsverktyg 24
4.1.2 Intervjuer 25
4.2 Resultat av teknisk lösning för att skapa en bättre webbtillgänglighet 27
4.2.1 Back-end delen 27
4.2.2 Front-end delen 28
4.2.3 Test av webbtillgänglighet på webbsidan före och efter implementation av
lösning 29
Diskussion 31
5.1 Resultat 31
5.2 Jämförelse mot andra arbeten 33
5.3 Ekonomi, säkerhet, integritet och miljö kring utvecklade systemet 33
Slutsatser 35
Referenser 36
Abstract
Creating accessibility for the disabled on the web has become of increasing interest to companies as new rules have been established regarding web accessibility. One standard that describes web accessibility is WCAG. If a website does not reach the level within certain standards, it will be difficult for people with disabilities to be able to access content on the website. At the same time, the supplier on the website loses potential customers by not adapting its service to WCAG's standards.
In the project, two goals were set. The first goal of the project is to describe the difference in terms of web accessibility between a regular company website and an optimized website for the visually impaired. The second goal is to demonstrate a technical solution that improves the ability of a visually impaired user to assimilate personal information that is presented graphically in the form of images.
To describe differences in web accessibility between a standard company website and an optimized website for the visually impaired, the project has used a hybrid method. In that method, a technical accessibility measurement tool and interviews of people who tested the various websites with the help of a screen reader.
To achieve the second goal, a technical solution was created in the form of a web system built using various subsystems and techniques. The technical solution was implemented and web accessibility was measured before and after the implementation.
The result of the first goal was compiled in a list. The differences between a regular business website compared to a website optimized for the visually impaired is that a regular website
● has poorer contrast
● often lacks useful navigation support
● often lacks text alternatives to non-text-based content
● may contain elements that change content at short intervals.
The result for the second goal showed an improvement in terms of web accessibility after the technical solution was implemented on a website that presents customers' data graphically in the form of images.
Conclusions that can be drawn are that the project results reach the goals that the project has set.
Sammanfattning
Att skapa tillgänglighet för funktionshindrade på webben har blivit av allt större intresse för företag då nya regler har fastställts kring webbtillgänglighet. En standard som beskriver webbtillgänglighet är WCAG. Om en webbplats inte uppnår nivån inom vissa standarder blir det svårt för personer med funktionsnedsättning att kunna ta del av innehåll på webbplatsen.
Samtidigt går leverantören på webbplatsen miste om potentiella kunder genom att inte anpassa sin tjänst till WCAG:s standarder.
I Projektet sattes två mål upp. Första målet med projektet är att beskriva skillnaden sett till webbtillgänglighet mellan en vanlig företagshemsida och en för synskadade optimerad hemsida. Andra målet är att visa på en teknisk lösning som förbättrar möjligheten för en synskadad användare att tillgodogöra sig personlig information som redovisas grafiskt i form av bilder.
För att beskriva skillnader i webbtillgänglighet mellan en vanlig företagshemsida och en för synskadade optimerad hemsida har projektet använt sig av en hybrid metod. I den metoden användes ett tekniskt tillgänglighetsmätverktyg och intervjuer av personer som testat de olika hemsidorna m.h.a. en skärmläsare.
För att uppnå det andra målet skapades en teknisk lösning i form av ett webbsystem byggt med hjälp av olika delsystem och tekniker. Den tekniska lösningen implementerades och webbtillgängligheten mättes före och efter implementeringen.
Resultatet av första målet sammanställdes i en lista. Skillnaderna mellan en vanlig företagshemsida jämfört med en hemsida optimerad för synskadade är att en vanlig hemsida
● har sämre kontrast.
● saknar ofta användbart stöd för navigering.
● saknar ofta textalternativ till icke textbaserat innehåll.
● kan innehålla element som byter innehåll med korta intervaller.
Resultatet för andra målet visade på en förbättring sett till webbtillgänglighet efter att den tekniska lösningen implementeras på en webbsida som presenterar kunders data grafiskt i form av bilder.
Slutsatser som kan dras är att resultaten uppnår de mål som projektet har satt upp.
1. Introduktion
1.1 Problembeskrivning
Tillgänglighet för alla på webben innebär [1] att alla personer, inklusive dem som har
funktionshinder ska ha tillgång till den digitala värld som många av oss lever i och nyttjar. Av hela Europas befolkning så finns det mellan 10 till 15 procent som lider av ett
funktionshinder som försvårar eller hindrar deras möjligheter att använda webben och den digitala världen. 10 till 15 procent av Europas befolkning motsvarar cirka 50 till 70 miljoner människor. Webben är och har blivit en mer vanlig plats för människor att finna glädje och ta del av tjänster såsom film streaming, sociala medier m.m. Utöver det [2] så har även
utbildning, rådgivning och vägledning med hjälp av videor, podcasts, bilder osv. blivit allt populärare att använda sig av. På de Synskadades Riksförbunds hemsida finns det flera berättelser som beskriver hur användare haft svårt eller inte alls kunnat sköta de mest vardagliga av samhällstjänster. Exempelvis, när du vill anmäla vård av barn hos Försäkringskassan är det tvärstopp. Läsa årsbesked på CSN är väldigt svårt eftersom pdf-filerna inte går att läsa av. Ännu ett exempel är att passbokning hos polisen inte fungerar för den som är synskadad. Det har dessutom uppmärksammats en rätt kraftig ökning av antalet kryssrutor för samtycke som inte fungerar för en synskadad efter att gdpr infördes.
Utan undertexter och textalternativ till formaten ovan så är de inte tillgängliga för personer som är synskadade [3]. Detsamma skulle till exempel gälla ifall en blind person skulle vilja ta del av en webbsida som visar grafer och det inte finns möjlighet till en berättarröst eller liknande. Nedan beskrivs ett konkret exempel på ett problem som kan uppstå vid utveckling av webbtillgänglighet på webbsidor. Ett problem som ska försöka lösas i detta projekt.
Magnus Olander, utvecklingschef på Quicksearch (Personlig kommunikation M Olander 2020-10-02) berättar att i många fall kan man komma långt på att hårdkoda text för att beskriva delar av sin webbsida för att få en skärmläsare att fungera för en synskadad. Men det finns fall då utvecklare måste ta steget längre och se till att data som ska beskriva en webbsida för synskadade är dynamiskt anpassad för varje enskild person eller kund.
Exempel på när dynamisk data måste presenteras kan vara när personlig kunddata presenteras i form av en bild/graf i ett webbsystem. Varje bild är unik för varje kund. Detta gör att det är omöjligt som utvecklare att med hårdkodad text beskriva de bilder som produceras för varje enskild kund. Därför måste en dynamisk lösning skapas för att lösa detta problem. Exempel på två bilder som genereras i ett webbsystem till en webbsida som har samma struktur men olika data går att se i figur 1 och 2. I detta projekt ska en teknisk lösning till detta problem skapas för att lyckas beskriva de olika graferna oberoende av vilken graf/bild det är. Lösning ska göra att webbtillgängligheten på webbsidan blir bättre efter lösningen skapats och implementerats än innan.
Figur 1. Frågan “Säljare ville ha affären”. Exempel på en av många grafer/bilder som presenterar unika kunders data.
Figur 2. Frågan “Affär/Inte Affär”. Exempel på en av många grafer/bilder som presenterar unika kunders data.
I många länder har det satts upp lagar gällande att myndigheters webbsidor måste hålla en viss standard vad gäller tillgänglighet för funktionshindrade. Standarderna utgår ifrån WCAG 2.0:s riktlinjer [4]. Trots att det är många företag där ute som inte är en myndighet så finns det ett stort intresse från företag, stort som litet att också göra sina webbsidor och tjänster mer tillgängliga för personer med funktionshinder (Personlig kommunikation M Olander 2020-10-02). Att inte optimera sina webbsidor och tjänster för den andel av befolkning med funktionsnedsättning är att gå miste om 15% av potentiella kunder. Som utvecklare är det inte alltid självklart hur man ska gå tillväga för att skapa webbtillgängligihet utifrån WCAG 2.0:s riktlinjer. Därför kommer i detta arbete undersökningar utföras för att ta reda på vad som är viktigt vid skapande av webbtillgänglighet. Sedan kommer även problemet som beskrevs tidigare försöka lösas med hjälp av en teknisk lösning för att skapa en bättre webbtillgänglighet på webbsidan.
1.2 Syftet med projektet
Projektet syftar till att det ska vara lättare för företag och utvecklare att ta fram och skapa bättre webbsidor för synskadade, vilket i sin tur ger synskadade bättre möjligheter att ta del av det material och tjänster som finns ute på Internet.
1.3 Mål
Första målet med projektet är att beskriva skillnaden sett till webbtillgänglighet mellan en vanlig företagshemsida och en för synskadade optimerad hemsida. Andra målet är att visa på en teknisk lösning som förbättrar möjligheten för en synskadad användare att tillgodogöra sig personlig information som redovisas grafiskt i form av bilder.
1.4 Frågeställningar
För att uppnå målet behöver projektet svara på följande frågor:
● Hur kan webbtillgänglighet undersökas och mätas?
● Vad skiljer en vanlig företagshemsida från en webbsida optimerad för synskadade användare?
● Går det att komplettera en befintlig webbsida med en mjukvara som gör så att synskadade användare tillgodogör sig personlig information som redovisas grafiskt?
1.5 Avgränsningar
Projektet undersöker bara webbtillgänglighet för synskadade.
2. Bakgrund
2.1 WCAG 2.0
WWW Consortium (W3) beskriver i ett dokument att WCAG 2.0 tagits fram för att ge rekommendationer om hur webbinnehåll kan bli mer tillgängligt (oavsett webbteknologi) i olika webbteknologier [5]. WCAG 2.0 består av 12 riktlinjer indelade i fyra huvudprinciper för webbtillgänglighet.
WCAG:s fyra huvudprinciper är:
-uppfattbar -användbar -förståelig -robust
Varje riktlinje omfattar olika framgångskriterier. Riktlinjerna betraktas som ett ramverk som leder utvecklaren och webbansvariga i syfte att göra innehåll lättillgängligt för
funktionshindrade användare. W3 beskriver att det är viktigt att följa dessa riktlinjer för att ge äldre och funktionshindrade användare tillgång till innehåll utan några hinder. Det är dock svårt att mäta och testa om innehållet uppfyller riktlinjerna. Därför föreslogs det att
framgångskriterierna skulle testas manuellt eller automatiskt med hjälp av
webbtillgänglighetskontroll. Den svenska översättning av WCAG:s 12 punkter [5] visas nedan.
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.
1.2 Tidsberoende media: Tillhandahåll alternativ till tidsberoende media.
1.3 Anpassningsbart: Skapa innehåll som kan presenteras på olika sätt (exempelvis med enklare layout) utan att information eller struktur går förlorad 1.4 Urskiljbart: Gör det enklare för användare att se och höra innehåll, bland annat genom att skilja förgrund från bakgrund.
2.1 Tillgängligt via tangentbord: All funktionalitet ska vara åtkomlig med ett tangentbord.
2.2 Tillräckligt med tid: Ge användaren tillräckligt med tid för att läsa och använda innehållet
2.3 Krampanfall: Designa inte innehåll på ett sätt som kan orsaka krampanfall.
2.4 Navigerbart: Tillhandahåll sätt att hjälpa användarna att navigera, hitta innehåll och avgöra var de är.
3.1 Läsbart: Gör textinnehåll läsbart och begripligt.
3.2 Förutsägbart: Säkerställ att webbsidor presenteras och fungerar på ett förutsägbart sätt.
3.3 Inmatningsstöd: Hjälp användare att undvika misstag och rätta till misstag.
4.1 Kompatibelt: Maximera kompatibiliteten med nuvarande och framtida användarprogram, inklusive hjälpmedel.
2.2 Tillvägagångssätt för att undersöka webbtillgänglighet
I ett arbete skrivet av Abdullha Alsaeedi [6] berättar han att det huvudsakligen finns fyra tillvägagångssätt som används för att utvärdera webbplatsers tillgänglighet. Det första tillvägagångssättet är det automatiska tillvägagångssättet som kör
webbtillgänglighetsverktyg på webbplatsen för att samla in överträdelser som sker mot fördefinierade riktlinjer. Det finns en hel del olika webbtillgänglighetsverktyg att välja mellan [7]. Abdullha Alsaeedi fortsätter beskriva att verktyg för utvärdering av webbtillgänglighet kan definieras som program som hjälper webbadministratörer att avgöra om en webbplats
uppfyller riktlinjer för tillgänglighet på webben.
Det andra tillvägagångssättet [6] är manuell utvärdering med hjälp av mänskliga experter som undersöker webbsidor för att identifiera överträdelser av tillgänglighetsriktlinjer.
Begränsning med automatiserade verktyg är att vissa riktlinjer är subjektiva vilket gör att experter blir tvungna att undersöka dessa subjektiva riktlinjer.
En studie som jämförde mänskliga experter mot automatiserad testning, av Soongoo Hong, Pairin Katerattanakul och Dae-hyung Lee [8], visade dock att automatiserade
testningsverktyg har förmågan att upptäcka fler tillgänglighetsfel än mänskliga experter.
Den tredje metoden [6] är att testa med hjälp av användare som är funktionshindrade.
Denna sortens tillvägagångssätt bygger på användartestning för att identifiera
tillgänglighetsproblem med hjälp av funktionshindrade användare som interagerar med innehållet på webbsidor. I en artikel av Helen Petrie och Nigel Bevan [9] skriver de att det anses vara ett ultimat tillvägagångssätt för att utvärdera tillgängligheten på webbsidor. Men trots att det anses som ett effektivt tillvägagångssätt så är det svårt att få till rekrytering av funktionshindrade [10].
Det fjärde och sista tillvägagångssättet [6] är en hybridstrategi som kombinerar automatiserad och manuell utvärdering. I ett arbete skrivet av Hend S Al-Khalifa [11]
användes WAVE som kontrollverktyg vid mätning av tillgänglighet tillsammans med manuell mätning för att utvärdera 36 saudiarabiska förvaltningswebbplatser för att upptäcka de allra vanligaste tillgänglighetsfelen. Likt den tredje metoden är detta tillvägagångssätt väldigt tidskrävande och komplext att få till [12].
2.3 Skärmläsare
Vid undersökningen kring intervjuerna kommer en skärmläsare vara en central punkt.
Skärmläsaren [3] är ett verktyg som kan göra en stor skillnad för blinda och synskadade vid deras användning av webbsido. En skärmläsare gör det lätt för en person med synskada att ta del av en webbsida genom att lyssna på vad skärmläsaren läser upp utifrån vad som händer på skärmen. En skärmläsare är ett program som tillåter blinda eller synskadade användare att lyssna eller läsa texten som visas på skärmen med en talsyntes eller punktdisplay. En skärmläsare är [3] gränssnittet mellan datorns operativsystem, dess
applikationer och användaren. Rent praktiskt så skickar användaren kommandon genom att trycka på olika tangentkombinationer på datorns tangentbord för att instruera talsyntesen vad man ska säga och att tala automatiskt när förändringar sker på skärmen. Ett kommando kan instruera talsyntesen att läsa eller stava ett ord, läsa en rad eller helskärm med text, hitta en textsträng på skärmen, meddela platsen för datorns markör eller fokuserade objekt
och så vidare. Dessutom tillåter det användare att utföra mer avancerade funktioner, som att hitta text som visas i en viss färg, läsa förutbestämda delar av skärmen på begäran, läsa markerad text och identifiera det aktiva valet i en meny. Användaren kan också använda stavningskontrollen i en ordbehandlare eller läsa cellerna i ett kalkylblad med en
skärmläsare.
2.3.1 Strukturerad HTML
För att en skärmläsare [13] ska fungera så krävs det i grund och botten strukturerad HTML.
En hel del webbinnehåll kan göras tillgängligt för synskadade bara genom att rätt HTML-kod används för rätt ändamål. Ett konkret exempel på vad som gör stor skillnad på om en
skärmläsare fungerar eller inte är om man läser på de två olika kod raderna nedan.
<img src=”dinosaur.png”>
<img src=”dinosaur.png”
alt=”En blå Tyrannosaurus Rex”: En tvåbent blå dinosaurie som står rakt upp med två små armar och vassa tänder>
Första kodraden skulle på en webbsida skapa en bild men problemet här är att när
skärmläsaren vill beskriva för personer med synskada med hjälp av en talsyntes så kommer det bara läsas upp “bild”. En lösning på detta och som är nyckeln till att beskriva bilder och objekt med hjälp av skärmläsare är att lägga till en “alt” del till <img> objektet. Skulle skärmläsaren läsa upp andra kodraden istället skulle det låta såhär, “Bild. En blå
Tyrannosaurus Rex: En tvåbent blå dinosaurie som står rakt upp med två små armar och vassa tänder”. Så helt enkelt krävs det konkret beskrivande text för att skärmläsaren ska kunna samarbeta och underlätta för personer som är synskadade.
2.4 Webbtekniker
För att nå projektets andra mål (“att visa på en teknisk lösning som förbättrar möjligheten för en synskadad användare att tillgodogöra sig personlig information som redovisas grafiskt”) kommer en webblösning skapas för att optimera webbtillgängligheten för synskadade. Det som behöver lösas är att skapa en teknisk lösning som genererar data till grafer/bilder utifrån vald graf/bild för att på så sätt skapa en bättre webbtillgängliget för synskadade. Till
lösningen kommer många olika verktyg användas. Två tekniska verktyg som kan underlätta och göra utvecklingen mer smidig i projektet mellan olika delsystemen är Hibernate och AJAX.
2.4.1 Hibernate
För att hämta, hantera och göra data från en databas så lätthanterligt för en utvecklare som möjligt finns det ett ramverk som heter Hibernate. Det är ett ramverk [14] som gör det enkelt för en utvecklare att hantera data från en databas i ett objektorienterat
programmeringsspråk. Det gör att man slipper skriva en stor mängd SQL. Istället kan allt styras från en webbapplikation med hjälp av ett programmeringsspråk. Hibernate som är ett ramverk tillhandahåller ett SQL-inspirerat språk som heter Hibernate Query Language (HQL) för att skriva SQL-liknande frågor mot Hibernates dataobjekt. Hibernate hanterar problem med matchning av objektrelationell resistans genom att ersätta direkta databas åtkomster
med objekthanterings funktioner på hög nivå. I ett arbete skrivet av Chuanlong Xia, Guangcan Yu och Meng Tang [15] skriver de att “Som ett öppet källkodsprojekt använder Hibernate en väldigt begränsad och en enkel struktur för att uppnå ihållande objektrelation, datakartläggning och lättviktspaket. Således undviks användningen av Entity Bean
komplexiteten i förverkligandet av processen, vilket avsevärt förbättrar prestanda för system, minskar bördan för utvecklare och gör lösningen mycket skalbar”. De beskriver även att [15]
Hibernate syftar till att vara en komplett lösning på problemet med hantering av ihållande data i det objektorienterade språket. Det förmedlar att applikationen är i interaktion med en relationsdatabas, vilket ger utvecklaren frihet att koncentrera sig på affärsproblem eller liknande, spegling av denna beskrivning går att se i figur 3.
Figur 3. Arkitektur av Hibernate. Hämtad från [15]
Hibernate är [15] inte något jobbigt ramverk att hantera. Som användare är du inte skyldig att följa många Hibernate-specifika regler och designmönster när du skriver din affärslogik och ihållande klasser. Dessutom integreras Hibernate smidigt med de flesta nya och
befintliga applikationer och kräver inte komplicerade ändringar av resten av applikationen. I ett annat arbete beskriver Chitra Babu och Gunasingh G [16] de unika fördelar med
Hibernate, “Hibernate erbjuder bättre anpassning och prestation som andra ramverk inte kan erbjuda som till exempel Object Relational Bridge (OJB). Hibernate har den mest tillförlitliga anslutningspoolimplementeringen, nämligen Connection Pool 3.0 (CP3.0) ”.
2.4.2 AJAX
För att smidigt och enkelt jobba mellan olika delar i en webblösning finns det en lösning för detta, AJAX. AJAX är [17] en akronym som står för Asynchronous JavaScript och XML, och beskriver en uppsättning utvecklingstekniker som används för att bygga webbplatser och webbapplikationer. AJAX:s kärnfunktion är att uppdatera webbinnehåll asynkront, vilket innebär att en användares webbläsare inte behöver ladda om en hel webbsida när endast en liten del av innehållet på sidan behöver ändras. I ett arbete skriver Jonas Kluge, Frank Kargl och Michael Weber [18] att “Ajax-tekniken sägs göra internet snabbare, mer interaktivt och användarvänligt”. I ett annat arbete [19] beskrivs Ajax och hur det funkar. För att helt förstå hur webbapplikationer fungerar interagerade med Ajax kan man titta på figur 4 för att se den klassiska webbapplikationsmodellen, jämfört med den asynkrona. Figuren visar att asynkrona förfrågningar i Ajax-modellen är helt transparent för slutanvändaren. Ajax modellen låter applikationen skicka Http-förfrågningar och information utan att visa någon visuell bekräftelse, även i webbläsarens statusfält.
Figur 4. Jämförelse av klassisk och asynkron modell. Hämtad från [19]
I Ajax-applikationer [19] kommer användare inte uppleva vanliga fördröjningar vid
sidladdning så snart webbläsaren har skapat det laddade biblioteket för programmet. Ajax ramverk och webbserver kan uppdatera innehållet genom att driva data till webbläsarens användargränssnitt via DOM (Document Object Module) manipulering.
2.5 Automatiska tillgänglighetsverktyg
Vid utvärdering av webbtillgänglighet kan automatiska tillgänglighetsverktyg användas.
Verktygen ska vara till hjälp för att besvara de frågor som ställts i projektet och underlätta arbetet. Det gäller både vid utvärdering av de två hemsidorna och vid testning av den tekniska lösningen som tas fram under projektet för att skapa en bättre webbtillgänglighet.
De två tillgänglighetsverktyg som kommer användas beskrivs nedan.
2.5.1 Deque - Axe DevTools Pro
På leverantörens hemsida kan man läsa att, Axe Devtools [20], drivs av världens mest populära motor för tillgänglighetsregler, kallad ax-core. Detta regelbibliotek öppnades 2015 och granskas dagligen av utvecklare och tillgänglighetsexperter, vilket enligt tillverkaren ska säkerställa dess anpassning till den senaste versionen av WCAG och upprätthåller dess mantra av “inga falska positiva resultat”. Axe DevTools visar direkt i browsern problem som de även visar potentiella lösningar till.
Figur 5. Hur användningen av Axe DevTools ser ut på en webbsida. Hämtad från [21]
2.5.2 WAVE
WAVE är ett automatiskt verktyg utvecklat av WebAIM som gör det möjligt för användare att ange webbadressen till en aktuell webbplats. Det syftar till att hjälpa webbutvecklare att kontrollera tillgängligheten för en viss webbsida för att göra den mer tillgänglig [22]. Till skillnad mot Axe DevTools lägger WAVE till ikoner på en webbsida som tillåter användare att kontrollera potentiella tillgänglighetsproblem. Röda ikoner avser tillgänglighetsfel, gula ikoner indikerar varningar, gröna ikoner visar på tillgänglighetsfunktioner och alla ljusblå ikoner indikerar strukturella, semantiska eller navigationselement.
Figur 6. Hur användningen av WAVE ser ut på en webbsida. Hämtad från [21].
2.6 Modeller för mätning och utvärdering av webbtillgänglighet.
Det finns många olika sätt kring hur man kvantitativt kan mäta hur väl en webbsida är utvecklad sett till tillgänglighet. I denna sektion beskrivs olika formler som är framtagna vid andra arbeten för mätning och utvärdering av webbtillgänglighet.
Ett av de första sätten att kvantitativt mäta webbtillgängligheten på en webbsida föreslogs av Matson och Sullivan [23]. I studien valdes åtta kontrollpunkter för prioritet 1 från WCAG 1.0 för att testa webbplatser. Felfrekvensen (FR) mäter förhållandet mellan faktiska
tillgänglighetsfel och potentiella tillgänglighetsfel för en viss webbsida p. Det totala antalet tillgänglighetsfel betecknas som Bpoch antalet potentiella tillgänglighetsfel betecknas som Np.
𝑓𝑎𝑖𝑙𝑢𝑟𝑒 𝑟𝑎𝑡𝑒 (𝐹𝑟 (1)
𝑝) = 𝑁𝐵𝑝
𝑝
I ett arbete skrivet av Abdullha Alsaeedi [6] har ett systematiskt tillvägagångssätt tagits fram för att mäta tillgänglighetsnivån på webbsidor. Dessutom kan mätningen betraktas som en prestationsindikator genom att jämföra olika webbsidor när det gäller webbtillgänglighet.
Alsaeedi beskriver att mätningen till exempel går att använda för att avgöra vilka
universitetswebbsidor som uppfyller WCAG 2.0 kriterierna. Den viktigaste fördelen med lösningen som tagits fram beskrivs vara att den hjälper webbutvecklare att avgöra om den nya versionen av en webbsida är mer tillgänglig än den gamla versionen. Alsaeedi skriver att, “Anta att det finns ett antal webbsidor där tillgängligheten måste mätas med avseende på WCAG 2.0 och det finns olika tillgänglighetsgranskare för att upptäcka alla överträdelser.
Vi kan säga att en webbsida h är den mest tillgängliga webbsidan när man överväger WCAG 2.0 jämfört med andra webbsidor om det bryter mot färre av dessa riktlinjer”. För att mäta detta som beskrivs föreslår Alsaeedi, web accessibility accuracy (WAA) mätvärdet.
Noggrannheten för webbåtkomst kan mätas genom att beräkna ett WAA värde för varje webbsida. Webbsidan med högsta WAA värde kan anses vara den mest tillgängliga.
Formeln i ekvation (2) bygger på att två olika automatiska testverktyg körs på alla webbsidor som ska vara med vid mätning. Sedan samlas antal överträdelser mot WCAG in från båda mätverktygen. För att beräkna WAA värdet för varje hemsida läggs antal överträdelser från båda testverktygen samman för enskild webbsida. Summan som beskrevs divideras med antalet överträdelser från båda verktygen för alla webbsidor som är med i mätning. Detta gör att WAA-värdet som beräknas för varje webbsida får ett värde beroende av hur väl
webbtillgängligheten är på de andra webbsidorna.
𝑊𝐴𝐴 = 1 − 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝐸𝑟𝑟𝑜𝑟𝑠 𝑖𝑛 𝑈𝑛𝑖𝑜𝑛𝐸𝑟𝑟𝑜𝑟𝑠 𝑠𝑒𝑡 𝑓𝑜𝑟 𝑔𝑖𝑣𝑒𝑛 𝑤𝑒𝑏𝑝𝑎𝑔𝑒 (2)
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝐸𝑟𝑟𝑜𝑟𝑠 𝑖𝑛 𝑡ℎ𝑒 𝑈𝑛𝑖𝑜𝑛𝐸𝑟𝑟𝑜𝑟𝑠 𝑠𝑒𝑡 𝑓𝑜𝑟 𝑎𝑙𝑙 𝑤𝑒𝑏𝑝𝑎𝑔𝑒𝑠
Paramanto och Zeng [24] beskriver ett mått baserat på WCAG:s kontrollpunkter för att automatiskt testa tillgängligheten med hjälp av automatiserade
tillgänglighetsutvärderingsverktyg. Dessutom föreslås mätvärdet att uppfylla flera krav. Det första kravet är mätning av tillgänglighet med en kvantitativ poäng för att representera tillgänglighetsområdet från perfekt tillgänglighet till oåtkomlig. Den kvantitativa poängen skulle hjälpa webbutvecklare att bedöma förändringar när det gäller tillgänglighet över tid och att jämföra mellan webbplatser. Det andra kravet är att den metriska poängen gör det möjligt att mäta hastigheten för förändring av webbtillgänglighet över tid. Det tredje kravet är måttlighetens rättvisa genom att ta hänsyn till storleken på webbplatserna, och man kan använda flera webbsidor för att säkerställa att webbsidor har olika storlekar och komplexitet.
V anger den totala överträdelsen av en webbsida.
𝑊𝐴𝐵 (3)
𝑠𝑐𝑜𝑟𝑒 = 𝑝=1
𝑁𝑃
∏
𝑝=1 𝑉
∏ (𝐵𝑃𝑝𝑗
𝑝𝑗
)(𝑊𝑖) 𝑁𝑃
En hög WAB poäng betecknar fler tillgänglighetsbarriärer för funktionshindrade användare, medan lägre WAB poäng innebär färre tillgänglighetsbarriärer för funktionshindrade
användare. Det vill säga lägre WAB poäng innebär att en webbplats tar hänsyn till fler tillgänglighetskriterier. De totala webbsidorna för en webbplats betecknas som NP. Bpj betecknar antalet överträdelser och Ppjbetecknar antalet potentiella överträdelser. Wi betecknade vikten av överträdelser i omvänd proportion till WCAG:s prioritetsnivå.
2.7 Relaterade arbeten
Tidigare har det gjorts en del liknande arbeten vad gäller undersökning av webbtillgänglighet på webbsidor. Ett arbete skrivet av Sebastian Lundqvist och Johan Ström [25] undersökte de hur webbtillgänglighetsproblem kan lösas i en e-lärande applikation. De beskriver att “Deras resultat är konkreta exempel som utvecklare kan använda för att skapa webbtillgänglighet på e-lärande applikationer”. Ett annat relaterat arbete är ett skrivet av Abdullha Alsaeedi [6].
Han undersöker olika metoder för hur webbtillgänglighet kan undersökas och mätas. I arbetet tas en formel fram för att undersöka webbtillgänglighet på sex olika universitets
webbsidor. Efter mätningar drar Alsaeedi slutsatser kring vad som skiljer kvaliteten sätt till webbtillgänglighet mellan de olika universitetsstartsidorna.
3. Metod
3.1 Tillvägagångssätt för att identifiera skillnader sett till webbtillgänglighet mellan webbsidor.
Första målet för projektet är att beskriva skillnaden sett till webbtillgänglighet mellan en vanlig företagshemsida och en för synskadade optimerad hemsida.
Som exempel på “en för synskadade optimerad hemsida” väljer projektet Synskadades Riksförbunds hemsida då man kan anta att den hemsidan är väl optimerad för synskadades behov. Som exempel på en vanlig företagshemsida väljer projektet företaget Quicksearch hemsida. Quicksearch hemsida är ett bra exempel på en vanlig företagshemsida eftersom Quicksearch med sina 25 anställda med omsättning på ca 25 miljoner kronor ligger mitt i spannet för definitionen av ett småföretag [26].
För att kunna beskriva skillnader behöver webbsidors webbtillgänglighet beskrivas och jämföras. I bakgrunden sektion 2.2 beskrivs hur man på olika sätt kan undersöka webbtillgänglighet. De fyra olika olika tillvägagångssätten är:
● Utvärdering med hjälp av automatiska tillgänglighetsverktyg.
● Expert utför manuell testning för utvärdering av webbsida
● Utvärdering med hjälp av användare som är funktionshindrade
● Hybrid. En kombination av de ovanstående tillvägagångssätten.
Vid undersökningen för att beskriva skillnader mellan en vanlig företagshemsida
(Quicksearch hemsida) och en optimerad hemsida (Synskadades Riksförbunds hemsida) sett till webbtillgänglighet kommer en hybrid metod användas. Det hybrida
tillvägagångssättet kommer vara en kombination av intervjuer och med hjälp av ett automatiskt mätningsverktyg. Bakgrunden till att projektet väljer det hybrida
tillvägagångssättet är att för att intervjuerna och det automatiska mätverktyget ska
komplettera varandra. Som beskrevs i bakgrunden har de olika tillvägagångssätten både för och nackdelar där väljs ett tillvägagångssätt som är hybrid. Summan av resultaten från intervjuer och resultatet från testverktyget förväntas kunna utgöra underlag för en beskrivning av skillnader i webbtillgänglighet mellan en “vanlig” och en för synskadade optimerad hemsida.
3.1.1 Metod för intervjuer
De intervjuer som ska genomföras kommer vara semistrukturerade intervjuer. Willig [27]
beskriver i ett arbete, “Att utföra semistrukturerade intervjuer gör att forskaren får möjlighet att lyssna på respondenternas syn och upplevelse av det ämne som studeras”. Detta passar bra i denna undersökning. Frågor som ställs gör att samtalet uppmuntras till att bli öppet och fritt samtidigt som forskaren kan styra intervjun med sin forskningsfråga. Viktigt att ha i åtanken som forskare är att ha en förberedd intervju agenda som följs. Intervjuerna kommer följa en struktur där respondenterna beskriver sina upplevelser av de två hemsidorna med hjälp av tre frågor. Dessa beskrivs nedan. Under intervjuerna förväntas respondenterna beskriva de hinder och de användarstöd de upplevt när de i rollen som synskadade testat de två hemsidorna. Det förväntade resultatet av intervjuerna är en punktlista bestående av
viktiga hinder och eller användarstöd som bara förekommer på den “vanliga” hemsidan eller den “optimerade” hemsidan.
Respondenterna
Till undersökningen har tre personer valts ut för att testa de två olika webbsidorna med hjälp av en skärmläsare för att sedan intervjuas utifrån tre frågor. Det optimala för denna
undersökning hade varit att ha synskadade testpersoner men det har varit svårt att få till det på grund av coronasituationen. Därför har undersökning gjorts på tre före detta studenter som fått ta på sig en ögonbindel innan testningen började för att göra det så likt som möjligt.
Ingen av respondenterna har någon tidigare erfarenhet av skärmläsare. I undersökningen kallas de tre olika personerna för person A, person B och person C.
● Person A: 25-årig kille. Använder glasögon och har problem att se på nära håll. Har lätt att lära sig nya tekniska verktyg.
● Person B: 23 årig kille. Aldrig haft några synproblem. Har lätt att lära sig nya tekniska verktyg.
● Person C: 23 årig kille. Använder glasögon. Också problem att se på nära håll. Har lätt att lära sig nya tekniska verktyg.
Utförande av intervjuerna
De tre respondenterna har som sagt ingen tidigare erfarenhet av användning av skärmläsare sedan innan. Därför fick de tre personerna möjlighet att testa och lära sig det mest relevanta om hur en skärmläsare fungerar på en webbsida genom att testa i några minuter på en för undersökningen irrelevant webbsida. Skärmläsaren som används i intervjuerna är MacOS egna skärmläsare som heter Voice Over. Därefter så får de tre deltagarna i uppgift att hitta den del där kontakt finns i form av e-post till person på företaget. Respondenterna får inte använda någon sökmotor under testet utan de måste pröva sig fram hela vägen genom webbsidan för att hitta det som sökes. Poängen med uppgiften är att respondenterna ska få en helhetsbild av de båda webbsidorna med skärmläsaren.
Tre frågor kommer sedan ställas till varje respondent. Frågorna är inspirerade från WCAGs 12 punkter [28] och är centrala för att få en överblick för vad som är viktigt vid en webbsida sett till tillgänglighet. Frågorna kretsar kring:
● Struktur: Hur upplevdes strukturen kring menyerna? Var det någon skillnad mellan de två webbsidorna. Har webbsidan en tydlig väg som beskriver vad som sker från start till slut?
● Syfte: Framgår syftet med webbsidan tydligt?
● Interaktion: Hur upplevs samspelet mellan webbsidan och skärmläsaren?
Nedan visas delar av de båda startsidorna.
Figur 7. Bild av Synskadades Riksförbunds hemsida. Hämtad från [29]
Figur 8. Bild av Quicksearch hemsida. Hämtad från [30]
3.1.2 Metod för mätning med automatiska tillgänglighetsverktyg
Det automatiska tillgänglighetsverktyget/mätverktyget som kommer användas vid denna undersökning är WAVE, beskrivs i sektion 2.5.2. Här hoppas projektet förstå hur stora mätbara skillnader det finns mellan en optimerad och en icke optimerad webbsida sett till webbtillgänglighet. WAVE och många andra tillgänglighetsverktyg funkar på så sätt att genom att skicka en URL till webbsidan som ska undersökas skickas svar tillbaka i form av olika överträdelser och varningar. Detta beroende på hur väl webbsidan är utvecklad sett till webbtillgänglighet. WAVE kommer användas på Quicksearch hemsida och Synskadades riksförbunds hemsida för att ta del av resultaten som genereras och tillsammans med
intervjusvaren kunna svara på vad som skiljer en optimerad webbsida sett till
webbtillgänglighet. Det förväntade direkta resultatet av mätningarna med verktyget är en lista på avvikelser mot WCAG 2.0 för den “vanliga” respektive “optimerade” webbsidan. Den listan analyseras och avvikelserna grupperas. Det färdiga resultatet av den automatiska mätningen förväntas vara en punktlista på typer av avvikelser enligt WCAG 2.0 som endast finns hos den ena typen av webbsidor.
3.2 Metoder och verktyg vid skapande av teknisk lösning
Inför projektet sattes en plan upp tillsammans med företaget arbetet gjordes hos. Planen var att ta fram en potentiell teknisk lösning som dynamiskt kan framställa data som beskriver olika grafer för att skapa en mer webbtillgänglig webbsida. Systemet är tänkt att bygga på fyra delar.
-Databas. Data som beskriver de olika graferna ligger i en databas.
-Webbapplikation back-end. Hämta och hantera data som kommer från databas för att skicka vidare mot ett REST-API.
-REST-API. Vid hantering av data mellan olika delar i systemet måste ett REST-API användas.
-Webbapplikation front-end. Hämtar data från REST-API för att sedan presentera datat på webbsidan.
De verktyg som används för att bygga och sätta ihop de fyra delsystemen ovan beskrivs i sektionerna nedan.
3.2.1 ASP.NET (Backend)
Den metod och verktyg som främst kommer användas är ASP.NET utveckling. ASP.NET [31]
används för skapande av webbapplikationer och är utvecklat av Microsoft. Projektet utförs hos är ett företag med endast Windows datorer vilket gör det naturligt att använda och utveckla med server-side språket ASP.NET. Programmeringsspråk som används vid programmering i ASP.NET är C# MVC. MVC Står för Model, View, Controller och är ett sätt att strukturera upp kod i olika mappar för att underlätta webbutveckling. Beskrivet i ett arbete [32], “ASP.NET skapar en sammanbunden webbapplikation, det ger också en
programmeringsmodell och ram för en mer mångsidig och stabil applikation som hjälper anmärkningsvärt med säkerheten”.
3.2.2 Microsoft SQL
För att kunna hantera varierande data beroende av vilken tabell/bild som visas i den visuella delen av lösningen krävs en databas där all beskrivande data av tabellerna finns.
Databashanterare som används i detta projekt är Microsoft SQL. Microsoft SQL är ett relations databashanteringssystem som stöder ett brett utbud av transaktionsbearbetning, affärsinformation och analys applikationer i ett företags IT-miljöer. Microsoft SQL server är en av de tre marknadsledande databas teknologierna tillsammans med IBMs DB2 och Oracle Database [33].
3.2.3 HTML, CSS och Javascript/JQuery
Lösningen i projektet ska ha en visuell del och den byggs med hjälp av HTML, CSS och Javascript. HTML som är den viktigaste delen för att få en skärmläsare att fungera är språket för att beskriva strukturen på webbsidor. HTML [34] ger utvecklaren möjlighet att publicera online-dokument med rubriker, text, tabeller, listor, foton m.m. Hämta online information via hypertextlänkar, genom att klicka på en knäpp. Design formulär för
genomförande av transaktioner med fjärrtjänster, för användning vid informationssökning, bokning, beställning av produkter m.m. Inkludera kalkylark, videoklipp, ljudklipp och andra applikationer direkt i sina dokument.
CSS [34] är språket för att beskriva presentationen av webbsidor, inklusive färger, layout och teckensnitt. Det gör att man kan anpassa presentationen till olika typer av enheter, såsom stora skärmar, små skärmar eller skrivare. CSS är oberoende av HTML och kan användas med alla XML-baserade markeringsspråk. Separationen av HTML och CSS gör det lättare att underhålla webbplatser, dela stilar över sidor och skräddarsy sidor till olika miljöer.
Javascript [35] är ett programmeringsspråk som ursprungligen skapades för att bygga och skapa “levande webbsidor”. Programmen inom detta språk kallas för “scripts”. Scripts kan skrivas direkt i en webbsidas HTML och köras automatiskt när sidan laddas. Scripts tillhandahålls och körs som ren text. De behöver inte speciell förberedelse eller sammanställning för att kunna köras.
JQuery [36] är ett snabbt, litet och funktionsrikt JavaScript-bibliotek. Det gör saker som HTML-dokumentgenomgång och manipulation, animering, händelsehantering och Ajax-anrop mycket enklare med ett lättanvänt API som fungerar i en mängd olika webbläsare. Beskrivet från jQuerys sida, “med en kombination av mångsidighet och töjbarhet har jQuery förändrat hur miljoner människor skriver JavaScript”.
3.2.4 REST API
För att kunna dela data mellan de olika delarna i en webbapplikation krävs det att ett REST API används. Representational State Transfer (REST) [37] är en stil för att bygga
distribuerade hypermedia system. HTTP (HyperText Transfer Protocol) är huvud protokollet för de vanligaste REST-implementeringarna. Ett RESTful API fungerar kring resurser som kan vara vilken typ av data, objekt eller tjänster som helst som kan nås via en identifierare, som är en URL. REST API:er använder HTTP som ett protokoll så att det kan utföra vanliga HTTP-metoder. Användning av resurs identifierare tillsammans med HTTP-metoder gör att klienten kan utföra gemensamma operationer på resurser.
3.2.5 Hibernate
Hibernate är ett ramverk som beskrevs i bakgrund sektion 2.4.1. Genom att koppla upp Hibernate mellan databas och webbapplikationen ska det göra att datat som hämtas blir objektorienterat vilket underlättar när man jobbar med ett objektorienterat
programmeringsspråk som C#. I lösningen som skapas i detta projekt kommer Hibernate användas för att förenkla för utvecklaren som slipper att skriva egna SQL-frågor.
3.2.6 AJAX
Ett annat tekniskt verktyg som beskrevs i bakgrunden, sektion 2.4.2 som kommer användas vid lösningen i detta projekt är AJAX. Det ska användas för att på ett smidigt och enkelt sätt hantera och skicka datat mellan de olika delsystemen i lösningen. I bakgrunden beskrivs att AJAX gör webbsidor snabbare för användare och gör det enklare för utvecklare.
3.3 Tillvägagångssätt vid skapande av teknisk lösning till webbsida
Med de beskrivna delsystemen och teknikerna ovan ska projektet skapa en teknisk lösning som ska framställa data dynamiskt. Datat beskriver olika grafer och dess svar så att en skärmläsare kan beskriva innehållet för en synskadad. Exempel på hur graferna ser ut i projektet går att se i figur 1 och 2.
3.3.1 Hämta rätt data utifrån vald graf/bild från databas
Första steget i den tekniska lösningen är att hämta rätt data utifrån vald graf. För att lyckas med detta ska back-end applikationen (applikation byggd i ASP.NET) hämta ett unikt ID för den valda grafen. Det görs genom att läsa av ID:et från ett REST-API och dess URL. För att sedan få tag på data till grafen används ID:et för att söka i databasen efter rätt graf. När grafen hittats ska data för den valda grafen skickas tillbaka till ASP.NET applikationen via ramverket Hibernate. Genom att implementera Hibernate så underlättas arbetet på back-end sidan då datat som kommer från databasen blir objektorienterat och blir då lättare att jobba med.
3.3.2 Hantera datat och anpassa till textformat/JSON
Nästa steg i lösningen är att hantera datat som kommer från databasen så att det anpassas till JSON format. Datat för grafen kommer behöva sorteras i för att plocka ut det mest
relevanta som beskriver grafen/bilden. I detta arbete så har datat som ligger till grund för alla grafer/bilder samma struktur vilket gör att denna lösning funkar. Skulle datat som graferna beskriver ha olika struktur skulle detta tillvägagångssätt inte fungera. Till graferna/bilderna i figur 1 och 2 kan intressant data att beskriva för en synskadad vara:
● Vilken typ av fråga det är.
● Vilka svarsalternativ som finns
● Hur många som har svarat på de olika svarsalternativen.
Det är upp till utvecklaren hur mycket data som ska beskrivas och beroende på vad för sorts bilder som ska beskrivas. I detta fall är det olika sorters grafer. Efter datat valts ut skapas en ny klass i ASP.NET applikationen som ska generera datat i JSON format i det REST API som anropades från start. Viktigt här är att datat läggs in i en specifik datastruktur, i detta fallet kommer en dictionary användas. En dictionary [38] (även kallad mapp) har en struktur som följer hur JSON är utformad och mappen är dynamisk och växer i storlek beroende av behov.
3.3.3 Front-end och Ajax anrop
Sista steget i lösningen är när datat från databasen valts ut, modifierats, anpassats till JSON och lagts upp på ett REST API som går att komma åt via en URL. Då ska en
med att använda jQuery är att det är smidigt att sätta upp en webbapplikation och det är lätt att blanda Javascript med HTML i en textredigerare. Den textredigerare som används för front-end delen kommer vara Visual Studio Code. Under färdigställandet av lösningen kommer ingen tid ha lagts på design/CSS. I webbapplikationen för front-end delen ska ett API-anrop till den URL som vid starten av lösningen fylldes med data beroende vilket ID som användes i URL:en. API anropet görs med hjälp av ett ramverk som heter AJAX. Genom en GET metod hämtas datat från REST-API:et in i front-end applikationen i form av en variabel.
I sista steget ska datat som hämtats in för den unika grafen/bilden sättas upp och presenteras på webbsidan där en blandning av hårdkodad text och den hämtade datan skapar en meningsfull beskrivning av grafen/bilden för den synskadade användaren.
3.4 Metod för att kvantitativt mäta resultat av den optimerade webbsidan
I bakgrunden, sektion 2.7 beskrivs information kring olika sätt en webbsida kvantitativt kan mätas sett till webbtillgänglighet med avseende på WCAG 2.0. I detta projekt kommer tillvägagångssättet skapat av Abdullha Alsaeedi [6] användas för att mäta och avgöra ifall en befintlig webbsida får högre eller lägre webbtillgänglighet efter att den optimerats med stöd av den lösning som projektet tagit fram. Alsaeedi beskriver att tillvägagångssättet, kallad web accessibility accuracy (WAA) har en stor fördel och det är att den hjälper
webbutvecklare att avgöra om den nya versionen av en webbsida är mer tillgänglig än den gamla versionen. En annan fördel med tillvägagångssättet är att den utgår från WCAG 2.0:s riktlinjer, något som är centralt i detta arbete.
För att mäta resultatet av en optimering behövs en beskrivning av hur läget var före optimeringen och en beskrivning av läget efter optimering sett till webbtillgänglighet. Som beskrivning av före och efter läget används automatiska mätningsverktyg. För att öka kvaliteten i mätningen bör man använda fler än ett automatiskt mätningsverktyg. Dessa verktyg ger en lista på överträdelser mot WCAG 2.0. Efter att verktygen används på
webbsidan före och efter optimering finns en summa på antal överträdelser från för och efter läget. Automatiska verktyg som kommer används vid mätningen är Axe DevTools och
WAVE, beskrivna i sektion 2.5.1 och 2.5.2.
För varje automatiskt tillgänglighetsverktyg samlas överträdelser med avseende på WCAG 2.0 in för varje enskild sida. Med data från de automatiska mätningsverktygen som input och med hjälp av formeln som tagits fram av Abudullha Alsaeedi [6], ekvation 2 i sektion 2.6 beräknas ett värde för webbtillgängligheten. Förhållandet i formeln representerar andelen överträdelser mot WCAG 2.0:s riktlinjer som upptäcks av alla verktyg för den aktuella webbsidan dividerat med totala antalet överträdelser för alla webbsidorna som är involverade i jämförelseprocessen. WAA-värdet som genereras är ett procentuellt värde anpassat utifrån hur webbtillgängliga de andra webbsidorna är. Ju högre WAA-värde desto bättre webbtillgänglighet. Det förväntade resultatet av mätningen är att WAA-värdet efter den tekniska lösningen implemterats är högre än före optimering. Om WAAefter> WAAförehar optimeringen lyckats i den meningen att den har förbättrat webbtillgängligheten.
4. Resultat
4.1 Skillnader mellan en vanlig hemsida jämfört mot en optimerad hemsida sett till webbtillgänglighet för synskadade webbsidorna
4.1.1 Mätning med automatiskt mätningsverktyg
Vid undersökningen av vad som är skillnader mellan en vanlig hemsida jämfört mot en optimerad hemsida sett till webbtillgängligihet för synskadade användes på webbsidorna det automatiska mätningsverktyget WAVE, beskriven i sektion 2.5.2. Först på Quicksearch hemsida och sedan Synskadade Riksförbunds hemsida. Resultaten från WAVE visas i tabellen nedan. Observera att Synskadades Riksförbunds hemsida inte har några felmeddelanden när hemsidan testades med WAVE.
Quicksearch SRF
Error Message Number of Occurrenc es
WCAG- criteria
Error Message
Number of Occurrences
WCAG - criteria Missing alternative
text
1 1.1.1 0
Linked image missing alternative text
5 1.1.1
2.4.4
0
Spacer image missing alternative text
1 1.1.1 0
Missing form label 1 1.1.1 1.3.1 2.4.6 3.3.2
0
Empty form label 1 1.1.1
1.3.1 2.4.6 3.3.2
0
Multiple form labels
1 1.1.1
1.3.1 2.4.6
0
Empty link 9 2.4.4 0
Contrast Errors 90 1.4.3 0
Tabell 1. Resultat från WAVE för båda webbsidor
Resultaten av testet med automatiska webbtillgänglighetsverktyget visade klart och tydligt att det var skillnader mellan Quickseach hemsida och Synskadades Riksförbunds (SRF)
hemsida. Som går att se i tabell 1 hade SRF:s hemsida inte några överträdelser mot WCAG 2.0 överhuvudtaget medan Quicksearch hemsida hade en total av 109 överträdelser, dock var 90 av dessa 109 överträdelser relaterade till kontrastfel. De övriga 19 felmeddekandena relaterade i de flesta fall (17 av 19) till överträdelser mot WCAG:s riktlinje “2.4
Navigerbart:Tillhandahåll sätt att hjälpa användarna att navigera, hitta innehåll och avgöra var de är.” Väl hälften (10 av 19) av samma övriga felmeddelande relaterade till
överträdelser mot WCAG:s första riktlinje “1.1Textalternativ: 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.”
De övriga 19 felmeddelandena relaterade i de flesta fall (17 av 19) till överträdelser mot WCAG:s andra riktlinje ”2.4 Navigerbart: Tillhandahåll sätt att hjälpa användarna att navigera, hitta innehåll och avgöra var de är.” Väl hälften (10 av 19) av samma övriga felmeddelande relaterade till överträdelser mot WCAG:s första riktlinje ”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.”
Skillnaderna mellan en “vanlig” och en “optimerad” hemsida baserat på det automatiska testverktyget skulle kunna sammanfattas så här.
En vanlig hemsida
1. har genomgående mycket sämre kontrast.
2. saknar ofta användbart stöd för navigering som gör att användaren kan hitta innehåll och avgöra var på sidan man är.
3. saknar ofta textalternativ till icke textbaserat innehåll så som till exempel bilder och grafisk presentation av data.
4.1.2 Intervjuer
Efter att mätningar genomförts med stöd av automatiskt testverktyg genomfördes intervjuer.
Sammanställning av svaren från respondenterna visas nedan.
Struktur
På frågan hur strukturen upplevs kring menyerna så var alla tre personerna ense om att Synskadades riksförbunds webbsida var bättre beskriven än vad Quicksearch webbsida var vad gäller menyerna. Person B tyckte “Det kändes som att strukturen följde ett liknande mönster på båda webbsidorna vad gäller menyerna men att på Synskadades Riksförbunds sida så beskrevs varje del i menyn mer ingående för skärmläsare användaren”. Person A upplevde att det var svårt att styra skärmläsaren och förstod ganska snabbt att ett visst tålamod skulle krävas för att ta sig igenom webbsidan. Det han tyckte var bra med menyerna var att “På båda webbsidorna trots att jag visst att jag inte i denna uppgift fick använda mig av den var det bra att det fanns sökfönster man kunde använda”. Något han säger skulle vara det första han skulle använda om han var blind och använde en webbsida. Person C nämnde också det positiva med sökfönster men han tyckte det var svårt att uppfatta på den
mindre optimerade webbsidan uppfatta att det var ett sökfönster när han stod på det med skärmläsaren. Han säger att “beskrivning av vad skärmläsaren läser upp var inte tillräckligt bra på företagets webbsida. Och det var inte bara sökrutan som var dåligt beskriven utan många andra delar”.
På frågan har webbsidan en tydlig väg som beskriver vad som sker från start till slut så tycker person A att Synskadades Riksförbunds(SRF) var en betydligt bättre webbsida att följa med skärmläsaren. Han tyckte allting var lite bättre beskrivet jämfört med den mindre optimala webbsidan. Efter testningen fick personerna se hur de båda webbsidorna såg ut och person A kunde konstatera att det fanns en del i Quicksearch webbsida som fick honom att bli väldigt förvirrad. Bland annat var det en större ruta som visade en bild och efter några sekunder så byttes bild och detta gjorde det svårt för respondenterna att förstå vad som föregick. Person B och C upplevde att så länge man hade ett gott tålamod och lyssnade noga så tog man sig fram och hittade till slut det man sökte. Dock sa person C det inte fungerade hela tiden då “det fanns i den mindre optimala webbsidan en del där jag trodde skärmläsaren hakat upp sig men när vi tittade på webbsidan så visar det sig bara att det var fem olika länkar som beskrevs med exakt samma data”.
Syfte
På frågan om syftet med webbsidan framgår tydligt var alla tre respondenterna överens om att syftet framgick betydligt bättre på SRF webbsida. Person B visste på förhand vad de båda webbsidorna handlade men han tyckte “Det var bra att båda webbsidorna beskrevs från första början, det gav en första inblick på vart man befann sig. Dock beskrev SRF bättre syftet med sitt innehåll”. Person C tyckte att det återigen handlade om hur väl saker och ting var beskrivna på de olika webbsidorna. Han beskrev det som “SRF sida var alltid lite mer detaljerad vad gäller allt från bilder till länkar m.m. Att få den lilla extra förklaringen på vad länken man är på handlar om gör upplevelsen av webbsidan så mycket bättre” Detta tyckte person C gjorde att syftet framgick tydligare i alla delar av SRF sida. Person A tyckte att “Det fanns länkar som man enkelt förstod bara av att höra titelordet men att det på specifikt den mindre optimerade sidan finns länkar med titlar som fick honom att undra vad det betydde”
Han tyckte att det hade varit lättare att få en uppfattning kring vissa länkar om de beskrevs med några fler ord än bara en kort titel.
Interaktion
Hur upplevde personerna interaktionen mellan webbsidan och skärmläsaren? Person A hängde upp sig på att skärmläsaren läser upp innehåll med helt fel uttal och försvårade då förståelsen av innehållet. Som han beskrev det, “Oftast var det ord som var skrivna på engelska till exempel Quicksearch som fick skärmläsaren att låta konstigt. Det fanns även svenska ord som inte alls stämde vid uttalet och fick mig att behöva tänka efter vad
skärmläsaren egentligen sa”. Person B tyckte SRF sida var fiffigt upplagd då de hade lagt in i början av webbsidan länkar där man kunde hoppa direkt till olika innehåll men hjälp av några kommando som skärmläsaren läser upp högt. Han sa “I denna uppgift så var det ju sagt att vi inte skulle ta några “genvägar” men det var smart att lägga in kommandon som gör att man kommer till det innehåll man är intresserad. Är man första gången inne på en webbsida så kanske det är svårt att veta vart man vill gå men för den som vet är detta en smart lösning då skärmläsaren är ganska långsam att ta sig fram med”. Person C var också inne på att uttal av vissa ord försvårar förståelsen av visst innehåll. Han tyckte heller inte om
rösten. “Den läste för snabbt i vissa lägen och om jag själv hade varit blind så hade jag absolut lagt ner pengar på att skaffa mig en skärmläsare som har mer naturlig berättarröst”.
Skillnaderna mellan en “vanlig” och en “optimerad” hemsidan baserat på intervjuerna skulle kunna sammanfattas så här.
En vanlig hemsida
4. har inte lika användbart stöd för navigering som gör att det går att hitta innehåll och avgöra var på sidan man är.
5. kan innehålla element som byter innehåll med korta intervaller.
6. har korta eller inga beskrivningar av menyer och länkar.
4.2 Resultat av teknisk lösning för att skapa en bättre webbtillgänglighet
Med alla delsystem och tekniker beskrivna i metoddelen tog projektet fram en teknisk lösning, ett webbsystem (Webbsystemet), som i sin tur vid användande gav en bättre webbtillgänglighet, se längre ner i texten. Flödesschema för Webbsystemet går att se i figur 9 nedan.
Figur 9. Flödesschema för resultat av teknisk lösning till problemet.
4.2.1 Back-end delen
Webbsystemet startas genom att manuellt ladda URL:en med det unika ID:et för vald graf.
När URL:en laddats läser och hämtar back-end applikationen (ASP.NET) det unika ID:et för grafen från URL:en. När ID:et hämtats från URL till back-end används sedan detta ID för att, via Hibernate, hämta data från databas med det specifika ID:et. Hibernate genererar det hämtade datat i en objektorienterad form vilket gör det lätt för utvecklaren att anpassa och hantera datat i back-end applikationen. Från datat som hämtats plockas det mest
fundamentala ut som kan beskriva bilden/frågan. Datat omvandlas och anpassas till JSON och skickas sedan tillbaka till REST-API:et och den URL som laddats vid starten av
Webbsystemet.
4.2.2 Front-end delen
När datat hämtats från databas, anpassats och skickats till REST API är datat klart att skickas vidare till Webbsystemets front-end del. Front-end delen är en webbapplikation med uppgift att presentera datat för användaren. För att få datat till front-end applikationen används teknikerna AJAX. JQuery kombinerat med AJAX hämtar datat från REST-API:et genom att en GET metod anropar den URL där all data som beskriver grafen finns. Anropet med AJAX måste i lösningen ske manuellt genom att skriva in ID:et för den graf som ska hämtas. När datat tillslut är hämtat till front-end applikationen kombineras hårdkodad text med datat som hämtats för att kort och koncist beskriva och presentera innehållet av grafen i klartext. Genom att byta ID hämtas annan data för annan graf. På så sätt kan Webbsystemet som det är konstruerat presentera data om valfri graf under förutsättning att datat i
databasen följer samma datamodell.
I Figur 10 nedan visas resultatet av den tekniska lösning på JQuery webbsidan. Datat som hämtats är unikt för ID 176168 vilket motsvarar grafen/frågan “Säljare ville ha affären” och är presenterat i klartext. Själva webbsidan och grafen går att se i figur 1.
Figur 10. Dynamisk data presenterad på webbsidan som beskriver bilden/frågan, Säljare ville ha affären med ID 176168.
Målet med Webbsystemet är att datat som presenteras på webbsidan i figur 10 ska befinna sig i en “<alt> tag” så att webbtillgängligiheten för synskadade ska bli bättre genom att en skärmläsare kan läsa upp texten i <alt>tagen. I nästa sektion beskrivs resultaten av testen av Webbsystemet.
4.2.3 Test av webbtillgänglighet på webbsidan före och efter implementation av lösning
Genom att implementera lösningen, Webbsystemet som skapats under projektet, på en webbsida hos det företag jag jobbade hos, har mätningar kunnat utföras för att kontrollera hur mycket bättre eller sämre webbtillgängligheten blev efter implementeringen. Det som mäts är ett värde, web accessibility accuracy (WAA), beskrivet i sektion 3.4. Värdet
redovisas i procent och alla värden för webbsidorna är i jämförelse med varandra. På grund av att företaget jag skrev arbetet hos inte vill visa för mycket detaljer från sitt system kommer inte de exakta överträdelserna mot WCAG 2.0 visas från de automatiska
tillgänglighetsverktygen för webbsidan. Webbsidan testningen gjordes på kan inte heller visas. Dock kan totala antalet överträdelser från de båda mätverktygen anges. Det är allt som krävs för att kontrollera hur mycket bättre den tekniska lösningen som tagits fram under projektet bidrar till att ge en webbsida ökad webbtillgänglighet. Vid implementeringen
användes den tekniska lösningen, Webbsystemet som skapats för att hämta data för unik graf och beskriva grafen. Datat läggs sedan in i grafen/bildens img<> element.
Data = Här läggs data för att beskriva grafen. Hämtad m.h.a. den tekniska lösningen som skapats under projektet.
<img src=”bild av vald graf” alt=Data>
I tabellerna nedan visas antal överträdelser uppmätta med automatiska tillgänglighetsverktygen WAVE och Axe DevTools på webbsidan före och efter implementering av den tekniska lösningen.
Resultat från mätverktyget WAVE.
Webbsida Före Efter
Antal Överträdelser mot WCAG 2.0
68 67
Tabell 2. Antal överträdelser mätta mha. WAVE med avseende på WCAG 2.0. Före och efter tekniska lösningen till webbsida implementerades
Resultat från mätverktyget Axe DevTools.
Webbsida Före Efter
Antal Överträdelser mot WCAG 2.0
82 81
Tabell 3. Antal överträdelser mätta mha. AxeDevTools med avseende på WCAG 2.0. Före och efter tekniska lösningen till webbsida implementerades
Med antalet överträdelser beräknade före och innan implementering med automatiska tillgänglighetsverktygen presenteras nedan i figur 11 WAA-värdet för webbsidan.
Jämförelsen är innan webbsidan implementerades med den tekniska lösningen och efter.
Figur 11. Web Accessibility Accuracy, jämförelse före och efter implementering av teknisk lösning
100 * (50.34-49.66) / 49.66 = 1.369
Resultatet av mätningen före och efter den tekniska lösningen implementeras visar att det blev en förbättring på 1.37% sett till webbtillgänglighet efter implementering av den lösning som skapades under projektet.
5. Diskussion
5.1 Resultat
Ett av målen med arbetet var att beskriva skillnader mellan en vanlig företagshemsida mot en optimerad hemsida med avseende på webbtillgänglighet för synskadade.
Det automatiska testverktyget ger en lista på viktiga skillnader mellan en optimerad och en vanlig hemsida som säger att en vanlig hemsida
1. har genomgående mycket sämre kontrast.
2. saknar ofta användbart stöd för navigering som gör att användaren kan hitta innehåll och avgöra var på sidan man är.
3. saknar ofta textalternativ till icke textbaserat innehåll som till exempel bilder och grafisk presentation av data
Intervjuerna ger på motsvarande sätt en lista som säger att en vanlig hemsida
A. har inte lika användbart stöd för navigering som gör att användaren kan hitta innehåll och avgöra var på sidan man är.
B. kan innehålla element som byter innehåll med korta intervaller.
C. har korta eller inga beskrivningar av länkar och menyer.
Listorna liknar varandra. Till exempel så kan punkt 2 och punkt A anses beskriva samma skillnad. Punkt C beskriver att en vanlig hemsida har korta eller inga beskrivningar av länkar och menyer. Avsaknad av bra beskrivningar bidrar till att en vanlig hemsida inte har lika användbart stöd för navigering (punkt A).
Slår man samman listorna skulle en gemensam lista kunna se ut såhär
Skillnaderna mellan en vanlig företagshemsida mot en hemsida optimerad för synskadade är att en vanlig hemsida
i. har genomgående mycket sämre kontrast
ii. saknar ofta användbart stöd för navigering som gör att användaren kan hitta innehåll och avgöra var på sidan man är.
iii. saknar ofta textalternativ till icke textbaserat innehåll som till exempel bilder och grafisk presentation av data
iv. kan innehålla element som byter innehåll med korta intervaller.
Därmed kan man säga att projektets första mål är uppnått, d.v.s. att beskriva skillnaden sett till webbtillgänglighet mellan en vanlig företagshemsida och en för synskadade optimerad hemsida.
Andra målet i projektet var att visa på en teknisk lösning som förbättrar möjligheten för en synskadad användare att tillgodogöra sig personlig information som redovisas grafiskt i form av bilder. Resultatet från mätningar med de två automatiska testverktygen ger att värdet för web accessibility accuracy (WAA) som är högre efter optimering än före av webbsida. Det betyder att den tekniska lösningen som projektet tagit fram för att förbättra webbtillgänglighet verkligen förbättrar webbtillgängligheten. Därmed har projektet nått även sitt andra mål.
