Retningslinje
4.1.3 Statusbeskjeder
Suksesskriteriet har som formål å gjøre brukerne oppmerksomme på statusendringer.
Innholdet kan være utdatert
Hvorfor er suksesskriteriet viktig?
Med skjermleser vil bare en liten del av nettsiden vises av gangen (med punktskrift eller opplesing med syntetisk tale). Endringer som vises andre steder på siden, og som ikke får fokus, er vanskelige å oppdage når du bruker skjermleser. Hensikten med dette suksesskriteriet er å sikre at brukere gjøres oppmerksomme på dynamiske meldinger og statusendringer. Dette skal skje på en måte som ikke endrer fokus til skjermleseren, noe som kan være veldig forstyrrende for brukeren.
Dette suksesskriteriet er primært laget for å sikre at hjelpeteknologi får med seg synlig tekst som dukker opp på nettsiden. Kriteriet gjelder imidlertid også andre endringer:
Anbefalinger
Suksesskriterie 4.1.3 omhandler statusendringer. To ting avgjør om noe er en statusmelding/endring:
I denne artikkelen om suksesskriterium 4.1.3 betyr kontekstendring at fokus flyttes fra der brukeren er til et annet sted på siden. I WCAG har kontekstendring en mer omfattende definisjon.
Det kan legges til informasjon som ikke oppfyller definisjonen av en statusmelding. For eksempel regnes ikke søketreff som en statusoppdatering og dekkes derfor ikke av dette suksesskriteriet. Korte meldinger som vises om fullføringen eller statusen til søket, for eksempel "Søker...", "18 resultater funnet" eller "Ingen resultater funnet" er derimot statusoppdateringer hvis de ikke får fokus.
For å gi skjermlesere beskjed om statusmeldinger uten å flytte fokus brukes WAI-ARIA. Statusmeldinger/endringer legges i en div
(eller liknende) med ulike roller. Aktuelle roller og litt om hvordan disse fungerer i praksis med skjermlesere er beskrevet nedenfor:
Vi anbefaler at du bruker riktige semantiske roller, altså merker status med rollen som er riktigst i den konteksten statusendringen forekommer. Dessverre håndteres rollene litt forskjellig av ulike skjermlesere, og foreløpig har ingen skjermlesere utnyttet hele potensialet som ligger i disse rollene:
Morten har laget en testside der du også kan lese flere detaljer om skjermlesere og status-rollene.
Vanlige misforståelser
Når utviklere begynner å bruke WAI-ARIA er det en vanlig misforståelse at standarden skal brukes overalt og til alt mulig. Dette gjelder også rollene som er aktuelle i forbindelse med statusmeldinger/endringer: status
, alert
, log
, progressbar
, marquee
og timer
. Bruk disse rollene kun til det de er ment for og ikke ellers.
Har du for eksempel en expander som bruker aria-expanded=true/false
skal ikke innholdet som vises når expanderen utvides merkes som en statusendring. Gjør du et valg i et skjema som fører til at det vises nye felt skal ikke disse merkes som statusendring (det kan være tilfeller der du kan vurdere å gi en kort melding om at det har skjedd endringer). Meldinger som krever handlinger skal heller ikke merkes med disse rollene (vurder i så fall role=alertdialog). Eksempler på innhold som derimot skal merkes som statusmeldinger er:
Hvordan teste kravet?
Kjernespørsmålet
Får brukere, spesielt de som bruker skjermleserteknologi, beskjed om viktige endringer i innholdet uten at fokus endres?
Innhold du må teste
Statusmeldinger/endringer på siden.
Testmetode
Dette suksesskriteriet er det enklest å teste med en skjermleser. Du kan selvsagt sjekke kode, men ofte er det vanskelig å se om attributter er plassert helt riktig eller om ulike wai-aria egenskaper ødelegger for hverandre:
Enkelte statusendringer skal ikke leses opp automatisk, for eksempel regioner merket med role=marquee eller role=timer. Videre vet vi at skjermlesere håndterer wai-aria rollene forskjellig, og du bør egentlig sette deg inn i forventet virkemåte for den skjermleseren du tester med.
Ofte-stilte spørsmål
Les også
Medvirkende