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 det mening og struktur med semantisk HTML. Det kommer en egen artikkel om temaet etter hvert, 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 landemerker til å dele innholdet inn i seksjoner. Sørg for at alt innhold er inni et landemerke. Ikke bruk flere landemerker enn nødvendig - de skal brukes til grove inndelinger av innholdet som tilsvarer sidens layout, ikke til hvert eneste tema på siden.
• Bruk semantiske elementer som lister, tabeller og figure + figcaption fremfor å bare bruke visuell styling til å strukturere innhold.
• Prøv å opprettholde en logisk rekkefølge i 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 det finnes et nativt HTML-element som kan gjøre samme jobben. Vi har en tendens å bruke altfor mye ARIA i løsningene våre, og statistikken viser at jo mer ARIA som er brukt på en side, jo flere tilgjengelighetsfeil har den. Unngå å bli en del av denne dystre statistikken - sett deg inn i hvordan det fungerer før du tar det i bruk.

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 bare er til dekorasjon og ikke tilføyer noen 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årt eksempelrepo for å se disse i aksjon.

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 horisontal scrolling (med mindre det er et kart e.l. 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 blir 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 hvert suksesskriterium 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 landemerker 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 du lager løsninger som møter kravene.
• Accessibility Support kan gi deg en pekepinn på om funksjonen du utforsker er bredt nok støttet for å kunne brukes.

Nettleseraddons

• Landmark Navigation via Keyboard or Pop-up viser deg landemerker 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 med mer.
• disable-HTML lar deg skru av CSS, bilder, JS, popups og cookies.