Aula og webtilgængelighed

Da de fleste danske skoleelever kom tilbage fra efterårsferien sidste år, var der sket en markant ændring i deres, lærernes og forældrenes hverdag: Aula havde erstattet Skoleintra — en længe ventet ændring.

Vi har kradset lidt (meget lidt!) i overfladen af Aula, for at se hvordan opgaven er løst i forhold til et af Shifts primære fokusområder, webtilgængelighed. Det skyldes naturligvis en faglig interesse og en passion for området, men også at Aula er en offentlig platform og derfor SKAL leve op til WCAG AA standarden, for at alle borgere kan bruge den, uanset eventuelle fysiske og psykiske lidelser. Efter lidt gravearbejde fandt vi frem til noget af det oprindelige udbudsmateriale (kan findes her: https://kombit.dk/review-samarbejdsplatform), hvor der i bilag 2.1 (“Kravspecifikation”) under punkt 6.3.4 (“Tilgængelighed”) står følgende:

Udbudsmaterialet kan naturligvis være ændret og ting kan have ændret sig, men den danske lov om webtilgængelighed, der blev vedtaget i juni 2018 og trådte i kraft i september samme år, kræver at alle offentlige websteder, der er udgivet efter 23. september 2019 skal leve op til standarden, og derfor kan der ikke herske nogen tvivl om at Aula skal være tilgængeligt — og vi kan da heller ikke forestille os mange andre sites, hvor det giver bedre mening, end Aula, der bruges af over 2 mio. danskere og har så vigtig en funktion i vores samfund, som at understøtte vores uddannelsessystem.

Og som de fleste nok har gættet, så lever Aula ikke op til standarden. Når vi i vores indledning skrev, at vi havde kradset i overfladen, så mente vi faktisk lige præcis det, idet vi kun har kigget på forsiden af Aula, altså den, der ser sådan her ud:

Der er tale om en helt simpel side, der grundlæggende består af et link (“Vil du vide mere om Aula”) og tre knapper (“Forælder”, “Barn”, “Medarbejder”). Hvis man kører en automatiseret tilgængelighedstest på den side, så viser resultatet at der blot er én fejl, der har en effekt på tilgængeligheden:

1. Det skal være muligt for en bruger at zoome ind og forstørre tekst, men det er på Aula blevet slået fra. Her er der tale om punkt 1.4.4 i standarden.

Det lyder jo ikke af meget, men én ting man skal huske på, er at automatiserede tilgængelighedstests i praksis kun kan teste 30–40% af de ialt 50 kriterier, der findes i specifikationen.

En af de manuelle tests, som det er nemmest at gennemføre, og ofte er en af dem, der giver mest bang for the buck, er om en side kan bruges udelukkende vha. et keyboard. Her dumper Aula, idet de fejler på det kriterie, der hedder 2.1.1. Når et site ikke lever op til 2.1.1 kriteriet, skyldes det som oftest en af to ting:

1. Den visuelle indikator af hvilket element, der er i fokus, er blevet fjernet af æstetiske årsager.
2. Der er ikke brugt semantisk HTML, dvs. at der f.eks. ikke er brugt en knap til et element, der fungerer som en knap, men i stedet er blevet lagt ekstra funktionalitet på en anden type element.

I Aulas tilfælde er det en kombination af de to faktorer. De tre knapper er nemlig slet ikke knapper, men derimod et HTML-element, der ikke besidder nogen egenskaber i sig selv, men har fået pålagt nogle ekstra egenskaber af udvikleren. Her bliver det faktisk lidt interessant (og måske lidt nørdet), for når man kigger på koden, kan man se, at der rent faktisk er blevet forsøgt at gøre elementet tilgængeligt. Den interessante del af HTML-koden ser således ud:

<div tabindex="0" role=”button”>...</div>

Den kode kunne i stedet være skrevet således:

<button>...</button>

Den del af koden, hvor der står tabindex="0" gør at elementet kan få fokus vha. et keyboard, og dermed i teorien bruges vha. keyboardet. role="button" gør at elementet eksponeres for f.eks. en skærmlæser som en knap, og dermed vil “den falske knap” fungere, når der er tilføjet det JavaScript, der får den til at eksekvere sin funktionalitet — det rigtige knap-element kræver også JavaScript for at fungere, så på den måde kan man sige at alt burde være i orden. Sådan forholder det sig dog ikke, for udvikleren har bl.a. tilføjet følgende i CSS-koden (som er den kode, der styrer design og layout):

div:focus {
  outline: 0;
}

Og lige præcis den kode fjerner den visuelle indikator², der gør det synligt (bogstaveligt talt) for brugere, der kigger på skærmen og benytter keyboardet. Dvs. at man kan sidde og bruge sin tabulator-tast lige så flittigt man vil, men man kan simpelthen ikke se, hvilken knap, man eventuelt vælger at trykke på. Årsagen til, at den visuelle indikator ofte bliver fjernet, er som regel, at nogen synes den ikke matcher designets æstetiske udtryk eller at designeren har udeladt at designe, hvordan elementet skal se ud, når det er i fokus.

Vores tese er at udvikleren, der har lavet ovenstående, har draget en konklusion, som mange ofte drager, nemlig at de brugere, der benytter keyboard til navigation, er de samme brugere som benytter skærmlæsere, dvs. primært svagtseende og blinde. For en bruger af skærmlæseren vil “knapperne” nemlig fungere og give mening, mens det for brugere, der benytter en kombination af tastatur og skærm, ikke vil virke.

Det er vigtigt for os at pointere, at når vi sætter os til tastaturet og skriver sådan en smøre her, så er det ikke for at hænge nogen ud, og præcis derfor har vi valgt ikke at nævne navnet på udviklingsfirmaet, der har lavet Aula. Vi synes dog at kunden, i dette tilfælde KOMBIT, burde kræve af deres leverandører, at leverancen lever op til både udbuddet og lovgivningen. Ikke mindst fordi det er skatteborgernes penge, der er brugt på projektet. Desværre er det også ofte sådan, at det er op til kunden selv, at teste om, de har fået det, de har betalt for, og lige præcis tilgængeligheden bliver ofte glemt til fordel for funktionelle tests, der foretages af folk uden indsigt i hvordan brugere med funktionsnedsættelser benytter internettet.

Vores pointe er en anden og langt vigtigere, nemlig at webtilgængelighed til stadighed og til trods for både lovgivning og langt større bevågenhed, fortsat er en disciplin indenfor webdesign og udvikling, der ikke tages alvorligt nok, men nærmest altid er en eftertanke og har laveste prioritet.

Det er en skam, og noget vi i Shift hver dag kæmper for at ændre på, uanset hvilken type projekt vi er på, for i bund og grund ved vi at god tilgængelighed gavner alle, ikke blot den del af befolkningen, der lever med permanente funktionsnedsættelser. Keyboard-navigation kan f.eks. være meget brugbar, hvis ens mus holder op med at fungere eller løber tør for batteri.

Skal vi ikke være enige om at 2020 bliver året, hvor vi alle sammen giver den en ekstra skalle og forbedrer tilgængeligheden på de projekter, vi arbejder på — og hvis det virker uoverskueligt eller svært, så ring til os på 70 99 07 55 eller skriv til Kim på kim@shift.dk, så skal vi nok give en hjælpende hånd på den ene eller den anden måde. Så lover vi også at fortælle lidt om hvorfor webtilgængelighed ikke blot handler om at hjælpe brugere med funktionsnedsættelser, men rent faktisk er en god forretning.

1. WCAG versionen er siden dette udbudsmateriale blev skrevet blevet opgraderet fra version 2 til 2.1, hvilket skete i juni 2018.
2. Indikatoren vises i Chrome-browseren som en blå ring rundt om elementet, der er i fokus, imens den i f.eks. Firefox vises som en stiplet linje.