# Webtilgængelighed ## Hvad det er Webtilgængelighed er, hvor godt et website, en app eller et værktøj fungerer for mennesker med handicap. W3C's Web Accessibility Initiative (WAI) definerer begrebet ud fra, hvad folk kan gøre: opfatte, forstå, navigere og interagere med nettet og bidrage til det. Det sidste verbum vejer tungt. Et site, hvor en blind besøgende kan læse hver artikel, men hverken kan skrive en kommentar, uploade en fil eller gennemføre en tilmelding, opfylder kun halvdelen af definitionen. På engelsk forkortes ordet ofte a11y, hvor tallet tæller de elleve bogstaver mellem a og y. Omfanget er ethvert handicap, der påvirker adgangen til nettet. WAI nævner auditive, kognitive, neurologiske, fysiske, tale- og synsmæssige handicap, og hver gruppe møder sine egne barrierer: video uden undertekster, instruktioner, der hviler på hukommelsen, bevægelse, der udløser symptomer, kontroller, der kræver en rolig hånd og en mus, stemmestyring, der forventer flydende tale, og tekst, der kun fungerer i én størrelse og med én kontrast. Under den synlige side bygger browseren en anden struktur til hjælpemidlerne. ARIA-specifikationen kalder den tilgængelighedstræet: et træ af tilgængelige objekter, hvor hver knude repræsenterer et element i brugerfladen, for eksempel en trykknap eller et afkrydsningsfelt, og stilles til rådighed gennem platformens tilgængeligheds-API. Skærmlæsere, stemmestyring, kontaktstyring og punktskriftsdisplays arbejder ud fra træet frem for ud fra pixels. Hver knude bærer et navn, en rolle og en tilstand, og WCAG-kriteriet 4.1.2 Name, Role, Value kræver, at software kan bestemme dem for hver komponent i brugerfladen. Indbyggede HTML-kontroller opfylder ifølge standarden allerede 4.1.2, når de bruges efter specifikationen. En `div`, der blot reagerer på et klik, havner i træet som almindelig tekst uden rolle og uden plads i tastaturrækkefølgen. Tilgængelighed afhænger af flere dele, der spiller sammen, påpeger WAI: webteknologier, browsere, forfatterværktøjer og selve webstederne. Ejeren af et site råder over den sidste del, og det er dér, WCAG i testbare formuleringer fastlægger, hvad indholdet skal gøre. ## Hvorfor det betyder noget Nettet bærer uddannelse, arbejde, offentlige ydelser, indkøb og sundhed, og WAI peger på, at FN's konvention om rettigheder for personer med handicap definerer adgang til informations- og kommunikationsteknologi, nettet medregnet, som en grundlæggende menneskeret. Tilgængelighed er også lovpligtig i mange sammenhænge, og indkøbere omsætter det til en linje i kontrakten, der nævner WCAG 2.2 niveau AA. Den linje afgør, hvad leverandøren skal bygge og dokumentere. Det samme arbejde gavner mennesker, der aldrig ville kalde sig handicappede. WAI's egen liste rummer folk, der bruger telefoner, ure og fjernsyn med små skærme og andre inputmåder, ældre, hvis evner ændrer sig med alderen, en, der har brækket armen eller mistet sine briller, en, der står i skarpt sollys eller et sted, hvor lyd ikke kan afspilles, og alle på en langsom eller dyr forbindelse. Undertekster hjælper i en stille togvogn, og stærk kontrast hjælper på en telefon ved middagstid. Tidspunktet sætter prisen. WAI kalder det mest effektivt at bygge tilgængelighed ind helt fra projektets start, så arbejdet slipper for at blive lavet om. At vælge en indbygget knap koster ingenting den første dag. Udskiftes en hjemmebygget efter lanceringen, skal komponenten rettes, og hver side, der brugte den, skal testes igen på alle sprog og i alle temaer, sitet udgives i. Evaluering følger samme logik. Værktøjer hjælper, men WAI siger ligeud, at intet værktøj alene kan afgøre, om et site lever op til retningslinjerne for tilgængelighed, og at det kræver en kyndig menneskelig evaluering. En regelmotor læser, hvad markuppen siger. Et menneske med tastatur og skærmlæser finder ud af, hvad siden gør. ## Sådan ser det ud i praksis Et site klarede sine automatiske tilgængelighedsregler og rummede alligevel [elleve tilgængelighedsdefekter, som browseren anså for fejlfri](/da/portfolio/fixed-11-accessibility-defects-the-browser-called-healthy-131/). Alle opstod i gengivelsen af siden og ikke i det, markuppen udtrykte. Otte links i footeren var gemt med en egenskab, der kun slår reaktionen på pegeredskabet fra, så tabulatortasten stadig standsede ved dem, selv om ingen kunne se dem på skærmen. To fejl lå i kontrollerne selv. Layouttjekket åbnede hvert vindue 900 pixels højt, så en telefon vendt på tværs, 852 gange 393, blev aldrig besøgt, skønt to elementer dér stod syv pixels fra hinanden. Samtidig afviklede regelmotoren 70 af sine 105 regler. Siden udleder fire regler af arbejdet, blandt andet at et tjek af én akse kun beskytter den akse, og at synlighed skal vises med pixels frem for med dokumentet. Med fuldt omfang igen registrerede layouttjekket 128 fejl på tre sprog. Siden om [at give hver ikonknap et navn til skærmlæsere](/da/portfolio/named-all-seventeen-interface-icons-for-screen-readers-159/) skifter fra et website til en applikation skrevet i SwiftUI. Et systemsymbol uden tilgængelighedsetiket får sin interne betegnelse sagt højt af skærmlæseren, og derfor lød send-knappen som »arrow up circle, button«. De øvrige rene ikonkontroller gjorde det samme, sytten i alt, og hver fortalte, hvordan den så ud, frem for hvad den gjorde. Nu bærer hver af dem en etiket, der siger, hvad kontrollen gør, og hvor betydningen skifter med tilstanden, skifter etiketten med. En linter holder øje: Fra den konstruktion, der opretter en ikonkontrol, til dens etiket må der højst være otte linjer. Tærsklen er med vilje grov og fastsat ud fra målinger, og en attende kontrol kommer kun ind i koden sammen med en etiket. Siden gør også rede for reglens grænse: Den viser, at der står en etiket tæt på, men om etiketten er træffende, afgør først et menneske, der lytter. [Siden om at være klar til AI-agenter](/da/ai-ready/) tilføjer en nyere læser. Mange agenter, der styrer en browser, når siden ad samme vej som en skærmlæser, via tilgængelighedstræet. Alt det, der gør et site til at bruge uden mus, altså knapper, der er ægte knapper, formularfelter med etiketter, overskrifter i logisk orden og landmærker, hjælper dermed også en agent med at finde en formular og udfylde den. ## Hvor det går galt **En hjemmebygget rullemenu virker med mus og spærrer alle andre ude.** En `div` med en klikhandler har ingen rolle, modtager intet tastaturfokus og melder ingen åben eller lukket tilstand, så en skærmlæser oplæser almindelig tekst, og tabulatortasten springer den over. Start med det indbyggede element, `select`, `button` eller `details`, som bringer rolle, fokus og tilstand med sig. Kræver designet virkelig en særlig widget, så følg dens mønster i ARIA Authoring Practices Guide, og test den derefter med tastatur og skærmlæser. **Alt-teksten beskriver billedet, når læseren havde brug for dets funktion.** 1.1.1 Non-text Content kræver et tekstalternativ, der tjener samme formål, og et linket logo beskrevet som »blåt sekskantet logo« fortæller en skærmlæserbruger intet om, hvor linket fører hen. Skriv alternativet ud fra billedets rolle: destinationen for et linket billede, konklusionen for et diagram, ordene for et billede af tekst. Giv rent dekorative billeder en tom `alt=""`, så hjælpemidler springer dem over. **Fokus hopper til toppen af siden, når en dialog lukkes.** Når en dialog lukkes, eller en single-page-app skifter rute, forsvinder det element, der havde fokus. Fokus falder tilbage til dokumentets body, og en bruger med tastatur eller skærmlæser mister sin plads. Send fokus tilbage til den kontrol, der åbnede dialogen. Efter et ruteskift på klientsiden flyttes fokus til den nye visnings hovedoverskrift, som får `tabindex="-1"`, så den kan modtage fokus, og skærmlæseren annoncerer, hvor brugeren er landet. **Fejl vises kun som en rød kant.** 1.4.1 Use of Color kræver, at farve ikke er det eneste visuelle middel til at formidle information, og 3.3.1 Error Identification kræver, at en registreret inputfejl identificeres og beskrives for brugeren i tekst. En rød kant gør ingen af delene for den, der ikke kan skelne rødt fra gråt eller slet ikke kan se feltet. Sæt en kort besked ved siden af feltet, der siger, hvad der er galt, og hvordan det rettes, forbind den med `aria-describedby`, så en skærmlæser læser begge dele sammen, og behold farven som et ekstra signal. ## Læs mere - [Introduction to Web Accessibility](https://www.w3.org/WAI/fundamentals/accessibility-intro/) — WAI's definition, hvem der har gavn af tilgængelighed, og hvorfor evaluering kræver mennesker såvel som værktøjer. - [How People with Disabilities Use the Web](https://www.w3.org/WAI/people-use-web/) — historier om brugere, de barrierer, de møder, og de værktøjer og teknikker, de støtter sig til. - [The Business Case for Digital Accessibility](https://www.w3.org/WAI/business-case/) — rækkevidde, innovation, brand og juridisk risiko, fremlagt for dem, der godkender budgetter. - [Evaluating Web Accessibility Overview](https://www.w3.org/WAI/test-evaluate/) — fra hurtige tjek til en fuld evaluering af overensstemmelse, med værktøjer og rapportering. - [ARIA Authoring Practices Guide](https://www.w3.org/WAI/ARIA/apg/) — mønstre for særlige widgets med de roller, tilstande og den tastaturadfærd, hver af dem kræver.