Tilgjengelighet for utviklere: Bygge inkluderende kode
Utviklere er arkitektene for tilgjengelighet på implementeringsnivå. Mens designere setter det visuelle og interaksjonsmessige grunnlaget, er det koden som til syvende og sist avgjør om et nettsted fungerer med tastaturnavigasjon, kommuniserer riktig med skjermlesere, og opprettholder tilgjengelighet på tvers av nettlesere og enheter.
Den gode nyheten er at de fleste beste praksiser for tilgjengelighet er i tråd med generelle beste praksiser for ren, semantisk, standardkompatibel kode. Å skrive tilgjengelig kode handler ikke om å legge til kompleksitet — det handler om å skrive kode riktig i utgangspunktet.
Semantisk HTML først
Det mest virkningsfulle du kan gjøre for tilgjengelighet er å bruke semantiske HTML-elementer korrekt. HTML5 tilbyr et rikt vokabular av elementer som bærer iboende mening og tilgjengelighetsfunksjoner. Et <button>-element er automatisk fokuserbart, aktiverbart med tastatur, og annonseres som en knapp av skjermlesere. En <div> med en onclick-handler har ingen av disse funksjonene uten betydelig ekstra arbeid.
Bruk <nav> for navigasjonsområder, <main> for hovedinnholdet, <header> og <footer> for sine respektive seksjoner, <section> og <article> for innholdsområder, <h1> til <h6> for overskrifter i korrekt hierarkisk rekkefølge, <ul> og <ol> for lister, <table> med <th> for tabelldata, <label> med for-attributter for skjemaelementer, og native <button>- og <a>-elementer for interaktive kontroller.
Disse elementene skaper et tilgjengelighetstre som hjelpeteknologier bruker for å presentere innholdet ditt for brukere. Når du bruker dem korrekt, håndteres mye av tilgjengeligheten automatisk.
Overskriftsstruktur
Overskrifter skaper den strukturelle disposisjonen for siden din. Skjermleserbrukere navigerer ofte etter overskrifter for å forstå innholdsorganisering og finne spesifikke seksjoner. Hver side bør ha nøyaktig én <h1>, og overskrifter bør følge et logisk hierarki uten å hoppe over nivåer — en <h3> bør ikke følge etter en <h1> uten en <h2> i mellom.
Bruk aldri overskriftselementer for visuell styling. Hvis du trenger stor, fet tekst som ikke er en overskrift, bruk CSS på et annet element. Omvendt, hvis innhold fungerer som en overskrift, marker det som en overskrift uavhengig av den visuelle presentasjonen.
Tastaturtilgjengelighet
All funksjonalitet må kunne betjenes gjennom et tastaturgrensesnitt alene. Dette betyr at hvert interaktivt element — lenker, knapper, skjemaelementer, menyer, modaler, glidebrytere, faner — må kunne nås via Tab-tasten (eller Shift+Tab for bakover), aktiveres med Enter eller Mellomrom, og lukkes der det er aktuelt.
Skap aldri tastaturfeller der brukere kan tabbe inn i et element men ikke kan tabbe ut igjen. Modale dialoger bør fange fokus innenfor dialogen mens den er åpen og returnere fokus til utløserelementet når den lukkes, men å trykke Escape bør alltid avvise dialogen.
Sørg for at fokusrekkefølgen følger en logisk sekvens som samsvarer med den visuelle layouten. DOM-rekkefølgen bør generelt samsvare med den visuelle presentasjonen. Unngå å bruke positive tabindex-verdier, som overstyrer den naturlige fokusrekkefølgen og skaper forvirring. Bruk tabindex="0" for å gjøre ikke-interaktive elementer fokuserbare når det er nødvendig, og tabindex="-1" for elementer som kun bør kunne fokuseres programmatisk.
Sidespråk
Angi standardspråket for hver side ved hjelp av lang-attributtet på <html>-elementet. Dette forteller skjermlesere hvilke uttalesregler de skal bruke. Hvis språket endres innenfor innholdet — for eksempel en fransk frase i en norsk side — marker endringen med et lang-attributt på det omsluttende elementet.
Skjematilgjengelighet
Skjemaer er der brukere gir input, og de er en hyppig kilde til tilgjengelighetsfeil. Hvert skjemaelement må ha en programmatisk tilknyttet merkelapp, typisk ved å bruke <label>-elementet med et for-attributt som samsvarer med kontrollens id. Grupper relaterte elementer med <fieldset> og <legend>.
Når inndatafeil oppdages, identifiser feltet med feilen og beskriv feilen i tekst. Gi forslag til korreksjon der det er mulig. For felt som aksepterer spesifikke formater, gi tydelige instruksjoner om forventet format. Bruk autocomplete-attributtet for å aktivere nettleserens autofyll for vanlige felt som navn, e-post, adresse og telefonnummer.
Statusmeldinger som ikke mottar fokus — som «vare lagt til i handlekurven» eller «3 resultater funnet» — må annonseres til skjermleserbrukere gjennom ARIA live-regioner eller statusroller.
Alternativ tekst
Hvert ikke-dekorativt bilde må ha meningsfull alternativ tekst som beskriver innholdet eller funksjonen. For informative bilder, beskriv hva bildet formidler. For funksjonelle bilder (som en logo som lenker til hjemmesiden), beskriv funksjonen. For dekorative bilder som ikke tilfører informasjon, bruk et tomt alt-attributt (alt="") slik at skjermlesere hopper over dem helt.
Komplekse bilder som diagrammer, grafer eller illustrasjoner kan trenge lengre beskrivelser gitt gjennom en bildetekst, tilstøtende tekst eller en lenket detaljert beskrivelse.
WAI-ARIA
Spesifikasjonen for Accessible Rich Internet Applications gir ytterligere semantikk for situasjoner der nativ HTML er utilstrekkelig. ARIA lar deg kommunisere roller, tilstander og egenskaper til hjelpeteknologier for egendefinerte widgeter og dynamisk innhold.
Imidlertid bør ARIA brukes med omhu. Den første regelen for ARIA er: hvis du kan bruke et nativt HTML-element som har den semantikken og oppførselen du trenger, gjør det. ARIA tilfører ikke funksjonalitet — det tilfører bare semantikk. En <div role="button"> trenger fortsatt JavaScript for tastaturhåndtering, mens en nativ <button> håndterer det automatisk.
Bruk ARIA-landemerkeroller (eller deres HTML5-ekvivalenter) for å definere sideregioner. Bruk aria-label og aria-labelledby for å gi tilgjengelige navn der synlig tekst er utilstrekkelig. Bruk aria-expanded, aria-selected, aria-checked og andre tilstandsattributter for å kommunisere den nåværende tilstanden til interaktive widgeter. Bruk aria-live-regioner for å annonsere dynamiske innholdsoppdateringer.
Responsiv design og omflytting
Innhold må kunne presenteres uten tap av informasjon ved 320 CSS-piksler bredde uten å kreve horisontal rulling. Dette sikrer at brukere som zoomer til 400 % på en standard skjerm fortsatt kan få tilgang til alt innhold. Design layoutene dine slik at innholdet flyter om til en enkelt kolonne ved smale bredder i stedet for å kreve rulling i to dimensjoner.
Hopp-lenker
Tilby en mekanisme for tastaturbrukere til å hoppe over gjentatte innholdsblokker, som navigasjonsmenyer, og gå direkte til hovedinnholdet. Den vanligste implementeringen er en «Hopp til hovedinnhold»-lenke som er det første fokuserbare elementet på siden og blir synlig når det fokuseres.
Utviklerens testsjekkliste
Før du deployer en funksjon, verifiser: all funksjonalitet fungerer med tastatur alene; fokusrekkefølgen er logisk; fokus er synlig på alle interaktive elementer; alle bilder har passende alt-tekst; alle skjemaelementer har merkelapper; sidespråk er angitt; overskriftshierarkiet er korrekt; ARIA brukes korrekt og kun når det er nødvendig; innhold flyter om ved 320px bredde; og dynamiske innholdsoppdateringer annonseres til skjermlesere.
I denne seksjonen
Er nettstedet ditt tilgjengelig?
Skann nettstedet ditt gratis og få WCAG-poengsummen din på noen få minutter.
Skann nettstedet ditt gratis