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 sidens innhold 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, 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 ved å sette deg inn i hvordan ARIA 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 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
Det finnes en rekke verktøy det er lurt å ha med i verktøykassa di.
Den aller viktigste testen er brukertesten.
Løsningene våre kan være 100 % i samsvar med kravene, men allikevel gi en forferdelig brukeropplevelse. "Test min løsning" er et tilbud til produktteamene i NAV som lar deg sjekke hvordan ekte brukere opplever løsningen din. Ta kontakt med oss på uu@nav.no eller via Slack på #nav-uu om du er interessert.
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. VoiceOver er innebygget i Mac, mens Narrator er innebygget i Windows.
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.