Statusberichten

Wat wordt vereist

Wanneer de pagina de gebruiker informeert dat er iets is gebeurd — „Artikel aan winkelwagen toegevoegd“, „3 resultaten gevonden“, „Verbinding verbroken“, „Opslaan…“ — moet dat bericht schermlezersgebruikers bereiken zonder dat de focus gedwongen wordt te verschuiven. De informatie moet programmatisch worden vastgelegd als een status, zodat hulptechnologie deze kan opvangen en aankondigen.

Drie categorieën die WCAG benoemt:

• Succes / voltooiing — „Profiel opgeslagen“, „E-mail verzonden.“
• Resultaten van een actie — „12 resultaten“, „Geen overeenkomsten gevonden.“
• Toestand van de applicatie — „Opslaan…“, „Opnieuw verbinden“, „Upload 40%.“

Hoe te voldoen

• Plaats bij het laden van de pagina een live-regio in de DOM — een leeg element met role="status" (vriendelijk) of role="alert" (dwingend). Schrijf bij een update de nieuwe tekst erin.
• Gebruik voor niet-kritieke bevestigingen en resultattentallen role="status" of aria-live="polite". Schermlezers wachten tot de gebruiker inactief is, en kondigen dan aan.
• Gebruik voor kritieke berichten — formulierinzendingsfouten, verbindingsverlies, sessie die op het punt staat te verlopen — role="alert" of aria-live="assertive". De aankondiging onderbreekt.
• Toastmeldingen hebben een live-regio nodig. De toastcontainer moet in de DOM aanwezig zijn voordat de toast verschijnt, met aria-live ingesteld, en de toasttekst wordt als onderliggend element ingevoegd.
• Combineer aria-live met aria-atomic="true" als u wilt dat de gehele regio bij elke update opnieuw wordt voorgelezen, niet alleen de gewijzigde knooppunten.
• Voor formulierfouten kan het inline foutbericht role="alert" gebruiken, of de focus kan worden verplaatst naar een samenvatting boven aan het formulier — maar doe niet beide; gebruikers hoeven het maar één keer te horen.

Veelvoorkomende fouten

• Toastmeldingen die worden weergegeven in een element dat nog niet bestond vóór de toast — de live-regio-listener wordt nooit gekoppeld, er wordt niets aangekondigd.
• Een successbanner die wordt ingevoegd maar buiten elke aria-live-regio valt — zichtbaar voor ziende gebruikers, onzichtbaar voor schermlezersgebruikers.
• Aantal zoekresultaten („12 van 340 weergegeven“) dat na filteren stilzwijgend wordt bijgewerkt. Gebruikers navigeren met Tab terug naar de resultaten zonder zekerheid of er iets is veranderd.
• Formuliervalidatie die een inline <span class="error"> bijwerkt zonder role="alert" of aria-live — fout verschijnt, schermlezer blijft stil.
• aria-live="assertive" gebruiken voor elke statusupdate. Constante onderbrekingen; schermlezersgebruikers schakelen de pagina uit.
• Focus verplaatsen naar een statusbericht dat geen kop of interactief element is — focus belandt op een niet-tabbaar element, toetsenbordgebruikers raken hun positie kwijt.
• „Opslaan…“ / „Opgeslagen“-indicatoren die een CSS-klasse omschakelen maar nooit tekstinhoud binnen een live-regio bijwerken.

Waarom het belangrijk is

Statusberichten zijn waar moderne single-page applicaties tekortschieten. De pagina herlaadt nooit, de focus verschuift zelden, en het enige signaal dat er iets is gebeurd is een visuele wijziging — nutteloos voor iedereen die niet naar het scherm kijkt. 4.1.3 dwingt pariteit af: als een ziende gebruiker „Aan winkelwagen toegevoegd“ kan zien, kan een schermlezersgebruiker het horen. De oplossing is bijna altijd goedkoop (één live-regio, gevuld bij elke update) en de afwezigheid ervan doorbreekt vrijwel altijd kernstromen — afrekenen, zoeken, formulierinzending, realtime chat.