4.1.3 Statusberichten niveau AA

Uitleg

Het WCAG-criterium 4.1.3 Statusberichten richt zich op het effectief communiceren van dynamische inhoud of statusveranderingen die plaatsvinden op een webpagina. Dit geldt voor situaties waarbij de status van een element of de pagina verandert, bijvoorbeeld wanneer een formulier wordt ingediend, er een fout optreedt, of wanneer er andere visuele updates plaatsvinden die voor de gebruiker belangrijk zijn om te weten.

Dit criterium zorgt ervoor dat gebruikers van assistieve technologieën, zoals schermlezers, altijd op de hoogte worden gebracht van dergelijke veranderingen. Wanneer de status van een pagina of een interactief element verandert, moet de gebruiker hierover geïnformeerd worden, zonder dat ze handmatig hoeven te zoeken of te raden wat er veranderd is.

Wat houdt het in?

Volgens dit criterium moeten statusberichten (zoals foutmeldingen, bevestigingsberichten of updates) op een manier worden gepresenteerd dat ze toegankelijk zijn voor gebruikers van assistieve technologieën. Dit betekent dat de verandering van status op een duidelijke en tijdige manier moet worden gecommuniceerd.

Dit kan bijvoorbeeld het geval zijn wanneer:

• Een formulier succesvol is ingediend of er een fout optreedt.
• Er een systeemfout is of een bewerking niet kan worden uitgevoerd.
• De status van een bepaalde taak wordt bijgewerkt, zoals een voortgangsbalk.

Hoe voldoet men aan dit criterium?

Om aan criterium 4.1.3 te voldoen, moet de applicatie of website ervoor zorgen dat statusveranderingen op een duidelijke manier worden gepresenteerd aan de gebruiker. Dit kan onder andere door:

1. Gebruik van ARIA-live-regionen: Wanneer een statusbericht moet worden gepresenteerd, kan een ARIA-live region worden gebruikt om het bericht automatisch en onmiddellijk aan een schermlezer door te geven.

   Het aria-live attribuut kan worden ingesteld om aan te geven hoe belangrijk de update is:

   • aria-live="polite": De boodschap wordt pas uitgesproken wanneer het andere, minder urgente werk is afgerond.
   • aria-live="assertive": De boodschap wordt onmiddellijk uitgesproken, ongeacht wat er al op dat moment wordt gelezen door de schermlezer.

   Bijvoorbeeld:

   <div aria-live="polite">Formulier succesvol verzonden!</div>

2. Zorg ervoor dat foutmeldingen goed worden gepresenteerd: Wanneer er een fout optreedt, moet dit direct aan de gebruiker worden gecommuniceerd. Dit kan worden gedaan door visuele meldingen te koppelen aan aria-describedby of aria-invalid, zodat schermlezers ook een melding krijgen van de fout.

   Bijvoorbeeld:

   <input type="text" aria-invalid="true" aria-describedby="error-message" />
   <div id="error-message" role="alert">Dit veld is verplicht.</div>

3. Gebruik visuele en tekstuele meldingen: Zorg ervoor dat fout- of succesberichten zowel visueel als voor schermlezers beschikbaar zijn. Een melding in een alert-box moet zowel visueel zichtbaar zijn als toegankelijk zijn voor schermlezers.

4. Voeg context en verduidelijking toe: Het is belangrijk om statusberichten te voorzien van duidelijke uitleg, zodat gebruikers precies weten wat er gebeurd is, wat ze moeten doen of welke actie ze moeten ondernemen.

   Bijvoorbeeld:

   <div role="alert" aria-live="assertive">Fout bij het verzenden van je formulier. Probeer het later opnieuw.</div>

5. Real-time updates communiceren: Als er dynamische updates plaatsvinden (bijvoorbeeld bij live zoekresultaten), moet de gebruiker automatisch op de hoogte worden gebracht van nieuwe informatie die in de interface verschijnt.

Voorbeelden van het probleem

• Een foutmelding die enkel visueel wordt gepresenteerd zonder enige vorm van communicatie naar gebruikers van schermlezers, waardoor ze de melding niet kunnen horen of begrijpen.
• Een voortgangsbalk die de status van een taak weergeeft, maar die geen feedback geeft aan assistieve technologie wanneer deze is bijgewerkt.

Oplossingen voor dit probleem

Om te zorgen dat de statusberichten correct toegankelijk zijn, moet je:

• ARIA-live-regionen gebruiken om statusberichten automatisch te laten voorlezen door schermlezers.
• Verduidelijking en uitleg bieden bij statusveranderingen, vooral bij foutmeldingen.
• Visuele en tekstuele meldingen combineren om de toegankelijkheid te verbeteren.

Voorbeeld van een correct geïmplementeerde statusmelding

<form id="contact-form">
  <label for="email">E-mail:</label>
  <input type="email" id="email" name="email" required />

  <button type="submit">Verzenden</button>

  <!-- Status bericht na versturen -->
  <div id="status-message" role="alert" aria-live="assertive">
    Je formulier is succesvol verzonden! We nemen snel contact met je op.
  </div>
</form>

In dit voorbeeld wordt een succesvol verzonden bericht weergegeven en toegankelijk gemaakt met de role="alert" en aria-live="assertive" voor onmiddellijke aankondiging door schermlezers.

Hulpmiddelen voor testen

• Axe Accessibility Tool: Met deze tool kun je de toegankelijkheid van je statusberichten testen en controleren of ze voldoen aan de WCAG-vereisten.
• NVDA of JAWS: Gebruik schermlezers zoals NVDA of JAWS om te testen of statusberichten effectief en tijdig aan gebruikers worden gepresenteerd.
• WAVE Tool: WAVE kan helpen om te controleren of statusberichten correct zijn geïmplementeerd en toegankelijk zijn voor gebruikers van assistieve technologieën.

Referenties

• WCAG 2.2 Richtlijn 4.1.3 Statusberichten: Bekijk de officiële WCAG-documentatie voor meer details over dit criterium.