AUTOMATISK EVALUERING TILGÆNGELIGHED. Af Michael Christoffersen & Lars Nyberg. 4-ugersprojekt Vejleder: Martin Sønderlev Christensen

Transkript

1 AUTOMATISK EVALUERING AF TILGÆNGELIGHED Af Michael Christoffersen & Lars Nyberg 4-ugersprojekt Vejleder: Martin Sønderlev Christensen IT-højskolen Maj 2003

2 Resumé Rapporten består af en teori- og analysedel. I teoridelen defineres hvad tilgængelighed er, blandt andet set i forhold til brugevenlighed og handicap vedrørende World Wide Web. Desuden beskrives Web Content Accessibility Guidelines (WCAG eller ofte WAIs retningslinier), med henblik på hvem, hvad og hvorfor. Sidst i teoridelen gives der et overblik over de automatiske evalueringsværktøjer til analyse af tilgængelighed. Herefter analyseres to af disse evalueringsværktøjer, nemlig Bobby ver og WAVE 3.0 beta. Analysens mål er på basis af værktøjernes baggrund, funktionaliteter og især formidling, at vurdere værktøjernes evne til at gøre dets brugere opmærksomme på tilgængelighedsproblemer på deres websteder. 2

3 Indholdsfortegnelse Indledning... 4 Problemformulering...5 Rapportens opbygning...5 Ordforklaring...5 Om forfatterne...6 Teori... 7 Hvad er tilgængelighed?...7 Web Content Accessibility Guidelines Automatisk evaluering af websteder Analyse...17 Analysemodel Analyse af Bobby Analyse af WAVE Sammenfatning af analyser Konklusion...29 Kildefortegnelse...30 Bilag 1: Websteder anvendt i analysen... i Bilag 2: Kommentarer vedrørende projektforløb... ii 3

4 Indledning Den teknologiske udvikling har gjort at vi ikke længere behøver at være afhængige af åbningstider og geografisk placering når vi søger information, går i banken eller køber ind. Internettet har i kraft af sin ikke-fysiske tilstand gjort det muligt for os at købe bøger i USA, læse russiske aviser og tjekke vores bankkonto i Hillerød. Alt sammen i ro og mag foran ens egen computer. Netop denne løsrivelse fra det fysiske univers, åbner op for mange muligheder for de mennesker som i det daglige er begrænset af den fysiske verden. Computeren og Internettet gør at handicappede hjemmefra kan ordne ting som før krævede at de bevægede sig ud i en verden fuld af forhindringer og utilgængelige informationer. Teknologien skaber mulighed for at gøre disse mennesker mindre afhængige af andre mennesker, så de derved kan leve deres liv på mere lige vilkår med resten af verdenen. Den del af Internettet de fleste bruger i det daglige, udover , er World Wide Web (WWW), som opstod i begyndelsen af 1990 erne. Oprindeligt var WWW tænkt som et system, hvor forskellige dokumenter kunne kædes sammen på kryds og tværs af afdelinger og operativsystemer. Denne universalitet åbnede også op for mange muligheder i forhold til tilgængelighed for handicappede. Men selv om WWW har alle disse muligheder så kræver det stadig at de, som skaber og konstruerer f.eks. websider har forståelse for de behov og tekniske krav, et tilgængeligt produkt stiller. Disse krav eller retningslinier for et tilgængeligt websted er blandt andet forsøgt opstillet i Web Accessibility Initiative s Web Content Accessibility Guidelines 1.0 (WCAG) [Web Accessibility Initiative, 1999a]. Retningslinierne i WCAG er i dag de mest benyttede og udgangspunktet for praktisk taget alle andre regler eller retningslinier for tilgængelighed blandt andet det meget omtalte Rehabilitation Act Section 508 (Section 508) i USA [Thatcher et al., 2003 side 33] og den knap så omtalte Hjemmesiders tilgængelighed fra det hedengangne Statens Information [2000]. De fleste websteder skabes i et samarbejde mellem flere mennesker med forskellig baggrund og kompetencer. For at sikre et WWW for alle, kræver det at tilgængelighed bliver integreret i designprocessen at de som koder, designer og vedligeholder overholder retningslinierne for tilgængelighed. I takt med at websteder bliver større og mere komplekse kræver det en viden og et overblik, som kan være vanskelig at administrere på tværs af forskellige faggrupper og processer. En måde at løse det problem på er ved at bruge værktøjer, der kan lave automatiske evalueringer af websteder. 4

5 Der findes i dag et udvalg af disse værktøjer. Nogle er online og andre skal downloades og installeres. Nogle undersøger bare webstedet andre prøver også på at rette de konkrete problemer. Blandt de organisationer og eksperter som beskæftiger sig med tilgængelighed er der dog udpræget skepsis overfor disse værktøjer. Dels på grund af at hvad værktøjerne kan. Dels den måde hvorpå de bliver opfattet og benyttet. Problemformulering Denne rapport vil diskutere om automatiske evalueringsværktøjer kan hjælpe i produktionen af tilgængelige websteder. Ved at analysere et udvalg af værktøjer håber vi at kunne besvare disse spørgsmål: Hvad kan automatiske værktøjer? Hvad kan de ikke? Hvorledes præsenteres resultaterne af evalueringen og formår værktøjerne at gøre dets brugere opmærksomme på tilgængelighedsproblemer på deres websteder? Rapportens opbygning I rapportens første del, Teori, vil vi på baggrund af litteraturen diskutere hvad begrebet tilgængelighed dækker, se på de mest udbredte retningslinier for tilgængelighed samt undersøge hvilke typer af automatiske værktøjer der eksisterer og hvordan de virker. Dette vil danne baggrund for rapportens anden del, Analyse, hvor vil vi analyserer to udvalgte værktøjer udfra deres baggrund, funktionalitet og formidling. En oversigt over websider anvendt i analysen af værktøjerne findes i Bilag 1. Ordforklaring Som beskrevet ovenfor beskæftiger denne opgave sig med tilgængelighed på WWW. Vi anvender ordet WWW i sin rette betydning, nemlig som værende en specifik del af Internettet. Når vi anvender ordet webside refererer vi til en enkelt side på WWW. Ordet websted bruges, når vi refererer til en samling af websider som udgør en samlet helhed, oftest med samme overordnede adresse. I opgaven vil vi omtale de personer, der udarbejder et websted, som webdesignere. Webdesignere skal derfor forstås i betydningen af personer, der designer layout og struktur, skriver koderne eller er en del af tilblivelsesprocessen af et websted. Det betyder, at andre betegnelser som for eksempel webudvikler, er indeholdt i webdesigner for enkelthedens skyld. Når vi i opgaven anvender begrebet tilgængelighed, svarer det til det engelske accessibility, og anvendelse af begrebet brugervenlighed modsvarer det engelske usability. 5

6 Om forfatterne Michael Christoffersen er uddannet bibliotekar DB i 2002 og studerer i øjeblikket Internetteknologi på IThøjskolens kandidatuddannelse. Lars Nyberg er uddannet bibliotekar DB i 2002 og studerer i øjeblikket Design, Kommunikation og Medier på IT-højskolens kandidatuddannelse. 6

7 Hvad er tilgængelighed? Teori Access has a range of meanings that are all related to making things usable and understandable. If you are in a wheelchair, it represents ramps, elevators, and special toilets. Access signifies the ability to do what everybody else can do and to make use of what everybody else can use; access means liberty to make advantage of resources. Acceessibility is the breeze through the window of interest. [Wurman, 2000] Når vi i det daglige sprog siger, at noget er tilgængeligt, kan det betyde flere ting. Dels kan det betyde at noget overhovedet er tilstede, som når vi f.eks. siger at information er tilgængeligt på flere sprog. Dels kan noget være svært tilgængeligt, underforstået at det er svært at forstå eller begribe uden visse kundskaber og erfaringer. Tilgængelighed som det forstås i denne rapport og generelt inden for arkitektur og design, handler først og fremmest om at gøre noget, en bygning eller et produkt, tilgængeligt for handicappede. Handicap defineres»som en betegnelse for tab eller begrænsning af muligheder for at deltage i samfundslivet på lige fod med andre.«[det Centrale Handicapråd, 2003] Et handicap er situationsbestemt og relativt. En blind er ikke handicappet, når hun lytter til musik, og en gangbesværet har ikke problemer med at læse eller se fjernsyn. Vi kan alle være handicappede i specifikke situationer. Hvis jeg er i udlandet og ikke taler sproget er jeg på mange områder handicappet. Hvis jeg er træt og har svært ved at koncentrere mig er jeg handicappet i forhold til at læse og forstå informationer. At være handicappet kan altså defineres bredt som værende mennesker der er funktionshæmmede eller situationshæmmede [Thatcher et al., 2002 side 13]. Det vil sige mennesker der lider af et kognitivt, fysisk eller teknisk handicap [Christoffersen & Nyberg, 2001], hvad enten det er kronisk eller periodisk. Man kan diskutere om arbejdet med tilgængelighed først og fremmest bør koncentrere sig om at forhindre diskrimination af de mennesker som lider af ufrivillige og kroniske funktionsnedsættelser [Clark, 2003 side 37]. Men under alle omstændigheder har tilgængeligt design det med at hjælpe både de, som ikke har noget valg og de, som blot midlertidigt eller frivilligt har valgt at være handicappede. F.eks. er ramper til kørestole også en fordel for barnevogne og cykler, og tilgængeligt webdesign kan også hjælpe de, der bruger andre browsere eller operativsystemer end flertallet af brugerne. 7

8 Når ideen om at hjælpe så mange forskellige brugere, i så mange forskellige situationer, som muligt er integreret i designprocessen, er det traditionelt blevet kaldt universelt design [Thatcher et al., 2002 side 12] eller design for alle. Med udgangspunkt i denne brede definition af handicap, mener vi at tilgængelighed er at mindske de udfordringer og problemer som den handicappede kan have i sin dagligdag altså gøre den handicappede mindre handicappet, i en verden som er lavet af og til ikke-handicappede. Brugervenlighed og tilgængelighed På mange måde overlapper tilgængelighed og brugervenlighed hinanden, men de fleste er dog enige om at der er en forskel. Brugervenlighed er ifølge ISO-standarden (ISO ) defineret som tre parametre: effectiveness, efficiency og satisfaction [Brajnik, 2000]. Tilgængelighed dækker de samme områder, men er mindre fokuseret på tilfredshed (satisfaction) [Thatcher et al., 2003 side 8] og begrænser sig normalt til handicappede brugere. Et tilgængeligt websted er ikke nødvendigvis brugervenligt, men for en handicappet er tilgængelighed forudsætningen for brugervenlighed. Meget af det som er brugervenligt for de fleste, er oftest påkrævet for at være tilgængeligt for handicappede [Thatcher et al., 2003 side 12]. Det gør sig især gældende når det drejer sig om tilgængelighed for kognitivt handicappede, ordblinde og læsesvage, hvor et websted skal være så overskueligt og letforståeligt som muligt noget som er brugervenligt for de fleste andre brugere. Oftest bliver tilgængelighed anset som noget teknisk, centreret omkring standarder og kode. Brugervenlighed derimod bliver betragtet som noget mere abstrakt, noget der opstår i interaktionen mellem brugeren og produktet. Det er da også sandt, at en stor del af tilgængelighedsproblemerne skal løses på det tekniske plan. Men det er vigtigt at disse tekniske løsninger også er meningsfulde i konteksten mellem webstedet og brugeren. F.eks. er en alternativ tekst til et billede kun brugbar hvis den også er korrekt og meningsfuld i forhold til billedets funktion [Thatcher et al., 2002 side 8]. Det er i disse tilfælde at brugervenlighed og tilgængelighed er svære at adskille. Men det er også her hvor vi mener det bliver interessant i forhold til automatisk analyse og denne metodes begrænsninger. Tilgængelighed på WWW For at bruge et websted skal den handicappede, ligesom alle andre, kunne interagere og forstå det gennem en computer. Der findes forskellige teknologiske hjælpemidler (assistive/adaptive technology), som gør det muligt eller lettere for den handicappede at bruge en computer. Disse hjælpemidler kan være software, hardware eller mere traditionelle 8

9 hjælpemidler som f.eks. støtte til nakke eller arme. Selve den handicappedes funktionsnedsættelse samt måden hvorpå disse hjælpemidler virker, stiller forskellige krav til webstederne. I det følgende gennemgås kort disse problemstillinger. Motorisk handicappede kan have problemer med at benytte almindelig mus og tastatur. Oftest bruges en inputenhed som kræver at man for at vælge et område af websiden, et link eller et formularfelt, skal trykke sig igennem alle aktive områder på siden indtil det valgte element er i fokus. For motorisk handicappede vil det gøre et websted betydeligt mere tilgængeligt hvis der ikke er meget lange lister af links eller hvis det er muligt at springe over disse. [Clark, 2003 side 30] Døve og hørehæmmede har oftest ingen problemer med at bruge websteder i dag, men det kan ændre sig i takt med at lyd bliver mere integreret i kommunikationen på WWW. Der kan være problemer med video- og lydklip samt flashfilm og andre multimedier med lyd. Problemerne kan løses med undertekster eller hvis de samme informationer er tilstede i tekstform. [Clark, 2003] Blinde og svagsynede kan bruge forskellige hjælpemidler. Blinde bruger skærmlæsere og/eller dynamiske punktskriftsapparater (Braille displays), mens svagsynede oftest bruger skærmlæsere, specialskærme eller softwarebaserede forstørrelsesprogrammer. Til brugere af skærmlæsere og punktskriftsapparater skal tekstalternativer 1 til billeder og anden visuel information være til stede. Man skal være opmærksom på at forskellige formater som PDF eller flash, ikke nødvendigvis er tilgængelige i disse hjælpemidler. Blinde har naturligvis problemer med at bruge en mus og de samme problemstillinger, som ved de motorisk handicappede, gør sig derfor gældende. Kontrasten mellem tekst og baggrund samt valget af farver, typografi og skriftstørrelse har også stor betydning for de svagsynede. Det sidste især for de som ikke bruger eksterne hjælpemidler, men kun har browsernes egne muligheder for at gøre teksten større. Derudover har blinde og svagsynede oftest svært ved at overskue en webside, fordi de ikke kan se/høre hele siden på en gang. De fleste skærmlæsere har mulighed for at springe mellem sektioner og overskrifter på websiden. Det er derfor vigtig at bruge korrekt HTML/XHTML 2 til markering af sidens struktur. [Clark, 2003; Thatcher et al., 2002] 1 Såkaldte alt-tekster. 2 Hypertext Markup language og extensible Hypertext Markup language 9

10 Ordblinde, læsesvage 3 og kognitivt handicappede 4 bruger i visse tilfælde skærmlæsere til oplæsning af tekst. Derudover er et klart og enkelt design, uden for mange forvirrende signaler, vigtigt for denne gruppe. Samt naturligvis letforståelig tekst suppleret med billeder eller audiovisuelle forklaringer. [Clark, 2003 side33] Teknisk handicappede bruger anderledes browsere, andre operativsystemer, langsomme forbindelser eller mindre skærme og displays end flertallet af brugerne på WWW. Vigtigst for denne gruppe er, at webstedet er lavet fleksibelt, således at funktionaliteten bevares. Mange af de samme problemstillinger som hos de ovenstående grupper gør sig også gældende her. [Christoffersen & Nyberg, 2001] De fleste af de ovenstående krav og problemer overlapper hinanden, men der er alligevel en betragtelig mængde overvejelser at træffe, hvis et websted skal gøres tilgængeligt. I det følgende afsnit vil vi se nærmere på et sæt af retningslinier som forsøger at tage højde for de forskellige problemer. Web Content Accessibility Guidelines Som nævnt er Web Content Accessibility Guidelines 1.0 (WCAG) [Web Accessibility Initiative, 1999a] det mest udbredte og benyttede sæt retningslinier for tilgængelighed på WWW. I dette afsnit vil vi se lidt nærmere på hvem der står bag retningslinierne, hvad de indeholder og diskutere fordele og problemer ved dette. WCAG er lavet af en arbejdsgruppe under Web Accessibility Initiative (WAI), som igen er en del af World Wide Web Consortium (W3C). W3C, oprettet i 1994, er en international sammenslutning af organisationer og virksomheder med interesse i WWW. Derudover består W3C af specielt indbudte eksperter samt en gruppe fastansatte medarbejdere under ledelse af Tim Berners-Lee, opfinderen af WWW. Konsortiets mission er»to lead the World Wide Web to its full potential by developing common protocols that promote its evolution and ensure its interoperability.«[world Wide Web Consortium, 2003] Med det langsigtede formål at gøre 3»1 million voksne danskere har så vanskeligt ved at læse og skrive selv ret simple og korte beskeder, at de har svært ved at begå sig på arbejdsmarkedet og i hverdagen i det hele taget.«[vigh, 2001] Man kan desuden være situationsbestemt læsesvag, hvis man har et andet modersmål end det som bliver brugt på webstedet. 4 Eksempler på kognitive handicap er epilepsi, autisme, demens, mentalt retarderede og neurologiske skader som påvirker evnen til at kommunikere, forstå eller relatere sig til andre mennesker. Det indebærer ikke nødvendigvis at den handicappede er mindre intelligent end den almene befolkning. [Seeman, 2002] 10

11 WWW til et troværdigt, universelt og semantisk netværk. [Christoffersen & Nyberg, 2001] W3C er delt op i fire overordnede domæner hvoraf et af disse er WAI. WAI arbejder med fem hovedområder: teknologi, retningslinier, værktøjer, undervisning og opsøgende arbejde, samt forskning og udvikling. Disse områder varetages af forskellige arbejds- og interessegrupper, hvoraf en af disse er Web Content Accessibility Guidelines Working Group (WCAG WG) [Web Accessibility Initiative, 2003a]. Version 1.0 af WCAG [Web Accessibility Initiative, 1999a] blev færdig i maj 1999 og består af fjorten retningslinier (se Tabel 1) som hver især kan indeholde flere såkaldte kontrolpunkter (checkpoints). Endvidere er disse kontrolpunkter tildelt en prioritet fra 1 til 3, hvor prioritet 1 skal overholdes for at et webstedet er tilgængeligt, prioritet 2 bør overholdes for at fjerne betydelige barrierer for tilgængelighed og prioritet 3 kan overholdes for at gøre det nemmere for nogle handicappede at bruge webstedet. Tabel 1: Web Content Accessibility Guidelines 1. Provide equivalent alternatives to auditory and visual content. 2. Don't rely on color alone. 3. Use markup and style sheets and do so properly. 4. Clarify natural language usage 5. Create tables that transform gracefully. 6. Ensure that pages featuring new technologies transform gracefully. 7. Ensure user control of time-sensitive content changes. 8. Ensure direct accessibility of embedded user interfaces. 9. Design for device-independence. 10. Use interim solutions. 11. Use W3C technologies and guidelines. 12. Provide context and orientation information. 13. Provide clear navigation mechanisms. 14. E Ensure that documents are clear and simple. [Web Accessibility Initiative, 1999a] Et websted kan inddeles i tre forskellige niveauer: A, Dobbelt-A og Trippel-A, hvor Trippel-A svarer til overholdelse af prioritet 1, 2 og 3. Et websted kan angive overholdelsen af WCAG, ved at oplyse det relevante niveau med tekst eller benytte nogle dertil fremstillede ikoner (se Billede 1) [Web Accessibility Initiative, 1999b]. 11

12 Billede 1: WAI ikoner De forskellige kontrolpunkter varierer i kompleksitet og hvor teknisk specifikke de er. Kontrolpunkt 1.1 [Web Accessibility Initiative, 1999a] lyder således: Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video. Mens kontrolpunkt 14.1 lyder:»use the clearest and simplest language appropriate for a site's content.«[ibid.] Oftest er kontrolpunktet herefter efterfulgt af korte beskrivelser og eksempler. Der er ved alle punkter et link til en uddybelse af konkrete teknikker til opnåelse af kravene i det specifikke punkt. Disse tekniker er samlet i dokumentet Techniques for Web Content Accessibility Guidelines 1.0 [Web Accessibility Initiative, 2000] og spænder fra konkrete eksempler på kode, til gode råd om skrivning og strukturering af tekst. WCAG er som nævnt meget udbredt og danner udgangspunkt for næsten al information omkring webtilgængelighed, online eller på tryk. Kritik og problematisering af retningslinierne eksisterer, selv om det er svært at finde. Et kritikpunkt, som i øvrigt ofte forekommer når det gælder materiale fra W3C er, at WCAG er svær at læse, fordi den er skrevet i et meget formelt og upersonligt sprog. Strukturen og sprogbruget er desuden ofte inkonsekvent. The guidelines are too vague and too detailed all at once; ask for the moon, without giving you a rocket to get you there or even instructions on how to build one; and are unusably long and meandering. [Clark, 2003 side51] Endelig kritiseres WAI for ikke at inddrage alle typer af handicap ligeligt i retningslinierne [Robertson, 2002]. Især forbigås de kognitivt handicappede og de ordblinde. Dels fordi de kontrolpunkter der er relevante for disse grupper, oftest er ukonkrete og meget generelle. Dels fordi prioritet 1 oftest kun sikrer at information er tilstede og ikke nødvendigvis at den er forståelig. Således bliver de kognitive handicappede først tilgodeset, hvis webstedet overholder niveau dobbelt-a eller højere. [Seeman, 2002] 12

13 I øjeblikket er WAI ved at udarbejde WCAG 2.0 [Web Accessibility Initiative, 2003b]. Den nye version, som endnu er en arbejdsudgave, er mere generel og rettet mod et bredere udvalg af teknologier. Den mest synlige forskel er at retningslinierne er skåret ned fra 14 til 5, og at alle kontrolpunkter er mindre teknologispecifikke. I stedet vil der blive udarbejdet eksterne dokumenter, såkaldte technology-specific checklist som vil indeholde information om krav specielt for forskellige teknologier som f.eks. XHTML, CSS 5 og SMIL 6. Automatisk evaluering af websteder I takt med at websteder er blevet en integreret del af organisationers markedsføring og kommunikation, er behøvet for hurtig og billig sikring af websteders kvalitet steget markant. Også den stigende fokusering på brugervenlighed og tilgængelighed fra både brugere og myndigheder har gjort sit til at flere og flere efterspørger enkle og effektive måder at teste websteder på. Automatisk evaluering har mange fordele i denne henseende, selvom det naturligvis ikke erstatter en menneskelig evaluering. Først og fremmest kan det reducere tid og omkostninger samt behovet for specialuddannet personale. Automatisk evaluering kan også sikre konsistente fejlrapporter, så det er nemmere at sammenligne forskellige resultater, og øge effektiviteten automatiske værktøjer bliver ikke trætte eller distraherede Automatiseringen vil, på grund af det lave ressourceforbrug, også åbne for muligheden for at teste mere og tidligere i en designproces. [Brajnik, 2002a; Ivory & Hearst, 2001] Endelig kommer man ikke uden om at muligheden for automatiske testmetoder kan være med til at udbrede tilgængelighed og brugervenlighed til de der normalt ikke vil have overvejet dette. [Boldyreff, 2002] En automatisk evaluering skal bygge på nogle opstillede regler. Der findes mange forskellige regelsæt, tommelfingerregler eller heuristikker for kommunikation på WWW. De kan blandt andet opdeles i følgende kategorier: Designregler, som er et sæt specifikke regler for f.eks. et operativsystem eller en software applikation; Style guides, som først og fremmest samler retningslinier for konsistent og ensartet kommunikation indenfor f.eks. en organisation; samlinger af retningsliner, som er mere eller mindre specifikke retningsliner rettet mod en bred gruppe af brugergrænseflader eller medietyper 7 ; samt standarder som er overordnede regler oftest på nationalt eller internationalt plan. Jo mere generelle retningslinerne bliver, desto mere abstrakt bliver fortolkningen af disse. [Scapin et al., 2000] 5 Cascading Style Sheets 6 Synchronized Multimedia Integration Language 7 WGAG er et eksempel på en samling af retningslinier 13

14 En anden måde at opstille dette problem på er at betragte en regel som værende afhængig af en intern eller en ekstern egenskab. Interne egenskaber kan evalueres ved alene at kigge på produktet, mens eksterne egenskaber (attributes) kun kan evalueres ved at se på produktet i forhold til dets omgivelser. En intern egenskab kan f.eks være størelsen i kb på et websted, antallet af ord i en tekst eller overholdelsen af syntaksen for HTML. Eksterne egenskaber er f.eks. om et ord er meningsfuldt i forhold til konteksten, eller om information kun bliver givet ved hjælp af farve. [Brajnik, 2000; Brajnik, 2001] Når man evaluerer et websted i forhold til tilgængelighed eller brugervenlighed, skal man tage både interne og eksterne egenskaber i betragtning. Kun interne egenskaber kan automatiseres, men eksterne egenskaber kan evalueres semiautomatisk f.eks. ved at advare om potentielle problemer. [ibid.] Typer af evalueringsværktøjer Der findes mange forskellige værktøjer, som mere eller mindre automatisk, kan bruges til at evaluere et websted for brugervenlighed og/eller tilgængelighed. Alt efter udgangspunktet kan disse redskaber inddeles i forskellige kategorier. Tager man udgangspunkt i det primære formål med evalueringen kan de inddeles i f.eks. logfilsanalyse, evaluering af tilgængelighed, test af ydeevne etc. [Brajnik, 2002a]. I praksis er det dog ikke nogen særlig god kategorisering, da en del redskaber ofte kan bruges til flere formål. En anden måde at foretage en kategorisering på er ved, at se på hvilke handlinger værktøjet udfører. WAI kategoriserer de forskellige værktøjer i de følgende kategorier: Evalueringsværktøjer, der fremstiller en rapport med mulige fejl; reparationsværktøjer, som retter fejl og problemer på webstedet; og endelig filter- og transformeringsværktøjer, der modificerer eller konverterer webdokumenter i forskellig grad [Web Accessibility Initiative, 2003c]. En ligefrem og overskuelig kategorisering, der dog indeholder nogle problemer. For det første kan alle de forskellige værktøjer siges at være evalueringsværktøjer. For det andet bruges filterog transformeringsværktøjerne til at konvertere og ændre websteder. De kan derfor lige så godt betegnes som reparationsværktøjer. Størstedelen af værktøjerne, som WAI kategoriserer her, er desuden mest rettet mod brugerne af webstedet og ligger derfor uden for denne opgave. Ivory & Hearst [2001] foreslår en mere facetteret kategorisering ud fra først evalueringsmetoden (f.eks. brugertest, inspektion eller simulering) og herefter en yderligere kategorisering efter disse metoder: automatisk dataindsamling, automatisk analyse og automatisk kritik. Denne inddeling giver et meget detaljeret overblik. I vores tilfælde, for detaljeret. 14

15 Endelig foreslår Brajnik [2000] en enkel inddeling i værktøjer til fejlidentificering: de finder fejl på baggrund af simuleret brugeradfærd; værktøjer til fejlanalyse som finder årsager til fejl på baggrund af webstedets kode; og analyse og reparationsværktøjer som retter fejl fundet ved en analyse. Af de eksisterende værktøjer som er beskrevet i litteraturen, og de som vi ellers har kendskab til, er der ingen, der er relevante for webtilgængelighed, som vi kan kategorisere som værktøjer til fejlidentificering. Til gengæld er der et bredt udbud af værktøjer til fejlanalyse eller analyse og reparationsværktøjer. [Kirchner, 2002; Faulkner & Arch, 2003; Ivory & Chevalier, 2002; Harrison & O Grady, 2002] Evaluering og undersøgelser af værktøjer En del undersøgelser og evalueringer af eksisterende værktøjer er offentliggjort. Nogle undersøgelser fokuserer på at sammenligne forskellige værktøjer, for at give et generelt billede af de eksisterende teknologiske muligheder [Harrison & O Grady, 2002; Kirchner, 2002; Brajnik, 2000]. Andre fokuserer på værktøjernes korrekthed i forhold til WCAG niveau-a [Faulkner & Arch, 2003], eller hvordan webdesignere forstår og bruger dem [Ivory & Chevalier, 2001; Ivory & Mankof & Le, 2002]. Brajnik [2001 & 2002b] opstiller forskellige kvalitetskrav til hvor godt et værktøj evaluerer efter de relevante retningslinier. Først og fremmest definerer han to typer af fejl som værktøjet kan lave: Falsk positiv, værktøjet rapporterer en fejl som ikke er en fejl og falsk negativ, værktøjet finder ikke en fejl selv om den eksisterer. For det andet beskriver han to krav til værktøjets fortolkning af en regel for, at den er gyldig. Den skal først og fremmest være korrekt det vil sige at der ikke er nogen falske positiver. Desuden skal den være komplet, således at den aldrig rapporterer falske negativer. De forskellige undersøgelser viser at de fleste værktøjer er nogenlunde korrekte [Faulkner & Arch, 2003], men at de til gengæld ikke er komplette. Det skyldes først og fremmest de grundlæggende retningsliniers afhængighed af eksterne egenskaber, som fremkalder manuelle og semiautomatiske evalueringer. En del af disse skyldes dog interne egenskaber og kan således godt automatiseres, værktøjet har bare ikke nogen teknisk løsning endnu. [Brajnik, 2000] Undersøgelserne viser også at de fleste værktøjer havde problemer med, eller fuldstændig udelod, evaluering af teknologier som Flash, Javascript og CSS. Desuden var der en del som ikke inkluderede samtlige punkter i WCAG. [Kirchner, 2002; Harrison & O Grady, 2002] Alle undersøgelser konkluderer følgende: at 15

16 ingen af værktøjerne kommer i nærheden af at erstatte menneskelig evaluering, men at de kun kan assistere i en sådan manuel evaluering. En undersøgelse [Ivory & Chevalier, 2001; Ivory & Mankof & Le, 2002] af hvorledes webdesignere opfattede og brugte evalueringsværktøjerne, konkluderede desuden at halvdelen af de adspurgte webdesignere, som brugte automatiske værktøjer, mente at de hjalp dem i at lave tilgængelige websteder og lærte dem om bedre design. Et flertal af de adspurgte mente dog ikke at værktøjerne var gode nok, at brugen resulterede i bedre websteder eller at værktøjerne var nemme at bruge. Desuden blev det undersøgt hvor godt det lykkedes webdesignere at rette fejl og problemer, på udvalgte websteder, ved hjælp af værktøjerne. Selv om designerne fik præsenteret eventuelle fejl, så lykkedes det ikke at implementere effektive rettelser i deres redesign. Kun de som ikke tog udgangspunkt i et værktøj, men i deres egne erfaringer, lykkedes at lave egentlige forbedringer. Selv om automatisk evaluering altså uden tvivl kan hjælpe med at gøre websteder tilgængelige, så tyder alt på at de for de første ikke kan hjælpe med alle typer af problemer. For det andet kan værktøjerne være svære at bruge og deres resultater svære at implementere. Det er især de eksterne egenskaber og de følgende manuelle eller semiautomatiske evalueringer, som er problemet. For at gøre værktøjerne bedre er det derfor vigtigt at undersøge hvordan værktøjerne formidler sine resultater og hvorledes dette kan gøres mere forståeligt. 16

17 Analyse Der findes som beskrevet en række værktøjer til automatisk evaluering af tilgængelighed på websider, og af dem har vi valgt at analysere to værktøjer til fejlanalyse, nemlig Bobby og WAVE. For begge evalueringsværktøjer gælder, at de er udviklet på basis af WCAG samt Section 508. Vi har valgt Bobby af to grunde, nemlig at Bobby er det værktøj som flest stadigvæk kender, samt på grund af at Bobby præsenterer sine resultater både visuelt og tekstuelt. WAVE har vi valgt udfra den betragtning, at det præsenterer sine resultaterne visuelt, og på en, efter vores mening, nytænkende måde. Desuden er både Bobby og WAVE tilgængelige online. Det vil sige, at vi derfor har valgt ikke at analysere nogle af de værktøjer, som kan downloades. Dette valg har vi fortaget, da vi ikke umiddelbart mente, at disse værktøjer, som vi kender til, bidrog med en væsentlig anderledes formidling af evalueringsresultaterne, end Bobby og WAVE. Desuden skal man ofte betale for disse værktøjer. Dog har værktøjerne til download blandt andet den finesse, at de kan evaluere flere sider i samme proces. Om denne analyse kan det nævnes, at det ikke er hensigten at analysere os frem til hvordan værktøjerne virker i teknisk henseende 8. Det vil sige, at vi højest perifert berører problematikker vedrørende hvor komplet og korrekt værktøjerne følger WCAG. Vi mener dermed ikke, at det er uvæsentligt om der undersøges for det ene eller det andet, men det interessante for os er, at se på værktøjernes formidling af resultaterne. Vi er selvfølgelige ikke blinde for, at den teknologiske udvikling i henhold til evalueringsværktøjerne, har og vil have indflydelse på, hvordan formidlingen af resultaterne foregår. En oversigt over websider anvendt i analysen af værktøjerne findes i Bilag 1. Analysemodel For at kunne besvare spørgsmålene stillet i problemformuleringen, har vi opstillet følgende model til analyse af de udvalgte automatiske evalueringsværktøjer: Baggrund + Funktionalitet + Formidling Virkning 8 I Bilag 1 beskriver vi dog kort nogle af de tekniske problemer der har været i forbindelse med test af en række websteder. 17

18 Med denne analysemodel vil vi for hvert evalueringsværktøj på basis af baggrunden, funktionaliteten og formidlingen, give vores vurdering af hvordan webdesignere påvirkes i fortolkningen og implementeringen af evalueringsværktøjernes testresultater. Baggrunden er at finde ud af hvilke personer eller organisationer, som har udviklet og/eller står bag det enkelte evalueringsværktøj. Ydermere er baggrunden, at finde ud af hvorfor og hvad formålet er med det enkelte evalueringsværktøj. Funktionaliteten er en beskrivelse af de valgmuligheder brugerne har i forbindelse med hvad de vil teste for, og hvor meget de vil have præsenteret i resultatet. Formidlingen er en beskrivelse af den måde hvorpå de enkelte evalueringsværktøjer har valgt at præsentere deres resultater. Virkningen er vores kritiske kommentarer vedrørende de enkelte værktøjers evne til at gøre brugeren opmærksom på tilgængelighedsproblemer på testede websteder. Analyse af Bobby Baggrund Bobby blev offentliggjort i 1996 af The Center for Applied Special Technology (CAST), som er en nonprofit organisation. Det som drev CAST til at udvikle Bobby, var deres engagement i at anvende teknologi til at hjælpe handicappede, specielt i uddannelsesmiljøer, med at overkomme forhindringer bedre [Cooper, 2000]. Bobby blev derfor udviklet i den ånd at det skulle være med til at uddanne webdesignere om tilgængelighed, og det at designe universelt [Cooper & Rejmer, 2001]. Det vil sige, at den måde Bobby præsenterer sine resultater (rapporter), er baseret på, at brugeren skal lære noget af at bruge værktøjet. Herved skulle man opnå som webdesigner, at man forstår de principper som ligger bag tilgængelighed og universelt design samt at kunne omdanne disse principper til tekniske løsninger. [Cooper, 2000] Bobby er i dag overtaget af WatchFire, som sælger løsninger til automatisk testning og analyse af websider. Efter WatchFires overtagelse af Bobby er det ikke længere muligt frit at benytte Bobby. Downlaodudgaven kan i dag kun erhverves mod betaling og onlineudgaven, som vi arbejder med, kan kun benyttes én gang i minuttet, angiveligt for at undgå misbrug. 18

19 Version Vi har arbejdet med version af onlineudgaven af Bobby i vores analyse. Som beskrevet er denne udgave begrænset i brugen rent tidsmæssigt. Funktionalitet Der er to indgange til at foretage test i onlineudgaven af Bobby. Den ene (standardtest) bliver brugeren præsenteret for allerede på forsiden, og her har brugeren mulighed for at vælge om websiden skal testes op mod WCAG, eller op mod Section 508. Den anden indgang (tilpasset test) findes under punktet Customization Options i undermenuen. Her er det nu muligt for brugeren at vælge om websiden skal testes op mod WCAG prioritet 1, prioritet 1 & 2 eller prioritet 1, 2 & 3. Ydermere har brugeren mulighed for at ændre på nogle parametre vedrørende præsentationen af resultaterne, det vil sige at disse parametre ikke er valgbare i standardtesten. For det første er det muligt at vælge ikke at få vist den visuelle del af rapporten. Den visuelle del vises som standard ikke ved den tilpassede test, men vises ved standardtesten. For det andet kan brugeren ud for de enkelte punkter i den tekstuelle del, desuden vælge at få vist den bid HTML-kode, hvor fejlen forefindes, i stedet for som i standardtesten kun at få en henvisning til et linienummer i koden. Dette blev i de første versioner af Bobby vist i standardtesten, men i arbejdet med at gøre Bobby mere international [Cooper & Rejmer, 2001], blev visningen af HTML-koden flyttet til den tilpassede test, som en valgbar parameter. For det tredje har brugeren mulighed for at teste om hans fejlsider 9 også er tilgængelige. I standardtesten tjekkes fejlsider ikke, men i den tilpassede test bliver de tjekket. Men der er nogle problemer med denne funktion, da visse fejlsider ikke kan testes i Bobby. Om problemet skyldes den aktuelle server, som den testede webside ligger på, har vi ikke undersøgt nærmere. Sidst kan brugeren vælge hvilken browser Bobby skal imitere, eftersom nogle websteder viser indhold i forhold til hvilken browser som webstedet ses med. For både standardtesten og den tilpassede test er ingen specifikke browsere valgt. Formidling Bobby kombinerer en visuel (Billede 2) og tekstuel (Billede 3) formidling i præsentationen af resultaterne af testen. Dog vises resultatet nogle gange kun tekstuelt, hvis eksempelvis en side der testes består af 9 Fejlsider er de websider, som fremkommer, når der opstår fejl eller sider ikke findes på et websted. 19

20 rammer 10. Bobby er derfor ikke konsekvent i sin præsentation af sine resultater angående forholdet mellem den visuelle og tekstuelle del. Begrebsmæssigt betegner Bobby desuden kun den tekstuelle del som rapporten. Men vi opfatter både den visuelle og tekstuelle del som rapporten, og skriver derfor ud fra denne opfattelse. Billede 2: Den visuelle del Den visuelle del består af en præsentation af den testede webside i sit originale udseende, dog vises JavaScript og CSS ikke. At den originale sides stylesheet ikke vises, mener vi kan være problematisk. Grunden herfor er at nogle af de retningslinier der testes for, går på en websides layout, blandt andet kontrastforholdet mellem farverne anvendt til tekst og baggrund. Men grunden til at JavaScript og CSS ikke vises er, at rapporten, som helhed, skulle blive mere læsbar uden [WatchFire, 2003]. I den visuelle del indsætter Bobby i præsentationen af den testede webside: ingen, et eller flere symboler, enten spørgsmålstegn eller Bobbyhatte. Spørgsmålstegnene antyder overfor brugeren at der muligvis er en fejl, hvor Bobby-hattene angiver at der på det givne sted er en fejl som skal rettes. Symbolerne linker hver især til et punkt i den tekstuelle del. 10 Når Bobby tester websider som består af rammer, vil brugeren i første omgang få vist en resultatside med links til hver delrammes webside. Her mener vi, at Bobby burde gøre sine brugere opmærksom på, at det ikke er muligt at teste mere end én webside i minuttet. 20