Je export is klaar. Hoort je gebruiker dat ook?

Je klikt op Export maken. Een draaicirkel verschijnt, verdwijnt en ergens rechtsboven staat “Klaar”. Wie het scherm ziet, begrijpt misschien wat er gebeurt. Wie ondertussen met een screenreader door de filters navigeert, krijgt mogelijk niets mee. Het proces is afgerond, maar de terugkoppeling niet.

Een statusmelding vertelt wat er gebeurt zonder de gebruiker naar een andere plek te sturen. Denk aan zoeken, opslaan of een bestand voorbereiden. De ontwerpvraag is niet hoe opvallend je melding kan worden, maar welke informatie iemand nodig heeft om met vertrouwen door te werken. Dit artikel behandelt die terugkoppeling, niet het openen en sluiten van dialoogvensters.

Ontwerp eerst de toestanden, daarna de melding

Begin met een kleine lijst: klaar om te starten, bezig, gelukt, mislukt en uitkomst onbekend. Die laatste toestand voorkomt een belangrijke leugen. Een weggevallen verbinding bewijst niet dat de server niets heeft gedaan. Schrijf daarom alleen “Export mislukt” als de applicatie dat werkelijk weet. Anders past “We kunnen de status nog niet bevestigen. Controleer je exports voordat je opnieuw begint.”

W3C legt bij WCAG 4.1.3 uit dat relevante statusinformatie zonder focusverplaatsing programmatisch herkenbaar moet zijn. Een gewone tekstwijziging of een andere kleur is daarvoor niet altijd voldoende. Een korte melding over een afgeronde zoekactie is iets anders dan de hele bijgewerkte resultatenlijst. Kondig de uitkomst aan; maak niet automatisch alle nieuwe inhoud tot een livebericht.

Een export van begin tot einde

INVOER
Een fictieve gebruiker filtert een orderoverzicht op november en kiest Export maken. De export duurt enkele seconden. De gebruiker blijft op dezelfde pagina en kan de filters blijven lezen.

TOESTANDEN
Start: “Export voor november wordt voorbereid.”
Bevestigd resultaat: “Export voor november klaar: 38 orders. Download beschikbaar.”
Bevestigde fout: “Export niet gemaakt. Probeer het opnieuw.”
Onzeker resultaat: “Status van de export onbekend. Controleer eerst je exportoverzicht.”

CONTROLE
De melding is zichtbaar en wordt via de afgesproken screenreadercombinaties begrijpelijk aangekondigd. De toetsenbordfocus blijft waar de gebruiker werkt. De downloadlink is apart bereikbaar en duidelijk benoemd.

Gebruik een rustige, bestaande statusregio

Voor niet-dringende voortgang en resultaten is role="status" een passende mogelijkheid. De rol heeft volgens WAI-ARIA impliciet aria-live="polite" en aria-atomic="true". Polite is bedoeld om een aankondiging op een geschikt moment te laten plaatsvinden, zonder de huidige activiteit onnodig te onderbreken. Het is geen garantie dat iedere gebruiker onmiddellijk exact dezelfde gesproken zin hoort.

W3C-techniek ARIA22 adviseert de statuscontainer al aanwezig te laten zijn voordat de melding ontstaat. Verander vervolgens de inhoud van die container. Als de hele zin nodig is voor begrip, adviseert de techniek expliciet aria-atomic="true", omdat niet elke omgeving de standaardwaarde hetzelfde behandelt. Zo voorkom je dat alleen “38” wordt aangekondigd terwijl “orders geëxporteerd” ontbreekt.

1. Plaats één herkenbare statusregio bij het proces voordat de gebruiker begint. Houd de tekst ook zichtbaar voor mensen die geen screenreader gebruiken.
2. Werk die regio bij op betekenisvolle toestandsovergangen. Vermijd een nieuw bericht voor ieder percentage of ieder ontvangen datablok.
3. Geef de melding voldoende context: welk proces, welke selectie en welk resultaat? “Klaar” is zelden zelfstandig begrijpelijk.
4. Houd bedienbare vervolgstappen, zoals een downloadlink of opnieuw-proberenknop, apart bereikbaar. Verplaats de focus niet alleen om een succesmelding voor te lezen.
5. Koppel de melding aan de actuele aanvraag. Een laat antwoord op een oudere selectie mag niet doen alsof de huidige selectie klaar is.

Test meer dan de juiste attributen

Een controle van de HTML is noodzakelijk, maar vertelt niet hoe het geheel wordt ervaren. Test met toetsenbord en de browser-screenreadercombinaties die jouw doelgroep gebruikt. Leg de versies en waarnemingen vast. Laat de tester na de start verder navigeren en vraag vervolgens wat er gebeurde en welke volgende stap beschikbaar is. Daarmee toets je begrip in plaats van alleen aanwezigheid.

Voeg bewust een trage verbinding, een fout, twee snel opeenvolgende aanvragen en een onbekende serveruitkomst toe. Controleer ook dat een her-render niet dezelfde melding steeds opnieuw laat horen. Een melding die na enkele seconden verdwijnt, kan gemist worden. Laat de uitkomst daarom terugvindbaar bij het proces staan, zeker wanneer iemand een vervolgstap moet kiezen.

Wanneer is deze terugkoppeling bruikbaar?

• Bezig, succes, fout en onzekerheid hebben verschillende, feitelijk juiste teksten.
• De volledige noodzakelijke context wordt aangekondigd in de geteste combinaties; alleen kleur of een los getal volstaat niet.
• De focus verspringt niet bij een gewone statusupdate en alle vervolgstappen blijven met het toetsenbord bereikbaar.
• Een oudere aanvraag kan de status van een nieuwere aanvraag niet overschrijven.
• De test geeft geen overmatige herhalingen en de definitieve uitkomst blijft terugvindbaar.

Dit is geen volledige toegankelijkheidsaudit en role="status" is niet voor iedere melding de juiste rol. Dringende waarschuwingen, invoerfouten en lange voortgangsprocessen vragen een eigen afweging. Voor gewone asynchrone resultaten is de winst al concreet: dezelfde begrijpelijke informatie, zonder dat de interface het werk van de gebruiker overneemt.