Download - Digitaliseringsstyrelsen

Digitaliseringsstyrelsen 2012 – Design: www.kopilot.dk
SÅDAN TESTER
DU HJEMMESIDER
– VEJLEDNING
Vejledning til tilgængelighedstest
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 eks-
perter 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å hjemme-
sider generelt. Andre teknologier, som fx Flash, AJAX o.l. bør du nok have assistance med. Vi viser endvi-
dere, 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 for-
tæ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-ret-
ningslinjerne 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æk-
kefø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 pile-
tasterne 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 syn-
ligt 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 vi-
dere fra et element (fx video) ved at tabbe; du sidder fast i elementet. Tjek samtidig om rækkefølgen i tab-
ningen 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
Tabel 2. Strukturtests.
UDDYBENDE FORKLARING
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.
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. , , 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

ede 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 , men ikke , imens WAT viser
, men ikke . 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
UDDYBENDE FORKLARING
Billeder
Billeder skal have alternativ tekst undtagen, hvor de er:
• 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.
• 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
1.4.3. Kontrast (minimum)
Tabel 4. Farve og kontrast.
• Tjek, at ingen sensoriske egenskaber, inkl. farve, er benyttet til at angive handling.
• Tjek vha. Contrast Analyser, at der er tilstrækkelig kontrast imellem for- og baggrund.
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
Tabel 5. Bevægelse og blink.
• Tjek med både mus og tastatur, at indhold, der ændrer sig, kan stoppes.
•Tjek at intet blinker hurtigere end 3 gange i sekundet.
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 ere sider
3.2.4 Konsekvent identikation
Tabel 6. Konsistens.
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.
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.
1.3.1. Information og relationer
2.4.6. Headings og labels
Disse er IKKE obligatoriske. Overskrifter m.m. kan give den
samme funktionalitet.
Overskrifter
• Identicer, at der er brugt overskrifter.
• Tjek for usynlige overskrifter.
• Identicer 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 eldset 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 eldset 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
1.2.2. Undertekster
• 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 ndes billeder af tekst, dog med
undtagelse af logoer.
• 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 ere sider.
3.2.4 Konsekvent identikation • På enkelt side: Test, at elementer med samme funktion har
samme navn.
• På tværs af ere 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 grup-
pere 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