Tilgængeligheden til Danskernes Digitale Bibliotek

Ekspertvurdering Tilgængeligheden til Danskernes Digitale Bibliotek udarbejdet af Sensus ApS Dato: 29. september 2014 Udgave: 1.0 Status: Endelig

Ophavsret Sensus ApS. Alle rettigheder forbeholdes. Dette dokument må uden forudgående accept fra Sensus offentliggøres eller distribueres til tredjepart. Undtaget herfor er de virksomheder, som er direkte involveret i nærværende projekt, og som skal anvende dokumentet i den videre implementering og/eller afprøvning af løsningen. Sensus ApS Københavnsvej 27. 2. DK-3400 Hillerød Telefon: +45 48 22 10 03 E-Mail: sensus@sensus.dk Web: www.sensus.dk 2

Indhold 1 Indledning... 4 2 Sammenfatning... 5 3 Metode... 6 4 Detaljeret analyse og vurdering... 8 4.1 Princip Opfattelig... 8 4.1.1 Retningslinje - tekstlige alternativer... 8 4.1.2 Retningslinje - Tidsafhængige medier... 9 4.1.3 Retningslinje - Tilpasset... 12 4.1.4 Retningslinje Adskillelig... 14 4.2 Princip 2: Anvendelig... 18 4.2.1 Retningslinje - Tilgængelig via tastatur... 18 4.2.2 Retningslinje - Passende tid... 19 4.2.3 Retningslinje - Anfald... 20 4.2.4 Retningslinje - Navigerbar... 20 4.3 Princip 3: Forståelig... 23 4.3.1 Retningslinje - Læselig... 23 4.3.2 Retningslinje - Forudsigelig... 24 4.3.3 Retningslinje - Inputhjælp... 25 4.4 Princip 4: Robust... 26 4.4.1 Retningslinje - Kompatibel... 26 3

1 Indledning Denne rapport sammenfatter resultaterne af en gennemgang af tilgængeligheden på Danskernes Digitale Bibliotek (testet via Køge bibliotekerne). Vurderingen er gennemført i forbindelse med en præsentation for IT-faggruppen den 1. oktober 2014, og afprøvet i perioden 24. 26. september 2014 af Sensus ApS. I forbindelse med afprøvningen blev følgende URL anvendt: https://www.koegebib.dk Kapitel 2 er en sammenfatning af vurderingen af løsningen. Kapitel 3 indeholder en specifikation af det metodemæssige grundlæg for ekspertvurderingen samt en oversigt over værktøjer, som er anvendt i ekspertvurderingen. Kapitel 4 indeholder resultatet af den detaljerede analyse og vurdering. Resultatet er sammenfattet i et skema og dækker samtlige de områder, der indgår i ekspertvurderingen. For hvert område er eventuelle problemer identificeret, og konsekvenserne ved pågældende problemer er beskrevet. 4

2 Sammenfatning Dette afsnit sammenfatter det centrale indhold fra den detaljerede analyse og vurdering af Danskernes Digitale Bibliotek netsted. Løsningen har en primær målgruppe hvorfor løsningen skal kunne betjenes af alle. Den foretagne vurdering er baseret på de internationale retningslinjer for tilgængelighed WCAG 2.0. WCAG (Web Content Accessibility Guidelines) er en standard som skal sikre, at hjemmesider er tilgængelige for flest mulige mennesker i flest mulige situationer herunder folk med funktionsnedsættelser, men også folk i al almindelighed. WCAG er opbygget af 38 succeskriterier, og det samlede resultat er, at netstedet bryder med 14 af disse. Den samlede vurdering af netstedet på basis af disse brud er, at løsningen på nuværende tidspunkt er mindre tilgængeligt. Dette skyldes, at der findes en række brud på retningslinjerne for tilgængelighed, som er listet i kort form herunder. Når der benyttes billeder i løsningen skal der benyttes alt-tekst såfremt en bruger har mulighed for at tilgå billedets information. De alt-tekster der findes i løsningen bærer præg af at være redigeret efter de er blevet lagt ind i løsningen. Dette er især relateret til forsiden. Såfremt et billede kun er til stede som et sensorisk virkemiddel, bør altteksten være tom. Det bør sikres, at der altid benyttes korrekt struktur ved brug af headings. I løsningen findes problemer med at benytte korrekt hierarki. Dette hindrer muligheden for skærmlæserbrugere i at danne overblik over indhold, samt at springe mellem afsnit i større tekstmængder. Korrekt brug af headings er en væsentlig del af at opnå en god tilgængelig løsning. I løsningen findes en række links, som udelukkende bliver præsenteret for brugeren ved hjælp af farve. Brug af farve som eneste visuelle middel til at præsentere et element er et alvorligt problem for mennesker med farveblindhed samt svagsynede. I dette tilfælde er resultatet, at det vil være muligt at vurdere hvad der er links i løsningen for disse brugere. Læs mere om dette i afsnit 1.4.1. Kalenderfunktionen kan betjenes ved brug af tastatur. Personer som benytter tastatur som navigation vil derfor blive afskåret fra denne del af løsningen. Dette gælder eksempelvis skærmlæserbrugere, men også en lang række andre grupper, eksempelvis gigtramte, folk med tennisalbue eller mennesker, som på anden vis er hindret i at bruge mus. Læs mere om dette i afsnit 2.1.1. Videoer er en svær tilgængelighedsmæssig problematik at imødekomme. Flere af de 38 punkter i WCAG er tilknyttet netop disse punkter, og løsningen fejler tre af disse succeskriterier; 1.2.2, 1.2.3 og 1.2.5. Dette skyldes, at filmene mangler tekstligt alternativ samt synstolkning. De ovenstående brud er alle kritiske i forhold til navigation og generel brug af løsningen. Det må derfor forventes, at en række mennesker med særlige behov kan anvende løsningen. Dette gælder både brugere med og uden kompenserende teknologi. Disse områder og yderligere kriterier er beskrevet i detaljer i afsnit 4. Generelt kan det siges, at fejlene i løsningen forekommer både i form af redaktionelt indhold, samt som tekniske fejl, der er enten er CMS- eller template baseret. De af de fundne fejl, som er template-baseret, vil i givet fald også forekomme i andre løsninger, hvor denne template benyttes, og vil derfor på lige vis være utilgængelig for en lang række brugere, herunder blinde og svagsynede, samt mennesker med begrænset bevægelighed. Det anbefales derfor, at disse løsninger ligeledes testes og gennemgås for de fundne fejl. 5

3 Metode Formålet med en tilgængelighedstest er dels at afprøve om et netsted er tilgængeligt, dels at identificere konkrete tilgængelighedsproblemer på netstedet. Netstedet er blevet testet i forhold til de internationale retningslinjer for tilgængeligt webdesign fra World Wide Web Consortium (www.w3.org/tr/wcag20). Disse retningslinjer er alment accepterede og anvendes bl.a. som fundament for de danske retningslinjer fra Digitaliseringsstyrelsen (http://www.digst.dk/arkitektur-ogstandarder/standardisering), af EU og af de øvrige EU medlemslande. Tilgængelighedstesten er blevet gennemført af erfarne specialister hos Sensus, som siden 1995 har vurderet netsteder for tilgængelighed. I dette dokument anvendes WCAG 2.0 til at referere til de internationale retningslinjer for tilgængeligt webdesign. Tilsvarende anvendes W3C til at henvise til World Wide Web Consortium. Tilgængelighedstesten omfattede følgende: En komplet manuel analyse af netstedet i forhold til testresultater og tjeklister. Analysen er sket i overensstemmelse med de nationale og internationale retningslinjer for tilgængeligt webdesign. Automatisk validering af netstedet i forhold til de internationale retningslinjer for tilgængeligt webdesign. Validering af koden på netstedet (HTML, XHTML, XML) i forhold til de pågældende specifikationer. Grundlæggende for overholdelse af WCAG gælder det, at man kun ved at anvende teknologier, der understøtter tilgængelighed kan sikre, at succeskriterierne overholdes. Enhver form for information eller funktion, der leveres på en måde, der understøtter tilgængelighed, skal derfor findes også i en version, der understøtter tilgængelighed. Hvis teknologier anvendes på en måde, der understøtter tilgængelighed, eller hvis de anvendes på en måde, der overholder kravene, må de blokere for brugerens mulighed til at få adgang til resten af siden. Netstedet som helhed skal desuden fortsat overholde kravene, når en teknologi, som brugeren er afhængig af, slås til eller fra i browseren eller er understøttet i browseren. Følgende retningslinjer for tilgængelighedstesten: World Wide Web Consortium: Web Content Accessibility Guidelines 2.0 (WCAG 2.0). 2009. Netpublikation: www.w3.org/tr/wcag20/ Nedenstående tabel sammenfatter de anvendte valideringsværktøjer: Værktøj Beskrivelse URL W3C HTML validator AIS Toolbar Firefox Web Developer Extensions Officielt valideringsværktøj fra W3C. Validering i forhold til den angivne HTML og/eller XHTML specifikation. Valideringsværktøj og toolbar, som støtter i tjek for tilgængelighed. validator.w3.org/ http://www.paciellogroup.com/resource s/wat-ie-about.html https://addons.mozilla.org/da/firefox/ad don/5809 https://addons.mozilla.org/da/firefox/ad don/60 ColourChecker Farvekontrastanalyse. Udvidelse til Firefox. Valideringsværktøj og toolbar, som støtter i tjek for tilgængelighed. https://addons.mozilla.org/en- US/firefox/addon/7391/ 6

Værktøj Beskrivelse URL Colour Contrast Analyser Farvekontrastanalyse med pipette. http://www.paciellogroup.com/resource s/contrast-analyser.html Colour Contrast Check Wave SortSite tilgængelighedsmodul fra Electrum Internet Explorer 10 og 11 Farvekontrastanalyse via farvekode (hexkode). Valideringsværktøj og toolbar, som støtter i tjek for tilgængelighed. Valideringsværktøj, som tester netsteder i forhold til de internationale retningslinjer for tilgængeligt webdesign fra W3C. Browser. http://www.snook.ca/technical/colour_c ontrast/colour.html http://wave.webaim.org/toolbar http://www.powermapper.com/ http://www.microsoft.com/windows/do wnloads/ie/getitnow.mspx Firefox 24 Browser. http://www.mozilla.com/en-us/firefox/ Google Chrome 34 Browser. http://www.google.com/intl/da/chrome/ browser/ JAWS 14 Skærmlæserprogram. http://www.freedomscientific.com/down loads/jaws/jaws-downloads.asp 7

4 Detaljeret analyse og vurdering Nedenstående sammenfatter samtlige af de områder, der er omfattet af ekspertvurderingen. For hvert område er eventuelle problemer identificeret og der er angivet forslag til forbedringer og løsninger. Der er angivet eksempler på de enkelte problematr. Disse skal forstås som værende netop eksempler, og andre steder hvor lignende indhold optræder, kan de angivne problematr også gøre sig gældende. Løsningen bør derfor gennemgås for lignende problematr. 4.1 Princip Opfattelig Information og brugergrænsefladekomponenter skal præsenteres for brugere på måder, de kan opfatte. 4.1.1 Retningslinje - tekstlige alternativer Der skal anvendes tekstbaserede alternativer til enhver form for -tekstbaseret indhold, således at det kan ændres til de formater, som brugerne har behov for, f.eks. stor skrift, punktskrift, tale, symboler eller enklere sprog. WCAG 1.1.1 Ikke-tekstbaseret indhold: Alt -tekstbaseret indhold, der præsenteres for brugeren, har tilknyttet et tekstbaseret alternativ, som har samme formål, undtaget nedenstående situationer. Kontroller, input: Hvis -tekstbaseret indhold er en kontrol, eller hvis det accepterer bruger-input, har det et navn, der beskriver dets formål. (Se Retningslinje 4.4.1 vedr. yderligere krav til kontroller samt indhold, der accepterer brugerinput). Tidsafhængige medier: Hvis -tekstbaseret indhold er et tidsafhængigt medie, skal tekstbaserede alternativer som minimum give en beskrivende identifikation af det -tekstbaserede indhold. (Se Retningslinje 4.1.2 for yderligere krav til medier). Test: Hvis -tekstbaseret indhold er en test eller en øvelse, som ville være ugyldig, hvis den blev præsenteret som tekst, skal tekstbaserede alternativer som minimum give en beskrivende identifikation af det -tekstbaserede indhold. Sensorisk: Hvis den primære intention med -tekstbaseret indhold er at skabe en specifik sensorisk oplevelse, skal tekstbaserede alternativer som minimum give en beskrivende identifikation af det -tekstbaserede indhold. CAPTCHA: Hvis formålet med -tekstbaseret indhold er, at indhold anvendes af en person snarere end af en computer, skal der stilles tekstbaserede alternativer til rådighed, som identificerer og beskriver formålet med det -tekstbaserede indhold, og der skal findes alternative former for CAPTCHA, som anvender outputpræsentationer til forskellige typer af sensorisk perception med det formål at imødekomme forskellige handicap. Udsmykning, formatering, usynlig: Hvis -tekstbaseret indhold udelukkende fungerer som udsmykning, hvis det udelukkende anvendes som visuel formatering, eller hvis det præsenteres for brugerne, skal det implementeres på en sådan måde, at det kan ignoreres af kompenserende teknologier. Mange steder findes eksempler på forkert brug af alternative tekster til billeder. Alle grafiske elementer skal have et alt-tag tilknyttet. Der skal dog kun være indhold i alt-tagget, såfremt at billedet eller det grafiske element har et formål, som derfor skal beskrives for brugeren. Eksempelvis at billedet linker eller at det præsenterer en væsentlig sensorisk oplevelse eller stemning for brugeren. 8

WCAG 1.1.1 Ikke-tekstbaseret indhold: Der er her tale om billeder som har en alt-tekst med en meget lidt sigende alternativ beskrivelse. En alt-tekst skal kunne stå i stedet for billedet. For eksempelvis en blind bruger som benytter sig af talesyntese, vil en beskrivelse/alternativ tekst som ny hjemmeside, for et afsnit som hedder problemer med at reservere, være dækkende. Da billedet er illustrativt kan der i dette tilfælde benyttes en tom alt-tekst alt=. En talesyntese vil herefter ignorere billedet, hvilket giver god mening med en billedtung hjemmeside da det kan tage lang tid for en talesyntese at oplæse en hel side. Såfremt at alt-tekst og den efterfølgende link tekst er den samme, vil brugeren opleve oplæsningen som gentagelse. (et enkelt tilfælde) Fjern alt-teksten såfremt at billede og link er sammensat. Derved benyttes linkteksten. Figure 1: Skæve alt-tekster 2 Figure 2:Ekko ved oplæsning. De beskrevne fremgangsmåder for korrekt brug af alt-tags gør sig naturligvis gældende i hele løsningen. 4.1.2 Retningslinje - Tidsafhængige medier Der skal leveres alternativer til tidsafhængige medier. WCAG 1.2.1 Rent lydindhold (audio only) og rent videoindhold (video only) (forudindspillet): For forudindspillet rent lydindhold og forudindspillet rent videoindhold gælder følgende, undtagen når video eller lyd udgør et mediealternativ til tekst og klart er markeret som sådan: 9

WCAG 1.2.1 Rent lydindhold (audio only) og rent videoindhold (video only) (forudindspillet): Forudindspillet rent lydindhold: Der skal leveres et alternativ til tidsafhængige medier, som præsenterer information, der svarer til forudindspillet rent lydindhold. Forudindspillet rent videoindhold: Der skal leveres enten et alternativ til tidsafhængige medier eller et lydspor, som præsenterer information, der svarer til forudindspillet rent videoindhold. Der er fundet rent lydindhold eller rent videoindhold i løsningen. WCAG 1.2.2 Undertekster (forudindspillet): Der skal leveres undertekster til alt forudindspillet lydindhold i synkroniserede medier, undtaget når medier fungerer som medie-alternativ til tekst og er klart markeret som sådan. Der er tilknyttet undertekster til filmene i løsningen, og løsningen lever derfor op til dette succeskriterium. Undertekster benyttes blandt andet af døve til at få den information, som de ellers ville gå glip af. Figure 3: Skærmbillede af video element i løsningen Undertekster skal kun forstås som en tekstudgave af det talte. Det bør ligeledes indeholde navn på eksempelvis personen der taler, eventuelle lydeffekter samt andre elementer i lydbilledet. 10

WCAG 1.2.3 Synstolkning eller mediealternativ (forudindspillet): Der skal leveres et alternativ til tidsafhængige medier eller synstolkning af forudindspillet videoindhold i synkroniserede medier, undtagen når medierne er mediealternativ til tekst og er klart markeret som sådan. For at overholde dette succeskriterium er det nødvendigt at give blinde og svagsynede adgang til den visuelle information de ellers ville gå glip af. Der er to muligheder for at overholde dette succeskriterium. Første mulighed er at lave en synstolkning af filmklippet, dvs. at der bliver indsat et lydspor, hvor der indtales de nødvendige elementer fra billedet. Dette gøres normalt i talepauser i det eksisterende filmklip. Informationsmæssigt er der tale om eksempelvis; personer i billedet, sceneskift, og tekst som kan ses visuelt, men som bliver nævnt på anden vis. Den anden mulighed er at give adgang til al information i tekstform, både lydbilledet og det visuelle fra filmklippet. Det vil her være muligt at være mere uddybende end ved synstolkning, da der er en begrænsning i form af talepauser til den ekstra information. WCAG 1.2.4 A Undertekster (live): Der skal leveres undertekster til alt lydbaseret live-indhold i synkroniserede medier. Der er fundet live-indhold i løsningen. WCAG 1.2.5 A Synstolkning (forudindspillet): Der skal leveres synstolkning til alt forudindspillet videoindhold i synkroniserede medier. Dette succeskriterium er nær identisk med 1.2.3. Der skal laves synstolkning af film benyttet i løsningen, i givet fald brugeren går glip af visuelt indhold. Dette betyder at der skal indsættes et lydspor hvor der indtales de nødvendige elementer fra billedmaterialet i filmen. Dette gøres normalt i talepauser i det eksisterende filmklip. Informationsmæssigt er der tale om eksempelvis; personer i billedet, sceneskift, og tekst som kan ses visuelt, men som bliver nævnt på anden vis. I dette succeskriterium er der mulighed for at anvende andet alternativ i tekstform som i succeskriterium 1.2.3. Et problem med valget af YouTube, som er den nuværende afspiller i løsningen, er at det er muligt at slå synstolkning til eller fra. Der skal i løsningen således henvises til to forskellige film, alt efter om brugeren vil benytte synstolkning eller ej. 11

4.1.3 Retningslinje - Tilpasset Indhold skal udformes, så det kan præsenteres på forskellige måder (for eksempel med enklere layout), uden at information og struktur går tabt. WCAG 1.3.1 Information og relationer: Information, struktur, og relationer der formidles via præsentationen, kan bestemmes programmeringsmæssigt eller er tilgængelige som tekst. Dette succeskriterium dækker en række områder: For tekst gælder det, at man eksempelvis bruger <a>-tags til links, <strong> eller <em> til fremhævet tekst og <q> eller <blockquote> til citater. Man skal adskille præsentation og indhold, eksempelvis ved at anvende stylesheets til al præsentation. Det gælder at bruger man farve til at angive, hvad som er obligatoriske at udfylde af felter i en formular, skal dette også angives med fremhævet tekst. Man skal angive strukturer i tabeller eksempelvis ved at angive hvad som er overskrifter i tabeller og en beskrivelse af en given tabel (eksempelvis ved at anvende <th> til tabel-overskrifter og <caption> til beskrivelse, i en simpel datatabel). Knyt etiketter eksplicit til kontroller i formularer, eksempelvis ved at anvende <label>tags og gruppér sammenhørende kontroller (som eksempelvis radioknapper) under <fieldset> og <legend>. Angiv kodemæssig struktur til lister eksempelvis ved brug af <ol> og <ul>. Sørg for at sider er inddelt med overskrifter ved hjælpe af headings (H-tags) og angiv dem i en hierarkisk struktur. Der er i løsningen fundet problemer ved overholdelse af dette succeskriterium. Generelt er brugen af headings korrekt, og løsningen bør gennemgås for dette. Derudover er fundet andre enkeltstående problematr som videre beskrevet herunder. Heading rækkefølge En side bør altid starte med en heading 1, (H1). Det er derudover nødvendigt at holde en korrekt nestet struktur. I nedenstående figur springes niveau 1 over, og denne del af dette succeskriterium fejler dermed. 12

WCAG 1.3.1 Information og relationer: Figure 4: Liste over overskriftsstruktur på forsiden For at leve op til denne del af dette succeskriterium bør der springes over niveauer. Der er på forsiden benyttet en H1, som ellers giver skærmlæserbrugere indikation af indholdet, som seende kan få ved et kort blik på skærmen. Visuelle overskrifter Hvor tekst visuelt fremhæves som en overskrift og inddeler sidens indhold, skal dette også gøres strukturelt. I løsningen findes en problemer med visuelle headings. Figur 5 viser et eksempel fra sidemenuen, hvor hovedelementer (forfatter og materialetype) på siden visuelt fremstår som overskrifter, men er angivet som sådan strukturelt. Figure 5: Eksempel på manglende opmærkning af overskrifter Flere steder mangler opmærkning af underoverskrifter i løsningen. Disse tekster vil derfor fremgå for en skærmlæserbruger som overskrifter. Overskrifter benyttes til at springe mellem afsnit, samt danne overblik over indhold især af personer der benytter kompenserende teknologi. Det bør derfor sikres, at tekst som benyttes som overskrifter markeres i koden som en heading(overskrift). Dette gør sig gældende for hele løsningen, hvor visuelle overskrifter benyttes. 13

WCAG 1.3.2 Meningsfuld rækkefølge: Når den rækkefølge, som indhold præsenteres i, påvirker indholdets mening, kan en korrekt læserækkefølge bestemmes programmeringsmæssigt. Rækkefølgen af indholdet i løsningen synes generelt at være fornuftig. WCAG 1.3.3 Sensoriske egenskaber: Instruktioner, der vedrører forståelse og betjening af indhold, er udelukkende afhængige af komponenternes sensoriske egenskaber såsom form, størrelse, visuel placering, orientering eller lyd. Der benyttes termologi som til højre eller lign. 4.1.4 Retningslinje Adskillelig Det skal gøres lettere for brugere at se og høre indhold, herunder at adskille forgrunden fra baggrunden. WCAG 1.4.1 Anvendelse af farve: Farve er det eneste visuelle middel, der anvendes til at formidle information, gøre opmærksom på en handling, anmode om respons eller udskille et visuelt element. Links midt i en sætning som kun er indikeret med farve, kan give problemer for farveblinde. Figure 6: Eksempel på brug af farve som eneste indikation på link Dette er tilfældet gennemgående i løsningen. Ved brug af henvisninger til sensoriske egenskaber skal det kombineres med henvisning til overskrifter eller linknavne. På denne vis vil brugere der benytter skærmlæsere ligeledes have mulighed for at finde elementerne der henvises til.der findes en række andre eksempler i løsningen på samme problematik. Især er det problematisk når en linktekst står midt i en større tekstmængde, som herunder hvor teksten Metodevejviseren er et link: Dette kan være et problem for mennesker med farveblindhed samt svagsynede. Det bør sikres, at der på anden vis gøres opmærksom på hvilke dele af løsningen der linker, eksempelvis ved brug af ikoner, knapper eller understregning af den pågældende tekst. Her er brug af understregning ved mouse-over en tilstrækkelig løsning. 14

WCAG 1.4.2 Kontrol af lyd: Hvis eventuel lyd på en webside spiller automatisk i mere end tre sekunder, skal der enten være en mekanisme, som kan anvendes til at afbryde lyden helt eller midlertidigt, eller der skal findes en mekanisme, som kan regulere lydstyrken uafhængigt af systemets generelle lydniveau. Der er fundet lyd i løsningen, der går i gang af sig selv og som kan pauses. WCAG 1.4.3 A Kontrast (minimum): Den visuelle præsentation af tekst og billeder af tekst skal have et kontrastforhold på mindst 4,5:1, undtagen i følgende situationer: Stor skrift: Tekst og billeder af tekst i stor skrift har et kontrastforhold på mindst 3:1; Ikke betydningsbærende: Tekst eller billeder af tekst, der udgør en del af en interaktiv brugergrænsefladekomponent, som udelukkende er ren udsmykning, som er synlig for nogen, eller som udgør en del af et billede, der indeholder andet væsentligt visuelt indhold, er underlagt et kontrastkrav. Logotyper: Tekst, der udgør en del af et logo eller varemærkenavn er underlagt et kontrastkrav. Kontrastforholdet mellem tekst og baggrund har problemer flere steder. Dette sker ved menupunkt samt ofte hvor der er tale om et link. Figure 7: Svag kontrast på menu Den sekundærer topmenu( markeret tekst) har et kontrast niveau på 3 : 1 og er på 12pt. Forholdet for almindelig tekst bør være minimum 4,5:1. Forholdet for stor tekst (14pt fed eller større, 18pt eller større) bør være minimum 3:1. Teksten optræder som almindelig tekst og overholder derfor gældende retningslinjer. Dette vil være et pro- Figure 8: Testværktøj viser svag kontrast ved den blå farve 15

WCAG 1.4.3 A Kontrast (minimum): blem alle steder hvor samme fontfarve og størrelse er benyttet. Der er ligeledes problemer med den blå linkfarve, især den som har fokus. skærmbillede her af vores testværktøj hvor værdierne er tastet ind viser hvor denne fejler. I dette tilfælde fejler den uanset om der er tale om stor eller lille font størrelse. Såfremt der er fokus på linket med mus, så overholder den mørkere blå nuance dette succeskriterie. Figure 9: Grøn farve(link) fejler kontrast test Figur 9 viser ligeledes en kontrast fejl på det grønne link. Dette sker også for den gule farve som også benyttes til visse links. WCAG 1.4.4 A Ændring af tekststørrelse: Tekst kan, med undtagelse af undertekster og billeder af tekst, forstørres op til 200 % uden brug af kompenserende teknologi uden tab af indhold eller funktion. Løsningen kan forstørres op til 200% med zoomfunktionen i browseren uden at det går ud over indhold eller funktion, og lever derfor op til dette succeskriterium. At overholde dette succeskriterium gavner især mennesker med nedsat syn, som har behov for at forstørrer tekst for at kunne læse den. Ved 200% zoom af løsningen slår den over til anden fremvisning. 16

WCAG 1.4.4 A Ændring af tekststørrelse: Figure 10: Denne præsentation sker ved 200% zoom Dette er potentielt et problem for svagsynede som ofte benytter en zoom kraftigere end 200%. Skiftet bør optræde ved brug af mobil platform i stedet for på opløsning, eller ved at bruger opt-out af denne funktion. WCAG 1.4.5 A Billeder af tekst: Hvis de anvendte teknologier kan håndtere den visuelle præsentation, anvendes tekst frem for billeder af tekst til formidling af information, undtagen i følgende tilfælde: Kan tilpasses: Billedet af tekst kan tilpasses visuelt til at imødekomme brugerens krav; Nødvendig: En særlig præsentation af tekst er nødvendig for den information, der formidles. Note: Logotyper (tekst, der udgør en del af et logo eller varemærkenavn) opfattes som nødvendig. Der er fundet grafisk tekst i løsningen, ud over tekst som er inkluderet i en form for logo. Løsningen lever således op til dette succeskriterium. 17

4.2 Princip 2: Anvendelig Brugergrænsefladekomponenter og navigation skal kunne anvendes. 4.2.1 Retningslinje - Tilgængelig via tastatur Alle funktioner skal kunne benyttes via et tastatur. WCAG 2.1.1 Tastatur: Alle indholdets funktioner kan betjenes via en tastaturgrænseflade uden at der er behov for specifik tidsindstilling af individuelle tastetryk, undtaget tilfælde, hvor den underliggende funktion kræver input, der er afhængige af at kunne følge hele rækken af brugerens bevægelser og blot slutpunkterne. For at overholde dette succeskriterie skal det være muligt at kunne navigere i hele tjenesten uden brug af mus. Løsningen er tilgængelig via tastatur i det meste af løsningen. Der er dog et problem med kalender funktionen som kan benyttes, dog kan der manuelt indtastes værdier. Figure 11: Denne kalender kan findes under "min konto", "rediger brugerprofil" Såfremt at kalender funktionen ses som alternativ til almindelig indtastning, kan dette anses som overholdt. 18

WCAG 2.1.2 Ingen tastaturfælde: Hvis tastaturfokus kan flyttes til en af sidens komponenter ved hjælp af en tastaturgrænseflade, kan fokus fjernes fra denne komponent udelukkende ved hjælp af en tastaturgrænseflade. Hvis det kræver mere end utilpassede pile- eller tab-taster eller andre standard lukkemetoder, skal brugeren rådgives om metoden til at fjerne fokus. Der er fundet tastaturfælder, og løsningen overholder derfor dette succeskriterium. 4.2.2 Retningslinje - Passende tid Giv brugerne tilstrækkelig tid til at læse og anvende indhold. WCAG 2.2.1 Passende tid For hver tidsbegrænsning, der er givet i indholdet, gælder mindst et af følgende punkter: Slå fra: Brugeren kan slukke for tidsbegrænsningen, før den udløber; eller Tilpasse: Brugeren kan tilpasse tidsbegrænsningen, før den udløber, over en bred skala, der er mindst ti gange varigheden af standardindstillingen; eller Udvide: Brugeren advares, før tiden udløber, og får mindst 20 sekunder til at forlænge tidsbegrænsningen ved hjælp af en simpel handling (for eksempel tryk på mellemrumstasten ), og brugeren har mulighed for at forlænge tiden mindst ti gange; eller Undtagelse ved real-time: Tidsbegrænsningen er en nødvendig del af en begivenhed i real-time (for eksempel en auktion), og der findes noget muligt alternativ til tidsbegrænsningen; eller Nødvendig undtagelse: Tidsbegrænsningen er nødvendig, og en forlængelse vil gøre handlingen ugyldig; eller 20 timers undtagelse: Tidsbegrænsningen varer længere end 20 timer. Det er fundet tidsbegrænsninger i løsningen. WCAG 2.2.2 Pause, stop, skjul: Ved bevægelse, blinken, rulning eller automatisk opdatering af information gælder samtlige følgende punkter: Bevægelse, blinken, rulning (scrolling): Ved enhver form for bevægelse, blinken eller rulning (scrolling) af information, der (1) starter automatisk, (2) varer mere end 5 sekunder og (3) præsenteres samtidigt med andet indhold, findes der en mekanisme, så brugeren kan stoppe skjule eller sætte informationen på pause, medmindre bevægelsen, blinket eller rulningen (scrolling) er en del af en handling, hvor dette er nødvendigt; og Automatisk opdatering: Ved enhver form for automatisk opdatering af information, der (1) starter automatisk og (2) præsenteres samtidigt med andet indhold, findes der en mekanisme, som gør det muligt for brugeren kan stoppe skjule eller sætte opdateringen på pause, eller at kontrollere opdateringsfrekvensen, medmindre den automatiske opdatering er en del af en aktivitet, hvor dette er nødvendigt. 19

WCAG 2.2.2 Pause, stop, skjul: Der er fundet indhold i løsningen der automatisk opdaterer. 4.2.3 Retningslinje - Anfald Indhold må designes på en måde, der vides at kunne forårsage (epileptiske) anfald. WCAG 2.3.1 Grænseværdi på tre glimt eller derunder: Intet indhold på en webside glimter mere end tre gange på et sekund, eller glimtet ligger under grænseværdien for generelt glimt og rødt glimt. Der er fundet indhold, der glimter. Løsningen lever derfor op til dette succeskriterium. 4.2.4 Retningslinje - Navigerbar Brugerne skal hjælpes med at navigere, finde indhold og afgøre, hvor de befinder sig. WCAG 2.4.1 Spring over blokke: Der findes en mekanisme til at springe over blokke af indhold, der gentages på flere websider. Dette succeskriterium er overholdt, da der er er implementeret en mulighed for at springe over menuen. Dette bør der være såfremt at en struktur gentages i gennem løsningen som er placeret over indhold. Eksempelvis navigation og menu struktur. Der bør som minimum være et hop til hovedindhold link. Disse er typisk lavet som skjulte links. Da der findes iframes (youtube videoer)i løsningen skal disse have en title beskrivelse for at give brugeren mulighed for at springe over uinteressant indhold. I løsningen har iframes en title. Dette succeskriterium fejler derved. Iframes i løsningen forekommer ved YouTube filmklip. Se mere om dette i afsnit 4.1.2. 20

WCAG 2.4.2 Sider har titler: Websider har titler, der beskriver emne eller formål. Der er anvendt fornuftigt formulerede og specif titler i løsningen, der beskriver den enkelte sides emne eller formål for brugeren. Løsningen lever derfor op til dette succeskriterium. WCAG 2.4.3 Fokusrækkefølge: Hvis der kan navigeres sekventielt på en webside, og hvis navigationssekvenserne påvirker mening eller betjening, skal fokuser bare komponenter opnå fokus i en rækkefølge, der bevarer meningen eller betjeningsmulighederne. Tabuleringsrækkefølgen i løsningen forekommer logisk i det meste af løsningen, der er dog et problem som opstår hver gang der er valgt et filter i søgeresultaterne. Fokus hopper væk fra menuen og ud til det valgte indhold. Da der er menupunkter med underpunkter giver dette et problem da eksempelvis skærmlæserbrugere opdager at der var underpunkter til stede. Løsningen lever dog op til dette succeskriterium da der er mere tale om gene, end et egentlig brud. Figure 12: Fokusrækkefølge ved søgning Når et filtervalg er foretaget, så skal der tabuleres til denne igen for at foretage endnu filtervalg. Såfremt at der fremvises 10 søgeresultater er der tale om 40 tabuleringer. Hvert resultat giver 3-4 tabuleringer ekstra. Brugere som kan benytte mus, vil se dette som særdeles tidskrævende. Der bør implementeres access-keys således at der kan hoppes til relevante områder. 21

WCAG 2.4.4 Formål med links (i kontekst): Formålet med ethvert link kan bestemmes ud fra link-teksten alene eller ud fra linkteksten sammen med den link-kontekst, der er programmeringsmæssigt bestemt; undtaget herfra er tilfælde, hvor linkets formål vil forekomme flertydigt for alle brugere. Det bør sikres, at formålet med ethvert link i løsningen kan bestemmes ud fra dens link-tekst. Et enkelt sted er der dog et eksempel på en linktekst, som er problematisk, hvis denne ses uden for kontekst: Figure 13: Eksempel på en -unik link som relatere sig ti lomkransende tekst Link-teksten Læs mere giver information til brugeren om linkets funktion. En skærmlæserbruger vil liste alle links for at få overblik og her kan den omkransende tekst ses. En undtagelse er dog hvis link og følgetekst er i samme afsnit, så kan sammenhængen accepteres. Dette er tilfældet i løsningen hvorfor løsningen overholder succeskriteriet WCAG 2.4.5 A Flere måder: Der findes mere end en måde at lokalisere en webside på inden for en samling af websider. Undtaget er tilfælde, hvor websiden udgør et resultat af eller et trin i en proces. Der findes flere måder at lokalisere en webside på i løsningen, idet der findes et globalt søgefelt. Løsningen lever således op til dette succeskriterium. 22

WCAG 2.4.6 A Overskrifter og ledetekster: Overskrifter og ledetekster beskriver emne eller formål. Der er generelt i løsningen fornuftigt formulerede overskrifter og ledetekster, hvor de benyttes. Overskrifter i løsningen er dog et par steder strukturelt mærket korrekt op, idet der forekommer visuelle overskrifter. Dermed lever netstedet op til dette succeskriterium. Se 1.3.1 for yderligere om denne problematik. WCAG 2.4.7 A Synligt fokus: Enhver tastaturbetjent brugergrænseflade har en betjeningstilstand, hvor tastaturfokusindikatoren er synlig. Der forekommer steder i løsningen hvor fokus er synligt. Dermed lever netstedet op til dette succeskriterium. I toppen af løsningen i søg, Min konto samt log ud funktionen kan fokus ses ved tabulering igennem disse elementer. Figure 14: Elementer som viser fokus ved tabuleringen Manglende brug af synligt fokus gør det vanskeligt at benytte tastatur til navigation. Det bør derfor sikres, at der er synligt fokus alle steder i løsningen. 4.3 Princip 3: Forståelig Information og betjening af brugergrænsefladen skal være forståelig. 4.3.1 Retningslinje - Læselig Tekstbaseret indhold skal gøres læseligt og forståeligt. WCAG 3.1.1 Sproget på siden: Det menneskelige standardsprog for hver side kan bestemmes programmeringsmæssigt. Alle sider i løsningen synes programmeringsmæssigt at være sat til dansk, og den lever derfor op til dette succeskriterium. I givet fald der laves en engelsksproget del af løsningen bør det sikres, at denne del ligeledes programmeringsmæssigt er sat til engelsk. Korrekt sprogmarkering i koden er afgørende for, at indholdet bliver forståeligt for en skærmlæserbruger, da dette afgør hvilket sprog teksten 23

WCAG 3.1.1 Sproget på siden: bliver læst op på. WCAG 3.1.2 A Sprog, der anvendes til dele af indhold: Det menneskelige sprog, der anvendes i hver passage eller frase i indholdet, kan bestemmes programmeringsmæssigt; undtaget herfra er egennavne, tekniske termer, ord med ubestemmeligt sproglig baggrund samt ord eller vendinger, der er blevet en del af sprogbrugen i den tekst, de umiddelbart indgår i. Der forekommer dele af indhold på andet sprog end dansk som er opmærket korrekt. Løsningen lever derfor op til dette succeskriterium. Der er her tale om en Engelsk del oversættelse. 4.3.2 Retningslinje - Forudsigelig Websider skal præsenteres og fungere på forudsigelige måder. WCAG 3.2.1 I fokus: Når en komponent kommer i fokus, medfører dette en ændring af kontekst. Der forekommer ændringer af kontekst ved skiftende fokus. WCAG 3.2.2 Ved input: Ændring af indstillingerne i en hvilken som helst brugergrænsefladekomponent medfører automatisk ændring af kontekst, medmindre brugeren er blevet advaret herom, inden komponenten anvendes. Der forekommer ændringer af kontekst ved input. WCAG 3.2.3 A Konsekvent navigation: Navigationsmekanismer, der gentages på flere websider inden for en samling af websider, skal optræde i samme relative rækkefølge, hver gang de gentages, medmindre brugeren selv foretager en ændring. Navigationen optræder i samme rækkefølge på alle sider, og løsningen lever derfor op til dette succeskriterium. 24

WCAG 3.2.4 A Konsekvent identifikation: Komponenter med samme funktion inden for en række websider skal defineres konsekvent. Generelt synes identifikationen af komponenter med samme funktion at være konsistent i løsningen. 4.3.3 Retningslinje - Inputhjælp Brugere skal have hjælp til at undgå og rette fejl. WCAG 3.3.1 Identifikation af fejl: Hvis en inputfejl registreres automatisk, skal det fejlbehæftede element identificeres, og fejlen beskrives for brugeren ved hjælp af tekst. Der er fundet brug af formularfelter med automatisk registrering af inputfejl i løsningen. WCAG 3.3.2 Ledetekster eller instruktioner Der findes ledetekster eller instruktioner, når indhold kræver brugerinput I løsningen forekommer ingen eksempler på manglende ledetekst ved formularfelter i forbindelse med et søgefelt. Løsningen lever dermed op til dette succeskriterium. Såfremt dette mangler kan det være et problem for brugere som eksempelvis anvender skærmlæser og samtidig skal være sikre på, hvad som skal indtastes. WCAG 3.3.3 A Fejlforslag: Hvis en inputfejl registreres automatisk, og der findes forslag til retning af fejlen, skal forslagene præsenteres for brugeren, medmindre dette ville undergrave srheden eller indholdets formål. Der er fundet brug af formularfelter med automatisk registrering af inputfejl i løsningen. WCAG 3.3.4 A Forhindring af fejl (juridisk, økonomisk, data): For websider, som medfører juridiske forpligtelser eller økonomiske transaktioner for brugeren, som tilpasser eller sletter data, som kan kontrolleres af brugeren i datalagringssystemer, eller som afleverer svar på test udført af brugeren, skal mindst et af følgende 25

WCAG 3.3.4 A Forhindring af fejl (juridisk, økonomisk, data): punkter gælde: 1. Reversibel: Det sendte er reversibelt. 2. Tjek: Data, der indtastes af brugeren, tjekkes for inputfejl, og brugeren får mulighed for at rette fejlene. 3. Bekræftelse: Der findes en mekanisme som gør det muligt at gennemse, bekræfte eller rette information, før forsendelsen afsluttes. Det er muligt at forpligtige sig juridisk på webløsningen. Løsningen lever dermed op til dette kriterium. 4.4 Princip 4: Robust Indhold skal være robust nok til at kunne anvendes på stabil vis af en bred vifte af brugeragenter, herunder kompenserende teknologier. 4.4.1 Retningslinje - Kompatibel Kompatibilitet med nuværende og fremtidige brugeragenter, herunder kompenserende teknologier, skal maksimeres. WCAG 4.1.1 Parsing: I indhold, der er implementeret ved hjælp af markup-sprog, har elementer afsluttede start- og slut-tags, elementer er nestet efter deres specifikationer, de indeholder attribut-dubletter og ID er er un; undtaget herfra er tilfælde, hvor specifikationerne tillader disse funktionaliteter. Det er fundet brud på dette succeskriterium. Det bør dog også fremadrettet sikres, at der i løsningen gøres brug af un ID'er, samt at der benyttes korrekt brug af start og slut tags, idet manglen kan betyde at løsningen vises på samme vis i forskellige browsere eller enheder, og især kan skabe problemer for kompenserende teknologier. WCAG 4.1.2 Navn, rolle, værdi: For alle brugergrænsefladekomponenter (herunder, men alene formularelementer, links og komponenter, der er genereret via scripts) gælder det, at navn og rolle kan bestemmes programmeringsmæssigt. Tilstande, egenskaber og værdier, der kan indstilles af brugeren, kan indstilles programmeringsmæssigt, og besked om ændringer i disse elementer kan tilgås af brugeragenter, herunder kompenserende teknologier. Iframes i løsningen har en title beskrivelse, hvilket er et brud på dette succeskriterium. I koden ser iframen eksempelvis således ud: <p><iframe allowfullscreen="" frameborder="0" height="315" src="//www.youtube.com/embed/aoxrywlnsbu" width="420"></iframe></p> 26

WCAG 4.1.2 Navn, rolle, værdi: Dette relaterer sig til samme problematik som er beskrevet i punkt 2.4.1. 27