Op verzoek van Waterschap Zuiderzeeland is een toegankelijkheidsonderzoek uitgevoerd op de door hun aangeboden website, https://woo.zuiderzeeland.nl/portaal , om te beoordelen hoe deze voldoet aan de gestelde WCAG norm.
Doel van het onderzoek is om te beoordelen of de informatie op de website voor iedereen, inclusief mensen met een functiebeperking, toegankelijk is en bedient kan worden.
Deze rapportage bevat de bevindingen van dit onderzoek. Uitgewerkt per richtlijn benoemen we de status waarin aan de succescriteria voldaan wordt, wat daarbij geconstateerde toegankelijkheidsproblemen zijn en eventuele opmerkingen ter advies.
De opgetekende bevindingen zijn indicatief. Een betreffend probleem kan dus op meerdere locaties binnen de website voorkomen zonder dat die apart benoemd worden.
De gebruikte onderzoeksmethode, WCAG-EM, werkt op basis van een steekproef. Hoewel de steekproef van het onderzoek zorgvuldig wordt samengesteld om een evenwichtig beeld van de vastgestelde scope te onderzoeken, kan het voorkomen dat een toegankelijkheidsprobleem niet geconstateerd wordt, maar dit bij een vervolgonderzoek wel aan het licht komt. Ook kunnen bevindingen op een later tijdstip mogelijk anders geïnterpreteerd en beoordeeld worden door verdere ontwikkeling van kennis en technieken.
De WCAG (Web Content Accessibility Guidelines) zijn internationaal geaccepteerde richtlijnen, gepubliceerd door het W3C (World Wide Web Consortium), ter bevordering van de toegankelijkheid van webcontent voor mensen met een functiebeperking. De richtlijnen zijn techniek-onafhankelijk opgebouwd via een viertal principes: Waarneembaar, Bedienbaar, Begrijpelijk en Robuust. Deze principes bevatten een serie richtlijnen met succescriteria waarmee webcontent beoordeeld kan worden.
Het toegankelijkheidsonderzoek voor de website https://woo.zuiderzeeland.nl/ is op 20 februari 2026 afgerond. Hiervoor is gebruikgemaakt van de WCAG-EM evaluatiemethode om te kijken hoe de onderzochte website voldoet aan de gestelde norm van WCAG 2.2 Niveau AA.
Op de volgende pagina's staan per succescriterium de bevindingen genoteerd. Deze bevindingen kunnen gebruikt worden om aanpassingen te maken en de toegankelijkheid van de website verder te verbeteren. Let er bij het maken van aanpassingen op dat hierdoor nieuwe toegankelijkheidsproblemen kunnen ontstaan.
Bij sommige succescriteria staan opmerkingen vermeld. Deze opmerkingen zijn geen foute bevindingen voor het betreffende criterium, maar genieten een sterke aanbeveling ter verbetering van de gebruikerservaring.
Hieronder staan per succescriterium eventuele bevindingen genoteerd. Deze bevindingen kunnen gebruikt worden om aanpassingen te maken en de toegankelijkheid van de website en haar content verder te verbeteren. Let er bij het maken van aanpassingen op dat hierdoor nieuwe toegankelijkheidsproblemen kunnen ontstaan.
Tevens staan bij sommige succescriteria opmerkingen. Deze opmerkingen zijn geen foute bevindingen voor het betreffende criterium, maar genieten een sterke aanbeveling ter verbetering van de gebruikerservaring.
Afbeeldingen in PDF hebben geen of onjuist tekstalternatief
De menuknop in de interface opent en sluit een uitklapmenu met instellingen (zoals “Klik en lees voor” en “Automatisch scrollen”).
De knop houdt echter geen programmatische status bij via bijvoorbeeld aria-expanded. Hierdoor wordt niet doorgegeven of het menu momenteel is ingeklapt of uitgeklapt.
Visueel is de status wel waarneembaar, maar deze informatie is niet beschikbaar voor hulptechnologie.
Impact op gebruikers
Screenreadergebruikers krijgen bij focus op de menuknop geen informatie over de huidige status van het menu.
Hierdoor is onduidelijk:
Of het menu al geopend is
Of activeren van de knop het menu zal openen of sluiten
Dit kan leiden tot verwarring en onzekerheid bij bediening.
Oplossing
Zorg dat de menuknop de status van het menu bijhoudt met aria-expanded="true" wanneer het menu geopend is en aria-expanded="false" wanneer het gesloten is.
Koppel de knop ook programmatisch aan het menu dat getoond wordt, via aria-controls.
Screenshots
Knoppen bij datumvelden hebben geen unieke, contextspecifieke naam
Bij zowel het algemene zoekveld als de zoekvelden voor start- als einddatum zijn meerdere actieknoppen aanwezig (datumkiezer openen, veld leegmaken, zoeken).
Deze knoppen hebben generieke toegankelijke namen zoals:
“open datumkiezer”
“voer zoekopdracht uit”
“maak veld leeg”
Omdat meerdere identieke knoppen op dezelfde pagina voorkomen, is uit de toegankelijke naam niet af te leiden bij welk veld de actie hoort.
Impact op gebruikers
Screenreadergebruikers kunnen de knoppen niet goed onderscheiden, zeker in combinatie met bevindingen ISSUE-921d6e58.
Het is niet duidelijk genoeg of een knop betrekking heeft op het startdatumveld, het einddatumveld of het algemene zoekveld. Dit kan leiden tot verwarring en fouten bij gebruik.
Oplossing
Maak de toegankelijke naam contextspecifiek, bijvoorbeeld:
De sliders (range input) voor het instellen van een waarde (visueel aangeduid met een icoon) bevatten geen programmatisch gekoppelde toegankelijke naam.
Hoewel er visueel een icoon naast de slider wordt getoond dat het doel suggereert, is er geen zichtbaar of verborgen <label>-element aanwezig dat via for of aria-labelledby aan het <input type="range">-element is gekoppeld.
Impact op gebruikers
Screenreadergebruikers krijgen bij focus op de slider geen duidelijke aanduiding van wat deze bedieningselement regelt. Zij horen bijvoorbeeld alleen “slider” of “onbekend”, zonder context.
Hierdoor is onduidelijk:
Wat wordt aangepast (bijvoorbeeld volume, snelheid)?
Wat de huidige waarde betekent?
Oplossing
Voorzie de slider van een programmatisch gekoppelde toegankelijke naam door:
Een zichtbaar <label>-element toe te voegen en te koppelen via het for-attribuut, of
Een bestaande zichtbare tekst via aria-labelledby te koppelen, of
Indien geen zichtbaar label gewenst is: een betekenisvolle aria-label toe te voegen.
Zorg dat de toegankelijke naam beschrijft wat wordt aangepast (bijvoorbeeld “Snelheid”, “Volume”, etc.) en dat deze overeenkomt met de visuele context.
Screenshots
Toggle-opties gebruiken aria-label voor status, waardoor zichtbare en toegankelijke naam niet overeenkomen
De opties in het instellingenmenu (zoals “Klik en lees voor”, “Automatisch scrollen” en “Lees knop tekst voor”) functioneren als aan/uit-instellingen.
Visueel wordt de status weergegeven met een icoon (X of vinkje). In de code wordt de status echter verwerkt in het aria-label, bijvoorbeeld:
“Zet voorlezen met klik uit” of “Zet voorlezen van knop tekst aan”
Hiermee wordt de actie (aan/uit zetten) opgenomen in de toegankelijke naam. De zichtbare tekst (“Klik en lees voor”, “Lees knop tekst voor”) komt daardoor niet overeen met de toegankelijke naam.
Daarnaast wordt de huidige status niet vastgelegd via het daarvoor bedoelde mechanisme (aria-pressed of aria-checked), maar impliciet verwerkt in het label.
Impact op gebruikers
Voor screenreadergebruikers is onduidelijk wat de vaste naam van de instelling is, omdat deze verandert afhankelijk van de actie (“Zet … aan/uit”).
Voor gebruikers van spraakbediening kan het lastig of onmogelijk zijn om de knop te activeren met de zichtbare tekst, omdat deze niet overeenkomt met de programmatische naam.
Dit leidt tot inconsistentie tussen wat visueel zichtbaar is en wat hulptechnologie aankondigt, en maakt de bediening minder betrouwbaar.
Oplossing
Implementeer deze opties als correcte toggles:
Gebruik de zichtbare tekst als vaste toegankelijke naam (bijvoorbeeld “Klik en lees voor”).
Leg de huidige status vast met aria-pressed="true/false" op de <button>
Zo communiceer je de status via een apart statusattribuut en niet via een wijzigende aria-label en komt de toegankelijke naam goed overeen de zichtbare tekst.
Screenshots
Invoerveld voor zoeken heeft alleen een placeholder als label
Het zoekveld voor het doorzoeken van publicaties bevat geen zichtbaar <label>-element. De toegankelijke naam van het invoerveld wordt uitsluitend bepaald door de placeholdertekst “Zoeken naar…”.
Wanneer een gebruiker tekst invoert, verdwijnt deze placeholder. Hierdoor is er geen zichtbaar label meer aanwezig dat aangeeft wat het doel van het veld is.
De loupe van het zoekicoon kan als zichtbaar label beschouwd worden, maar omdat deze zonder invoer gedimd is en daardoor niet altijd voldoet aan de minimale contrasteisen, is deze niet in de beoordeling meegenomen.
Impact op gebruikers
Een placeholdertekst is geen volwaardig label en wordt tevens deze door sommige hulptechnologieën minder consistent ondersteund als toegankleijke naam.
Gebruikers met cognitieve beperkingen of geheugenproblemen kunnen vergeten wat het doel van het veld is zodra ze beginnen met typen. Een permanent label helpt hen met de juiste context.
Gebruikers die inzoomen of slechts een deel van het scherm zien, missen context wanneer het label niet persistent zichtbaar blijft.
Oplossing
Gebruik een expliciet en persistent zichtbaar <label>-element dat programmatisch gekoppeld is aan het invoerveld via het for-attribuut.
Voeg een zichtbaar label toe boven of naast het veld. De placeholder kan aanvullend gebruikt worden als voorbeeldtekst, maar mag het label niet vervangen.
Zorg dat de toegankelijke naam overeenkomt met het zichtbare label.
Alternatief: zorg dat het loupe-icoon altijd voldoet aan de contrasteisen en niet gedimd wordt bij een leeg invoerveld.
Screenshots
Metadata van gepubliceerde documenten is niet semantisch als definitielijst opgemaakt
De metadata van gepubliceerde documenten (zoals publicatiedatum, kenmerk, documenttype en andere eigenschappen) wordt visueel gepresenteerd als label-waardeparen.
In de HTML-structuur is deze informatie echter niet semantisch gemarkeerd als een definitielijst (<dl>, <dt>, <dd>). In plaats daarvan wordt gebruikgemaakt van generieke <span> elementen, zonder programmatische relatie tussen label en bijbehorende waarde. Hierdoor wordt de relatie tussen eigenschap en waarde niet expliciet vastgelegd in de code.
Impact op gebruikers
Screenreadergebruikers krijgen de metadata als losse tekstfragmenten aangeboden. De onderlinge relatie tussen bijvoorbeeld “Publicatiedatum” en de bijbehorende datum is daardoor minder duidelijk.
Dit vermindert de begrijpelijkheid en structuur van de informatie, vooral wanneer meerdere metadata-eigenschappen onder elkaar worden gepresenteerd.
Oplossing
Markeer de metadata semantisch als een definitielijst:
Gebruik <dl> als container
Gebruik <dt> voor de eigenschapsnaam
Gebruik <dd> voor de bijbehorende waarde
Screenshots
Zichtbare labels van datumvelden zijn niet gekoppeld aan de invoervelden
De datumvelden “Start” en “Eind” hebben visueel zichtbare labels. Deze labels zijn echter niet programmatisch gekoppeld aan de bijbehorende invoervelden via een <label for="">-constructie of aria-labelledby.
Daarnaast hebben beide invoervelden dezelfde toegankelijke naam, afkomstig uit de placeholdertekst (“jjjj-mm-dd | jjjj-mm | jjjj”).
Hierdoor ontbreekt een unieke, correcte naamgeving per veld.
Impact op gebruikers
Screenreadergebruikers krijgen geen duidelijke context of het om het start- of einddatumveld gaat.
Omdat beide velden dezelfde naam hebben, is het verschil tussen de velden niet duidelijk. Dit kan leiden tot fouten bij invoer.
Oplossing
Koppel de zichtbare labels programmatisch aan de invoervelden via <label for="">.
Zorg dat elk veld een unieke en betekenisvolle toegankelijke naam heeft (“Startdatum”, “Einddatum”).
Gebruik de placeholder uitsluitend als invoerhint, niet als primaire naam.
Koppel de bovenstaande koptekst "Publicatiedatum" via aria-describedby voor nog duidelijkere context.
Screenshots
PDF bevat een onjuiste en vervuilde tags-structuur
Screenreadergebruikers zijn afhankelijk van een correcte tags-structuur voor bijvoorbeeld navigatie via koppen en andere structuurelementen, het begrip van relaties en een logische en consistente voorleesvolgorde.
Een onjuiste en vervuilde structuur kan leiden tot verwarrende of onlogische voorlezing met onnodige pauzes of lege aankondigingen en verminderde navigatiemogelijkheden.
Daarnaast zorgen onduidelijke of onjuist opgemaakte documenten voor een verhoogde cognitieve belasting.
Oplossing
Herstructureer de tags-structuur van het document. Houd daarbij rekening met onder andere de volgende zaken:
Zorg dat koppen correct zijn getagd als H1–H6 en dat ze volgens een logische hiërarchie verlopen.
Tag paragrafen als <P>
Tag lijsten als <L> met correcte <LI>-structuur
Verwijder lege of overbodige tags
Markeer decoratieve elementen als artifact
Controleer de leesvolgorde in de tags-structuur
Controleer na correctie het document met een screenreader of toegankelijke PDF-viewer.
Actieve tab in mobiele weergave is niet programmatisch aangegeven
In de mobiele weergave wordt gebruikgemaakt van een tab-achtige navigatiestructuur om te wisselen tussen “Documenten” en “Kenmerken”.
Visueel is zichtbaar welke knop actief is via kleurverschil en getoonde informatie, maar programmatisch is niet duidelijk:
Welke knop actief is
Welke inhoud momenteel wordt weergegeven
Welke relatie bestaat tussen knop en bijbehorende content
Er wordt geen gebruikgemaakt van een correct tabpatroon met bijvoorbeeld role="tablist", role="tab", role="tabpanel" en aria-selected.
Impact op gebruikers
Screenreadergebruikers krijgen geen informatie over welke tab/weergave actief is, dat er een tab-achtige structuur is, en welke content bij welke knop hoort.
Oplossing
Implementeer deze structuur volgens het ARIA-tabpatroon voor tabs (link bij documentatie):
Gebruik een container met role="tablist".
Geef de knoppen role="tab".
Gebruik aria-selected="true/false" om de actieve tab aan te geven.
Koppel iedere tab aan een bijbehorend role="tabpanel" via aria-controls en aria-labelledby.
Zorg dat alleen de actieve panel-inhoud zichtbaar en toegankelijk is.
Binnen het portaal kan worden gewisseld tussen verschillende weergavemodi (bijvoorbeeld lijstweergave en gridweergave). De actieve weergave wordt visueel aangeduid via kleurverschil.
De actieve status van de gekozen weergave wordt echter niet programmatisch vastgelegd. Er wordt geen gebruikgemaakt van bijvoorbeeld aria-pressed, aria-selected of een vergelijkbaar statusattribuut.
Hierdoor is voor hulptechnologie niet kenbaar welke weergave momenteel actief is. Aangezien dit de getoonde informatie beïnvloedt, is dit belangrijk.
Impact op gebruikers
Screenreadergebruikers krijgen geen informatie over welke weergave actief is.
Hierdoor is het niet duidelijk in welke modus de resultaten momenteel worden getoond en of het activeren van de knop een wijziging zal veroorzaken. Dit vermindert de voorspelbaarheid en maakt de bediening minder inzichtelijk.
Oplossing
Implementeer de weergavekeuze als een correcte selectiecomponent en gebruik aria-pressed="true/false" of introduceer een tab-patroon met aria-selected="true/false".
Zorg dat de actieve status dynamisch wordt bijgewerkt en slechts één optie tegelijk als actief wordt gemarkeerd.
Screenshots
Sorteer-combobox maakt naam, rol en geselecteerde waarde niet correct bekend
De sorteerfunctionaliteit is geïmplementeerd als een custom combobox.
Het element met role="combobox" bevat de relevante ARIA-attributen (aria-expanded, aria-labelledby, aria-label), maar heeft tabindex="-1" en is daardoor niet focusbaar.
De focus komt terecht op het onderliggende <input>-element. Dit inputveld heeft een eigen aria-label="sort-searchbox" en kondigt daardoor alleen “sort-searchbox” aan.
Hierdoor wordt bij benadering met een screenreader:
De rol combobox niet aangekondigd
De toegankelijke naam “Sorteer methode” niet correct gebruikt, maar deze wordt sowieso overschreven door de aria-labelledby verwijzing naar de input.
De huidige geselecteerde waarde (“Publicatiedatum - aflopend”) niet bekendgemaakt
De naam, rol en waarde zijn dus niet correct programmatisch beschikbaar voor de focusbare component.
Impact op gebruikers
creenreadergebruikers krijgen geen duidelijke informatie over:
Dat het om een combobox gaat, wat de functie van het element is (sorteermethode) en wat de huidige geselecteerde waarde is. Hierdoor is het onduidelijk wat het element doet en wat de huidige instelling is. Dit belemmert het begrijpen en aanpassen van de sortering.
Oplossing
Implementeer de combobox volgens het juiste ARIA-patroon. Gebruik de APG als een startpunt voor een juiste implementatie.
Binnen de datumkiezer worden dagen aangekondigd als losse cijfers (bijvoorbeeld “1”, “2”, “3”). De volledige datum (bijvoorbeeld dag, maand en jaar) wordt niet zo aangekondigd, terwijl deze informatie visueel wel beschikbaar is. Hierdoor ontbreekt context bij het navigeren door de kalender.
Impact op gebruikers
Screenreadergebruikers kunnen moeilijk bepalen welke exacte datum wordt geselecteerd.
Losse cijfers zonder maand- en jaaraanduiding maken het lastig om de juiste datum te kiezen.
Oplossing
Zorg dat elke datumcel een volledige, betekenisvolle, toegankelijke naam heeft, bijvoorbeeld: “1 januari 2026” of “15 maart 2026”
Gebruik hiervoor bijvoorbeeld aria-label op de datumknoppen.
Screenshots
Huidige pagina in paginering is niet programmatisch gemarkeerd
In de paginering wordt de huidige actieve pagina visueel aangeduid, maar deze status is niet programmatisch vastgelegd.
Het actieve paginanummer bevat geen attribuut zoals aria-current="page" waarmee de huidige positie binnen de paginering kenbaar wordt gemaakt aan hulptechnologie.
Impact op gebruikers
Screenreadergebruikers krijgen geen duidelijke melding welke pagina momenteel actief is.
Hierdoor is het lastig om:
De huidige positie binnen de resultaten te bepalen
Te begrijpen of een paginanummer verwijst naar de huidige pagina of naar een andere pagina.
Oplossing
Markeer het actieve paginanummer met aria-current="page"
Plaats dit attribuut op het element (button) dat de huidige pagina en zorg dat dit attribuut alleen aanwezig is op de daadwerkelijk actieve pagina.
Screenshots
Kopniveaus worden overgeslagen in de paginalay-out
Binnen de hoofdlayout van het portaal worden kopniveaus overgeslagen. De pagina bevat een <h1>, waarna direct <h4>-koppen worden gebruikt voor onderdelen van de filters. Vervolgens worden <h3>-koppen toegepast voor de resultaten.
De gekozen kopniveaus lijken primair gebaseerd op visuele vormgeving in plaats van op een logische hiërarchische structuur.
Hoewel de informatiestructuur inhoudelijk nog begrijpelijk is, wijkt de koppenhiërarchie af van een consistente, oplopende structuur.
Impact op gebruikers
Screenreadergebruikers gebruiken koppen om snel door de pagina te navigeren en de structuur te begrijpen.
Wanneer kopniveaus worden overgeslagen of niet logisch oplopen:
Kan de structuur minder voorspelbaar aanvoelen
Wordt het lastiger om de hiërarchie van onderdelen correct te interpreteren
Kan verwarring ontstaan over de onderlinge relatie tussen secties
Hoewel dit in deze situatie niet direct tot verlies van informatie leidt, vermindert het de consistentie van de navigatiestructuur.
Oplossing
Pas een logische en consistente hiërarchie toe door kopniveaus per sectie in oplopende volgorde te gebruiken (h1 → h2 → h3 → h4)
Gebruik kopniveaus uitsluitend voor structurele betekenis, niet voor visuele styling. Pas vormgeving aan via CSS in plaats van via kopniveau en zorg dat de koppenstructuur de daadwerkelijke inhoudelijke hiërarchie weerspiegelt.
Screenshots
Huidige pagina in paginering wordt alleen met kleur aangegeven en heeft onvoldoende contrast
In de paginering wordt de huidige actieve pagina uitsluitend visueel aangeduid met een groene tekstkleur (#97BF0D) op een witte achtergrond (#FFFFFF).
De contrastverhouding tussen deze kleur en de achtergrond is onvoldoende voor indicatie. Daarmee wordt de actieve status uitsluitend via kleurverschil gecommuniceerd. Er is geen aanvullende visuele indicator zoals contrast of een onderstreping, kader of andere markering.
Impact op gebruikers
Gebruikers met een visuele beperking of verminderd contrastzicht kunnen de actieve pagina moeilijk onderscheiden van andere paginanummers.
Gebruikers met kleurenblindheid kunnen het verschil mogelijk niet waarnemen wanneer dit uitsluitend via kleur wordt aangegeven.
Oplossing
Verhoog het contrast van de actieve paginakleur tot minimaal 3:1 tegenover de achtergrond. Houd daarbij het contrast met de tekst (nummers) in de gaten. Dit dient minimaal 4.5:1 te blijven
Voeg als alternatief een aanvullende visuele indicator toe naast kleur (bijvoorbeeld een kader met 3:1 contrast of vetgedrukte tekst).
Screenshots
Onvoldoende contrast van geselecteerde optie in resultaten-keuzelijst
In de keuzelijst voor het aantal resultaten per pagina wordt de geselecteerde optie (bijvoorbeeld “20”) weergegeven met witte tekst (#FFFFFF) op een roze/rode achtergrond (#F07D7D).
De gemeten contrastverhouding tussen deze kleuren is 2,6:1.
Voor reguliere tekst geldt een minimale contrastverhouding van 4,5:1. De huidige combinatie voldoet hier niet aan.
Dit valt momenteel ook deels onder 1.4.11 Gebruik van kleur en 1.4.11 Contrast van niet-tekstuele content, omdat de tekst nu onvoldoende contrast heeft met het rood.
Impact op gebruikers
Gebruikers met een visuele beperking of verminderd contrastzicht kunnen de geselecteerde optie moeilijk lezen.
Omdat het hier gaat om een actieve en geselecteerde optie binnen een interactieve component, kan onvoldoende contrast leiden tot onzekerheid over welke optie actief is.
Oplossing
Verhoog het contrast tussen tekst en achtergrond tot minimaal 4,5:1 voor reguliere tekst.
Screenshots
Minimaal kleurverschil gebruikt als indicator voor status of interactie
Op meerdere plaatsen binnen het portaal wordt een minimaal kleurverschil toegepast om interactieve elementen (zoals links) te onderscheiden van reguliere tekst.
De linkkleur wijkt beperkt af van de standaard tekstkleur. Er wordt geen aanvullende visuele indicatie gebruikt, zoals onderstreping of een andere structurele markering. Bij hover of focus vindt slechts een lichte kleurverandering plaats.
Hoewel het contrastverschil tussen linkkleur en omliggende tekst voldoet aan de minimale eis van 3:1 (momenteel 3.3:1), is het onderscheid subtiel en uitsluitend gebaseerd op kleur.
Impact op gebruikers
Gebruikers met kleurenblindheid of verminderd kleuronderscheid kunnen moeite hebben om interactieve elementen te herkennen wanneer het onderscheid minimaal en alleen kleurgebaseerd is.
Oplossing
Gebruik naast kleur een aanvullende visuele indicator voor interactieve elementen of voor aanduiding van status.
Screenshots
Tekstkleur van links bij focus heeft onvoldoende contrast
In het PDF-document zijn contrastproblemen vastgesteld, zoals tekst met onvoldoende contrast tegenover de achtergrondkleur en tekst die is opgenomen in afbeeldingen met onvoldoende contrast.
De gemeten contrastverhoudingen voldoen in meerdere gevallen niet aan de minimale vereisten voor leesbare tekst.
Geldt voor onderzochte documenten:
Document: 250225 KeVos Systems Engineering Management Plan VK def
Gebruikers met een visuele beperking of verminderd contrastzicht kunnen delen van de tekst moeilijk of niet lezen.
Bij tekst die in afbeeldingen is opgenomen, kan dit extra problematisch zijn, omdat:
Het contrast niet kan worden aangepast door de gebruiker.
De tekst niet schaalbaar is.
In sommige gevallen geen tekstalternatief beschikbaar is.
Dit heeft directe impact op de leesbaarheid van het document.
Oplossing
Verhoog het contrast van tekst tot minimaal 4,5:1 voor reguliere tekst.
Voor grote tekst (≥ 18pt of ≥ 14pt vet) geldt minimaal 3:1.
Vermijd bij voorkeur het gebruik van tekst in afbeeldingen. Indien dit noodzakelijk is, zorg dan voor voldoende contrast en een passend tekstalternatief.
Placeholdertekst in invoervelden heeft onvoldoende contrast
De placeholdertekst in het zoekveld en andere invoervelden wordt weergegeven in kleur #808080 op een witte achtergrond (#FFFFFF).
De gemeten contrastverhouding is 3,9:1. Voor reguliere tekst is minimaal 4,5:1 vereist.
Hierdoor voldoet de placeholdertekst niet aan de minimale contrastvereisten.
Impact op gebruikers
Gebruikers met een visuele beperking of verminderd contrastzicht kunnen de placeholdertekst moeilijk lezen.
Omdat placeholdertekst vaak aanvullende instructie of context bevat (bijvoorbeeld wat ingevoerd moet worden), kan onvoldoende contrast leiden tot onzekerheid of fouten bij invoer.
Oplossing
Verhoog het contrast van de placeholdertekst tot minimaal 4,5:1 vergeleken met de achtergrondkleur.
Dit kan bijvoorbeeld door:
Een donkerdere grijstint te gebruiken, of
De standaardtekstkleur van invoervelden toe te passen.
Let erop dat dit consequent wordt toegepast op alle invoervelden binnen het portaal.
Screenshots
timeout indicator van statusmelding heeft onvoldoende contrast
De resterende tijd van de statusmelding wordt uitsluitend visueel weergegeven via een dunne lichtroze of lichtgroene voortgangsindicator onderaan de melding.
Deze indicator heeft onvoldoende contrast tegenover de achtergrond en voldoet niet aan de minimale contrastverhouding van 3:1 voor niet-tekstuele UI-componenten.
Impact op gebruikers
Gebruikers met verminderd contrastzicht kunnen de voortgangsindicator moeilijk waarnemen.
Oplossing
Verhoog het contrast van de voortgangsindicator tot minimaal 3:1 tegenover de achtergrond.
Screenshots
Focus keert niet terug naar het juiste invoerveld na gebruik van de datumkiezer
Bij gebruik van de datumkiezer wordt na selectie van een datum de focus niet teruggeplaatst naar het bijbehorende invoerveld.
In plaats daarvan verplaatst de focus zich naar het einde van de pagina. Hierdoor wordt de verwachte focusvolgorde doorbroken.
Impact op gebruikers
Toetsenbordgebruikers raken hun positie kwijt op de pagina. Dit kan leiden tot desoriëntatie en er is veel extra navigatie nodig om terug te keren naar de juiste plek. Voor andere hulpsoftware ontstaat er onzekerheid of de datum correct is ingevuld.
Oplossing
Zorg dat bij het sluiten van de datumkiezer de focus terugkeert naar het invoerveld waarin de geselecteerde datum is geplaatst
Screenshots
Focus wordt niet binnen de geopende datumkiezer gehouden
Wanneer de datumkiezer wordt geopend, blijft de toetsenbordfocus niet beperkt tot het geopende component.
Het is mogelijk om met de Tab-toets buiten de datumkiezer te navigeren terwijl deze nog zichtbaar en actief is. Hierdoor functioneert de datumkiezer niet als een modaal component met een gesloten focuscirkel (focus trap).
Impact op gebruikers
Screenreader en toetsenbordgebruikers kunnen ongemerkt of onbedoeld buiten de datumkiezer terechtkomen terwijl deze nog geopend is.
Zeker omndat de interactie aan het einde van de pagina zit, valt de focus daarmee direct buiten de pagina. Dit kan leiden tot desoriëntatie en onbedoelde interactie met onderliggende pagina-inhoud.
Bij modale componenten wordt verwacht dat de focus binnen het actieve onderdeel blijft totdat dit wordt gesloten.
Oplossing
Implementeer correct focusbeheer bij openen van de datumkiezer:
Verplaats de focus bij openen naar een logisch startpunt binnen de datumkiezer (bijvoorbeeld de huidige datum of eerste selecteerbare datum). (dit gebeurd al).
Houd de focus binnen de datumkiezer zolang deze geopend is (focus trap).
Zorg dat de focus bij sluiten terugkeert naar het element dat de datumkiezer heeft geopend. Bij selectie van een datum is het beter terug naar het invoerveld zelf te gaan zodat de geselecteerde datum gecomuniceerd wordt aan hulpsoftware.
Gebruik hierbij een correcte modale implementatie, bijvoorbeeld met aria-modal="true" en passend focusbeheer in JavaScript.
De foutmelding verdwijnt automatisch na afloop van een timer.
Gebruikers krijgen geen mogelijkheid om:
De tijdslimiet te verlengen
De automatische verdwijning te pauzeren
De melding permanent zichtbaar te houden
Hierdoor is sprake van tijdsafhankelijke informatie zonder instelbaarheid.
Dit geldt ook voor succesmeldingen, al is de impact hiervan minder relevant en worden bijvoorbeeld voltooide downloads al via de browser gemeld.
Impact op gebruikers
Gebruikers met een visuele beperking, cognitieve beperking of verminderde reactiesnelheid kunnen de foutmelding missen doordat deze automatisch verdwijnt. Essentiële informatie kan hierdoor verloren gaan.
Oplossing
Laat foutmeldingen niet automatisch verdwijnen of bied een mechanisme om de tijd te verlengen en de melding handmatig te sluiten.
In de documenteigenschappen van het PDF-bestand is een onjuiste primaire documenttaal ingesteld. Momenteel is het document gemarkeerd als Engels door de en_US waarde, maar de inhoud van het document is in het Nederlands.
Geldt voor onderzochte documenten:
Document: 250225 KeVos Systems Engineering Management Plan VK def
Document: 250121 KeVos Notitie Duurzaamheid def
Controleer ook andere documenten!
Impact op gebruikers
Screenreaders kunnen zonder juist ingestelde taal niet de juiste uitspraakregels toepassen. Dit kan leiden tot verkeerde uitspraak of onbegrijpelijke voorlezing.
Oplossing
Stel de primaire documenttaal in (bijvoorbeeld Nederlands) via de documenteigenschappen.
Markeer afwijkende taalfragmenten in het document (bijvoorbeeld Engelse onderdelen) correct in de relevante tags.
Dynamische update van resultatenlijst wordt niet aangekondigd
Wanneer filters of een zoekterm worden toegepast, wordt de resultatenlijst dynamisch bijgewerkt zonder volledige paginareload.
De bijgewerkte informatie (zoals het aangepaste aantal resultaten en de nieuwe lijstinhoud) wordt visueel weergegeven, onder andere in de koptekst:
“1 tot en met X van de X resultaten”.
Deze wijziging wordt echter niet programmatisch aangekondigd via bijvoorbeeld een aria-live-regio.
Hierdoor worden screenreadergebruikers niet geïnformeerd dat de inhoud van de pagina is gewijzigd.
Bij sommige filterinteracties wordt het aantal resultaten deels aangekondigd tijdens selectie, maar dit gebeurt niet consistent (bijvoorbeeld niet bij het invoeren van een zoekterm).
Impact op gebruikers
Screenreadergebruikers krijgen geen duidelijke feedback dat de resultaten zijn bijgewerkt.
Oplossing
Maak de resultatenupdate programmatisch kenbaar.
Plaats het element met de resultatenkop (“1 tot en met X van de X resultaten”) in een aria-live="polite"-regio, of voeg een aparte visueel verborgen statusmelding toe die bij elke update wordt aangepast.
Zorg dat alleen relevante statusinformatie wordt aangekondigd (bijvoorbeeld het nieuwe aantal resultaten), en voorkom overmatige of dubbele aankondigingen.
Wanneer er een fout optreedt (bijvoorbeeld een serverfout bij het laden van documenten), wordt visueel een foutmelding getoond in een rood meldingsvlak.
Deze foutmelding wordt echter niet aangekondigd via een aria-live-regio en bevat geen rol zoals role="alert" of role="status".
Hierdoor wordt de foutmelding niet automatisch gecommuniceerd aan screenreadergebruikers wanneer deze verschijnt.
Dit geldt ook voor succesmeldingen die hetzelfde mechanisme gebruiken.
Impact op gebruikers
Screenreadergebruikers krijgen geen directe melding dat er een fout is opgetreden.
Oplossing
Maak foutmeldingen programmatisch kenbaar. Gebruik role="alert" op de foutmelding voor foutmeldingen die direct aandacht vereisen of plaats de foutmelding binnen een permanente aria-live-regio.
Screenshots
Combobox “Aantal resultaten” maakt naam, rol en huidige waarde niet correct bekend
ID
ISSUE-bb1c2e02
Ernst
Gemiddeld
Type
WCAG Fout
Beschrijving
De selector voor “Aantal resultaten” is geïmplementeerd als een custom combobox.
Het element met role="combobox" bevat relevante ARIA-attributen zoals aria-expanded, aria-labelledby en aria-label, maar heeft tabindex="-1" en is daardoor niet focusbaar.
De toetsenbordfocus komt terecht op het onderliggende <input>-element. Dit inputveld heeft een eigen aria-label="page-size-searchbox".
Hierdoor wordt bij benadering met een screenreader de rol combobox niet aangekondigd, de toegankelijke naam “Aantal resultaten” niet correct gebruikt en de huidige geselecteerde waarde (standaard “20”) niet als comboboxwaarde gepresenteerd.
Impact op gebruikers
Screenreadergebruikers krijgen geen duidelijke informatie dat het om een keuzelijst (combobox) gaat waarmee het aantal resultaten per pagina wordt ingesteld en wat de huidige geselecteerde waarde is.
Oplossing
Overweeg een eenvoudigere dropdown/select implementatie. Als vastgehouden dient te worden aan de huidige combobox-implementatie, gebruik dan het juiste patroon voor select-only.
Gebruik de ARIA Authoring Practices Guide als uitgangspunt.
Thumbnails van documenten hebben een overbodig tekstalternatief
ID
ISSUE-c0b0e7be
Ernst
Gemiddeld
Type
WCAG Fout
Beschrijving
Bij gepubliceerde documenten wordt een thumbnail weergegeven.
Wanneer geen thumbnail beschikbaar is, wordt een bestandstype-icoon getoond (bijvoorbeeld PDF of DOC).
Wanneer wel een thumbnail aanwezig is, betreft dit een kleine visuele preview zonder voldoende detail om inhoudelijk informatief te zijn.
In beide gevallen is een tekstalternatief toegevoegd.
De informatie over het bestandstype en andere kenmerken (zoals documenttype) wordt echter al expliciet weergegeven in de metadata van het document. De thumbnail voegt geen aanvullende betekenisvolle informatie toe.
Impact op gebruikers
Screenreadergebruikers krijgen extra, niet-noodzakelijke informatie voorgelezen. Dit kan leiden tot overbodige herhaling, verhoogde cognitieve belasting en minder efficiënte navigatie door de documentlijst.
Wanneer afbeeldingen geen aanvullende inhoudelijke waarde hebben, draagt een tekstalternatief niet bij aan de toegankelijkheid.
Oplossing
gebruik alt="" zodat deze door hulptechnologie wordt genegeerd.
Voeg alleen een betekenisvol tekstalternatief toe wanneer de afbeelding unieke, relevante informatie bevat die niet elders beschikbaar is.
Screenshots
Metadata op detailpagina is onjuist semantisch opgemaakt als lijst met label-elementen
ID
ISSUE-96f5f1ca
Ernst
Gemiddeld
Type
WCAG Fout
Beschrijving
Op de detailpagina van een document wordt de metadata (zoals Uitgever, Kenmerk, Identifiers, Publicatiedatum, etc.) visueel gepresenteerd als label-waardeparen.
In de HTML-structuur is deze informatie opgemaakt als een <ul>-lijst. Binnen elk lijstitem wordt gebruikgemaakt van een <label>-element voor de dikgedrukte term, gevolgd door een <p>-element met de bijbehorende waarde.
Deze implementatie is semantisch onjuist:
Een <ul> is bedoeld voor opsommingen, niet voor definitieparen.
Het <label>-element is bedoeld voor formulierelementen en niet voor statische metadata.
Impact op gebruikers
Screenreadergebruikers krijgen de metadata gepresenteerd als een gewone lijst zonder duidelijke semantische relatie tussen term en waarde.
Daarnaast kan het gebruik van <label>-elementen zonder gekoppeld formulierelement verwarrend zijn voor hulptechnologie.
Oplossing
Gebruik geen <label>-elementen voor statische tekst. Markeer de metadata semantisch correct als definitielijst:
Gebruik <dl> als container
Gebruik <dt> voor de term (bijvoorbeeld “Uitgever”)
Gebruik <dd> voor de bijbehorende waarde
Screenshots
Focus blijft niet binnen geopende filtermodal (mobiele weergave)
ID
ISSUE-9d680570
Ernst
Gemiddeld
Type
WCAG Fout
Beschrijving
In de mobiele weergave worden de filteropties weergegeven in een modaal menu (overlay).
Wanneer dit filtermenu geopend is, wordt de toetsenbordfocus niet binnen de modal gehouden. Het is mogelijk om met de Tab-toets naar elementen in de onderliggende pagina te navigeren, terwijl deze visueel verborgen of inactief is.
Impact op gebruikers
Toetsenbordgebruikers kunnen ongemerkt terechtkomen in content achter de modal.
Dit kan leiden tot desoriëntatie (focus staat op elementen die niet zichtbaar zijn) en onbedoelde interactie met onderliggende content.
Bij modale componenten wordt verwacht dat interactie beperkt blijft tot het geopende venster totdat dit wordt gesloten.
Oplossing
Implementeer correct focusbeheer voor de modal:
Verplaats bij openen de focus naar een logisch startpunt binnen de modal.
Houd de focus binnen de modal zolang deze geopend is (focus trap).
Verplaats de focus bij sluiten terug naar het element dat de modal heeft geopend.
Maak onderliggende content niet focusbaar zolang de modal actief is (bijvoorbeeld via inert of vergelijkbare techniek).
Toegankelijke naam van knoppen komt niet overeen met zichtbare tekst
ID
ISSUE-0d96464e
Ernst
Gemiddeld
Type
WCAG Fout
Beschrijving
Op meerdere plaatsen in het portaal bevatten knoppen een aria-label dat de zichtbare knoptekst overschrijft.
Het aria-label bevat daarbij aanvullende of afwijkende tekst ten opzichte van de zichtbare knoptekst. Hierdoor komt de toegankelijke naam niet overeen met wat visueel wordt getoond.
De zichtbare tekst maakt daardoor geen (volledig) onderdeel uit van de programmatisch bepaalde naam.
Impact op gebruikers
Voor screenreadergebruikers kan verwarring ontstaan doordat wat wordt aangekondigd niet overeenkomt met wat visueel zichtbaar is.
Voor gebruikers van spraakbediening kan dit leiden tot bedieningsproblemen, omdat de knop mogelijk niet geactiveerd kan worden met de zichtbare tekst.
Dit vermindert de voorspelbaarheid en consistentie van de interface.
Oplossing
Zorg dat de zichtbare naam in zijn geheel voorkomt met de toegankelijke naam, ook als deze via aria-label wordt aangepast.
Gebruik bij voorkeur de zichtbare tekst als primaire toegankelijke naam.
Vermijd het overschrijven van zichtbare tekst met een afwijkend aria-label.
Indien aanvullende context nodig is, voeg deze toe via aria-describedby in plaats van via aria-label.
De zichtbare tekst moet (minimaal) onderdeel zijn van de toegankelijke naam, voor de meest betrouwbare interactie dient deze tekst aan het begin te staan.
Screenshots
ARIA wordt toegepast op elementen zonder geschikte rol of semantische functie
Op meerdere plaatsen binnen het portaal worden aria-label-attributen toegepast op HTML-elementen die geen interactieve functie hebben en geen geschikte ARIA-rol bevatten.
Het betreft elementen bijvoorbeeld <div> of <span> elementen die geen interactieve semantiek hebben en/of geen correcte ARIA-rol toegewezen krijgen, maar toch een aria-label bevatten
Volgens de ARIA-specificatie is aria-label bedoeld om de toegankelijke naam te definiëren van interactieve of semantisch relevante elementen. Het toepassen op niet-interactieve elementen zonder passende rol is onjuist en heeft geen gegarandeerd effect.
Impact op gebruikers
Het onjuiste gebruik van ARIA op niet-semantische of interactieve elementen kan leiden tot onvoorspelbaar gedrag in screenreaders, dubbele of verwarrende aankondigingen en andere onbedoelde toegankelijkheidsproblemen bij samengestelde componenten.
Oplossing
Gebruik aria-label uitsluitend op elementen die een toegankelijke naam nodig hebben, bijvoorbeeld interactieve elementen of elementen met een ARIA-rol).
Indien een niet-semantisch element een interactieve functie krijgt, ken dan eerst een passende rol toe voordat een toegankelijke naam wordt toegevoegd.
Vermijd overmatig of onnodig gebruik van ARIA (“No ARIA is better than bad ARIA”).
Testplan
Dit zijn de geteste pagina's en componenten die onderdeel zijn van de steekproef.
De documentpreview is als externe plugin buiten beschouwing gelaten, omdat hier geen invloed op is. Er is wel onderzocht dat de viewer geen blokkade vormt voor het verdere gebruik van de pagina's waarop deze gebruikt wordt.
Screenshots
Document: 250225 KeVos Systems Engineering Management Plan VK def
