Auditiv feedback i menyer på webben: Ljud som navigeringsstöd för personer med synnedsättning

AUDITIV FEEDBACK I MENYER PÅ WEBBEN

Ljud som navigeringsstöd för personer med synnedsättning

AUDIO FEEDBACK IN MENUS ON THE WEB

Sound as a navigational aid for people with visual impairment

Examensarbete inom huvudområdet Informationsteknologi Grundnivå 30 högskolepoäng

Vårtermin 2021

Alice Fritz

Handledare: Henrik Gustavsson

Sammanfattning

Internet är för många en självklarhet för att kunna dela och ta del av information. För andra kan användandet av internet vara frustrerande och exkluderande. En sådan grupp är personer med olika former av synnedsättningar. För dessa personer finns vissa verktyg tillgängliga så som screen readers. Dessa underlättar för personer som är helt eller delvis blinda men kan upplevas som långsamma att använda för personer som till viss del klarar av att utan stöd av en screen reader. För att underlätta för dessa personer kan ljud användas i olika delar av användargränssnittet. En studie genomfördes för att undersöka hur en modifierad navigeringsmeny med ljud påverkar tiden det tar för användare att lösa navigeringsrelaterade uppgifter i en webbapplikation. Webbapplikationen använde sig av en simulering av synnedsättningen glaukom (grön starr) Resultaten visade inte på några statistiskt signifikanta skillnader varken gällande tiden det tog att lösa uppgifterna eller hur svår navigeringsmenyn upplevdes att använda. Utifrån detta dras slutsatsen att ljud inte påverkar hur lätt eller svårt det är för användare att lösa navigeringsrelaterade uppgifter.

Nyckelord: synnedsättning, auditory icons, earcons, tillgänglighet

Innehållsförteckning

1 Introduktion ... 1

2 Bakgrund ... 2

2.1 Synnedsättning ... 2

2.1.1 Synnedsättning och webben ... 2

2.1.2 Simulering av synnedsättning ... 3

2.2 Menyutformning ... 5

2.3 Ljud i menyer ... 7

2.3.1 Auditory Icons och Earcons ... 10

3 Problemformulering ... 14

3.1 Metodbeskrivning ... 14

3.2 Etik ... 16

4 Genomförande ... 18

4.1 Litteraturstudie ... 18

4.2 Progression... 21

4.2.1 Grafiskt användargränssnitt ... 21

4.2.2 Uppgiftsinstruktioner ... 25

4.2.3 Insamling av data ... 26

4.2.4 Simulering av synnedsättning ... 28

4.2.5 Ljuddesign ... 31

4.2.6 Implementation av ljud ... 32

4.3 Pilotstudie ... 33

4.3.1 Korrigeringar efter pilotstudie ... 36

5 Utvärdering... 41

5.1 Presentation av undersökning och resultat ... 41

5.2 Analys ... 50

5.3 Slutsatser ... 51

6 Avslutande diskussion ... 52

6.1 Diskussion ... 52

6.1.1 Etik ... 54

6.1.2 Samhällsnytta och risker ... 55

6.2 Framtida arbete ... 56

Referenser ... 57

1 Introduktion

Ett stort antal människor lever med någon form av synnedsättning vilket påverkar stora delar av deras vardag. Vissa aktiviteter kan utföras med lätthet även av personer med synnedsättning medan andra, ofta mer visuellt intensiva aktiviteter är svårare. En sådan visuellt intensiv aktivitet är att använda grafiska gränssnitt så som en webbläsare. För personer som är helt eller delvis blinda finns verktyg i form av screen readers som gör att även blinda kan ta det av information på internet. För personer med mildare grader av synnedsättning kan screen readers kännas långsamma eftersom de måste översätta webbsidorna till (syntetiserat) talad text men de har ändå svårt att använda grafiska gränssnitt jämfört med personer utan synnedsättning.

Som ett stöd till grafiska gränssnitt kan ljud användas. Ljud i användargränssnitt delas upp i kategorierna Auditory Icons och Earcons där Auditory Icons är ljud som har en tydlig koppling till fysiska objekt och händelser. Earcons har inte denna tydliga koppling utan är mer abstrakta och består ofta av korta musikaliska kompositioner . De två kategorierna är lämpade för olika användningsområden men kan även kombineras. Det finns viss forskning kring hur fördelarna med respektive kategori bäst tillämpas men forskningen är allt annat än entydig.

I detta arbete kommer en webbsida med ljud som navigeringsstöd i en meny att jämföras med en grafiskt identisk webbsida utan ljud. I ett människoinriktat experiment kommer testdeltagare att få utföra en rad uppgifter som är utformade för att likna verkliga situationer på webben. Under undersökningens gång kommer data samlas in. En kontrollgrupp kommer att använda webbsidan utan ljud och en testgrupp kommer att använda webbsidan med ljud.

I genomförandekapitlet beskrivs utvecklingsprocessen av de webbapplikationer som används i studien. Viktiga designval tas upp och exemplifieras med kodstycken eller andra figurer. Med de utvecklade webbapplikationerna genomfördes en pilotstudie för att utvärdera webbapplikationerna och det tänka tillvägagångssättet för den kommande studien.

Med stöd av det som framkommit under pilotstudien genomfördes ett fåtal korrigeringar som också beskrivs i detta kapitel.

Studiens mål är att undersöka om auditiv feedback i form av Auditory Icons och Earcons kan användas i en navigeringsmeny i en webbapplikation för att underlätta navigering för personer med synnedsättning. Ett människoinriktat experiment utfördes där testpersoner fick använda de webbapplikationer som utvecklats. Under experimentet simulerades synnedsättningen glaukom, grön starr. Under experimentets gång samlades tiden det tog för testpersonerna att lösa navigeringsrelaterade uppgifter in. Testpersonerna fick även svara på ett antal självskattningsfrågor om hur de upplevde experimentet. Resultaten från experimentet analyserades för att klarlägga eventuella skillnader mellan att använda en webbapplikation med auditiv feedback i navigeringmenyn och att använda en webbapplikation utan någon form av auditiv feedback.

2 Bakgrund

2.1 Synnedsättning

I en enkätsöversikt sammanfattades enkätssvar från 51 enkäter från 39 olika länder gällande synnedsättning (Pascolini & Mariotti 2012). Målet med enkätöversikten var att sammanställa data och uppskatta hur stor del av jordens befolkning som har någon form av synnedsättning och vilka orsakerna till dessa synnedsättningar var. Pascolini och Mariotti uppskattade att 285 miljoner människor hade någon form av synnedsättning varav 39 miljoner var blinda enligt ICD-10‘s (International Classification of Diseases) definition.

Den främsta orsaken till nedsatt syn var enligt Pascolini och Mariotti brytningsfel och grå starr, 43% respektive 33%, men de poängterar också att en stor del av fallen var odiagnosticerade (18%). Grå starr var även den vanligaste orsaken till blindhet, 51%, med andelen odiagnosticerade fall på 21%. I rapporten poängteras bristen på större nationella och standardiserade undersökningar vilket gör att insamlad data inte nödvändigtvis kan appliceras på global nivå. På grund av detta menar de att deras uppskattningar kan vara uppemot 20% fel i vardera riktning.

Det finns många olika typer av synnedsättningar med olika orsaker och symtom. De vanligaste symtomen är låg skärpa, förlust av periferiseende, störningar i seendet och förlust av färgseende. Några vanliga synnedsättningar som också har simulerats i tidigare forskning (Lewis, Brown, Cranton & Mason 2011 samt Ates, Fiannaca & Folmer 2015) är:

 Macular degeneration (makuladegeneration, förändringar på gula fläcken). Ger försämrad synskärpa i mitten av synfältet.

 Diabetic retinopathy (diabetisk näthinnesjukdom). Ger fläcker i synfältet, försämrad synskärpa och ljuskänslighet.

 Glaucoma (glaukom). Ger dimmig syn och resulterar i förlust av periferiseende.

 Cataracts (grå starr). Ger dimmig syn och försämrad synskärpa.

 Color blindness (färgblindhet). Gör det svårt att skilja mellan olika färger.

 Diplopia (dubbelseende). Gör att personen ser dubbelt.

 Hemianopia (halvseende). Förlust av halva synfältet.

 Myopia och hyperopia (närsynthet respektive långsynthet). Ger försämrad synskärpa på långt respektive kort håll.

2.1.1 Synnedsättning och webben

Många anser att användande av internet är en nödvändig del för att vara en del av dagens samhälle, frivilligt eller ej (Noh, Sulaiman, Noor, & Kit 2018). För de allra flesta är detta inget problem men för personer med synnedsättning kan det vara betydligt svårare. Detta medför att personer med synnedsättning riskerar att inte få tillgång till samma information och möjligheter som personer med fullgod syn. För att underlätta för personer med synnedsättning har vissa tekniska verktyg utvecklats.

Ett av de mest välkända och välanvända verktygen är screen readers. Screen readers omvandlar innehåll på skärmen till ljud i form av en syntetiserad röst (en konstgjord röst).

För att detta skall fungera optimalt är det viktigt att de som utvecklar webbsidor gör detta på ett sätt som är anpassat för en screen reader. Om så inte är fallet kan screen readern tolka

för olika språk som ett problem hos många screen readers. Med ett lågt eller bristfälligt stöd för olika språk ökar risken för missförstånd och förvirring. Noh m.fl genomförde en undersökning där 8 delvis blinda personer deltog. Samtliga av deltagarnas mordersmål var malajiska, ett språk som saknade stöd i då tillgängliga screen readers. Majoriteten av deltagarna uppgav att de sällan använde internet och att de föredrog att besöka webbsidor på malajiska. Att de screen readers som fanns tillgängliga saknade stöd för malajiska gjorde att det tog lång tid att ta till sig informationen på webbsidan vilket upplevdes som frustrerande.

2002 presenterades resultaten från SEE-projektet, Salisbury Eye Evaluation, som undersökte hur vardagssysslor påverkades av nedsatt synskärpa och nedsatt kontrastkänslighet (West, Rubin, Broman, Muñoz, Bandeen-Roche & Turano 2002). I studien deltog 2520 äldre (65-84 år) personer. I en kontrollerad miljö fick deltagarna genomföra tester som skapats för att efterlikna vanliga vardagssysslor. Testerna delades in i kategorierna mobilitetstester, dagliga aktiviteter med en stark visuell komponent och visuellt intensiva tester. Exempel på testerna var att gå upp och ner för trappor (mobilitet), att sätta in en nyckel i ett nyckelhål (daglig aktivitet) och högläsning (visuellt intensiv). För de flesta testerna mättes tiden det tog att lösa uppgiften men för vissa tester användes andra mätvärden som vid högläsning där antalet korrekt upplästa ord per minut användes.

Resultaten visade att prestationerna för testerna påverkades linjärt beroende på synnedsättningen (detta gällde för både nedsatt synskärpa och nedsatt kontrastkänslighet).

På grund av detta menar författarna att det inte går att dra en tydlig gräns för vad som bör anses som ett handikapp (West m.fl 2002). För att detta skall kunna göras krävs en tydlig punkt i den insamlade datan där deltagarna plötsligt presterar sämre. De menar också att utförandet av olika vardagssysslor påverkas olika mycket av synnedsättningar och att det därför är svårt att sätta en gräns för när nedsatt syn bör betraktas som ett handikapp.

West m.fl. poängterar att undersökningen inte fokuserade på hur länge deltagarna haft synnedsättningar. Det är därför möjligt att vissa deltagare haft synnedsättningen under en längre tid och därför utvecklat tekniker för att kompensera för synnedsättningen vilket kan ha påverkat hur de presterade i testerna. Undersökningen fokuserade inte heller på om deltagarna upplevde sin prestation som ett problem. Olika individer kan uppleva samma kvantifierade prestation på olika sätt, för vissa individer kan det ses som ett hinder och för andra inte.

2.1.2 Simulering av synnedsättning

Lewis, Brown, Cranton och Mason beskriver i sitt arbete hur spelmotorn Unreal Engine 3 använts för att simulera olika typer av synnedsättningar (2011). Tidigare har synnedsättningar visualiserats med hjälp av olika former av konstnärliga uttryck eller fysiska verktyg, t.ex. ‖Sim Specs‖ som är glasögon som på olika sätt förändrats för att påverka bärarens synfält. Mer moderna lösningar använder datorer för att simulera synnedsättning.

På detta sätt är det lättare att simulera olika grader av synnedsättning, något som inte var praktiskt tidigare vid användning av ‖Sim Specs‖ och liknande verktyg. Detta kunde dels vara simuleringar på skärmar men även simuleringar i VR-miljöer (Virtual Reality). Lewis m.fl menar att VR-miljöer bedöms som realistiska av användare trots att grafiken inte alltid är fullt naturtrogen och att VR-miljöer därför passar väl för simuleringar av olika typer av förhinder, däribland synnedsättningar.

Synnedsättningarna glaukom (grön starr), makuladegeneration (förändringar på gula fläcken, oftast åldersrelaterade), cataracts (grå starr), hemianopsia (halvseende), myopi (närsynthet) samt hyperopi (långsynthet) valdes ut för att implementeras i en virtuell miljö föreställande en restaurang. De olika typerna av synnedsättning implementerades med hjälp av overlays och/eller post processing (Lewis m.fl. 2011).

Simulatorn granskades av en forskare vid University of Nottingham som bedömdes ha förmåga att utvärdera simulatorns potentiella användningsområden i utbildningssyfte.

Utöver detta deltog 21 universitetsstudenter i en undersökning. Undersökningen bestod av två enkäter och ett test av simulatorn. Studenterna fick besvara en enkät innan simulatortestet och en enkät efter simulatortestet. Frågorna ställdes för att besvara hur medvetna studenterna var gällande olika former av synnedsättningar och hur simulatortestet påverkade denna medvetenhet.

Experten som granskade simulatorn bedömde att den var väl utformad för att kunna användas i utbildningssyfte. Synnedsättningssimulationerna bedömdes som ‖reasonably accurate‖ (rimligt precisa). Svaren från enkäterna tyder på att simulatorn höjde förståelsen och medvetenheten relaterade till synnedsättningar. Studenterna kunde efter undersökningen tydligare beskriva symtom bland olika former av synnedsättning än vad de kunde innan undersökningen. Detta var särskilt tydligt för diabetic retinopathy (diabetisk näthinnesjukdom) då endast ett fåtal kunde beskriva symtomen innan undersökningen men en majoritet kunde det efter undersökningen. Det är värt att notera att diabetic retinopathy inte nämndes bland de synnedsättningssimuleringar som implementerades tidigare i artikeln. Det är möjligt att denna simulering tillkom vid ett senare tillfälle.

Lewis m.fl. (2011) utvecklade en VR-miljö för att simulera olika former av nedsättningar. Ett potentiellt problem med detta är att det kräver att varje ny miljö som skall testas eller undersökas behöver utvecklas vilket tar tid och kostar pengar. Därför kan det vara lämpligare att använda AR, Augmented Reality (Förstärkt Verklighet). AR kombinerar grafiska element med verkligheten. Hur detta kan användas för att simulera olika former av synnedsättningar har undersökts av Ates, Fiannaca och Folmer (2015).

Med hjälp av ett VR-headset, kameror och det egenutvecklade simuleringsverktyget SIMVIZ kan användare utforska en fysisk miljö med synnedsättningssimulering i realtid. Detta arbetssätt kombinerar fördelarna med både mjukvarusimulering och fysiska verktyg (så som tidigare nämnda ‖Sim Specs‖). SIMVIZ utvecklades till skillnad från Lewis m.fl. simulator inte i en spelmotor utan använde programmet VR media player. Med hjälp av en plugin var det möjligt att strömma video direkt från kamerorna till VR media player. Olika filter kunde sedan appliceras på videoströmmen för att simulera synnedsättning. Ates, Fiannaca och Folmer valde ut synnedsättningarna Macular degeneration, Diabetic retinopathy, Glaucoma, Cataracs, Color blindness och Diplopia och implementerade simuleringar av dessa baserat på exempelbilder från National Eye Institute.

12 studenter anlitades för att agera testpersoner. Eftersom synnedsättningar kan upplevas väldigt olika för olika personer och det kan vara svårt för personer med synnedsättningar att använda simulationsverktyg lades fokus på att utvärdera hur simuleringsverktyget påverkar användarens immersion. Deltagarna delades upp i en försöksgrupp och en kontrollgrupp.

Försöksgruppen fick först använda SIMVIZ och sedan mjukvaran VisionSim på en iPhone 4S. Deltagarna fick besvara en enkät efter varje testomgång där de fick uppskatta immersion, användarvänlighet (‖ease of use‖) och potentialen att upptäcka tillgänglighetsproblem på en

5-gradig Likertskala. Kontrollgruppen genomförde testerna i omvänd ordning. Resultaten visade på signifikanta skillnader för immersion och potential för att upptäcka tillgänglighetsproblem mellan SIMVIZ och VisionSim (där SIMVIZ upplevdes som mer immersionshöjande och hade större potential för att upptäcka tillgänglighetsproblem).

Skillnaden för användarvänlighet var inte signifikant.

2.2 Menyutformning

Utformningen av en webbsidas navigeringsmeny har stor påverkan på hur användare löser navigeringsrelaterade uppgifter (Leuthold, Schmutz, Bargas-Avila, Tuch & Opwis, 2011). I en undersökning användes eye tracking-teknologi (sensorteknologi som gör att man kan följa ögonens rörelser) för att undersöka hur olika navigeringsmenystrukturerer och uppgiftskomplexitet påverkade användarnas navigering på en webbsida.

Navigeringsstrukturerna som undersöktes var ‖simple menus‖, ‖vertical menus‖ och

‖dynamic menus‖ (Leuthold m.fl 2011). Simple menus är menyer där samtliga länkar är synliga i en vertikal lista. Vertical menus är menyer som likt simple menus består av en lista av samtliga länkar men som även är uppdelade i subkategorier. Dynamic menus är menyer där länkarna är uppdelade i subkategorier men länkarna är dolda tills det att användaren markerar en specifik subkategori. Värt att notera är att samtliga menystrukturerer är uppdelade i olika huvudkategorier (se Figur 1). Att klicka på länken ‖Book fairs‖ kräver därför två klick (Books->Book fairs) även för simple menus (och fler för dynamic menus).

Figur 1

För att undersöka hur användarna löser navigeringsrelaterade uppgifter skapades två kategorier av uppgifter, enkla och komplexa uppgifter. Enkla uppgifter är uppgifter som tydligt beskriver vad som skall göra (Leuthold m.fl. 2011). ‖Put the DVD ‗Liar, Liar‘ with Jim Carrey in the shopping cart.‖ ges som ett exempel på en simpel uppgift. Komplexa uppgifter är uppgifter där användaren instrueras att utföra något baserat på vissa krav. ‖Find a DVD in Swiss German which was a box office success and that is suitable for your 5-year-old cousin.

If there is such a DVD, put it into the shopping cart.‖ ges som ett exempel på en komplex

uppgift. Komplexa uppgifter använder inte ord som återfinns i navigeringsmenyerna och det är därför upp till användaren att göra relevanta kopplingar mellan uppgiftsinstruktionerna och navigeringsmenyn, t.ex. ‖box office success‖ i uppgiftsinstruktionen -> ‖Bestsellers‖ i navigeringsmenyn.

De 120 undersökningsdeltagarna delades upp i sex grupper. Grupperna testade navigeringsmenystrukturerna i olika ordning. Varje testsegment bestod av tolv uppgifter – sex enkla och sex komplexa. Totalt fanns 36 olika uppgifter och inga testpersoner fick utföra samma uppgift mer än en gång. Under testsegmenten hade deltagarna på sig en eye tracker som samlade in data om var på skärmen de tittade. Efter varje testsegment fick deltagarna fylla i en enkät med frågor gällande hur de upplevde den nyss testade menystrukturen.

Resultaten visade att deltagarna föredrog den vertikala menyn framför både den enkla och den dynamiska menyn. Deltagarna presterade även bättre när de använde den vertikala menyn jämfört med den enkla respektive dynamiska menyn. Leuthold m.fl. (2011) menar att menyer bör utformas på ett sådant sätt att de synliggör så många länkar (‖navigation items‖) som möjligt, framförallt när användarna förväntas lösa komplexa navigationsrelaterade uppgifter.

I tidigare forskning av Tsunoda, Yamaoka, Yamashita, Matsunobe, Hashiya, Nishiyama och Takashi (2001) undersöktes fem olika menystrukturer. Menyerna var lämpade för en webbutik där produkterna tilldelades fyra olika attribut med tre olika möjliga värden per attribut. Detta gav 81 möjliga kombinationer och därmed 81 olika produkter (3 x 3 x 3 x 3 = 81). Menystrukturerna som testades var en ‖four-level-hierarchy‖ (3 x 3 x 3 x 3), en ‖three- level-hierarchy‖ (9 x 3 x 3), en ‖two-level-hierarchy‖ (27 x 3), en ‖one-level-hierarchy‖ (81 x 1) samt en så kallad ‖frame structure‖ (9 x 3 x 3). Artikeln saknar figurer vilket gör det svårt att tydligt visualisera hur dessa menyer ser ut och skiljer sig från varandra, särskilt för

‖three-level-hierarchy‖ och ‖frame structure‖ som båda beskrivs som (9 x 3 x 3). Hierarkista menyer beskrivs som menyer där användaren behöver gå vidare till nästa sida och en

‖frame-structured menu‖ som en meny där användaren har tillgång till samtliga produktlänkar från en sida.

För att utvärdera hur användare påverkas av olika menystrukturer genomfördes en studie där testdeltagare fick utföra uppgifter enligt instruktioner i olika menystrukturer. Dessa uppgifter delades upp i kategorierna ‖simple tasks‖ och ‖complex tasks‖. ‖Simple tasks‖

definerades som uppgifter som krävde ett litet antal klick och där instruktionen tydligt specificerade vilken produkt som efterfrågades (‖find a fountain pen, Company A, for men, classical one‖). ‖Complex tasks‖ var uppgifter som krävde ett större antal klick och inte exakt specificerade vilken produkt som efterfrågades (‖find the cheapest product manufactured by Company C for men or women‖). ‖Simple tasks‖ krävde endast envägs-navigering för att nå produkten som efterfrågades medan ‖complex tasks‖ krävde att testdeltagaren navigerade fram och tillbaka mellan olika produktsidor för att hitta rätt produkt. För varje menystruktur genomfördes endast en ‖simple task‖ och en ‖complex task‖. Efter varje utförd uppgift fick deltagarna skatta hur lätt/svårt de upplevde användandet av menystrukturen att vara på en femgradig skala. Undersökningen gjordes över internet vilket gjorde att deltagarna kunde delta på distans. Undersökningen begränsades av ett lösenord som endast delades ut på skolor och arbetsplatser som var godkända av författarna. 89 personer deltog i undersökningen. Endast tiden det tog att lösa respektive uppgift samlades in.

Resultaten visade att inga signifikanta skillnader fanns mellan tiden det tog att lösa ‖simple tasks‖ oavsett vilken hierarkisk menystruktur som användes. ‖Frame structure‖ jämfördes med ‖three-level-hierarchy‖ (de två strukturerna som kunde beskrivas som 9 x 3 x 3) och

‖frame structure‖ presterade sämre än ‖three-level-hierarchy‖ för ‖simple tasks‖. För

‖complex tasks‖ såg resultaten annorlunda ut. ‖One-level-hierarchy‖ presterades signifikant bättre än de andra hierariska menystrukturerna. ‖Frame structure‖ jämfördes återigen med

‖three-level-hierarchy‖ och för ‖complex tasks‖ presterade ‖frame structure‖ bättre.

Resultaten från deltagarnas skattning för lätthet att använda de olika strukturerna visade att olika strukturer föredrogs för ‖simple tasks‖ och ‖complex tasks‖. För ‖simple tasks‖

upplevdes menystrukturen med fler hierarkier lättare att använda (även jämfört med ‖frame structure‖) men för ‖complex tasks‖ föredrogs det motsatta – menystrukturer med färre hierarkier och ‖frame structure‖ upplevdes som lättare att använda. Detta är i linje med slutsatserna från Leuthold m.fl. (2011) där andra menystrukturer användes och strukturer med fler produkter/länkar synliga per skärm (färre hierarkier) presterade bättre än strukturer med färre synliga produkter/länkar per skärm (fler hierarkier). Denna skillnad gällde framförallt vid komplexa uppgifter – vid enklare uppgifter var skillnaderna små.

2.3 Ljud i menyer

Att endast använda grafik för att kommunicera information till användare riskerar att överbelasta användaren (Brewster 1997). I de flesta sammanhang använder människor mer än ett sinne för att ta del av information. Detta är inte möjligt i samma utsträckning för helt grafiska användargränssnitt. Brewster menar att grafiska användargränssnitt bör kompletteras med ‖non-speech sounds‖ (ljud som inte består av tal) för att förmedla information.

Ljud som implementeras utan djupare åtanke riskerar att inte hjälpa det grafiska användargränssnittet att förmedla information (Brewster 1997). För att ta reda på hur ljud bör implementeras i symbios med grafiska användargränssnitt anordnades ett experiment där ljud för knappar implementerades. I experimentet användes ljud av typen earcons.

Earcons är abstrakta ljud utan någon tydlig koppling till det de representerar men grupper av earcons kan med fördel grupperas för att ge olika element ett gemensamt sammanhang.

Earcons består vanligtvis av korta rytmiska sekvenser, så kallade motiv. Dessa motiv kan kombineras (‖compound earcons‖) för att förmedla mer komplexa meddelanden.

Ett av de mest centrala elementen i grafiska användargränssnitt är knappar (Brewster 1997).

Trots att de allra flesta grafiska användargränssnitten använder knappar i någon form menar Brewster att de har en del centrala problem. Ofta körs inte gränssnittsknappars funktion när musknappen trycks ned utan när musknappen släpps och musknappen fortfarande befinner sig över/på gränssnittsknappen. Denna funktionalitet gör att användaren kan ångra sig och avbryta en knapptryckning genom att flytta muspekaren från gränssnittsknappen men det gör också att användare av misstag kan flytta muspekaren från gränssnittsknappen och därmed tro att gränsnittsknappen har trycks på när den inte har det (se Figur 2). I vissa fall körs gränssnittsknappars funktion när muspekaren trycks ner vilket gör att användaren inte kan avbryta sin knapptryckning. Brewster menar att detta är ett tillfälle där feedback i form av ljud skulle kunna användas för att kommunicera att en knapptryckning misslyckats utan krav på var användaren tittar (vilket hade varit fallet med visuell feedback).

Figur 2 Exempel på misslyckad (över) och lyckad (under) knapptryckning på

För att undersöka om användandet av feedback i form av ljud för att hjälpa användare vid felklick skapades tre earcons. En ton på 130 Hz, en ton på 261 Hz samt två toner i följd på 1041 Hz. I artikeln benämns dessa som C4, C3 respektive C1 vilket inte är korrekt. Tonernas korrekta namn är C3, C4 respektive C6. Detta fel kan bero på att Brewster använt värden för våglängd istället för frekvens (Hz) när tonerna namngetts. Tonerna kommer härmed att benämnas efter frekvensvärdet (t.ex. 261 Hz) för att undvika förvirring. 130 Hz-tonen spelades så länge som muspekaren befann sig över en knapp (utan att musknappen trycks ner). 261 Hz-tonen spelades när muspekaren befann sig över en knapp OCH musknappen tryckts ner. De två 1046 Hz-tonerna spelades när användaren lyckades trycka på en knapp genom att släppa musknappen och hålla muspekaren över knappen. Om användaren misslyckades med knapptryckningen spelades inget ljud.

Under undersökningen mättes tiden för ‖error correction‖ – tiden det tog från att en misslyckad knapptryckning gjorts tills det att en korrekt knapptryckning (för rätt knapp) genomförts. Även det totala antalet knapptryck som gjordes under testet mättes. Deltagarna fick även svara på en enkät gällande ‖workload‖ – arbetsbörda, inom kategorierna Mental, Physical, Time, Effort, Annoyance, Frustration, Performance och Overall (Brewster 1997).

Deltagarna fick skatta arbetsbördan för varje kategori med ett värde mellan 0 och 20. Ett lägre värde innebar en lägre arbetsbörda förutom för Perfomance och Overall där ett högre värde innebar en lägre arbetsbörda.

Resultaten visade inga signifikanta skillnader gällande arbetsbörda mellan användargränssnittet med ljud och användargränssnittet utan ljud. Däremot föredrog deltagarna användargränssnittet med ljud framför användargränssnittet utan ljud. Brewster menar att detta kan bero på att ljuden gjorde att det var lättare att återhämta sig från misslyckade knapptryckningar men lyfter också att detta även borde ha synts i resultaten från enkätundersökningen då det bör ha minskat den upplevda arbetsbördan. Brewster misstänker att detta kan ha med hur frågorna i enkäten utformats. Om deltagarna uppfattade återhämtning från misslyckade knapptryckningar som en separat aktivitet från den huvudsakliga uppgiften kan de ha räknat bort arbetsbördan för återhämtningen i sina svar i enkäten. Att deltagarna föredrog användargränssnittet med ljud och att detta användargränssnitt inte ansågs mer irriterande eller frustrerande menar Brewster är ett

positivt tecken på att ljud i användargränssnitt är ett väl anpassat medium för att förmedla information.

I en studie undersökte Korhonen, Holm och Heikkinen hur ljudprocessering kunde användas för att förmedla information i en kalenderapplikation på mobila plattformar (2007). Författarna kallar denna processering för "sound effects‖ vilken kan vara något missledande då detta begrepp kan användas även i andra sammanhang med en annan betydelse där ‖sound effects‖/ljudeffekter syftar på ljud i sig och inte på effekter som appliceras på ljud. Korhonen m.fl. ville undersöka hur ljudprocessering i realtid kunde användas för att förmedla information i en mobilapplikation.

En kopia av en existerade kalenderapplikation skapades. I applikationen implementerades ljud som varierades med hjälp av ljudprocessering beroende på vilken handling som utfördes i applikationen. Till exempel applicerades ett reverb med varierade parametrar på ljudet som spelades upp när användaren markerade en dag i kalendern. För en dag utan innehåll applicerades ett stort reverb och för dagar fyllda med innehåll applicerades ett mindre reverb eller i vissa fall inget reverb alls (kan jämföras med hur ljud i ett tomt rum upplevs jämfört med ett inrett rum). Kalendern hade även stöd för notifikationer. För notifikationerna användes ett alarmljud. Användarna kunde svara på notifikationen med ‖snooze‖ eller

‖dismiss‖ och alarmljudet förändrades då med hjälp av ljudprocessering. Om användarna svarade med ‖snooze‖ applicerades en effekt för att likna en vinylskiva som håller på att stanna. Detta sköt upp notifikationen fem minuter. När den uppskjutna notifikationen återigen spelades upp började den från ett ‖stoppat‖ läge för att sedan startas upp med en omvänd vinylskive-effekt. Svarade användarna med ‖dismiss‖ applicerades en delay-effekt (kan beskrivas som ett eko) på alarmljudet som sedan gradvis tonade bort.

I undersökningen som genomfördes under en veckas tid deltog 22 personer (Korhonen m.fl.

2007). Samtliga deltagare använde dagligen en kalenderapplikation i vanliga fall. Deltagarna instruerades att använda applikationen på samma sätt och i samma utsträckning som de i vanliga fall använde sin ordinarie kalenderapplikation. Efter att ha använt kalenderapplikationen med ljud (och ljudeffekter) implementerade fick deltagarna besvara en enkät om deras upplevelse av applikationen. Svarsresultaten visade att en majoritet (64%) av deltagarna upplevde applikationen som mer informativ jämfört med sin ordinarie kalenderapplikation. 68% av deltagarna skulle vilja testa andra typer av applikationer med liknande former av auditiv feedback. Hälften av deltagarna svarade att de tyckte att applikationen var roligare att använda än den ordinarie kalenderapplikationen men 12 (av 22) deltagare uppgav att de tyckte applikationen var irriterande (på grund av den auditiva feedbacken). Detta är något motsägelsefullt eftersom deltagarna förmodligen inte irriterades av applikationen om de upplevde den som rolig. Detta tyder på att någon eller några deltagare kan ha missuppfattat frågan. Ljuden som implementerades hade tre syften – att förmedla information/data genom ljud, att ge feedback för händelser och för att göra intryck på användarna. Författarna bedömer att de till viss del lyckades med de tre syftena. Ljuden uppskattades av de flesta deltagarna men vissa ljud upplevdes som för lika vilket gjorde dem svåra att skilja åt. Sammanfattningsvis menar Korhonen m.fl. (2007) att ljud och ljudeffekter (effekter på ljud) kan användas för att förmedla viss generell information men att detaljerad information kan kräva stöd av visuell feedback eller liknande.

2.3.1 Auditory Icons och Earcons

Auditory Icons och Earcons är de två dominerande kategorierna av ljud som används i användargränssnitt. Oswald menar att definitionerna som normalt används för dessa begrepp ej är helt korrekta och bör revideras (2012). Dessa definitioner beskriver att auditory icons är ljud som är baserade på ljud i vardagen och därmed ikoniska och earcons är musikaliska och därmed symboliska.

Visuella tecken kan delas in i kategorierna Index, Ikoner och Symboler. Index är tecken som har ett logiskt samband med det de symboliserar. Exempelvis har rök ett samband med eld även om de visuellt är väldigt olika. Ikoner är tecken som har en visuell likhet med den den symboliserar, t.ex. vägskyltar som varnar för vilda djur. Vanligtvis består dessa av en siluett av ett djur. Bilförare förstår betydelsen av dessa skyltar eftersom siluetten liknar det djur den symboliserar. Symboler är tecken som endast har ett samband med det de symboliserar på grund av konvention. Ett exempel på detta är vägskylten för huvudled som består av en gul romb med en vit och svart ram. Denna skylt har ingen visuell likhet med det den symbolerar men betydelsen är något de flesta känner till.

Indextecken är lättast att förstå, eftersom det finns ett logisk samband mellan indexet och det det symboliserar. Ikoner är även de lätta att förstå eftersom det finns vissa likheter mellan ikonen och det den symboliserar även om det inte är till samma grad som för index.

Symboler har ingen naturlig koppling till det de symboliserar. Trots detta kan symboler i vissa fall vara att föredra före index eller ikoner eftersom symboler kan bli mer intuitiva med tiden de används av användare (Oswald 2012). Vad index, ikoner och symboler innebär för visuella tecken är lätt att förstå men för auditiva tecken är dessa svårare att definera.

Oswald diskuterar huruvida auditory icons faktiskt är ikoner eller om de i själva verket är auditory indeces. Han menar att enligt den egentliga semiotiska definitionen (som till största del är anpassad för visuella tecken, inte auditiva tecken) bör auditory icons benämnas som auditory indeces eftersom ljuden har en logisk koppling till det ljuden symboliserar, t.ex.

slutarljudet från en kamera. Han menar också att eftersom ljuden är en inspelning av originalljuden har de en ikonisk funktion. De inspelade ljuden kommer aldrig att vara helt identiska med originalljudet. Han landar därför i att auditory icons är den korrekta termen men inte på grund av att de har en logisk koppling till ljudets ursprung (vilket hade gjort ljudet till ett index) utan för att de är kopior som imiterar ursprungsljuden.

Vidare kompliceras auditory icons när de implementeras i ett användargränssnitt. Ljuden i sig kan benämnas som auditory icons men beroende på hur de används kan funktionaliteten bättre beskrivas som ett index eller en symbol. I många användargränssnitt finns även en grafisk motsvarighet, t.ex. ikonen för papperskorgen på en dators skrivbord. Den grafiska ikonen föreställer en fysisk papperskorg och ljudet som spelas när en användare ‖slänger‖

något i papperskorgen liknar det ljud som uppstår av att slänga något i en fysisk papperskorg. Det finns därför en tydlig koppling mellan den grafiska ikonen, ljudet som spelas och det fysiska objekt som de symboliserar. Oswald påpekar att denna tydliga koppling mellan de olika beståndsdelarna är ovanlig eftersom många av de grafiska element som återfinns i användargränssnitt saknas fysiska motsvarigheter (2012).

Earcons ursprungliga definition är ‖auditory signs based on musical principles — short micro-compositions of only a few notes length‖ (Oswald 2012). Oswald menar att denna definition till stor del är korrekt men att i diskussionerna kring Earcons utelämnas ofta hur

Oswald håller med om att musik som endast skapats för att vara musik (så kallad ‖‘pure‘ art music‖) ofta är självrefererande och inte förmedlar någon ytterliggare information men att funktionell musik, så som filmmusik, utan tvekan förmedlar information som inte handlar om musiken i sig (2012). Till viss del görs detta genom olika former av kulturella konventioner men de menar att vissa musikaliska parametrar fyller mer grundläggande och universella funktioner. En exalterad person pratar ofta snabbare, i ett högre tonläge och med högre intervall (mellan tonerna i talet) vilket ofta speglas i hur filmkompositörer förmedlar spänning eller upphetsning med musik.

Att Auditory Icons och Earcons skiljer åt är tydligt, men hur upplevs de av användare när de implementeras i användargränssnitt? Detta undersöktes av Garzonis, Jones, Jay och O‘Neill (2009). Användares upplevelser av Auditory Icons och Earcons jämfördes inom kategorierna intuitivitet, lärbarhet, notabilitet (minnesvärdhet) och preferens. Tio olika mobiltjänster valdes ut, delades in i fyra grupper (hierarkier) och ljudsattes. De Auditory Icons som användes togs fram med hjälp av enkätundersökningar där svarandena valde ut de ljud de ansåg bäst lämpade och de Earcons som användes togs fram med hjälp av en musiker och utvärderades sedan av en mindre grupp testpersoner. Som exempel användes ljudet från en stor publik på en arena (Auditory Icon) och ett piano som spelade en nedåtgående skala monofoniskt (Earcon) för att symbolisera tjänsten ‖Sports Information‖. Studien pågick under en längre tid (36 dagar) och hade 16 deltagare.

Intuitivitet, lärbarhet och notabilitet/minnesvärdhet testades vid separata tillfällen (Garzonis m.fl. 2009). Intuitivitet testades genom att testdeltagarna fick lyssna på ljuden och para ihop rätt mobiltjänst med rätt ljud. Detta gjordes för både Auditory Icons och Earcons.

Lärbarhet testades på ett liknande sätt där deltagarna skulle para ihop rätt ljud med rätt mobiltjänst men till skillnad från intuitivitetstestet upprepades detta test ett flertal gånger dag i en vecka. Deltagarna fick direkt veta vilka ljud och mobiltjänster som parats ihop korrekt och vilka som parats ihop felaktigt. I detta test spelades ljuden upp i blandad ordning (både Auditory Icons och Earcons testades samtidigt). Lärbarheten undersöktes även kommande vecka men då i en labbmiljö där deltagarna återigen fick para ihop ljud med mobiltjänster. Efter detta följde en träningssession där deltagarna fick lyssna på ljuden och samtidigt tillgång till vilken mobiltjänst respektive ljud tillhörde. Sedan fick deltagarna återigen para ihop ljuden och mobiltjänsterna, dels med feedback direkt efter varje ljud och dels med feedback efter att alla ljud spelats upp. Notabilitet/minnesvärdhet testades en respektive fyra veckor efter lärbarhetsundersökningen. Detta test genomfördes i valfri miljö på en webbsida. Deltagarna fick återigen lyssna på ljuden och skulle sedan para ihop dem med rätt mobiltjänst.

Resultaten visade att Auditory Icons var lättare för deltagarna att para ihop med korrekt mobiltjänst jämfört med Earcons både i intuivitetstesterna och de följande lärbarhetstesterna. Deltagarna var både bättre (större antal korrekta ihopparningar) och snabbare (tid det tog från att ljudet spelades till att det parats ihop med korrekt mobiltjänst) på att identifiera Auditory Icons jämfört med Earcons. Resultaten från notabilitet/minnesvärdetsundersökningen visade att deltagarna i högre grad kom ihåg Auditory Icons jämfört med Earcons. Även gällande preferens presterade Auditory Icons betydligt bättre än Earcons. För vissa av testdeltagarna gav de Earcons som användes upphov till negativa och frustrerande känslor. Detta kan bero på att inlärningsperioden för Earcons var längre än för Auditory Icons vilket kan upplevas som frustrerande, särskilt för ljud som inte har en tydlig koppling till det de symboliserar.

På grund av de entydiga resultaten rekommenderar författarna att Auditory Icons bör användas före Earcons i notifikationssystem på mobila enheter och att dessa Auditory Icons bör använda ljud som är lätta att identifiera och att lära sig. För ljud som används sällan är detta extra viktigt eftersom användare tenderar att glömma kopplingar mellan ljud och tjänster om de inte upprepas ofta. För att undvika ljud som upplevs irriterande bör blivande användare involveras i framtagningen av dessa ljud.

Användandet av Auditory Icons och Earcons i gränssnitt kan påverka användare både på ett positivt sätt vilket bl.a. Brewster (1997) och Korhonen m.fl. (2007) visat, men också på ett negativt sätt som i undersökningen av Garzonis m.fl. (2009) där earcon framkallade både negativa och frustrerade känslor hos testdeltagarna. För att förtydliga hur och när Auditory Icons och Earcons bör användas genomförde Absar och Guastavino (2008) en litteraturöversikt över tidigare forskning gällande Auditory Icons och Earcons. Deras artikel redovisar vad Auditory Icons och Earcons är, hur tidigare forskning använt respektive ljudkategori i sina undersökningar och när och var respektive ljudkategori visat sig användbar.

Sammanställningen visar att Auditory Icons och Earcons dels är lämpade för olika ändamål men också att de fyller olika funktioner beroende på vilket slags gränssnitt eller system de implementeras i. I artikeln presenteras två tabeller som tydligt redovisar för vilka ändamål och i vilka system Auditory Icons respektive Earcons är väl anpassade. Dessa tabeller kan ses i tabell 1 och 2.

Desktop interfaces Navigation; picture categorization;

hypermedia and web interfaces

Complex systems Monitoring tasks; collaborative tasks;

peripheral awareness cues; ambient sound;

navigation tasks

Immersive virtual environments Localization and navigation tasks; assembly tasks

Tabell 1 System och funktioner där Auditory Icons visats ha positiv effekt.

Desktop interfaces Sonically-enhanced widgets; menu

hierarchies; business and workplace applications; graphs and tables; hypermedia and web interfaces

Alarms and warning systems Vehicle- collision detection Immersive virtual environments Assembly tasks

Mobile systems Mobile phone menus

Tabell 2 System och funktioner där Earcons visats ha positiv effekt.

Absar och Guastavino (2008) poängterar att dessa tabeller är det som sammanställningen av tidigare forskning kommit fram till men att forskningen inte är helt konklusiv och även i undersökningar som använt liknande metoder har resultaten varit tvetydiga. Därför är dessa tabeller endast riktlinjer och inte regler. Författarna gör det också tydligt att man måste ha Auditory Icons och Earcons grundläggande egenskaper när ljud utformas för användargränssnitt. Auditory Icons är ljud har tydliga kopplingar till fysiska objekt och händelser och behöver därför generellt sett inte läras in av användaren. Earcons är abstrakta och saknar tydliga kopplingar till fysiska objekt och händelser och behöver därför läras in men har fördelen att de lättare kan ordnas i hierarkiska strukturer, något som inte är möjligt med Auditory Icons.

3 Problemformulering

Ett stort antal människor har någon form av synnedsättning. För de som räknas som blinda finns vissa verktyg, så som screen readers som med hjälp av syntetiserat tal översätter grafiska gränssnitt till ett medium som blinda kan ta del av (Noh m.fl. 2018). För personer med mildare grader av synnedsättning är screen readers inte lika användbara men på grund av deras synnedsättning kan de ändå inte ta full fördel av de grafiska gränssnitten.

Ljud kan används i grafiska gränssnitt för att förmedla information genom att till exempel påvisa misslyckade klick (Brewster 1997) men det finns begränsad forskning gällande hur ljud kan används för att öka tillgängligheten för personer med synnedsättning. Ljud i användargränssnitt brukar delas upp i kategorierna Auditory Icons och Earcons.

Klassificeringen beror dels på ljudets utformning men även hur ljudet implementeras och vad det symboliserar (Oswald 2012). Detta arbete ämnar att undersöka om Auditory Icons och Earcons kan användas för att underlätta menynavigering för människor med synnedsättning.

Problemet är att personer med mildare grad av synnedsättning inte har samma nytta av screen readers som blinda personer men dessa personer har svårare att använda webbsidor än personer utan synnedsättning. Detta arbete ämnar att undersöka om användandet av auditiv feedback på webbsidor kan underlätta webbsidenavigering för personer med mildare synnedsättning. Med mildare synnedsättning menas samtliga former och grader av synnedsättning som inte räknas som blind.

Frågeställningen är: Kan auditiv feedback användas på en webbsida för att underlätta navigering för personer med synnedsättning?

Hypotesen är: Auditiv feedback underlättar navigering på en webbsida för personer med synnedsättning.

Nollhypotesen är: Auditiv feedback underlättar inte navigering på en webbsida för personer med synnedsättning.

3.1 Metodbeskrivning

Undersökningar utformade för att ta fram empirisk data kan delas upp i självdeklarationsundersökningar, fallstudier samt experiment (Wohlin m.fl. 2012).

Undersökningsformerna kan utformas på olika sätt samt kombineras för att samla in både kvantitativ och kvalitativ data.

Till självdeklarationsundersökningar räknas både enkäter och intervjuer och dessa kan användas för att samla in både kvantitativ och kvalitativ data beroende på utformning.

Självdeklarationsundersökningar genomförs före eller efter undersökningsdeltagare introducerats till ett nytt arbetssätt, en ny programvara e.d.

Självdeklarationsundersökningar kan vara beskrivande, förklarande eller utforskande. Syftet är vanligtvis att samla in data som kan användas för att dra slutsatser om populationen (Wohlin m.fl. 2012). Självdeklarationsundersökningar fokuserar på undersökningsdeltagarnas upplevelser till skillnad från fallstudier och experiment som i huvudsak fokuserar på det faktiska utfallet.

Fallstudier är studier i verkliga situationer. Dessa genomförs för att undersöka ett eller flera fall på djupet under en begränsad tid (Wohlin m.fl. 2012). Fallstudier är observationsbaserade till skillnad från experiment som är kontrollerade.

Experiment är undersökningar i en kontrollerad miljö där en eller ett fåtal variabler manipuleras. Genom att endast manipulera en eller ett fåtal variabler kan man samla in data gällande hur just denna variabel påverkar utfallet. Experiment kan vara tekniska eller människoinriktade (Wohlin m.fl. 2012). Tekniska experiment kan användas för att jämföra ett flertal olika verktyg. Experimenten är ofta helt eller delvis automatiserade vilket gör att experimenten har en hög grad av replikerbarhet. Människoinriktade experiment är inte lika kontrollerade som tekniska experiment eftersom olika människor agerar olika i olika situationer. Deltagare i människoinriktade experiment kan vanligtvis inte utvärdera flera variabler utan att vara partiska. Därför används en kontrollgrupp och en eller flera försöksgrupper. Människoinriktade experiment kan utföras offline i en kontrollerad labbmiljö eller online i en realistisk miljö. Onlineexperiment saknar den kontroll som är möjlig i offlineexperiment men kan ge en mer realistisk bild av hur resultaten kan appliceras i verkliga situationer.

Detta arbete kommer att använda sig av ett människoinriktat experiment där testpersoner får ett antal uppgifter relaterade till navigering på en webbsida. Under experimentets gång kommer kvantitativ data i form av tiden det tar för användaren att lösa respektive uppgift, antalet knapptryckningar som görs samt antalet misslyckade knapptryckningar att samlas in. Efter experimentet kommer deltagarna att få besvara en kortare enkät där de får skatta sin upplevelse av experimentet inom olika kategorier. Denna enkät kommer att baseras på enkäter som använts i tidigare forkning av Brewster (1997), Ates m.fl. (2015) och Tsunoda m.fl (2001).

Uppgifterna som testdeltagarna kommer att utföra kommer att utformas efter det som både Leuthold m.fl. (2011) och Tsunoda m.fl. (2001) kallar ‖simple tasks‖ – uppgifter där användaren vet vad som eftersöks och som kräver ett litet antal klick/knapptryckningar för att utföras. Gällande menyutformning kommer inte någon av de strukturer som presenterats i Leuthold m.fl. (2011) och Tsunoda m.fl. (2001) att användas. Menyerna/strukturerna som användes i de artiklarna verkar förutsätta att användaren måste klicka på en länk för att tas vidare till en ny sida där fler länkar finns. Detta är inte nödändigt om menyer som öppnar sub-menyer med hjälp av ‖hover/mouseover‖-event används. För dessa menyer räcker det att användaren för muspekaren över ett menyobjekt för att öppna en submeny (om sådana finns). I övrigt kan detta arbetes menystruktur liknas med ‖dynamic menu‖ från Leuthold m.fl (2011). Leuthold m.fl. rekommenderar att menyer bör synliggöra så många menyobjekt som möjligt men att detta främst gäller vid mer komplexa navigationsuppgifter. Detta stöds även av Tsunoda m.fl. (2001). Det anses därför inte vara ett problem att använda en menystruktur där endast ett fåtal menyobjekt visas åt gången.

Experimentdeltagare kommer att delas in i en kontrollgrupp och en försöksgrupp. Den faktor som kommer att undersökas i experimentet är den auditiva feedbacken i navigeringsmenyn. Kontrollgruppen kommer att genomföra experimentet utan auditiv feedback och försöksgruppen kommer att genomföra experimentet med auditiv feedback.

En kontrollgrupp och minst en försöksgrupp krävs för att kunna utföra experiment (Wohlin m.fl. 2012). Människoinriktade experiment är svårare att kontrollera jämfört med helt tekniska experiment. Detta i kombination med att möjligheten till att utföra experimentet på

plats kommer att vara begränsad gör att vissa faktorer inte helt kan kontrolleras. Ett exempel på detta är miljön där experimentet utförs. Experimentmiljön kommer att variera mellan testpersonerna vilket kan introducera ytterliggare potentiella felkällor men det går även att argumentera för att detta gör experimentet mer verklighetstroget. Att göra experimentet tillgängligt på internet kan bidra till att fler väljer att delta jämfört med om experimentet behövde utföras på en bestämd plats.

För att kunna svara på frågeställningen kommer följande delmål behöva uppnås:

1. Utveckla en webbsida som kan navigeras med hjälp av en grafisk meny.

2. Framställa och implementera auditiv feedback.

3. Implementera kod för insamling av data.

4. Insamling av data i form av experiment.

5. Genomföra en statistisk analys av mätdata.

För att säkerställa att implementation och experimentutformning fungerar korrekt kommer en pilotstudie att genomföras. I pilotundersökningen kommer experimentets utformning av utvärderas och eventuellt revideras inför den senare undersökningen. Att få ihop testpersoner för ett experiment av en särskild grupp, så som personer med synnedsättning, kan vara svårt. Därför kommer webbsidan simulera synnedsättning vilket gör att även personer utan synnedsättning kan delta i experimentet. Denna simulering kommer att baseras på tidigare forskning beskriven i kapitel 2.1.2 Simulering av synnedsättning. Olika simuleringar kommer att testas som en del av pilotundersökningen.

3.2 Etik

Detta arbete skall utföras och dokumenteras på ett så transparent sätt som möjligt. Detta innebär att allt material som framställs skall göras tillgänglig för utomstående. All källkod kommer att publiceras på GitHub. Material som används skall antingen vara egenskapat eller användas i enlighet med de licenser som gäller för materialet. För detta arbete gäller detta främst de ljudfiler som kommer att implementeras. Detta görs främst för att experimentet skall kunna upprepas på ett så identiskt sätt som möjligt.

Eftersom detta arbete inkluderar ett människoinriktat experiment gäller sekretess. Det skall inte vara möjligt att identifiera testpersoner utifrån datan som samlas in. Om sådan data trots detta måste samlas in av någon anledning kommer denna data inte att publiceras. I övrigt skall all insamlad data publiceras. Detta för att analysarbetet skall kunna återupprepas med samma data som använts i detta arbete. Samtliga testpersoner skall informeras om experimentet innan det utförs. Detta innefattar vad experimentet går ut på, hur experimentet kommer gå till samt vilken data som kommer att samlas in under experimentets gång. Testpersonerna skall kunna avbryta experimentet om så önskas.

Det finns vissa risker med att utföra experiment på detta sätt. Experimentdeltagarna kan av olika anledningar uppleva experimentet som obehagligt. Detta kan t.ex. bero på vilka ljud som används i experimentet och då särskilt s.k. Auditory Icons som är ljud från vardagen eller det verkliga livet. Ett pistolskott eller en explosion kan ha väldigt tydliga kopplingar till tidigare erfarenheter hos experimentdeltagarna vilket kan upplevas som obehagligt. Detta bör has i åtanke när ljuden för experimentet tas fram och då särskilt för Auditory Icons. Ljud som är väldigt starka (hög volym) kan också upplevas som obehagliga och i vissa fall till och med skadliga för lyssnarens hörsel. Därför kommer samtliga ljud att normaliseras för att de

skall ha ungefär samma volym. Ytterliggare kommer experimentdeltagarna att kunna korrigera ljudnivån med hjälp av ett exempelljud innan experimentet påbörjas.

Experimentdeltagarna kommer att uppmuntras att börja från en låg ljudnivå när denna korrigering görs för att undvika att överraskas av ljudnivån av exempelljudet. De ljud som används skall antingen framställas på egen hand eller vara ljud som är fria att använda för detta ändamål.

Experimentet kommer att använda sig av en simulering av en synnedsättning och utföras av experimentdeltagare som inte nödvändigtvis har någon form av synnedsättning. Detta gör att resultaten inte nödvändigtvis kommer att kunna appliceras fullt ut på personer med synnedsättning. Vidare är det viktigt att poängtera att experimentet inte är menat att utbilda eller informera människor om hur det är att ha en synnedsättning. Trots detta skall simuleringarna göras så trovärdiga och verkliga som möjligt baserat på tidigare forskning men oavsett hur mycket tid och arbete som läggs ner på simuleringen kommer den på sin höjd att vara en approximering, inte en exakt avbildning av hur det är att leva med synnedsättning.

4 Genomförande

För att utföra detta arbete och dess studie krävs att en artefakt utvecklas. Denna artefakt består av två olika webbsidor som är visuellt identiska men där den ena har auditiv feedback i navigeringsmenyn och den andra har inte auditiv feedback i navigeringsmenyn.

Utvecklingen av artefakten kan delas upp stegen Grafiskt användargränssnitt, Simulering av synnedsättning, Uppgiftsinstruktioner, Ljuddesign, Implementation av ljud och Insamling av data. För att kunna genomföra dessa steg av utvecklingsprocessen på ett tillfredsställande sätt krävs en litteraturstudie där relevant litteratur för respektive steg gås igenom för att komma fram till lämpliga tillvägagångssätt för utvecklingen.

4.1 Litteraturstudie

Leuthold m.fl. (2011) och Tsunodas m.fl. (2001) studier visade på att menyutformningen gällande antalet hierarkinivåer har tydlig påverkan på hur användare löser komplexa navigationsuppgifter. Användarna löste dessa komplexa uppgifter snabbare och lättare i menyer med färre hierarkier och fler navigationsobjekt tillgängliga från en sida. För enklare uppgifter kunde inte någon signifikant skillnad mellan fler eller färre hierarkier uppmätas. I detta arbete kommer den enklare typen av uppgifter att användas (med enklare uppgifter menas uppgifter där instruktionen är så tydlig att användaren vet exakt vad den letar efter och som kräver ett litet antal knapptryck att utföra).

Det finns ett stort antal blogginlägg, artiklar, videor och forumsinlägg som beskriver hur menyer kan implementeras. I detta arbete kommer en ‖dropdown-meny‖ att användas. På grund av hur CSS kan användas för att förändra utseendet på HTML-element oavsett typ finns det många olika sätt att implementera en visuellt identisk navigeringsmeny. Detta betyder inte nödvändigtvis att alla implementationer är lämpliga då de i många fall inte följer de riktlinjer kring accessibilitet som finns. Una Kravets lyfter detta i en artikel publicerad på CSS-Tricks (Kravets 2020). I artikeln beskrivs hur en dropdown-meny kan implementeras i olika steg. Det första steget är en för muspekar-användare fullt funktionell meny men för personer som inte använder muspekaren och istället navigerar med hjälp av Tab-funktionen fungerar menyn inte som förväntat. I stegen som följer beskrivs hur dessa problem kan rättas till för att samtliga användare (även de som använder screen readers) skall kunna använda dropdown-menyn på ett tillfredsställande sätt. I detta arbetes studie kommer endast personer som använder muspekare att delta men trots detta anses det som viktigt att se till att artefakten är tillgänglig för så många som möjligt.

Lewis m.fl (2011) använde spelmotorn Unreal Engine 3 för att utveckla en VR-miljö (Virtual Reality) och simuleringar av olika synnedsättningar. Simuleringarna utvärderades sedan av en person som ansågs ha expertkunskap inom området synnedsättningar. Ates m.fl. (2015) utvecklade istället ett AR-verktyg (Augmented Reality) med simuleringar av synnedsättningar baserat på National Eye Institutes (NEI) exempelbilder för att antal olika synnedsättningar. Dessa bilder verkar inte längre finnas tillgängliga och kan därför inte användas för att utveckla detta arbetes simuleringar. Däremot finns andra exempelbilder tillgängliga på bl.a. Finlands Svenska Synskadades Förbunds hemsida (u.å).

Både Lewis m.fl. (2011) och Ates m.fl. (2015) använde VR-headsets i sina arbeten vilket gör att simuleringarna följer användarens huvudrörelser. Detta är inte möjligt för detta arbete

NoCoffee är ett exempel på ett verktyg som simulerar synnedsättningar på detta sätt (Leventhal 2013). I pluginens meny kan användare själva ställa in olika grader av synnedsättningar, t.ex. ‖visual acuity‖ (synskärpa), ‖contrast loss‖ (kontrastförlust) och

‖cloudiness (cataracts)‖ (dimmighet). Användare kan också välja mellan ett antal olika synnedsättningar inom kategorin ‖Blocked visual field‖ (blockerat synfält). Dessa kan även kombineras med den tidigare nämna menyn. Se figur 3 för en skärmbild av menyn och figur 4 för ett exempel på hur simuleringar kan se ut på en webbsida. NoCoffee saknar dokumentation men med hjälp av webbläsarens ‖Inspect‖-funktion är det möjligt att se webbsidans HTML, CSS och Javascript och därigenom utläsa hur pluginen påverkar webbsidan.

Figur 3 Skärmbild av Google Chrome-pluginen NoCoffees meny där

Figur 4 Skärmbild från LenaSYS (2021) med simulering av macular

Chrome-pluginen NoCoffee.

Brewster, Wright och Edwards (1995) menar att utformningen av earcons skall styras av gränssnittet de utvecklas för men att det finns vissa generella riktlinjer som man bör förhålla sig till. Dessa riktlinjer har tagits fram med grund i ett antal tidigare experiment utförda av Brewster. Timbre (klangfärg), register (tonhöjd) och rytm bör användas för den grundläggande strukturen. Dessa parametrar bör sedan varieras för att skapa ‖familjer‖ av earcons (om applikationen kräver detta). Om användarna skall kunna särskilja de olika ljuden utan någon referenspunkt måste skillnaderna mellan ljuden vara stora.

Timbre (klangfärg) bör varieras och klangfärgerna som används bör vara lätta att skilja åt.

Som exempel nämns att ‖brass‖ (brassinstrument/bleckblåsinstrument t.ex. trumpet eller trombon) och ‖organ‖ (orgel) är lämpliga att använda för att tydligt särskilja två olika element/funktioner i ett gränssnitt men att två olika brass/bleckblåsinstrument så som trumpet och trombon inte är lämpliga eftersom de kan upplevas som för lika.

Register (tonhöjd) nämns som en parameter som är svår att använda om användarna måste kunna särskilja ljud utan referenspunkt. I dessa fall krävs en väldigt stor skillnad i tonhöjd för att det skall vara effektivt (2-3 oktaver). Om användarna endast behöver särskilja ljuden relativt till varandra kan mindre skillnader i tonhöjd användas men generellt sett är det olämpligt att endast förlita sig på tonhöjd utan tonhöjd bör kombineras med minst en annan parameter. Ljuden bör inte använda sig av toner under 125-150Hz eller över 5kHz eftersom dessa ljud blir svårare att särskilja och i vissa fall kan de även ligga utanför vissa människor hörvidd eller utanför det tonomfång som hörlurar/högtalare kan återge.

Att variera antalet toner i earcons är ett effektivt sätt att särskilja dem. Om rytmerna är för lika är risken stor att användarna får det svårt att särskilja ljuden även om ljuden i övrigt är väldigt olika. Earcons bör också vara så korta som möjligt för att upplevas som interaktiva tillsammans med användargränssnittet. Om ljuden är för långa är risken stor att de kommer behöva klippas (avbrytas) när nästa ljud skall spelas alternativt att ljuden kommer ‖gå in‖ i varandra vilket kan upplevas som förvirrande. För att varje earcon skall upplevas som en

‖komplett rytmisk enhet‖ bör den första tonen vara något starkare och den sista tonen något längre.

Ljuds intensitet är den vanligaste orsaken till irritation hos användare och bör därför användas sparsamt. Samtliga earcons bör ha en jämn ljudnivå för att användaren skall kunna ställa in volymnivån på egen hand utan att något ljud är onödigt starkt eller svagt.

För att implementera ljud på en webbsida kan HTML-elementet <audio> användas. Audio- elementets ‖src‖-attribut innehåller en länk till den fil som skall spelas upp. Det är även möjligt att använda ett eller flera <source>-element inuti <audio>-elementet. Genom att använda samma ljud men i olika filformat kan man därmed försäkra sig om att de flesta webbläsare kommer att kunna spela upp ljudet (om webbläsaren inte stöder filtypen i det första <source>-elementet går den vidare till nästa, o.s.v.).

Om ljudprocessering (att lägga till effekter eller på andra sätt förändra ljudet) kan Javascripts Web Audio API användas. Web Audio API ersätter inte <audio>-elementet utan är en förlängning av elementets relativt grundläggande och ibland begränsande funktionalitet. För en undersökning likt den som utfördes av Korhonen m.fl. (2007) hade Web Audio API passat väl eftersom det gör det möjligt att utföra ljudprocessering i realtid. I denna studie kommer detta inte att krävas och Web Audio API anses därför överflödigt.

För att kunna spela upp ett flertal ljud kan ett antal olika tekniker användas. Genom att använda flera olika <audio>-element kan flera olika ljud spelas upp. Detta gör det också möjligt att spela upp flera ljud samtidigt. Det är även möjligt att använda ett<audio>- element, uppdatera dess ‖src‖-attribut (eller <source>-element) med en ny ljudfil, kalla funktionen load() på <audio>-elementet och sedan spela upp ljudet. Ett <audio>-element kan endast spela upp ett ljud åt gången. Det är därför inte möjligt att spela upp flera olika ljud samtidigt om endast ett <audio>-element används. Det tidigare ljudet kommer att stängas av i samband med att load()-funktionen kallas. För detta arbete kommer endast ett ljud att spelas upp åt gången och det bör därför räcka med ett <audio>-element.

För att samla in data från en webbsida (t.ex. genom att formulär) kan ett antal olika tekniker användas. Om väldigt mycket data skall samlas in kan det vara lämpligt att använda en databas men för mindre mängder data kan detta vara överflödigt och innebära mer jobb än vad det är värt. I detta arbete kommer en relativt liten mängd data att samlas in. För detta kan t.ex. Mike Strattons kod användas (2020). Koden hanterar data från ett formulär, formatterar den till json och skriver till en fil. Med ett fåtal korrigeringar kan denna kod användas för att läsa in en fil, spara innehållet i en array, spara datan från formuläret i samma array och sedan skriva arrayen till filen igen. Detta gör att data läggs till i filen utan att förändra eller förstöra datan som redan fanns i filen. Originalkoden skriver över filens innehåll varje gång.

Det är också möjligt att samla in data med olika formulär-tjänster, t.ex. Google Forms (Google 2020). Dels kan användare länkas till Google Forms för att svara på ett formulär men det är också möjligt att bädda in ett Google Form-formulär på en existerande sida. En fördel med detta är att insamlad data lätt kan exporteras för vidare analys i t.ex. Google Sheets (Google 2020).

Det är även möjligt att använda email för att samla in data. Genom att använda kod som hanterar data från ett formulär (t.ex. Mike Strattons kod som nämnts tidigare) kan en mailfunktion användas för att skicka data i form av ett email. Om PHP används kan PHP‘s mail()-funktion användas (The PHP Group 2021). Motsvarande funktionalitet finns även för Node.js med olika moduler t.ex. Nodemailer (Reinman 2021). En nackdel med detta är att den insamlade datan måste sammanställas manuellt eller med ett Tampermonkey-script eller liknande lösning (Biniok 2021).

4.2 Progression

I detta kapitel beskrivs utvecklingen av den applikation som skall användas i studien.

Inledningsvis gjordes detta med endast HTML, CSS och Javascript. I detta skede kunde applikationen köras lokalt genom att öppna HTML-filerna i en webbläsare. Senare utvecklades applikationen till en PHP-applikation. För att köra denna applikation krävdes därför en Apache-server med PHP installerat. För detta ändamål användes XAMPP under utvecklingen.

4.2.1 Grafiskt användargränssnitt

Det grafiska användargränssnittet är den del av applikationen som testdeltagarna kommer att se och interagera med. Denna består av en navigeringsmeny och en produktsida (förutom startsidan som inte är bunden till en specifik produkt). Testdeltagarna kommer att få instruktioner under testets gång. Dessa instruktioner kommer också att presenteras i det