28. mai 2021 vedtok Stortinget at EUs Web Accessibility Directive (WAD) skulle bli del av norsk rett, og vil etter en innføringsperiode fra 1. februar 2022 gjelde fra 1. februar 2023.
WAD er EUs webdirektiv om universell utforming av nettsteder og mobilapplikasjoner som stiller nye krav til offentlig sektor. Kort fortalt gjelder dette mer fokus på mobile enheter, og egenprodusert tilgjengelighetserklæring.
Som mye annet kan arbeid med universell utforming fort ta mer tid enn antatt. Har din organisasjon en plan for å være klar før fristen går ut?
WCAG 2.1
Med EUs nye webdirektiv vil Web Content Accessibility Guidelines (WCAG) 2.1 overta for WCAG 2.0. Det betyr at etter innføringsperioden så skal offentlig sektor følge 14 nye krav, inkludert synstolkning og å ta hensyn til intra- og ekstranett dersom disse er nye eller oppgradert siden.
Av totalt 17 nye suksesskriterier i den nye WCAG standarden har 12 blitt del av norsk rett. I en stadig mer digitalisert verden er målet med de nye kravene å utvide området universell utforming er i fokus til å også inkludere mobile enheter.
Kort fortalt vil de nye kriteriene dekke ting som gester og berøringsskjerm, og hindre utilsiktet aktivering av innhold. Enda kortere fortalt bør nettløsningen være veldig klar for bruk på mobil.
Tabbene du må unngå for tilgjengelige nettsider: - Mye som kan gå galt
Tilgjengelighetserklæring
Parallelt med ny WCAG standard kommer webdirektivet også med et nytt krav i form av tilgjengelighetserklæringen. Dette blir en lovpålagt erklæring om tilgjengelighet for offentlig sektor.
Det betyr at man tar en egensjekk på om nettsiden følger kravene for universell utforming, og fører resultatet inn i en felles løsning som utvikles av digitaliseringsdirektoratet.
Formålet med erklæringen er å beskrive hvordan og i hvilken grad den digitale løsningen oppfyller kravene, og få virksomheter til å selv kartlegge status på universell utforming. Resultatet i denne erklæringen skal også publiseres slik at den er tilgjengelig for alle.
Så la oss ta et dypdykk inn i hva de nye suksesskriteriene faktisk er
Totalt har vi fått 12 nye suksesskriterier, som gjelder følgende:
- Visningsretning
- Identifisere formål med inndata
- Dynamisk tilpasning
- Kontrast for ikke-tekstlig innhold
- Tekstavstand
- Pekerfølsomt innhold eller innhold ved tastaturfokus
- Hurtigtaster som består av ett tegn
- Pekerbevegelser
- Pekeravbrytelse
- Ledetekst i navn
- Bevegelsesaktivering
- Statusbeskjeder
3 superenkle og morsomme UU-tester
#1: Visningsretning 1.3.4
Formålet er at innholdet på siden skal følge samme orientering enheten er i, og at brukeren selv skal kunne velge om det skal vises i liggende eller stående retning (landskap eller portrett).
Eksempel på tommel opp:
Brukeren mister ikke innhold dersom orienteringen på enheten endrer seg. Det vil si at CSS på nettsiden tar i bruk et responsivt design.
#2: Identifiser formål med inndata 1.3.5
Formålet er at hensikten med skjemaelementer deklareres i koden slik at det kan kommuniseres videre til brukeren.
Eksempel på tommel opp:
Skjemaelementer tar i bruk autocomplete-attributtet, og at riktig token brukes i henhold til hva som skal fylles inn. F.eks autocomplete=”email” dersom det er mailadresse det er snakk om.
70 prosent sliter med norske apper og nettsider
#3: Dynamisk tilpasning 1.4.10
Fra før har det vært krav å kunne øke størrelse på tekst med opp til 200%, uten at innhold eller funksjonalitet går tapt. Nå skal innhold også kunne økes til 400% ved en bredde på 1280 piksler.
Eksempel på tommel opp:
Ved 400%-visning skal alt innhold kunne vises ved bare vertikal scrolling, det vil si uten å måtte scrolle horisontalt. 400%-visning for et vindu op 1280 piksler vil tilsi en bredde på 320 piksler.
#4: Kontrast for ikke-tekstlig innhold 1.4.11
I tillegg til eksisterende krav om en kontrast på minst 4,5:1 for tekstlig innhold, blir det nå krav om en kontrast på minst 3:1 for ikke-tekstlig innhold. Hensikten er at grensesnitt og annen grafikk skal være lett å se. F.eks på unntak er elementer som bare er pynt eller inaktive komponenter.
Eksempel på tommel opp:
Interaktive elementer og grafikk har en kontrast på minst 3:1 mot bakgrunnsfargen. F.eks så ha hvit inputfelt på hvit bakgrunn, dersom inputfeltet har en ramme med tilstrekkelig kontrastfarge.
Julias 8 beste CSS-tips: - Fikk sjokk da jeg fant ut dette!
#5: Tekstavstand 1.4.12
Formålet er å gjøre teksten lettere å lese, ved at brukeren selv kan bestemme ting som linjehøyde og avstand mellom avsnitt, ord og bokstaver.
Eksempel på tommel opp:
Brukeren har mulighet til å bestemme tekstavstand innenfor følgende:
- Linjeavstand til minst 1,5x skriftstørrelse
- Avstand etter avsnitt til minst 2x skriftstørrelse
- Avstand mellom ord til minst 0,16x skriftstørrelse
- Avstand mellom bokstaver til minst 0,12x skriftstørrelse
#6: Pekerfølsomt innhold eller innhold ved tastaturfokus 1.4.13
Formålet er å gi brukeren mulighet til å både oppfatte og forkaste innhold som dukker opp som del av en hover/focus effekt. Denne typen interaksjoner kan oppleves som irriterende da man kanskje ikke forventer at innholdet skal dukke opp.
Eksempel på tommel opp:
Innhold som dukker opp som en del av en hover/focus effekt følger noen vilkår.
- Innholdet må være mulig å avvise uten å måtte flytte verken musepekeren eller fokusområdet.
- Det skal være mulig å flytte musepekeren over til det nye innholdet uten at det forsvinner.
- Innholdet skal forbli synlig helt til brukeren enten lukker det eller flytter musepeker eller fokusområdet videre.
Hva bør en UX-designer kunne? "Vi er jo knapt enige om hva UX egentlig innebærer!"
#7: Hurtigtaster som består av ett tegn 2.1.4
Formålet er gi bedre kontroll til brukere som bruker stemmestyring. Da hurtigtaster som bare består av ett tegn kan fort bli trigget ved uhell. Ved å unngå dette vil man også skape en bedre brukeropplevelse for brukere som ofte taster feil.
Eksempel på tommel opp:
Brukeren kan enten slå av hurtigtastene, redigere de eller velge at de bare kan aktiveres når komponentet har fokus.
#8: Pekerbevegelser 2.5.1
Formålet er å sikre at funksjonalitet som krever mer avansert brukerinput (f.eks trykke på flere punkter samtidig som ved zooming på berøringsskjerm, eller sveiping i et bestemt mønster eller retning) også kan aktiveres med enkel brukerinput.
Eksempel på tommel opp:
Brukeren skal kunne aktivere all funksjonalitet ved bruk av enkel brukerinput. UU tilsynet definerer eksempler på enkel brukerinput som slik:
- For musepeker: Klikk, dobbeltklikk, klikk og hold.
- For berøringsskjerm: Trykk, dobbelttrykk, lange trykk.
Finn skjermstørrelsen med denne React-hooken
#9: Pekeravbrytelse 2.5.2
Formålet er å gjøre det vanskeligere å gjøre uhell eller feil input via bruk av musepekeren eller berøringsskjerm. Spesielt for brukere med nedsatt syn eller håndfunksjon.
Eksempel på tommel opp:
Brukeren skal enten kunne avbryte eller angre en prosess som starter ved bruk av musepekeren, eller bare aktivere den ved bruk av ‘mouseUp’ event og ikke ‘mouseDown’.
#10: Ledetekst i navn 2.5.3
Formålet er å sørge for at ledetekster (som f.eks labels for skjemaelementer) sitt synlige navn stemmer overens med sitt kodemessige navn. Kort sagt betyr det at f.eks et inputfelt har en label og navn attributt som matcher.
Dette er spesielt viktig for brukere som bruker stemmestyring.
Eksempel på tommel opp:
Elementer i grensesnittet har en ledetekst i koden som er enten identisk, eller starter med den synlige ledeteksten.
- Dessverre ofte bedt om å pynte på en løsning før lansering
#11: Bevegelsesaktivering 2.5.4
Formålet er å sikre at funksjonalitet som aktiveres ved at brukeren beveger på enheten (f.eks rister eller snur på den) også kan brukes med vanlige komponenter. Dette kravet er spesielt viktig for brukere med nedsatt motorikk.
Eksempel på tommel opp:
Om man kan gå til neste side ved å snu på enheten eller lukke applikasjonen med risting, så skal det også være mulig å utføre samme handlingene ved bruk av knapper.
#12: Statusbeskjeder 4.1.3
Formålet er at brukeren skal informeres om viktige endringer på siden uten å flytte fokus, ved at statusbeskjeder blir lest opp av skjermleser. Dette gjelder spesielt brukere med nedsatt syn.
Eksempel på tommel opp:
Statusbeskjeder er kodet med riktige ARIA egenskaper, slik at de kan leses opp av skjermleser. ARIA har ulike egenskaper som kan brukes, slik som ‘status’, ‘progressbar’ og ‘alert’ ut i fra hva konteksten er.
