Test universell utforming i innloggede tjenester

Forsiden er ofte den minst krevende delen av en digital tjeneste. De viktige brukeroppgavene ligger gjerne bak «Logg inn»: bestille time, sende søknad, lese faktura, administrere ansatte eller rette en feil i et skjema. Hvis testen stopper ved innloggingssiden, kan den derfor gå glipp av akkurat de barrierene som hindrer brukeren i å få gjort jobben.

Hvorfor en vanlig nettskanner ofte stopper for tidlig

Uu-tilsynet beskriver automatiske verktøy som et supplement til manuell testing. Tilsynet peker blant annet på at mange verktøy fungerer dårlig bak innlogging, kan gi falske treff og ofte ikke får med seg tilstander som først vises etter en handling – for eksempel en feiloppsummering etter innsending av et skjema.

• En nettskanner uten gyldig økt blir sendt tilbake til innloggingssiden og tester den samme siden om igjen.
• SSO og MFA krever ofte at en person fullfører den aktuelle innloggingsprosessen.
• Kontrollpaneler, dialoger, valideringsfeil, kvitteringer og andre dynamiske tilstander har ikke alltid en egen URL.
• Roller gir ulik tilgang. En sluttbruker, saksbehandler og administrator kan møte helt forskjellige grensesnitt.
• Tidsavbrudd, utløpte økter og krav om ny innlogging kan skape barrierer som ikke finnes i en statisk sideanalyse.

Innlogging avgjør normalt ikke om kravene gjelder

Uu-tilsynet forklarer at det normalt ikke er avgjørende om tilgangen er åpen eller krever innlogging når man vurderer om en løsning er et nettsted. Nettbank, betalingsartikler og «Min side» kan fortsatt være nettsteder. For offentlige intranett og ekstranett er publiseringsdato og vesentlig revisjon blant forholdene som kan utløse de utvidede kravene i webdirektivet.

Fagsystemer krever en mer konkret vurdering. Klassifisering, målgruppe og bruksområde kan påvirke om IKT-forskriften gjelder, mens anskaffelsesreglene fortsatt kan kreve at det stilles krav om universell utforming i anskaffelsen. Bruk derfor denne guiden som testmetode, ikke som en juridisk konklusjon om akkurat din løsning.

Slik setter du opp testen

Hva Synli lagrer ved interaktiv innlogging

Du skriver inn passordet til nettstedet i den kontrollerte nettleseren og fullfører innloggingen selv. Synli lagrer deretter den krypterte nettlesertilstanden for økten – ikke passordet til nettstedet. Skanneren bruker kontoens tilganger, men får ikke flere rettigheter enn kontoen har.

Test tilstander, ikke bare sider

Hva automatikken kan dokumentere – og hva et menneske må gjøre

Innenfor det avtalte omfanget kan Synli kjøre støttede nettleserbaserte kontroller og knytte funn til WCAG-kriterier med dokumentasjon og forslag til utbedring. Dette er effektivt for forhold som kan kontrolleres på samme måte hver gang, som semantikk, tilgjengelige navn, kontrast og enkelte tastaturproblemer. At den automatiske testen ikke finner feil, betyr likevel ikke at kriteriet er oppfylt.

• Test hele den representative oppgaven med tastatur – også veien tilbake, muligheten til å avbryte og retting av feil.
• Bruk relevante hjelpemidler og nettleserkombinasjoner, ikke bare visuell inspeksjon.
• Vurder om alternativtekster, lenketekster, overskrifter og instruksjoner faktisk formidler riktig mening.
• Kontroller tilstander skanneren ikke nådde, og noter hvorfor de ligger utenfor den automatiske dekningen.
• Bekreft hvert funn før det brukes som offisiell samsvarsvurdering, leverandørdokumentasjon eller erklæringsgrunnlag.

Dokumenter omfanget så testen kan gjentas

1. Navngi løsning, miljø, rolle og versjon – uten å legge hemmeligheter eller persondata i rapporten.
2. List opp de viktigste brukeroppgavene og tilstandene som faktisk ble testet.
3. Noter hvilke sider Synli nådde, og hva som krevde manuell navigasjon eller ble utelatt.
4. Skill mellom automatisk påviste funn, faglig bekreftede vurderinger og punkter som fortsatt er uavklart.
5. Ta vare på dato, testdata, nettleser, hjelpemidler og ansvarlig person slik at vurderingen kan oppdateres etter endringer.