[Statusbeskjeder kan] bestemmes programmatisk gjennom rolle eller egenskaper, slik at de kan presenteres for brukeren med [skjermleser] uten å få fokus.
Hvorfor er suksesskriteriet viktig?
Hensikten med dette suksesskriteriet er å sikre at skjermlesere gjør brukere oppmerksomme på dynamiske meldinger og statusendringer.
Med skjermleser kan du bare lese noen få tegn av gangen i punktskrift eller høre ett og ett ord med syntetisk tale. Endringer som vises andre steder på siden enn der brukeren befinner seg, og som ikke får fokus, er vanskelige å oppdage. Statusbeskjeder skal kunne formidles uten at skjermleserfokus endres fordi det blir forstyrrende for brukeren. Hvis skjermleserfokus endres må brukeren ofte lete seg tilbake til det han holdt på med før fokusendringen.
Hva er en statusbeskjed?
To ting avgjør om noe er en statusbeskjed:
Meldingen gir informasjon til brukeren om suksessen eller resultatene av en handling, om ventetilstanden til en applikasjon, om fremdriften til en prosess, eller om at det finnes feil.
Meldingen gis ikke gjennom en kontekstendring.
Det er ikke bare visuelle tekstmeldinger som er statusbeskjeder:
Meldinger eller tilleggsinformasjon som kun vises for skjermlesere
Endringer i statustekst (for eksempel et nummer som oppdateres)
Fjerning av statustekst (for eksempel meldinger av typen «Vent litt mens systemet oppdateres!»). Da kan det være fint med en beskjed om at ventetiden er over.
Ikke-tekstlig statusinnhold (grafikk)
Det kan legges til dynamisk innhold som ikke oppfyller definisjonen av en statusbeskjed. 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.
Anbefalinger
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:
Viktige og ofte tidssensitive meldinger. alert gir også et alternativ for hørselshemmede ved lydadvarsler.
Default: aria-live=assertive, aria-atomic=true
Statuslinje eller meldinger som ikke er like viktige som alert.
Default: aria-live=polite, aria-atomic=true
En type live-region der nye meldinger legges til på slutten.
For at log skal virke må du bruke appendChild (eller liknende), ikke eksisterende-tekst=eksisterende-tekst+ny-tekst.
Default: aria-live=polite
En framdriftslinje som vanligvis bruker litt tid på å bli ferdig. Du skal sette aria-valuemin, aria-valuemax, aria-valuenow og eventuelt aria-valuetext.
Default: aria-live=polite
Et område der det dukker opp endringer som ikke er sekvensielle (i kontrast til log).
Default: aria-live=off
Viser tid medgått fra starttidspunktet eller gjenværende tid.
Default: aria-live=off
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:
De fleste skjermlesere håndterer status og alert veldig likt. Vi anbefaler likevel at du bruker disse rollene på riktig måte.
Ingen skjermlesere så langt vi kjenner til gjør noe som helst med timer og marquee (har eksempelvis ikke hurtigtaster for å flytte til slike regioner). Her anbefaler vi også at rollene benyttes. Det vil gi økt effektivitet og brukervennlighet for skjermleserbrukere dersom det kommer ny funksjonalitet i skjermleserne.
progressbar håndteres ganske ulikt av ulike skjermlesere. Selv om Windows skjermleser ikke takler aria-valuetext bør dette attributtet vurderes. I mange sammenhenger vil aria-valuetext øke brukervennligheten til både Jaws, NVDA og VoiceOver.
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 statusbeskjeder: 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 statusbeskjed. 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:
"Antall søketreff: 88"
"Vent mens vi henter persondata." Her er det også fint med en skjult statusmelding som sier "Persondataene er nå innhentet" når meldingen forsvinner.
"Obs. Skjemaet inneholder 2 feil: epost mangler og telefonnummeret har for mange siffer."
Hvordan teste kravet?
Kjernespørsmålet
Får brukere, spesielt de som bruker skjermleser, beskjed om viktige endringer i innholdet uten at fokus endres?
Innhold du må teste
Statusbeskjeder/endringer på siden.
Testmetode
Dette suksesskriteriet er det sannsynligvis 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:
Start en skjermleser.
Åpne siden og gjør det som må til for å få fram statusbeskjeder.
Blir statusmeldingen lest opp automatisk av skjermleseren uten at fokus flyttes fra der du er?
Noen status-roller leses ikke opp automatisk (i alle fall foreløpig), 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
Alert-komponenten presenteres som vanlig statisk innhold for skjermleserbrukere. Benyttes variant="error" er det sannsynlig at beskjeden krever brukerens umiddelbare oppmerksomhet eller handlinger. Da kan du legge til role="alert" som gjør at innholdet i komponenten leses opp umiddelbart.
Hvis du bruker variant="warning" eller variant="success", kan du vurdere å bruke role="status". Da skal skjermlesere gjøre seg ferdig med det som leses før innholdet i Alert leses opp.
Ved bruk av varianten "info" trengs ikke role="alert" eller role="status".
Nei, status-rollene skal bare brukes når du ikke flytter fokus. Statusbeskjeder kan presenteres på forskjellig måte. Med syntetisk tale leses beskjeden. Leselister (punktskrift) kan for eksempel vise statusbeskjeden i noen sekunder og så returnere dit brukeren var.
Er det greit å merke flere regioner med alert eller status, for eksempel flere felt med feil i et skjema?
Det er ikke direkte feil å merke flere regioner med status-roller. I praksis blir det imidlertid skjelden bra for brukeren, og meldingene har en tendens til å slå hverandre ihjel. I skjemaer anbefaler vi heller å bruke ErrorSummary.