KORT FORTALT: Brukeren skal få statusbeskjeder om viktige endringer på nettsiden uten at det gir kontekstendring.
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.
I innhold som implementeres ved hjelp av oppmerkingsspråk, kan statusbeskjeder bestemmes programmatisk gjennom rolle eller egenskaper, slik at de kan presenteres for brukeren med hjelpemiddelteknologi uten å få fokus.
Formål
Hensikten med kravet er å gjøre brukeren oppmerksom på viktige endringer i innholdet (statusbeskjeder). Det skal videre skje på en måte som ikke forstyrrer eller avbryter brukeren, endringen i innholdet skal derfor ikke medføre kontekstendring.
Brukerbehov
Kravet er ment å ivareta personer som er blinde, har nedsatt syn eller nedsatt kognisjon.
Tilsynets tolking
For at kravet skal gjelde er forutsetningen for det første at beskjeden ikke fører til en kontekstendring. Dette følger både av definisjonen av statusbeskjed, og av at den skal presenteres uten å få fokus.
Kravet omfatter kun statusbeskjeder.
Begrepene Statusbeskjeder, Bestemmes programmatisk, Rolle og Hjelpemiddelteknologi er definert i WCAGs ordliste. Det samme gjelder Kontekstendring, som ikke inngår i ordlyden, men likevel er sentralt for forståelsen av suksesskriteriet.
Statusbeskjeder inkluderer etter definisjonen fire ulike situasjoner, der brukeren får informasjon om én av følgende
- resultatet av en handling
- ventetilstand i en løsning
- feilmeldinger
- framdriften i en prosess
De fire forskjellige statusbeskjedene har ulik prioritet. Derfor er det viktig å sette rett rolle eller andre egenskaper til riktig situasjon, jamfør teknikkene til kravet.
Ifølge forståartikkelen er kravet med hensikt formulert slik at det først og fremst gjelder når ny tekst legges til (blir synlig) på nettsiden. Dersom det kommer ny tekst, skal denne informasjonen være tilgjengelig for alle brukere.
Ved at statusbeskjeden får tilgjengelig navn (bestemmes programmatisk) kan den presenteres av hjelpemiddelteknologi, slik at alle brukere får tilgang til samme informasjon.
Endringer av innhold i statusmeldingen er ikke begrenset til tekst, men kan ifølge forståartikkelen også omfatte bilder og lyd.
Ikke alle endringer av innhold innebærer at det vises ny tekst på nettsiden. Følgende situasjoner er ifølge forståartikkelen likevel omfattet av kravet:
- Tekst som bare vises eller leses opp av hjelpemiddelteknologi.
- Endringer i eksisterende statusbeskjed - hele statusbeskjeden bør vanligvis leses opp ikke bare endringen, slik at brukeren får tilstrekkelig kontekst.
- En eksisterende statusbeskjed blir fjernet.
- Ikke tekstlige statusbeskjeder, for eksempel lyd eller ikoner, som skal oppfylle suksesskriterium 1.1.1 Ikke-tekstlig innhold i tillegg til 4.1.3.
Mindre viktig informasjon kan presenteres for brukeren når vedkommende er ledig. Det vil si at informasjonen gis senere og kan utsettes av hjelpemiddelteknologi.
Det er flere måter å oppfylle kravet på.
Krav til samsvar
For statusbeskjeder, som implementeres ved hjelp av oppmerkingsspråk, gjelder følgende:
- Resultatet av en handling skal kodes med én av følgende:
- role="status"
- aria-live="polite"
- Ventetilstand skal kodes med én av følgende:
- role="status"
- aria-live="polite"
- Feil skal kodes med én av følgende:
- role="alert"
- aria-live="polite"
- aria-live="assertive"
- Fremdriften i en prosess skal kodes med én av følgende:
- role="progressbar"
- elementet <progress>
- role="log"
- role="status" og aria-atomic="false"
- aria-live="polite" og aria-atomic="false"
Krav til samsvar gjelder tilsvarende for apper og dokumenter.
Når det gjelder apper, gjelder kravet kun dersom appen er kodet i et oppmerkingsspråk, jamfør ordlyden i suksesskriteriet. Per i dag gjelder suksesskriteriet derfor ikke for hybride eller native apper.
Kommentar
Eksempler på endringer i innholdet som er statusbeskjeder:
- Informasjon om søketreff etter at brukeren gjør et søk på nettstedet.
- Informasjon om hvor mange varer som ligger i handlekurven, etter at brukeren har lagt en ny vare.
- Feilmeldinger ved utfylling med feil inndata i skjema.
- Informasjon om at deler av innholdet laster, etter at brukeren har aktivert en prosess.
- Framdriftsanimasjon som viser hvor langt deler av innholdet er kommet med å laste inn.
- Etter innsending av skjema, får brukeren opp en tekst som sier at skjemaet er sendt inn.
- Informasjon om at bildet er lagret i et digitalt fotoalbum etter at brukeren har lagt til et nytt bilde.
Eksempler på endringer i innholdet som ikke er omfattet av kravet, fordi de ikke regnes som statusbeskjeder er:
- Alle endringer som medfører kontekstendring, for eksempel:
- Modalvindu
- Åpne et nytt vindu
- Flytte fokus til en annen brukergrensesnittkomponent
- Gå til en ny side
- Betydelig endring av innholdet på en side
- Innhold som kommer til syne eller blir gjemt når brukeren bruker innholdet, for eksempel en meny eller et trekkspill.
- Sporvalg i skjema, der nye skjemafelt blir lagt til basert på det brukeren svarer.
Når det gjelder hvilke roller og egenskaper som vurderes, legger tilsynet til grunn at statusmeldinger som hovedregel skal kodes i samsvar med teknikkene det blir vist til for kravet, eller med tilsvarende roller eller egenskaper, jamfør Accessible Rich Internet Applications (WAI-ARIA) 1.2 (W3C, engelsk).
Løsningsforslag og eksempler
Du finner veiledning til dette kravet i løsningsforslaget: