Screenreaders en WordPress testen: complete gids

Screenreaders en WordPress testen doe je door belangrijke pagina’s te doorlopen met een screenreader, naast een toetsenbordtest en een automatische scan. Kies minimaal NVDA op Windows of VoiceOver op Apple-apparaten, test realistische taken zoals navigeren en een formulier versturen, en leg per probleem vast wat de screenreader aankondigt, wat er verwacht werd en waar het probleem optreedt. Een enkele test bewijst niet dat je website volledig toegankelijk of WCAG-conform is.

Wat is screenreader-testen?

Een screenreader zet informatie op een scherm om in spraak of braille. Bezoekers gebruiken zo onder meer koppen, links, formulieren en landmarks om snel door een pagina te navigeren. Voor een WordPress-site is dat relevant omdat de toegankelijkheid niet alleen afhangt van de teksteditor. Ook het thema, page builder-blokken, navigatiemenu’s, formulieren, cookiebanners en plugins bepalen wat een screenreader kan lezen en bedienen.

Screenreader-testen maakt problemen zichtbaar die een visuele controle vaak mist. Denk aan een knop zonder naam, een formulierinvoer zonder gekoppeld label, een menu dat niet aangeeft of het is geopend, of een foutmelding die wel op het scherm staat maar niet wordt voorgelezen.

Waarom automatische scans niet genoeg zijn

Een automatische toegankelijkheidsscan is nuttig om technische signalen te vinden, maar beoordeelt niet betrouwbaar of een tekst begrijpelijk is, een leesvolgorde logisch voelt of een melding op het juiste moment wordt aangekondigd. W3C adviseert daarom een combinatie van hulpmiddelen en menselijke evaluatie.

Zie de vier controlevormen als aanvullend:

• Automatische scan: vindt een deel van de programmeerbare fouten, zoals ontbrekende attributen of contrastsignalen.
• Toetsenbordtest: controleert of interactieve onderdelen bereikbaar en bedienbaar zijn zonder muis.
• Screenreader-test: controleert wat de bezoeker hoort en hoe structuur, bediening en feedback worden aangekondigd.
• Test met gebruikers: geeft inzicht in de praktijkervaring van mensen die afhankelijk zijn van hulptechnologie.

Welke screenreader kies je?

Begin met de combinatie die past bij je eigen apparaat en gebruik daarna, waar mogelijk, een tweede combinatie voor belangrijke processen. Uitkomsten kunnen verschillen per besturingssysteem, browser, thema en plugin. Noteer daarom altijd welke combinatie je hebt gebruikt.

Testcombinatie	Praktische inzet	Waar let je extra op?	Prioriteit
NVDA op Windows	Basiscontrole van belangrijke WordPress-pagina’s en formulieren	Koppen, landmarks, links, formulierlabels, foutmeldingen en leesvolgorde	Start hier als je met Windows werkt
VoiceOver op macOS	Controle op een Mac, vooral voor navigatie en interactieve componenten	Naam en status van knoppen, menu’s, dialoogvensters en accordeons	Gebruik voor een aanvullende controle
VoiceOver op iPhone of iPad	Controle van mobiele navigatie, formulieren en overlays	Swipe-volgorde, bedieningslabels, focus en mobiele cookie- of chatbanners	Gebruik bij mobiel belangrijk verkeer
Toetsenbord zonder screenreader	Voorafgaand aan elke screenreader-test	Zichtbare focus, logische tabvolgorde, openen en sluiten van onderdelen	Altijd uitvoeren

Test niet alleen de homepage. Selecteer ten minste een pagina met een dienst, een pagina met een formulier en een pagina met interactieve onderdelen. Ook foutpagina’s verdienen aandacht: een toegankelijke 404-pagina en een goede aanpak voor soft-404-fouten helpen bezoekers wanneer een URL niet meer bestaat.

Screenreaders en WordPress testen: stappenplan

1. Kies een concrete taak. Bijvoorbeeld: een dienst vinden, een offerte aanvragen, een artikel zoeken of een afspraakformulier verzenden. Een taakgerichte test voorkomt dat je alleen losse technische signalen verzamelt.
2. Maak een testlijst van pagina’s en componenten. Neem de homepage, hoofdnavigatie, een dienstenpagina, contactformulier, zoekfunctie en belangrijke pop-ups of cookieconsent mee.
3. Test eerst met alleen het toetsenbord. Gebruik Tab, Shift+Tab, Enter, Spatie en Escape. Controleer of je elk interactief element bereikt, begrijpt en weer kunt verlaten.
4. Start de screenreader en begin bovenaan de pagina. Luister naar de paginatitel en controleer of de eerste aankondigingen aansluiten op de inhoud van de pagina.
5. Navigeer op structuur. Spring door koppen, landmarks, links en formuliervelden. De screenreader moet een bruikbare inhoudsstructuur aanbieden, niet alleen een lange reeks losse elementen.
6. Voer de gekozen taak uit. Open het menu, volg een link, gebruik een filter, vul een formulier in en verstuur het. Test ook foutieve invoer om foutmeldingen te beoordelen.
7. Test dynamische onderdelen apart. Open een accordion, modal, mobiel menu of zoekresultaat. Controleer of de screenreader de verandering aankondigt en of de focus logisch blijft.
8. Leg bevindingen reproduceerbaar vast. Noteer URL, taak, gebruikte combinatie, verwachte uitkomst, feitelijke aankondiging en het onderdeel dat aangepast moet worden.
9. Herstel en hertest. Pas niet blind een ARIA-attribuut toe. Controleer na elke wijziging opnieuw met toetsenbord én screenreader.

Controlepunten tijdens de test

Paginatitel, koppen en landmarks

De paginatitel moet duidelijk maken waar de bezoeker is. Daarna moet de koppenstructuur de inhoud logisch opdelen. Een bezoeker moet bijvoorbeeld snel kunnen springen naar de hoofdinhoud, navigatie, zoekfunctie of voettekst wanneer die onderdelen aanwezig zijn. Koppen mogen niet alleen zijn gekozen omdat ze visueel mooi ogen.

Navigatie, skiplink en linkteksten

Controleer of een eventuele skiplink vroeg op de pagina beschikbaar komt en de bezoeker naar de hoofdinhoud brengt. Loop daarna door het menu. Is duidelijk welk item een submenu opent? Wordt de geopende of gesloten status begrijpelijk aangekondigd? Controleer ook linkteksten buiten hun visuele context. Een reeks links met alleen “lees meer” is voor screenreadergebruikers vaak niet onderscheidend.

Afbeeldingen en alternatieve teksten

Een inhoudelijke afbeelding heeft een passend tekstalternatief nodig. Een decoratieve afbeelding hoort juist geen overbodige informatie toe te voegen. Luister dus of een afbeelding nuttige context geeft en niet alleen een bestandsnaam, herhaling of technische omschrijving oplevert. Lees ook onze gids over afbeeldingen optimaliseren in WordPress voor het beheer van afbeeldingen in je mediabibliotheek.

Formulieren, labels en foutmeldingen

Ga veld voor veld door een formulier. Elk veld moet een duidelijk label hebben, ook als er een placeholder zichtbaar is. Vereiste velden en invoerinstructies moeten vóór verzending begrijpelijk zijn. Verstuur vervolgens bewust onvolledige of onjuiste gegevens. De screenreader moet de foutmelding kunnen aankondigen, duidelijk maken welk veld aangepast moet worden en de bezoeker helpen het probleem te herstellen.

Knoppen, menu’s, modals en accordeons

Een knop moet een naam hebben die de actie beschrijft. Bij een uitklapbaar onderdeel moet de screenreader kunnen herkennen dat het om een knop gaat en of het onderdeel open of dicht staat. In een modal moet de focus bij openen naar de dialoog gaan en bij sluiten logisch terugkeren. Controleer dat ook met Escape en met het toetsenbord.

Leesvolgorde, focus en statusupdates

Wat de screenreader leest, moet overeenkomen met een betekenisvolle volgorde. Vooral kolommen, contentblokken van page builders, sticky elementen en mobiele varianten kunnen voor een onverwachte leesvolgorde zorgen. Bij een zoekresultaat, winkelmandwijziging of formulierstatus moet relevante feedback worden aangekondigd zonder dat de bezoeker die per ongeluk mist.

Veelvoorkomende problemen in WordPress

• Een logo of icoonlink zonder toegankelijke naam.
• Een menuknop die visueel verandert, maar de geopende status niet doorgeeft.
• Een formulierlabel dat alleen als placeholder bestaat.
• Een foutmelding die onderaan het formulier verschijnt zonder aankondiging.
• Een popup waarbij de focus achter de popup blijft staan.
• Een accordion die inhoud toont maar geen status communiceert.
• Een page builder-layout waarvan de technische leesvolgorde afwijkt van de visuele volgorde.
• Een plugin die een eigen widget toevoegt met onduidelijke knoppen of ontoegankelijke overlays.

Dit zijn geen problemen die je betrouwbaar oplost door alleen visueel te beoordelen. Daarom hoort toegankelijkheid thuis in de keuzes voor ontwerp, content en ontwikkeling. Bij een nieuw ontwerp of een grotere verbouwing kan een strategisch en creatief webdesigntraject helpen om structuur en gebruiksgemak vanaf het begin mee te nemen.

Leg resultaten vast met een praktisch scorecard

Gebruik per taak een korte, concrete registratie. Daarmee kan een ontwikkelaar of beheerder een probleem terugvinden en na herstel opnieuw testen.

Onderdeel	Testactie	Goed als	Veelvoorkomende afwijking	Actie bij probleem
Hoofdnavigatie	Open submenu en sluit het weer	Knopnaam en open/dicht-status zijn hoorbaar; bediening lukt met toetsenbord	Alleen visuele pijl, geen aankondiging van status	Laat ontwikkelaar semantiek, naam en status van de knop herstellen
Koppen	Navigeer per kop door de pagina	Hoofdonderwerpen zijn snel vindbaar en logisch geordend	Visuele tussenkoppen zijn gewone tekst of volgorde is onlogisch	Herstel de HTML-koppenstructuur in template of content
Afbeelding	Lees afbeelding met screenreader	Informatieve beelden krijgen relevante context; decoratie leidt niet af	Bestandsnaam wordt voorgelezen of afbeelding herhaalt omliggende tekst	Pas alt-tekst of decoratieve markering aan
Contactformulier	Vul in en verstuur bewust onvolledig	Velden hebben labels en fouten zijn hoorbaar, vindbaar en herstelbaar	Foutmelding is alleen zichtbaar of veld heeft alleen placeholdertekst	Controleer formulierplugin, labels, foutkoppeling en focusgedrag
Modal of cookiebanner	Open, bedien en sluit zonder muis	Focus gaat de modal in, blijft daarin en keert terug na sluiten	Focus springt naar content achter de overlay	Laat focusbeheer en sluitbediening aanpassen
Zoeken of filters	Zoek of wijzig een filter	Nieuwe resultaten of status worden aangekondigd	Resultaten verversen stil op het scherm	Voeg passende statuscommunicatie toe en hertest

Wanneer is zelf testen niet voldoende?

Een eerste screenreader-test is waardevol voor het vinden en prioriteren van duidelijke problemen. Hij is niet voldoende voor een volledige toegankelijkheidsbeoordeling. Schakel aanvullende expertise in wanneer je website een belangrijk aanvraagproces, uitgebreide formulieren, een klantportaal, e-commerce, complexe filters, veel dynamische content of maatwerkfunctionaliteit bevat. Betrek waar mogelijk ook mensen die dagelijks met screenreaders werken.

Werk je tegelijk aan een nieuw platform, structuur of conversie? Bekijk dan alle webdesign-, SEO- en online marketingdiensten van LYNX Media om te bepalen welke ondersteuning past bij jouw vraagstuk.

Praktische checklist voor je volgende test

• Ik heb de gebruikte screenreader, browser en apparaat genoteerd.
• Ik heb een realistische bezoekerstaak gekozen.
• Ik heb de taak ook zonder muis uitgevoerd.
• De paginatitel maakt duidelijk waar ik ben.
• Ik kan door koppen, landmarks, links en formuliervelden navigeren.
• Menu’s, knoppen en uitklappers hebben een duidelijke naam en status.
• Afbeeldingen voegen alleen relevante informatie toe.
• Formuliervelden hebben labels en foutmeldingen zijn hoorbaar.
• Focus blijft logisch bij pop-ups, cookieconsent en andere overlays.
• Dynamische wijzigingen, zoals zoekresultaten of formulierstatus, worden aangekondigd.
• Ik heb elk probleem met URL, stappen en verwachte uitkomst vastgelegd.

Veelgestelde vragen

Is NVDA voldoende om een WordPress-site te testen?

NVDA is een bruikbaar startpunt, maar niet voldoende om alle gebruikerssituaties af te dekken. Gebruik voor belangrijke processen ook een aanvullende combinatie, bijvoorbeeld VoiceOver op macOS of iOS. Test daarnaast met toetsenbord en automatische hulpmiddelen.

Is een screenreader-test hetzelfde als een WCAG-audit?

Nee. Een screenreader-test is een belangrijk onderdeel van toegankelijkheidsonderzoek, maar een WCAG-beoordeling vraagt om bredere controle van relevante succescriteria, technische implementatie en gebruikssituaties.

Moet ik ingelogd en uitgelogd testen?

Test beide wanneer bezoekers een account kunnen gebruiken of wanneer de beheeromgeving invloed heeft op publiek zichtbare functionaliteit. Voor bezoekers is de uitgelogde ervaring in ieder geval essentieel.

Hulp nodig bij de toegankelijkheid, structuur of gebruikservaring van je WordPress-website? Bespreek je website of online groeikansen met LYNX Media.