Jukselapp om WCAG-krav og tilgjengelighetserklæringer

La oss si at du jobber med at å lage selvbetjeningsløsninger, nettsider, apper, whatnot. Og så er det en prat i lunsjen om tilgjengelighetserklæringer og den nye uustatus-løsningen fra uutilsynet.

— Hvorfor tester ikke uustatus løsningen for oss? spør én
— Ja, hvorfor kan vi ikke konsentrere oss om å lage ting, ikke alle disse kravene? svarer en annen.

Hva svarer du da? Skumles nedover her, så finner du kanskje noen poenger å bruke 😄

Så, Stortinget har sagt ja til å innlemme EU sine regler for økt tilgjengelighet av digitale tjenester. Dette heter Web Accessibility Initiative (WAI), og har fra 2016 inkludert et krav om at nettsider og apper fra det offentlige skal ha en såkalt Web Accessibility Statement.

På norsk kaller vi dette en tilgjengelighetserklæring. I Europa er disse reglene implementert på litt forskjellig vis. I Norge har en valgt å lage en sentralisert løsning der tilgjengelighetserklæringen for et nettsted fylles ut. Altså skal ikke hver offentlige virksomhet lage hver sin, med forskjellig oppsett og utseende.

Vel, det er loven som bestemmer. Alt dette følger av EØS-avtalen, og i Norge har Stortinget valgt at det kun er offentlige nettsteder (altså, det offentlige er avsender) som må fylle ut skjemaet. Om en representerer det offentlige på nett må uustatus brukes.

Du fyller ut skjemaet, publiserer det, får en lenke, og legger dette i footeren på siden. Det er ingenting i veien for at private og frivillige virksomheter lager egne tilgjengelighetserklæringer. De får bare ikke gjort det via uustatus. Det er det Stortinget som har bestemt.

For å lage en ferdig tilgjengelighetserklæring må du gjennom seks steg. I filmen under får du en kort intro. (For ordens skyld: jeg har vært med og laget filmen.)

Dette er ikke nytt. Husk, EU sitt tilgengelighetsdirektiv ble lagt frem i 2016, vedtatt i 2019 og ble del av norsk lovverk i mai 2021, litt forsinket pga korona. Norge har underskrevet på EØS-avtalen og derfor blir gjerne EU sine regler til våre regler. Dette er altså en forutsigbar utvikling, ikke en overraskelse.

Vil du se hva fremtiden bringer for universell utforming? Sjekk hva EU skriver i deres Disability Strategy 2021—2030.

Mange tror det. De vil gjerne bare logge inn på uustatus og skrive inn “vi er gode på uu!”, trykke publisér og være ferdig med saken. OK, jeg overdriver litt. Men de fleste som kommer inn og ser på skjemaet blir straks klar over at dette er en stor jobb.

Skjemautfyllingen utløser nemlig et skred av oppgaver:

• For å kunne fylle ut skjemaet på korrekt vis, må hele nettløsningen testes ordentlig. Her får mange seg en overraskelse. Det er jo ganske mange krav å fylle ut svar for, og for hvert brudd på kravene, må du beskrive hva som er feil, og forklare om det finnes tilgjengelige alternativer.
• For å kunne vite hva uu-ståa er, og beskrive dette presist i skjemaet, må du kunne WCAG-kravene godt og vite hvordan du tester på korrekt vis.
• For å holde oversikt over feilene du finner (alle finner feil, sånn er det) må du lage en oversikt der du samler, systematiserer og kategoriserer feilene du finner (tips: start med regnearket som uutilsynet har laget).
• Deretter må en gå i gang med å rette opp feilene, teste dem, dokumentere at ting fungerer (eller ikke fungerer), legge det inn i oversikten, og så til slutt fylle det ut på korrekt sted i tilgjengelighetserklæringsskjemaet.

Og selv da, etter mye innsats, vil mange likevel oppdage at nettløsningen likevel inneholder brudd på kravene. Noe som er omtrent det første du ser i den ferdig publiserte tilgjengelighetserklæringen. Ikke all innsatsen dere har lagt ned. Ikke at det meste fungerer som det skal. Nei, for det er sluttbrukeren som tilgjengelighetserklæringen er til for, og hen lurer bare på: Hva er det som ikke fungerer her?

Hva da? WCAG-kravene? De er ikke nye, og de gjelder også deg (spesielt deg som tilbyr nettløsninger som brukes av det offentlige, da må du få orden i sysakene aller hurtigst).

I motsetning til fleste andre bransjer er ikke EDB-verden vant til at det finnes regler, forskrifter og lover som de må følge. For mange virksomheter var GDPR og de andre reglene som Datatilsynet følger opp en vekker. Men vi har hatt en egen forskrift om universell utforming av IKT-løsninger siden 2013, og diskriminerings- og tilgjengelighetsloven fra 2008 nevner IKT spesifikt.

For å overdrive litt, her er hvordan mye av IT-bransjen ser på regler: en holder seg for ørene, later som om de ikke finnes, og tenker at de forsvinner om en bare ignorerer dem.

Fordi forskriften sier at de skal lages for offentlige nettsider.

En kjapp måte for brukerne å sjekke 1. hva som ikke fungerer på en offentlig nettside og 2. om det finnes noen tilgjengelige alternativer for de tingene som ikke fungerer.

De nye reglene krever at de offentlige virksomhetene tester, og registrerer resultatene i et standardisert skjema på uustatus.no. Teksten en legges inn der, blir da synlig for brukerne. Tips: ikke skriv forklaringstekstene som om juristene i uutilsynet er mottakerne. Skriv til sluttbrukerne. Test gjerne tekstene med dem før du legger dem ut.

Ideen er at brukerne av offentlige nettsider kjapt skal kunne sjekke “hva er det som ikke fungerer på denne offentlige nettsiden?” på en standardisert måte. Alternativet ville ha vært at de ville ha fått servert et utall forskjellige oppsett og utforminger på alle mulige offentlige nettsteder.

Ønsket om at “uustatus-skjemaet fyller ut seg selv” er det mange som nevner. Men uustatus-skjemaet er ikke et testverktøy. Det er delvis et compliance verktøy, og delvis en løsning for å fortelle brukerne om hva som ikke fungererer. Ikke et testverktøy.

(Tips: NAV har en fin samleside om uu-testing)

Joda, det hadde vært supert om du bare kunne legge inn offentlignettsted.no i et felt på uustatus.no, trykke på en knapp, ta en kopp kaffe og være ferdig. Det er mye WCAG-testing som kan automatiseres, og de verktøyene bør du ta i bruk. Men mye må faktisk testes manuelt. Og i de kommende WCAG 3.0-reglene blir det større fokus på helhetlig testing med brukerne, ikke bare validering av formelle krav. Altså ville ikke en integrert, automatisert løsning ha sluttet sirkelen uansett.

Det som er uvant for mange nå er at krav til universell utforming av IKT-løsninger som WCAG-kravene, standarder som EN 301 549, ISO 9241–210:20190, EUs Digital Markets Act, og selvfølgelig GDPR, now have teeth. En kan få (tidvis) store bøter for å ikke følge dem, og negativ oppmerksomhet.

Selv om det finnes mange offentlige virksomheter som har stålkontroll på uu (fx NAV) så er det mange som ikke har holdt oppsikt med uu-ståa og nå får sabla mye å kartlegge og rette opp i innen 1. februar 2023.

uustatus og tilgjengelighetserklæringene som offentlige tjenestefolk og konsulenter skal fylle ut er bare en anføring av uu-ståa, og i grunnen siste steg i prosessen. Men mange starter fra altså denne enden og velger å jobbe baklengs.

“Vi må få fylt ut dette skjemaet” sier folk. Og så oppdager de at det visstnok var ganske mange punkter de skulle gjennom, og ser at alt må testes, rettes, og dokumenteres før en fylle ut tilgjengelighetserklærinskjemaet og få null brudd. For de fleste vil dette ta lang tid å komme dit. Det ermye jobb i vente, men er det nok folk til å gjøre jobben?

Sett opp mot behovet, er det for få fagfolk (frontendere, designere av alle slag, produktledere, backendutviklere, IT-arkitekter, the works) som i dag har nødvendig kompetanse om universell utforming. Altså løser en ikke dette ved å øke budsjetter. Det er et kompetanseløft i hele IKT-bransjen som må til.

At en har en løsning som bryter med WCAG-kravene er kjedelig, og må fikses. Og ja, det blir krevende å få tak i nok folk som kan fikse alt som bryter med forskriften.

Men det er nettopp dette som gjør tilgjengelighetserklæringer så bra.

Endelig må offentlige nettsteder si “Vi har sjekket uu-ståa, og her er hva som ikke fungerer per nå.” Det er vel bedre at avsender gjør det på en strukturert måte, og forteller det til brukerne, enn at brukerne får servert en nettside med udokumenterte feil og mangler?

For de feilene har jo konsekvenser. Har du forsøkt å endre passtimen din hos Politiet? Nei, når dette skrives, går det går ikke an, fordi Qmatic-bookingløsningen de bruker har en kritisk feil. Jeg har forsøkt. Jeg har snakket med PIT. Når dette skrives er Endre time laget slik at du ikke får bekreftet endringene. Slett timen du hadde, og bestill en ny. Konsekvenser? Vel, om du trenger pass, og må flytte timen, er det upraktisk for deg, er det ikke?

Stemmer. Dere er også ansvarlige for at WCAG-kravene overholdes i løsningene dere har kjøpt inn, som opptrer på deres, som dere serverer til brukerne er universelt utformet.

Her vil de flinkeste leverandørene allerede har tatt hånd om dette, og levert en ferdig testrapport som dere kan bruke ifm utfylling av tilgjengelighetserklæring. Men om de ikke har kontroll, eller ikke har dokumentert, da har dere ansvaret overfor brukerne.

Ja. Private virksomheter er underlagt de samme reglene. Forskjellen er at de ikke kan bruke skjemaene i uustatus-løsningen for å lage en tilgjengelighetserklæring.

Kompetanseheving neste!

Spørsmålene i innledningen er fiktive, men reflekterer innspill jeg har fått om tilgjengelighetserklæringer, WCAG-krav, forskrift om universell utforming av IKT-løsninger, m.m.

Enkelt sagt må alle vi som jobber med selvbetjening, nettløsninger, apper, osv heve vår egen kompetanse, lage gode rutiner løpende testing, dokumentering og forbedring av uu-ståa i løsningene vi lager.

Utfordringen da, er at det finnes for UX-/interaksjonsdesignere og frontendere, for få studieplasser til disse, for få som søker på disse plassene, knapt en god “overgangsutdanning” som gir folk med utdanning i andre felt en kvalifiserende vei inn i feltet, begrenset med etterutdanningsmuligheter og altfor få eksperter som kan undervise resten av oss i universell utforming, WCAG-reglene, forskriften, og mer til. Men, kanskje viser det seg at tilgjengelighetserklæringen var sparket bak vi trengte for å endre på dette.

I så fall kan du jo ta en kikk på denne tordentalen min fra Yggdrasilkonferansen 2022.