SÅDAN TESTER DU HJEMMESIDER

SÅDAN TESTER DU HJEMMESIDER VEJLEDNING Vejledning til tilgængelighedstest Digitaliseringsstyrelsen 2012 Design: www.kopilot.dk 1

SÅDAN TESTER DU HJEMMESIDER I det følgende finder du nogle anvisninger på, hvordan du kan teste HTML-baserede hjemmesider for en række af de krav, der indgår i de internationale tilgængelighedsretningslinjer, WCAG 2 niveau AA. Vi har bestræbt os på at forklare det på en måde, der ikke kræver ekspertviden indenfor HTML, men nogle få kriterier kræver dog en vis kodeforståelse. Vejledningen er ikke en egentlig introduktion til tilgængelighedsstandarden, WCAG, eller til gældende regler. Den dækker heller ikke alle standardens krav, eller andre teknologier end HTML, og der kan være andre måder at teste og overholde de enkelte krav på, end det vi beskriver her. WCAG er forholdsvis fleksibel, hvad det angår. De heri beskrevne metoder er imidlertid efter vores erfaring og dialog med mange webmastere og eksperter nogle af de mest nødvendige, letteste og mest praktiske måder at teste tilgængeligheden på, med mindre man besidder en høj grad af kodeforståelse, eller man har behov for at teste mere avancerede funktioner eller store systemer. I det sidste tilfælde anbefaler vi generelt, at man får en uvildig ekspert til at kigge på det allerede i løbet af udviklingsfasen og ifm overtagelsestests. Du er altid velkommen til at kontakte Digitaliseringsstyrelsens tilgængelighedsteam KIA på e-mail kia@ digst.dk, hvis du har spørgsmål til vejledningen eller til tilgængelighedsstandarden WCAG. God fornøjelse. OPBYGNING AF VEJLEDNINGEN Vi giver her nogle kortere introduktioner til, hvordan du kan teste de simplere ting i HTML og på hjemmesider generelt. Andre teknologier, som fx Flash, AJAX o.l. bør du nok have assistance med. Vi viser endvidere, hvordan du tester manuelt om end med brug af enkelte værktøjer. Vejledningen er bygget op således, at de enkelte WCAG-krav er grupperet under en overskrift, som fortæller, hvad det er for en type af krav, vi har med at gøre. Denne gruppering er ikke direkte identisk med grupperinger i WCAG, og anvendes udelukkende til illustrativ brug i denne vejledning. Nummer og titel på de enkelte kriterier er derimod taget direkte fra den danske oversættelse af WCAG-retningslinjerne her: http://www.w3.org/translations/wcag20-da/ Efter kriterierne har vi valgt at præsentere en tabel, hvor der meget kort fortælles, hvordan hvert kriterium bliver testet. Har du brug for mere uddybende information, så kommer det i den følgende tekst, hvor du kan dykke ned efter behov. 2

INDHOLDSFORTEGNELSE Sådan tester du hjemmesider 2 Opbygning af vejledningen 2 Indholdsfortegnelse 3 1. Tastatur 4 Overblikstabel 4 Uddybende forklaring 4 2. Struktur 6 Oversigtstabel 6 Uddybende forklaring 6 3. Lyd og billede 14 Overblikstabel 14 Uddybende forklaring 14 4. Farve og kontrast 16 Overblikstabel 16 Uddybende forklaring 16 5. Bevægelse og blink 18 Overblikstabel 18 Uddybende forklaring 18 6. Konsistens 19 Overblikstabel 19 Uddybende 19 Samlet tabel med test 20 Test af funktionalitet 22 Formularer til indberetning 22 Labels, fieldset og legend 22 I fokus 23 Retningslinje 3.3 Inputhjælp: Brugere skal have hjælp til at undgå og rette fejl 23 Lightbox 24 3

1. TASTATUR Her tester vi for WCAG-kriterierne 2.1.1 Tilgængelig via tastatur, 2.1.2 Ingen tastaturfælde, 2.4.3 Fokusrækkefølge, 2.4.7 Synligt fokus, 3.2.1 I fokus og 2.4.1 Spring over blokke Overblikstabel Tastaturtests 2.1.1 Tilgængelig via tastatur Brug Tab-knappen og se, om du kan få fat i alle interaktive elementer (links, formularfelter, knapper i medieplayer o.l.). Nogle formularer kræver, at du bruger piletasterne til at navigere og Enter-knappen eller mellemrumstasten til at vælge. 2.4.7 Synligt fokus Tjek, om det tydeligt fremgår, hvor du er på siden, når du tabber. 2.4.3 Fokusrækkefølge Tjek, at du kommer rundt på siden med tabning i en logisk rækkefølge. 3.2.1 I fokus Der må ikke ske ændringer i fokus blot ved, at man kommer dertil der skal være et aktivt valg. Eksempler på fejl er, 1. at der automatisk kommer en hjælpetekst frem i et inddateringsfelt, eller 2. at første punkt i en dropdown-menu vælges automatisk, når man forsøger at komme igennem menuen vha. tastaturet. 2.1.2 Ingen tastaturfælde Test, at du ikke sidder fast nogle steder på siden. Det kan typisk ske ved Flash, fx i videoer. 2.4.1 Spring over blokke Er der spring til eller over links, du kan nå med tastaturet? Se efter i browserens statusbar eller slå style sheets fra. Disse er IKKE obligatoriske. Overskrifter m.m. kan give den samme funktionalitet. Tabel 1. Tastaturtests. UDDYBENDE FORKLARING Alt skal kunne tilgås vha. tastaturet, hvilket vil sige at links og andre interaktive elementer (formularer, start-stop videoer m.m.) ikke bare skal kunne tilgås med musen. Dette princip er et af de allervigtigste, når du skal sikre tilgængeligheden af din løsning. I princippet en super simpel test. Brug tab-knappen og se, om du kan tilgå alle interaktive elementer. Har du svært ved at se, hvor du er henne på hjemmesiden, mens du tabber, er dette en fejl; der skal være synligt fokus. Altså en tydelig visuel markering af, hvilket element du har nået vha. tastaturet. De forskellige browsere laver selv en visuel markering, tydeligst i Chrome, men den kan være utydelig pga. af farvevalg på siden, eller den kan være forhindret af kode i sidens style sheet. Endelig kan man med fordel have givet en tydeligere visuel markering, end browserne selv gør. Samtidig tester du også for, om der er nogle tastaturfælder, hvilket betyder, at du ikke kan komme videre fra et element (fx video) ved at tabbe; du sidder fast i elementet. Tjek samtidig om rækkefølgen i tabningen giver mening så du når de forskellige elementer i den rækkefølge, du vil anse for at være logisk. 4

Nogle ting benytter man ikke tab-knappen til at nå, men piletasterne. Det gælder typisk i formularer. Her skal du også teste, at det er muligt at benytte piletasterne i en select-form (dem med drop-down), uden at formularen vælger det første punkt på listen automatisk. Brugeren skal selv kunne vælge. Ikke obligatorisk: Se efter, om der er spring over links i starten af siden. De kan evt. være gjort usynlige. Se i browserens statusbar, når du navigerer med tab, om der dukker nogle interne henvisninger op. Du kan også finde eventuelle links ved at slå brugen af style sheets fra på siden (denne vender vi tilbage til). 5

2.Struktur Her tester vi for 1.3.1. Information og relationer, 2.4.2. Sider har titler, 2.4.6. Headings and Labels Overblikstabel Strukturtests 1.3.1. Information og relationer 2.4.6. Headings og labels Overskrifter Identificer, at der er brugt overskrifter. Tjek for usynlige overskrifter. Identificer hierarki. Tjek, at overskrifterne er beskrivende for indholdet. Lister Tjek, at lister er opmærket som lister. Tabeller Tjek for tableheaders (th). Tjek for brug af scope eller id og headers. Formularer Tjek for labels. Tjek, at labelteksten er beskrivende. Tjek for fieldset og legend, hvis nødvendigt. 2.4.2. Side titel Tjek, at siden har en unik og beskrivende titel. Tabel 2. Strukturtests. UDDYBENDE FORKLARING Struktur (eller semantik) i kodningen af hjemmesiden og i de enkelte dokumenter giver en stor hjælp for en række brugere heriblandt søgemaskiner til at forstå og fortolke indholdet samt til at navigere i det. Langt det meste er lige ud ad landevejen. Der skal blot være en kodning, der modsvarer det visuelle. OVERSKRIFTER Her kigger vi efter Headings, dvs. <H1>, <H2>, <H3> osv. Brug WAT->Structure->Headings eller WebDeveloper->Fremhæv->Fremhæv Overskrifter (Web Accesibility Toolbar (WAT) er beskrevet i vejledningen Før du tester hjemmesider, side 2). Som vi så under tastaturtest, kan overskrifter med fordel benyttes til alle sidens samlinger af elementer, dvs. ikke blot i den enkelte artikel, men til navigationselementer, brødkrummer, kontakt m.m.m. Det kan gøre det lidt vanskeligere at bestemme hierarkiet i overskrifterne. I en artikel eller lignende fortløbende tekst er det nemt at fastslå det korrekte niveau for en overskrift, om den er på niveau 1, underliggende på niveau 2, underliggende for denne på niveau 3, sideordnet eller igen på et højere niveau osv. Når alle 6

sidens elementer har overskrifter er der ikke på samme måde en færdig facitliste. Du må bruge din sunde fornuft til at vurdere, om et element på siden er over-, side-, eller underordnet et andet element. Du kan med fordel tage udgangspunkt i hovedindholdet på siden, som typisk vil være artiklens indhold, formularen e.l. USYNLIGE OVERSKRIFTER Man kan vælge at benytte usynlige overskrifter på elementer, hvor en synlig overskrift ville kunne virke forstyrrende på seende brugere. Usynlige overskrifter bruges til menuer o.l. og er gjort usynlige for seende, men synlige for bl.a. skærmlæserbrugere vha. style sheets. Det er således bestemt ikke en fejl at have usynlige overskrifter, lige som det heller ikke er en fejl ikke at have dem, da man kan bruge andre teknikker til at opnå det samme resultat nemmere overblik og navigation. Har man bedt leverandøren om, at alle centrale elementer skal have overskrifter, er her en metode til at teste, om man har fået det. Den nemmeste måde at teste om der er usynlige overskrifter, er ved at slå style sheet fra i browseren. Det kan du nemt gøre med WAT eller WebDeveloper, ellers må du ind i browserens indstillinger og gøre det. Herunder kan du se det samme udsnit af en hjemmeside med og uden style sheets. Med style sheets slået til er det ikke muligt at se, at de to forskellige elementer har nogen overskrifter. Det fremgår derimod tydeligt, når style sheets er slået fra, hvor det ene element har overskriften Sektion, og den anden har overskriften Breadcrumbs. Se samtidig om overskrifterne er beskrivende for indholdet. Det skal de være. Figur 1. Udsnit af side set med style sheets. Figur 2. Udsnit af side set uden style sheet. 7

Man kan skjule elementer på en side vha. forskellige style sheet teknikker. Nogle af dem er desværre ikke gode i forhold til at skjule tekst, da de skjuler for godt, så kompenserende udstyr som skærmlæsere heller ikke kan se det. En forkert måde at gøre det på, er at bruge display : none i style sheetet. Her må du enten ind og tjekke i sidens style sheet eller noget nemmere; spørge leverandøren. Du kan med fordel bruge fx WebDeveloper til at vise sidens overskrifter, mens du ser siden uden style sheet. Det gør det nemmere at se, om overskrifterne optræder i den logiske, hierarkiske rækkefølge. Figur 3. Side set uden style sheet, men med WebDevelopers Fremhæv overskrifter slået til. LISTER Alle elementer, der har karakter af en opremsning, bør være opmærket som en liste, mens de ikke behøves at se ud som en liste, når det ses med style sheet. Test ved at se siden uden style sheets. Korrekt opmærkede lister vil nu enten have bullits eller fortløbende tal. Som du kan se af eksemplerne ovenfor, er topnavigationen korrekt opmærket som en unummereret liste (bullits). Tjek samtidig, om der er lavet lister ved blot at sætte tegn (typisk - ) foran tekst. Det er ikke rigtigt. Det skal være opmærket korrekt. TABELLER Tabeller bruges til at vise data, der er indbyrdes forbundne, og tabellerne skal være opmærkede korrekt. Det betyder, at tabeloverskrifter skal være opmærkede som tabeloverskrifter, og alt efter hvor kompliceret tabellen er skal de have enten scope (til at angive retningen for overskriften) eller id og headers til komplicerede tabeller med overskrifter, der dækker flere rækker eller kolonner. Derudover skal komplice- 8

rede tabeller have en summary, der forklarer tabellens opbygning og indhold. Man bør ikke men må godt benytte tabeller til layout. Disse tabeller skal ikke have tabeloverskrifter. SIMPEL TABEL Her viser vi først en simpel data-tabel Figur 4. En simpel data-tabel. Tabellen bliver her betegnet som simpel, da hver overskrift dækker én kolonne og ikke flere. For at se, om tabellen er opmærket korrekt, skal du i Tables i WAT vælge Show Data Tables, så vil tabellen, hvis den er rigtig opmærket se ud som i Figur 5 eller Figur 7, hvor du kan se, at der er brugt table headers (th), og at de har scope sat til at dække kolonnen (scope= col ). Skulle overskriften gælde horisontalt, skulle det være scope= row. Figur 5. En simpel data-tabel vist i WAT. 9

KOMPLICERET TABEL En kompliceret data-tabel har overskrifter, der dækker flere rækker eller kolonner. Figur 6. En kompliceret tabel. Når tabellen er kompliceret, kan man ikke nøjes med at bruge scope, der bliver man nødt til at benytte id og headers for at skabe en opmærkningssammenhæng mellem overskrifter og data. Figur 7 viser, hvordan det ser ud, hvis det er gjort korrekt. Figur 7. En kompliceret tabel vist i WAT. Her ses sammenhængen imellem tableheaders (th) og tabelcelle (td). I eksemplet er tabelcellen med teksten tal5 knyttet sammen med tabeloverskrifterne Overskrift (øverst oppe), Overskrit4 (5. kolonne) samt Vandret overskrift2 (til venstre i 4. række). Det sker vha. id= un_0, id= un_4 og id= un_6 i tabeloverskrifterne, der så fremgår i tabelcellens headers= un_0 un_6 un_0. Det er nemmere at se i en tabel, end det er at forstå en skriftlig forklaring! 10

Er tabellen ikke opmærket korrekt med tableheaders (th) samt enten scope eller id og headers, ja så bliver disse naturligvis ikke vist. I WebDeloper ser den korrekt opmærkede tabel ud som vist i figur 8. Her er brugt WebDeveloper > Information > Display Table Information. Figur 8. En kompliceret tabel vist i WebDeveloper. Læg mærke til, at WebDeveloper viser <summary>, men ikke <caption>, imens WAT viser <caption>, men ikke <summary>. Ja, det er irriterende! Tjek, at summary findes, og det er dækkende for tabellens indhold og opbygning. FORMULARER (MED SPECIFIK FOKUS PÅ OPMÆRKNING) For at teste formularer tilbundsgående skal man også teste for kvitteringer, validering, fejlmeddelelser m.m. Her har vi kun opmærksomhed på opmærkning. Du kan finde alle test inkl. de ovennævnte under Formularer til indberetning. Formularer eller forms giver brugeren mulighed for at indsende data på forskellig vis. Formularer kan i HTML-sprog betyde alt fra et søgefelt til en mere kompliceret selvbetjeningsløsning med et utal af valgmuligheder og indtastningsfelter. Til hvert inddateringsfelt skal der være en label. Dog kan man undtagelsesvist, hvis det er helt umuligt at benytte en label typisk i søgefelter benytte en titel i feltet. Brug WAT->Structure->Fieldset / Labels. Er der labels, vil det vises som i figur 9. Tjek, at den for, der er i labellen stemmer overens med den tilhørende id, samt at følgeteksten er beskrivende for inddateringsfeltet. 11

Figur 9. Radiobuttons med labels vist i WAT. Du kan også bruge den hurtige test. Tryk på teksten ved inddateringsfeltet, i eksemplet Ja, Nej og Ved ikke. Bliver feltet valgt, så er der typisk brugt labels. Til de lidt mere komplicerede formularer bør der også bruges fieldset og legend til at skabe overblik i formularen. Disse tags bruges til at gruppere inddateringsfelterne. De kan se forskelligt ud alt efter, hvordan de layoutes i style sheets, men typisk har de et udseende a la figur 10. Figur 10. En formular med fieldset og legend. Er du i tvivl. Brug WAT, hvor det tydeligt vises, om der er legend og fieldset. Figur 11. Formular vist ved hjælp af WAT. Du må hver gang selv vurdere, om brugen af fieldset og legend er nødvendig. Er det muligt at gruppere formularen i flere dele, er det oftest en fordel, at de bruges. Og det er bedre at bruge fieldset til formularer end at bruge overskrifter. 12

SIDETITLER Se i browserens title bar. Titlen skal være sigende for indholdet på den specifikke side. Den samme titel (f.eks. en myndigheds navn) må således ikke anvendes til samtlige sider på en hjemmeside. Figur 12. Title bar i Firefox. 13

3. LYD OG BILLEDE Her testes for 1.1.1. Ikke tekstbaseret indhold, 1.4.5. Billeder af tekst, 1.2.2. Undertekster Overblikstabel Test af lyd og billede 1.1.1. Ikke tekstbaseret indhold 1.4.5. Billeder af tekst Tjek at alle billeder har en sigende alternativ tekst. Billeder uden funktion i forhold til indholdet skal have en tom alt tekst. Tjek, at der ikke findes billeder af tekst, dog med undtagelse af logoer. 2.4.2. Side titel Tjek, at siden har en unik og beskrivende titel. Tabel 3. Test af lyd og billede. UDDYBENDE FORKLARING Billeder Billeder skal have alternativ tekst undtagen, hvor de er: Udsmykning eller usynlige (skal have en tom alt-tekst) CAPTCHA (En metode til at verificere, at det er et menneske og ikke en maskine, der forsøger at logge sig ind. Typisk består CAPTCHA af nogle slørede bogstaver, man skal gengive. Der skal være en alternativ verificeringsmulighed udover CAPTCHA, fx et simpelt spørgsmål a la, hvad er 2+3). Både Web Developer og WAT har funktioner, der hurtigt kan vise billedernes alternative tekster, og således også hvis ikke de har nogle. Du må manuelt gå billederne igennem og se, om de benyttede alternative tekster er dækkende for indholdet. Prøv at sætte dig i modtagerens sted. Hvad, ville du mene, var nødvendigt at få læst op, hvis du ikke kunne se billedet eller billederne? Og vurderer du, at billedet fungerer som udsmykning uden funktion i forhold til indholdet i øvrigt, så skal billedet have en tom alternativ tekst. Man bør ikke bruge billeder af tekst som tekst (fx til overskrifter). Dog må man godt i logoer. Der findes undtagelser til denne regel, men i HTML og CSS er det muligt at få næsten alle formateringer frem, så det burde meget, meget sjældent være nødvendigt. Test, at der ikke er brugt billeder af tekst som tekst ved at slå billedvisning fra i browseren eller via Web Developer eller WAT. VIDEO Video er ganske nemt at teste, men der er ikke nogen værktøjer til det. Der skal være captions, altså undertekster med væsentlig ekstra information om lyde o.l., hvis ikke videoen er et alter- 14

nativ til noget tekst. Testmetoden er derfor; start videoen, åben for captions, hvis ikke de starter som default. Er der ingen, eller understøttes captions ikke af videoplayeren, er videoen ikke tilgængelig. Tester du kun video, bør du også teste, at videoen kan betjenes med tastaturet. De forskellige browsere understøtter dette på forskellig vis og nogen slet ikke. Prøv derfor gerne i flere browsere. Endelig må hverken video eller lyd starte automatisk. Gør de det, er det en fejl. OBS! Er videoen et alternativ til tekst, fx en video, der viser hvordan man samler et skab, og der samtidig findes en manual i tekst, så behøves videoen ikke at have undertekster. Det skal blot være tydeligt markeret, at videoen er alternativ, og manualen skal nemt kunne findes fra siden med video. 15

4. Farve og kontrast Her testes for 1.3.3, Sensoriske egenskaber, 1.4.1. Anvendelse af farve, 1.4.3. Kontrast (minimum) Overblikstabel Farve og kontrast 1.3.3, Sensoriske egenskaber 1.4.1. Anvendelse af farve Tjek, at ingen sensoriske egenskaber, inkl. farve, er benyttet til at angive handling. 1.4.3. Kontrast (minimum) Tjek vha. Contrast Analyser, at der er tilstrækkelig kontrast imellem for- og baggrund. Tabel 4. Farve og kontrast. UDDYBENDE FORKLARING Det er en helt igennem manuel test uden brug af særlige værktøjer, der skal bruges til at teste for, at der ikke er brugt sensoriske egenskaber eller farve som den eneste betydningsbærende markør af, at en særlig handling skal foretages. Det betyder med andre ord, at man fx ikke alene må bruge farven grøn til at angive fortsæt, eller må skrive fx, at man skal trykke på den røde eller den runde knap, at man skal bruge navigationen til venstre eller indikere en fejl i formular med farve alene. Er der anvisninger som disse, så er løsningen fejlet. Der er til gengæld et værktøj til at teste for kontrast. Brug WAT, hvor der under Colour er flere værktøjer til at teste kontrast med. I Contrast Analyser applikationen kan man også se, hvordan de valgte elementers for- og baggrund ser ud med forskellige typer farveblindhed. Figur 13. Contrast Analyser. 16

Logoer og tekst, der kun har dekorativt formål, behøver ikke at overholde kravene til kontrast. Læg også mærke til, at kontrastkravene er forskellige for store (over 18pt for tekst uden fed, og 14pt for tekst med fed) og almindelige tekststørrelser. Det viser Contrast Analyser også. 17

5. Bevægelse og blink Her testes for 2.2.2 Pause, stop, skjul og 2.3.1 Grænseværdi på tre glimt eller derunder Overblikstabel Bevægelse og blink 2.2.2 Pause, stop, skjul 1.4.5. Billeder af tekst 2.3.1 Grænseværdi på tre glimt eller derunder Tjek med både mus og tastatur, at indhold, der ændrer sig, kan stoppes. Tjek at intet blinker hurtigere end 3 gange i sekundet. Tabel 5. Bevægelse og blink. UDDYBENDE FORKLARING Igen nogle manuelle tests. Findes der på løsningen, der testes, indhold, der ændrer sig automatisk ved blinkning, bevægelse, scrolling e.l., fx en nyhedskarrusel, skal brugeren kunne stoppe eller pause det. Husk at teste både med mus og med tastatur. Intet indhold på en hjemmeside må blinke mere end 3 gange på et sekund, da det kan forårsage epileptiske anfald. Brug din sunde dømmekraft for at vurdere om dette overholdes. 18

6. Konsistens Her testes for 3.2.3 Konsekvent navigation, 3.2.4 Konsekvent identifikation Overblikstabel Konsistens 3.2.3 Konsekvent navigation på tværs af flere sider 3.2.4 Konsekvent identifikation Test, at navigationen ikke ændrer rækkefølge eller på anden måde ikke er konsistent. På enkelt side: Test, at elementer med samme funktion har samme navn. På tværs af flere sider: Test, at elementer med samme funktion har samme navn. Tabel 6. Konsistens. UDDYBENDE Test navigationen på flere sider for at se, at fx rækkefølgen mellem menupunkter ikke ændres på forskellige sider, og at de forskellige elementer på siden bevarer deres placering, fx en søgefunktion placeret i øverste højre hjørne på samtlige sider. Konsekvent identifikation skal typisk også testes på tværs af flere sider, men også indenfor den enkelte. Her skal du se om elementer bliver identificeret konsekvent via labels, name og alternativ tekst. Et eksempel kunne være en artikel på flere sider. Her kan en Næste -knap have en alternativ tekst, der lyder Videre til side 2, Videre til side 3 og så fremdeles. Dette er en helt korrekt og konsistent identifikation af Næste -knappen. Identifikationen er ikke ens, men den er konsistent det er den samme bagvedliggende logik, der benyttes. En fejl kunne derimod være, hvis søgefunktionen på en side hedder Søg og på en anden hedder Find. Eller et link til et PDF-dokument hedder Læs om xx og et PDF-ikon, der peger til samme dokument, har en alternativ tekst, der hedder Download PDF. SAMLET TABEL MED TEST Her har vi samlet samtlige test i kort form. Du kan eventuelt skrive resultater af dine test ind i tabellen (se næste side). 19

Tabel med test Kriterie Kort forklaring Resultat 2.1.1 Tilgængelig via tastatur Brug Tab-knappen og se, om du kan få fat i alt. Nogle formularer kræver, at du bruger piletasterne til at navigere og Enterknappen eller mellemrumstasten til at vælge. 2.4.7 Synligt fokus Tjek, om det tydeligt fremgår, hvor du er på siden, når du tabber. 2.4.3 Fokusrækkefølge Tjek, at du kommer rundt på siden med tabning i en logisk rækkefølge. 3.2.1 I fokus Der må ikke ske ændringer i fokus blot ved, at man kommer dertil der skal en være et aktivt valg. Eksempler på fejl er, 1. at der automatisk kommer en hjælpetekst frem i et inddateringsfelt, eller 2. at første punkt i en dropdown-menu vælges automatisk, når man forsøger at komme igennem menuen vha. tastaturet. 2.1.2 Ingen tastaturfælde Test, at du ikke sidder fast nogle steder på siden. Det kan typisk ske ved Flash, fx i videoer. 2.4.1 Spring over blokke Er der spring til eller over links, du kan nå med tastaturet? Se efter i browserens statusbar eller slå style sheets fra. Disse er IKKE obligatoriske. Overskrifter m.m. kan give den samme funktionalitet. 1.3.1. Information og relationer 2.4.6. Headings og labels Overskrifter Identificer, at der er brugt overskrifter. Tjek for usynlige overskrifter. Identificer hierarki. Tjek, at overskrifterne er beskrivende for indholdet. Lister Tjek, at lister er opmærket som lister. Tabeller Tjek for tableheaders (th). Tjek for brug af scope eller id og headers. Formularer Tjek for labels. Tjek, at labelteksten er beskrivende. Tjek for fieldset og legend, hvis nødvendigt. Tjek for brug af scope eller id og headers. Formularer Tjek for labels. Tjek, at labelteksten er beskrivende. Tjek for fieldset og legend, hvis nødvendigt. 2.4.2. Side titel Tjek, at siden har en unik og beskrivende titel. 1.1.1. Ikke tekstbaseret indhold 1.4.5. Billeder af tekst Tjek at alle billeder har en sigende alternativ tekst. Billeder uden funktion i forhold til indholdet skal have en tom alt tekst. Tjek, at der ikke findes billeder af tekst, dog med undtagelse af logoer. 1.2.2. Undertekster Tjek, at videoen har captions, synkroniseret med det talte. 20

Tabel med test Kriterie Kort forklaring Resultat 1.3.3, Sensoriske egenskaber Tjek, at ingen sensoriske egenskaber, inkl. farve, er benyttet til 1.4.1. Anvendelse af farve at angive handling. 1.4.3. Kontrast (minimum) Tjek vha. Contrast Analyser, at der er tilstrækkelig kontrast imellem for- og baggrund. Vær opmærksom på, at der er forskel på kravene til almindelig og stor tekst. 2.2.2 Pause, stop, skjul Tjek med både mus og tastatur, at indhold, der ændrer sig, kan stoppes. 2.3.1 Grænseværdi på tre glimt Tjek at intet blinker hurtigere end 3 gange i sekundet. eller derunder 3.2.3 Konsekvent navigation Test, at navigationen ikke ændrer rækkefølge eller på anden måde ikke er konsistent på tværs af flere sider. 3.2.4 Konsekvent identifikation På enkelt side: Test, at elementer med samme funktion har samme navn. På tværs af flere sider: Test, at elementer med samme funktion har samme navn. 21

TEST AF FUNKTIONALITET Her finder du anvisninger til, hvordan du kan teste en specifik funktionalitet, når der ikke er behov for at teste hele hjemmesiden. Vi har indtil videre testmetoder til Formularer og til Lightboxe. Formularer til indberetning Her får du tips til, hvordan du tester en formular til indberetning. Det er relevant at teste i det mindste delelementer fra kriterierne 1.3.1. Information og relationer, 2.4.6. Headings and Labels, 3.2.1 I fokus, Retningslinje 3.3 Inputhjælp: Brugere skal have hjælp til at undgå og rette fejl. Labels, fieldset og legend Til hvert inddateringsfelt skal der være en label. Dog kan man undtagelsesvist, hvis det er helt umuligt at benytte en label typisk i søgefelter benytte en titel i feltet. I HTML en vil label omkranse følgeteksten. Brug WAT->Structure,->Fieldset / Labels. Er der labels, vil det vises som i figur 13. Tjek, at den for, der er i labellen stemmer overens med den tilhørende id, samt at følgeteksten er beskrivende for inddateringsfeltet. Figur 14. Radiobuttons med labels vist i WAT. Du kan også bruge den hurtige test. Tryk på teksten ved inddateringsfeltet. Bliver feltet valgt, så er der typisk brugt labels. Til de lidt mere komplicerede formularer bør der også bruges fieldset og legend til at skabe overblik i formularen. Disse tags bruges til at gruppere inddateringsfelterne. De kan se forskelligt ud alt efter, hvordan de layoutes i style sheetet, men uden særlig formattering har de et udseende a la figur 14. Figur 15. En formular med fieldset og legend. 22

Er du i tvivl. Brug WAT, hvor det tydeligt vises, om der er legend og fieldset. Figur 16. Formular vist i WAT. Du må hver gang selv vurdere, om brugen af fieldset og legend er nødvendig. Er det muligt at gruppere formularen i flere dele, er det oftest en fordel, at de bruges. Og de er bedre til at gruppere og strukturere i formularer end ved at bruge overskrifter, som bruges i almindeligt indhold. I FOKUS Formularen må ikke være udformet sådan, at indholdet ændres blot ved, at et felt kommer i fokus (feltet markeres). Det kan fx være, at der kommer en hjælpetekst frem, når inddateringsfeltet vælges, og fokus så flyttes til hjælpeteksten. Det skal være muligt for en bruger at tabbe sig forbi feltet og danne sig et overblik over den samlede formular, uden at det forhindres som beskrevet. På samme måde må der ikke vælges automatisk i en select-box ved navigering med piletasterne. Test ved at navigere i formularen vha. både mus og tastatur. Husk også at teste baglæns tabbing (SHIFT-Tab) forbi et inddateringsfelt og tilbage til det, samt at du kan vælge selv i select-boxe med piletaster og Enter. RETNINGSLINJE 3.3 INPUTHJÆLP: BRUGERE SKAL HAVE HJÆLP TIL AT UNDGÅ OG RETTE FEJL Der er en række tilgængelighedskriterier, der med god ret kan siges også at være almindelig brugervenlighed og best practise, ikke mindst under Inputhjælp. Kriterierne er: 3.3.1 Identifikation af fejl, 3.3.2 Ledetekster eller instruktioner, 3.3.3 Fejlforslag og 3.3.4 Forhindring af fejl (juridisk, økonomisk, data). For at teste disse kriterier skal du have mulighed for at foretage hele indberetningen og sende data. Har du ikke mulighed for at gøre dette, må du kontakte leverandøren og bede om deres dokumentation for, at kriterierne er overholdt. 23

HJÆLP OG INSTRUKTIONER Der skal være meget kortfattet hjælp og instruktioner til brugeren om, hvordan de enkelte felter skal udfyldes. Det kan fx være et felt til at indtaste dato, der angiver, hvordan dato skal skrives, eller et felt, der er obligatorisk, der har fået en asterix (*) eller tekst og evt. anden visuel markering af, at feltet er obligatorisk o.l. Testmetoden består i at bruge sin kritiske sans og sunde fornuft. Er der felter i formularen, hvor lidt instruktion kan hjælpe med at forhindre brugere i at udfylde dem forkert. FORKERT UDFYLDT FELT Udfyld et felt forkert. Senest efter at du har trykket send, men før endelig bekræftelse af indsendelse, bør formularen angive, hvori fejlen består med tekst og om muligt komme med forslag til rettelse. Stedet, hvor fejlen optræder, må ikke kun markeres med farve e.l., men skal som minimum have noget tekstligt. Denne tekst kan være i form af en asterix (*) e.l. Forhindring af fejl (juridisk, økonomisk, data) I formularer, hvor forkert indberetning kan have juridiske, økonomiske eller andre alvorlige implikationer for brugeren, skal der være en af tre muligheder: 1. Reversibelt. Det skal være muligt for brugeren at afvise eller fortryde det indsendte indenfor et angivet tidsrum 2. Datatjek. Det indsendte tjekkes for fejl og brugeren får mulighed for at rette 3. Bekræftelse. Der findes en måde, hvorpå brugeren bliver præsenteret for de indtastede oplysninger og har mulighed for at tjekke, bekræfte og rette i dem før oplysningerne bliver sendt. Testen består blot i at tjekke, at én af de tre muligheder er til stede. Testen består blot i at tjekke, at én af de tre muligheder er til stede. LIGHTBOX Figur 17. Eksempel på lightbox. 24

Lightboxe er blevet meget populære de senere år typisk til at vise større versioner af små billeder (thumbnails), men efterhånden også til andet indhold. Lightbox er en teknik, der lægger noget indhold som et lag ovenpå det normale indhold, bl.a. vha. javascript. De kan gøres tilgængelige, men der er særlige fokusområder, du skal være opmærksom på. Det centrale at teste mht. lightbox er 2.1.1 Tilgængelig via tastatur og 2.4.3 Fokusrækkefølge, men ellers skal andet relevant naturligvis også testes som beskrevet i det foregående. Lightboxen skal kunne aktiveres vha. tastatur, dvs. du skal kunne brug tab-knappen til at komme til linket, billedet eller andet, der bruges til at aktivere Lightboxen, og derefter trykke Enter-knappen til at aktivere. Når lightboxen er aktiveret, skal du tjekke, at fokus er flyttet til denne. Brug tab-knappen og se om, du er inde i lightboxen. Der bør altid være et link evt. en knap til at lukke lightboxen. Tjek, at du kan komme til denne vha. tab-knappen og lukke vha. Enter-knappen. Er der flere links eller formularfelter inde i lightboxen, skal du kunne bevæge dig rundt imellem dem med tastaturet på normal vis; dvs. enten med tab- eller piletaster. Når du lukker ned for lightboxen, enten via link eller Escape-knap, skal du komme tilbage til det udgangspunkt dér hvor du aktiverede lightboxen du havde før aktiveringen af lightboxen. Som noget særligt ved lightboxe skal du være opmærksom på, hvad der sker, hvis du tabber dig igennem lightboxen. Kan du komme til at bevæge dig udenfor typisk vil området uden for lightboxen være blevet mørkere og du kan tabbe igennem links, du ikke kan se, da de ligger under lightboxen, så er det en fejl. 25

26