Hopp til hovedinnhold

KORT FORTALT: For sider som medfører juridiske forpliktelser må det være mulig å kunne angre, kontrollere eller bekrefte dataene som sendes inn.

    Tolking

    Uu-tilsynets forståelse av det aktuelle kravet. Tolkingen er basert på en juridisk og uu-faglig vurdering og avveining av rettskildene, inkludert W3Cs normative og informative kilder til WCAG (W3C, engelsk). Viktige kilder er suksesskriteriet, WCAGs ordliste, Uu-tilsynets praksis, formål, forståartikkelen, teknikker og failures.

    Krav til samsvar

    Uu-tilsynets beskrivelse av hva som skal til for å oppfylle det aktuelle kravet. Ofte består det også av ulike delkrav. Vanligvis kan kravet møtes på flere måter.

    Testregel

    Uu-tilsynets framgangsmåte (prosedyre) for å teste og ta stilling til om krav til samsvar er oppfylt eller ikke. Vi har ofte flere testregler knyttet til et krav.

    For nettsider som medfører juridiske forpliktelser eller krever økonomiske transaksjoner fra brukeren, som endrer eller sletter brukerstyrte data i datalagringssystemer, eller som sender svar på tester utført av brukeren, gjelder minst ett av følgende punkter:

    • Reverserbarhet: Sendeprosesser kan reverseres.
    • Kontroll: Det kontrolleres om data som angis av brukeren, inneholder inndatafeil, og brukeren gis mulighet til å korrigere eventuelle feil.
    • Bekreftelse: Det finnes en mekanisme for gjennomgang, bekreftelse og korrigering av informasjon før den sendes.

    Formål

    Hensikten med kravet er å hjelpe brukere å unngå alvorlige konsekvenser av feil utfylling av skjema eller annet innhold som medfører juridiske forpliktelser, økonomiske transaksjoner og lignende viktige situasjoner.

    Brukerbehov

    Kravet er ment å ivareta personer som er blinde, har nedsatt syn, nedsatt kognisjon eller nedsatt motorikk.

    Tilsynets tolking

    Kravet er etter ordlyden i suksesskriteriet avgrenset til å omfatte nettsider som medfører visse typer plikter eller rettigheter for brukeren. Dette er nettsider, gjerne skjema, som

    • medfører juridiske og/eller økonomiske plikter for brukeren
    • endrer eller sletter brukerstyrte data i datalagringssystem
    • sender svar på tester utført av brukeren

    Dette kan være billettkjøp, banktransaksjoner, svar på tester eller endring eller sletting av opplysninger av brukerstyrt informasjon i ulike datalagringssystem, for eksempel en profil hos et reisebyrå.

    Begrepene Nettsider, Juridiske forpliktelser, Brukerstyrt, Inndatafeil og Mekanisme er definert i WCAGs ordliste.

    Begrepet Brukerstyrte data er ikke definert i ordlisten, men det forklares og eksemplifiseres nærmere i forståartikkelen. Der står det at brukerstyrte data er data som er synlig for brukeren og som brukeren kan endre og/eller slette med en bevisst (villet) handling.

    Eksempler er at brukeren kan oppdatere telefonnummer og adresser i en profil eller slette en oversikt over tidligere fakturaer fra et nettsted. Eksempler på noe som faller utenfor, er internettlogger eller metadata som en søkemotor samler inn, som brukeren ikke kan se eller samhandle med direkte.

    Når det gjelder endring eller sletting av brukergenererte data i datalagringssystemer, presiserer forståartikkelen videre at hensikten er å forhindre tap av store datamengder, som å slette en hel fil eller et register. Formålet er derimot ikke å kreve bekreftelse av hver enkelt lagring eller redigering som gjøres i dokumenter, register eller andre data.

    Suksesskriteriet lister opp tre ulike alternativer for å oppfylle kravet på, for nettsider som er omfattet.

    Alternativ 1: Reversere

    Brukeren skal få beskjed om at innsendingen eller sletting av data kan reverseres/angres. Beskjeden kan være en egen tekst med utfyllende informasjon eller en mekanisme, for eksempel en knapp «Avbestill», «Kanseller», «Ring oss for å avbestille», «Angre sletting», «Gjenopprett» eller lignende.

    Med utgangspunkt i teknikk G164 skal brukeren få informasjon

    • om tidsrommet for å reversere/angre innsendingen, for eksempel innen 24 timer
    • fremgangsmåten for å angre innsendingen

    Det skal faktisk la seg gjøre for brukeren å reversere/angre innsendingen, men det kreves ikke at denne prosessen er digital.

    Alternativ 2: Korrigere

    Brukeren skal ifølge ordlyden og teknikk G98 kunne endre/korrigere feil i inndata, i tilfeller der nettsiden kontrollerer om det finnes inndatafeil, og avdekker inndatafeil. Brukeren får anledning til å rette opp feilene før innsending.

    Alternativ 3: Bekrefte

    Før innsending har nettsiden en mekanisme som lar brukeren

    • gjennomgå all inndata
    • korrigere inndata
    • bekrefte inndata

    Brukeren skal kunne gjennomgå og ved behov oppdatere all inndata. Dette kan skje på ulike måter, for eksempel:

    • Skjemaet går bare over en nettside.
    • Det er mulig for brukeren å bla mellom sidene i skjemaet, og inndata ligger fortsatt i skjemaet når en navigerer fram og tilbake.
    • Brukeren får en samlet oppsummering av all inndata i skjemaet dersom skjemaet går over flere sider.

    Videre skal brukeren etter ordlyden og teknikk G155 jamfør teknikk G168 kunne bekrefte informasjonen før innsending.

    Mekanismen for å bekrefte informasjonen er et obligatorisk inndataelement, og skal i tillegg skal være separat fra mekanismen for å sende inn.

    En mekanisme for bekreftelse kan for eksempel være en avkryssingsboks med ledetekst «Jeg bekrefter at informasjonen er riktig», «Bekreft sletting» eller lignende.

    Det er flere måter å oppfylle kravet på.

    Krav til samsvar

    Etter ordlyden er det tilstrekkelig at ett av alternativene er oppfylt. Hvert alternativ har eget sett med krav til samsvar.

    Alternativ 1: Reversere

    • Etter innsending får brukeren beskjed om hvordan en kan reversere/angre innsendingen.
    • Innsending kan faktisk reverseres/angres.

    Alternativ 2: Kontrollere

    • Før innsending kontrollerer nettsiden om informasjon brukeren angir inneholder inndatafeil.
    • Dersom kontrollen avdekker inndatafeil, får brukeren faktisk korrigere disse.

    Alternativ 3: Bekrefte

    • Før innsending har nettsiden en mekanisme som lar brukeren
      • gjennomgå all informasjon
      • korrigere informasjon
      • bekrefte informasjon
    • Mekanismen for å bekrefte informasjon er separat fra den for innsending.
    • Mekanismen for bekreftelse er et obligatorisk inndataelement.

    Løsningsforslag og eksempler

    Du finner veiledning til dette kravet i løsningsforslagene:

    Merk at løsningsforslag for et tema kan dekke flere WCAG-krav.