Het nummer één principe in Jakob Nielsen’s 10 Heuristics of usability is ‘The visibility of System Status’ (NN/g, 1994). Het is dus belangrijk om de juiste systeemstatus en feedback te geven aan de gebruiker.
We gebruiken meldingen om voorwaarden te communiceren, een gebeurtenis aan te geven of feedback op gebruikersacties weer te geven. Zoals een toelichting, bevestiging, waarschuwing of foutmelding. Ze helpen gebruikers te begrijpen of ze (nog steeds) op weg zijn naar hun doel.
Zorg ervoor dat meldingen relevant, actueel en informatief zijn.
Wees terughoudend met meldingen gebruiken. Overmatig gebruik van meldingen, of meldingen die als storend worden ervaren, zorgen voor een frustrerende en ontmoedigende gebruikerservaring. Bovendien verlagen ze de aandacht van de gebruiker en worden belangrijke meldingen over het hoofd gezien. Dat noemen we ook wel meldingmoeheid.
Meldingen zijn grofweg in vier categorieën in te delen op basis van functionaliteit: Global, Sectional, Inline en Modal.
Global (banners) Banners verschijnen helemaal bovenaan het scherm en verschuiven de inhoud eronder. Ze geven informatie over de beschikbaarheid van het product.
Section (alerts) Plaats alerts op een bepaald gebied van een pagina of bovenaan een onderdeel waar ze bij horen. Ze geven contextuele feedback op acties van de gebruiker of laten belangrijke informatie zien.
Inline (validatie) Inline validatie is meteen te zien na een gebruikersactie. De feedback verschijnt dus in real time. De melding verschijnt bij het component en moedigt de gebruiker aan om meteen iets te doen.
Modal Modals onderbreken de flow van de gebruiker en vragen om actie. Ze zijn geschikt wanneer de gebruiker zijn aandacht moet richten op belangrijke informatie.
Beslissen wat je gaat gebruiken
Type melding | Functie van melding | Duur en interactie |
---|---|---|
Global (banners) | Systeemmeldingen die niet specifiek gekoppeld zijn aan een taak. | Blijven staan totdat de gebruiker ze verwijdert of het probleem is opgelost. |
Section (alerts) | Geven gebruikers niet-storende feedback of laten belangrijke systeemmeldingen zien. | Blijven staan totdat het probleem is opgelost. |
Inline (validatie) | Geven gebruikers niet-storende feedback voor specifieke invoer. | Blijven staan totdat het probleem is opgelost. |
Modals | Zeer storende meldingen die gebruikers essentiële informatie geven die hun aandacht of actie vereist. | Blokkeren andere taken totdat de gebruiker ze verwijdert. Modals staan meer interacties toe dan andere meldingen. |
Zorg ervoor dat screenreaders ook meldingen voor gebruikers kunnen voorlezen. Doe dat bijvoorbeeld door een ARIA role toe te voegen bij visuele meldingen, zoals een banner, alert of inline validatie. Hoe u dat het beste kunt doen, staat bij de componenten zelf.
Sr-only en ARIA roles Soms is het belangrijk dat de gebruiker veranderingen op het scherm ziet. Bijvoorbeeld ter bevestiging van een uitgevoerde actie of om de status van de applicatie te volgen. Dan is het vaak nodig om sr-only meldingen te geven of om de screen reader bepaalde veranderende informatie te laten voorlezen.
Sr-only meldingen zijn meldingen die wel door de screen reader worden uitgesproken maar niet op het scherm verschijnen.
Hiervoor zijn 2 technieken beschikbaar:
.sr-only
element in met role alert. Het effect is dat de screen reader uitspreekt “melding [tekst in element]”. Om problemen te voorkomen, is het belangrijk om deze alerts regelmatig ‘op te ruimen’. Bij een nieuwe alert moet de vorige alert in ieder geval eerst worden verwijderd.role="region"
en het attribuut aria-live="polite"
. Polite is de standaard prioriteit voor aria-live
attributen. In uitzonderlijke gevallen is de prioriteit “assertive” nodig.Houd zowel bij .sr-only
alerts als bij aria-live
regions de tekst zo kort mogelijk. De tekst wordt namelijk voorgelezen. Gebruik .sr-only
alerts voor eenmalige meldingen. Gebruik aria-live
regions juist om gebruikers doorlopend van een status op de hoogte te houden.
Ter illustratie twee voorbeelden van hoe belangrijk deze elementen zijn:
.sr-only
alert “[productnaam] verwijderd” dat bevestigen.aria-live
region van maakt, wordt het aantal resultaten steeds voorgelezen, ook als het verandert..sr-only
meldingen en aria-live
regions gebruiken is maatwerk. Betrek er altijd iemand met genoeg screenreader-ervaring bij als u dit soort meldingen gaat maken en testen. De toegankelijkheidsexpert van het DSO is bijvoorbeeld zo iemand.
Test met een screenreader
Pas op dat u de gebruiker niet overbelast met informatie. Blinde mensen gebruiken een website fundamenteel anders dan ziende mensen. Daarom is het belangrijk om te begrijpen hoe screenreaders werken. De ARIA role="alert"
onderbreekt bijvoorbeeld de flow van de screenreader. Gebruik hem dus alleen als het echt nodig is. Het allerbeste zou zijn om de applicatie te laten testen door blinde gebruikers. Zo weet u meteen of de applicatie toegankelijk is voor deze doelgroep.