Skriv tilgjengelig kode

Hvordan produsere frontend-kode som gjør løsningene våre tilgjengelig for alle?

Designsystemet

Ved å bruke komponenter fra designsystemet kan du spare mye tid og energi. De er ikke noe fiks-ferdig garanti for WCAG-etterlevelse, ettersom de må brukes riktig i kontekst, men de tar deg et skritt i riktig retning.

Semantisk HTML

Flere får tilgang til innholdet vårt når vi tildeler mening og struktur til det med semantisk HTML. Det kommer en egen artikkel om temaet etterhvert, men her er noen highlights:

• Bruk lang-attributtet på html-elementet for å sikre at skjermlesere leser opp innholdet med riktig stemme. Du bør også bruke det på andre elementer der språket er en annen enn det som er brukt på resten av siden.
• Strukturer hele siden i én serie med headings, med H1 som en beskrivelse av hovedinnholdet.
• Bruk landmarks til å dele innholdet inn i seksjoner. Sørg for at alle innholdet er i en landmark. Ikke bruk flere landmarks enn nødvendig--de skal brukes til grove inndelinger av innholdet som tilsvarer sidens layout, ikke til hver eneste tema på siden.
• Bruk semantiske elementer som lister, tabeller og figure + figcaption fremfor å bare bruke visuell styling til å strukturere innhold.
• Prøv å oppretteholde en logisk rekkefølge til HTMLen din, slik at betydningen av innholdet gjenspeiles i DOMen. Dette sparer deg for mange problemer generelt sett, men særlig problemstillinger tilknyttet hjelpemidler, som kan ha behov for å presentere innholdet til brukere i alternative formater. Bruker du React, kan du utnytte portals til å skyte inn innhold (f.eks. modalvinduer eller hoverboxes) til et logisk sted i DOMen.

ARIA

Den første regelen i ARIA er "ikke bruk ARIA"...i hvert fall ikke når en native HTML-element eksisterer som kan gjøre samme jobben. Vi har en tendens å bruke altfor mye ARIA i løsningene våre, og statistikkene viser at jo mer ARIA som er brukt på en side, jo flere tilgjengelighetsfeil den har. Unngå å bli en del av disse dystre statistikkene--før du tar ARIA i bruk i løsningene dine, sett deg inn i hvordan den fungerer.

Multimedia og bilder

Alt av meningsbærende ikke-tekstlig innhold--dvs., bilder, ikoner, videoer, animasjoner og andre ikke-tekstlige elementer som er faktisk en del av sidens innhold--må ha alternativ tekst.

Det er like viktig å ikke tilby alternativ tekst for ikke-tekstlig elementer dersom de ikke er en del av innholdet. Ikoner som er bare til dekorasjon og ikke tilføyer noe betydning til siden bør skjules fra skjermlesere.

Test koden din

Hvordan sjekke om du har fått det til?

Sett opp automatiske testverktøy.

Bruk uu-linting i IDEen din, og sett opp f.eks. cypress-axe, jest-axe eller nav-ally i byggpipelinen din for å begynne å luke ut de 20-30% av problemene som kan identifiseres automatisk. Ta en kikk på vår eksempelrepo for å se disse i action.

Test det du jobber på før du sjekker inn koden din.

Du må også teste koden som den faktisk blir rendret i nettleseren.

• Bruk et testverktøy som ARC Toolkit for å kjøre en automatisk analyse av koden som vist i nettleseren.
• Valider koden din. ARC Toolkit gjør det mulig å validere bare den delen av DOMen du jobber på.
• Sett musen din til siden. Sjekk at funksjonaliteten du bygger funker med bare tastatur.
• Test med skjermleser. VoiceOver er innebygget på Mac, og NVDA for Windows er gratis å laste ned.

Test det du jobber på i konteksten av hele siden.

Samsvar ("conformance" på engelsk) dreier seg om hele siden, så du må verifisere at det du jobber på funker i konteksten av sidene den skal leve i.

• Sjekk reflow og zoom. Endre viewportstørrelsen til 1280px bred og zoom til 400%. Alt av funksjonalitet og innhold må være tilgjengelig uten horizonal scrolling (med mindre det er noe som et kart som er avhengig av romlige forhold).
• Sjekk tekst- og linjespacing. Disse skal kunne justeres uten at brukeren mister tilgang til funksjonalitet eller innhold. Dette kan du teste med ARC Toolkit.
• Sjekk headingnivåene. Bruk f.eks. HeadingsMap til å se over headingstrukturen på hele siden. Den skal gjenspeile strukturen av innholdet. Headingene skal heller ikke hoppe over nivåer på veien ned (f.eks. H1 → H2 er bra; H1 → H3 er ikke OK.)
• Test med en skjermleser. Sørg for at status- og innholdsendringer er annonsert.

Nyttige ressurser

• WCAG 2.1-standarden er den vi skal etterleve i løsningene våre. Er du usikker, sjekk kilden.
• Understanding WCAG 2.1 hjelper det med nettopp det--for hver suksesskriteriet kan du lese detaljene om hvorfor det er viktig, forklaringer og nyanseringer, og ikke minst teknikker for å møte kravet.
• ARIA Authoring Practices Guide har detaljer om implementering av vanlige designmønstre, om beregning av tilgjengelig navn og beskrivelse, bruk av landmarks og mye mer.
• Inclusive Components av Heydon Pickering er en god ressurs for real-world implementasjon av tilgjengelige komponenter.
• Løsningsforslag for nettsider fra uu-tilsynet har mange gode råd om hvordan lage løsninger som møter kravene.
• Accessibility Support kan gi deg en clue om featuren du utforsker er bredt nok støttet for å kunne brukes.

Nettleseraddons

• Landmark Navigation via Keyboard or Pop-up viser deg landmarks på siden.
• HeadingsMap viser deg headingstrukturen på siden.
• ARC Toolkit kjører automatiserte tester i tillegg til at den viser fokusrekkefølge, lar deg validere DOMen, teste text spacing og mer.
• disable-HTML lar deg skru av CSS, bilder, JS, popups og cookies.