Tilgængelighed for udviklere: Byg inkluderende kode
Udviklere er tilgængelighedens arkitekter på implementeringsniveau. Mens designere sætter det visuelle og interaktionsmæssige fundament, er det koden, der i sidste ende afgør, om et website fungerer med tastaturnavigation, kommunikerer korrekt med skærmlæsere og opretholder tilgængelighed på tværs af browsere og enheder.
Den gode nyhed er, at de fleste best practices for tilgængelighed stemmer overens med generelle best practices for ren, semantisk og standardkonform kode. At skrive tilgængelig kode handler ikke om at tilføje kompleksitet — det handler om at skrive kode korrekt fra starten.
Semantisk HTML først
Det mest virkningsfulde, du kan gøre for tilgængelighed, er at bruge semantiske HTML-elementer korrekt. HTML5 tilbyder et rigt udvalg af elementer, der bærer iboende betydning og tilgængelighedsfunktioner. Et <button>-element er automatisk fokuserbart, kan aktiveres med tastatur og annonceres som en knap af skærmlæsere. Et <div> med en onclick-handler har ingen af disse funktioner uden betydeligt ekstra arbejde.
Brug <nav> til navigationsområder, <main> til det primære indhold, <header> og <footer> til deres respektive sektioner, <section> og <article> til indholdsområder, <h1> til <h6> til overskrifter i korrekt hierarkisk rækkefølge, <ul> og <ol> til lister, <table> med <th> til tabulære data, <label> med for-attributter til formularfelter, og native <button>- og <a>-elementer til interaktive kontrolelementer.
Disse elementer skaber et tilgængelighedstræ, som hjælpeteknologier bruger til at præsentere dit indhold for brugerne. Når du bruger dem korrekt, håndteres meget af tilgængeligheden automatisk.
Overskriftsstruktur
Overskrifter skaber den strukturelle disposition af din side. Skærmlæserbrugere navigerer ofte via overskrifter for at forstå indholdets organisering og finde specifikke sektioner. Hver side bør have præcis én <h1>, og overskrifter bør følge et logisk hierarki uden at springe niveauer over — en <h3> bør ikke følge en <h1> uden en <h2> imellem.
Brug aldrig overskriftselementer til visuel styling. Hvis du har brug for stor fed tekst, der ikke er en overskrift, brug CSS på et andet element. Omvendt, hvis indhold fungerer som en overskrift, markér det som én uanset dets visuelle præsentation.
Tastaturtilgængelighed
Al funktionalitet skal kunne betjenes alene via tastatur. Det betyder, at hvert interaktivt element — links, knapper, formularfelter, menuer, modaler, sliders, faner — skal kunne nås via Tab-tasten (eller Shift+Tab for omvendt rækkefølge), aktiveres med Enter eller mellemrum, og forlades hvor det er relevant.
Skab aldrig tastaturfælder, hvor brugere kan tabbe ind i et element men ikke ud af det. Modale dialoger bør holde fokus inde i dialogen mens den er åben og returnere fokus til det udløsende element når den lukkes, men at trykke Escape bør altid lukke dialogen.
Sørg for, at fokusrækkefølgen følger en logisk sekvens, der matcher det visuelle layout. DOM-rækkefølgen bør generelt matche den visuelle præsentation. Undgå at bruge positive tabindex-værdier, der overskriver den naturlige fokusrækkefølge og skaber forvirring. Brug tabindex="0" til at gøre ikke-interaktive elementer fokuserbare, når det er nødvendigt, og tabindex="-1" til elementer, der kun skal kunne fokuseres programmatisk.
Sidens sprog
Angiv standardsproget på hver side ved hjælp af lang-attributten på <html>-elementet. Dette fortæller skærmlæsere, hvilke udtaleregler der skal bruges. Hvis sproget ændres inden for indholdet — for eksempel en fransk sætning på en dansk side — markér ændringen med en lang-attribut på det omsluttende element.
Formulartilgængelighed
Formularer er der, hvor brugere giver input, og de er en hyppig kilde til tilgængelighedsfejl. Hvert formularfelt skal have en programmatisk tilknyttet label, typisk ved brug af <label>-elementet med en for-attribut, der matcher feltets id. Gruppér relaterede felter ved hjælp af <fieldset> og <legend>.
Når inputfejl opdages, identificér feltet med fejl og beskriv fejlen i tekst. Giv forslag til rettelse, hvor det er muligt. For felter, der accepterer specifikke formater, giv klare instruktioner om det forventede format. Brug autocomplete-attributten til at aktivere browserens autoudfyldning for almindelige felter som navn, e-mail, adresse og telefonnummer.
Statusmeddelelser, der ikke modtager fokus — som "vare tilføjet til kurv" eller "3 resultater fundet" — skal annonceres til skærmlæserbrugere gennem ARIA live regions eller statusroller.
Alternativ tekst
Hvert ikke-dekorativt billede skal have meningsfuld alternativ tekst, der beskriver dets indhold eller funktion. For informative billeder, beskriv hvad billedet formidler. For funktionelle billeder (som et logo, der linker til forsiden), beskriv funktionen. For dekorative billeder, der ikke tilfører information, brug en tom alt-attribut (alt=""), så skærmlæsere springer dem helt over.
Komplekse billeder som diagrammer, grafer eller infografikker kan kræve længere beskrivelser via en billedtekst, tilstødende tekst eller en linket detaljeret beskrivelse.
WAI-ARIA
Specifikationen for Accessible Rich Internet Applications giver yderligere semantik i situationer, hvor native HTML er utilstrækkelig. ARIA giver dig mulighed for at kommunikere roller, tilstande og egenskaber til hjælpeteknologier for brugerdefinerede widgets og dynamisk indhold.
Dog bør ARIA bruges med omtanke. Den første regel for ARIA er: hvis du kan bruge et native HTML-element, der har den semantik og adfærd, du har brug for, så gør det. ARIA tilføjer ikke funktionalitet — det tilføjer kun semantik. Et <div role="button"> kræver stadig JavaScript til tastaturhåndtering, mens et native <button> håndterer det automatisk.
Brug ARIA-landmark-roller (eller deres HTML5-ækvivalenter) til at definere sideregioner. Brug aria-label og aria-labelledby til at give tilgængelige navne, hvor synlig tekst er utilstrækkelig. Brug aria-expanded, aria-selected, aria-checked og andre tilstandsattributter til at kommunikere den aktuelle tilstand af interaktive widgets. Brug aria-live-regioner til at annoncere dynamiske indholdsopdateringer.
Responsivt design og ombrydning
Indhold skal kunne præsenteres uden tab af information ved 320 CSS-pixels bredde uden at kræve vandret scrollning. Dette sikrer, at brugere, der zoomer til 400 % på en standard desktop-skærm, stadig kan tilgå alt indhold. Design dine layouts til at ombryde indhold til en enkelt kolonne ved smalle bredder frem for at kræve scrollning i to dimensioner.
Spring-links
Giv tastaturbrugere en mekanisme til at springe gentagne indholdsblokke over, som navigationsmenuer, og hoppe direkte til hovedindholdet. Den mest almindelige implementering er et "Spring til hovedindhold"-link, der er det første fokuserbare element på siden og bliver synligt, når det får fokus.
Udviklerens testtjekliste
Før du udruller en funktion, verificér: al funktionalitet virker med tastatur alene; fokusrækkefølgen er logisk; fokus er synlig på alle interaktive elementer; alle billeder har passende alt-tekst; alle formularfelter har labels; sidens sprog er angivet; overskriftshierarkiet er korrekt; ARIA bruges korrekt og kun når nødvendigt; indhold ombryder ved 320px bredde; og dynamiske indholdsopdateringer annonceres til skærmlæsere.
I denne sektion
Er din website tilgængelig?
Scan din website gratis og få din WCAG-score på få minutter.
Scan dit site gratis