Hercontrole van de audit digitale toegankelijkheid van website formulier.s-hertogenbosch.nl
Samenvatting
Wij hebben de hercontrole van de website formulier.s-hertogenbosch.nl uitgevoerd tussen 10 en 20 oktober 2025. Op dit moment zijn 43 van de 55 succescriteria als voldoende beoordeeld. In dit rapport lees je wat er bij de overige 12 nog fout gaat, en hoe je dat kunt verbeteren.
Resultaat
De website is op 6 succescriteria verbeterd.
In dit onderzoek hebben we alle 55 toegankelijkheidseisen (succescriteria) uit de norm WCAG 2.2 onderzocht. We hebben het onderzoek uitgevoerd volgens de onderzoeksmethode WCAG-EM.
Toetsenbordfocus is niet zichtbaar (SC 2.4.7): Dit probleem komt op meerdere plaatsen voor, zowel in de footer van de website als bij knoppen en links die eruitzien als knoppen, en ook in het mobiele menu. Het zorgt ervoor dat gebruikers die met het toetsenbord navigeren niet goed kunnen zien waar de focus zich bevindt, wat de bruikbaarheid ernstig belemmert.
Dialoogvenster heeft geen toegankelijke naam (SC 4.1.2): Dit geldt voor dialoogvensters zoals "Je sessie vervalt binnenkort" en "Opslaan en later verdergaan". Het ontbreken van een toegankelijke naam maakt deze vensters onbruikbaar voor screenreadergebruikers.
Invoervelden voor persoonlijke gegevens hebben geen autocomplete-attribuut (SC 1.3.5): Dit probleem is gevonden in formulieren met persoonlijke gegevens, zoals achternaam, e-mailadres en telefoonnummer. Het ontbreken van het autocomplete-attribuut belemmert browsers en hulpsoftware bij het automatisch invullen van velden, wat de efficiëntie voor gebruikers vermindert.
Alle pagina's op de website formulier.s-hertogenbosch.nl
Alle PDF's op de website formulier.s-hertogenbosch.nl
Niet in scope:
Subwebsite(s) waarbij de HTML en/of het systeem afwijkt van de onderzochte website
De van derden afkomstige inhoud (wettelijke uitzondering voor de overheid)
Basisniveau toegankelijkheidsondersteuning
Mozilla Firefox, versie 142
Google Chrome, versie 140
Apple Safari, versie 18
PAC software to test PDF
NVDA schermlezer in combinatie met Firefox
VoiceOver schermlezer in combinatie met Safari
Andere gangbare browsers en hulpapparatuur
Technologieën van de website
HTML
CSS
JavaScript
WAI-ARIA
SVG
PDF
Over dit onderzoek
Leeswijzer
Onze rapporten zijn anders. Bij het bespreken van de gevonden problemen volgen wij niet de structuur van de norm, maar die van jouw website of app. Hierdoor kun je gewoon per pagina of scherm aan de slag gaan. Wel zo makkelijk! Je vindt verderop een overzicht van alle pagina’s met problemen.
We geven je bij elk gevonden issue een paar voorbeelden, maar niet een complete lijst. Controleer zelf of het probleem ook nog op andere plekken voorkomt. Zie het rapport als een leidraad.
Gebruikte norm
Dit onderzoek laat zien in hoeverre de website op dit moment voldoet aan WCAG 2.2, niveau A en AA. WCAG staat voor Web Content Accessibility Guidelines. Dit is de internationale norm voor digitale toegankelijkheid. De Europese norm EN 301 549 bevat alle eisen van WCAG op niveau A en AA.
In dit rapport hebben we korte beschrijvingen van de succescriteria uit de norm opgenomen, met een algemene uitleg erbij. Wil je ze helemaal lezen? Bekijk dan de documentatie van WCAG.
Gebruikte onderzoeksmethode
We gebruiken de onderzoeksmethode WCAG-EM van het W3C. Het proces ziet er als volgt uit:
vaststellen wat binnen en buiten scope valt
vaststellen welke technologieën zijn gebruikt
steekproef (sample) samenstellen
steekproef onderzoeken
gevonden issues beschrijven
Het grootste deel van het onderzoek doen we met de hand. Voor een deel van de toegankelijkheidseisen gebruiken we automatische tools als ondersteuning, zoals axe-core en Chrome Developer Tools.
Belangrijk om te weten
Dit rapport helpt je om de toegankelijkheid van je website te verbeteren. Maar let op: het is geen definitieve, volledige lijst van alle aanwezige toegankelijkheidsproblemen. Dat zit zo:
Het is een steekproef
Ten eerste is het onderzoek gebaseerd op een steekproef. Die is op een betrouwbare manier genomen, en de meeste problemen zullen daardoor zeker aan het licht komen. Toch kan een probleem net buiten de steekproef vallen. Bij een volgend onderzoek kan het wel ontdekt worden.
Op basis van falsificatie
We beoordelen vanuit het principe van falsificatie. Dat houdt in dat we proberen te bewijzen dat iets niet waar is, in plaats van te bevestigen dat het klopt. ‘Voldoet’ betekent daarom dat we geen reden hebben gevonden om een punt af te keuren. Maar als we later wél een reden vinden, kan het alsnog worden afgekeurd.
Voortschrijdend inzicht
Het komt voor dat de beoordeling van een succescriterium op detailniveau verandert. De norm beschrijft namelijk niet élk mogelijk scenario. Samen met andere onderzoeksbureaus overleggen we hoe we met bepaalde situaties omgaan. Zo kan iets dat nu wordt afgekeurd, soms bij een volgend onderzoek worden goedgekeurd en andersom.
Oplossen leidt tot nieuw probleem
Ten slotte kan het gebeuren dat bij het oplossen van een probleem onbedoeld een nieuw toegankelijkheidsprobleem ontstaat. Dat komt dan bij een volgend onderzoek pas naar voren.
Op alle pagina's van de website, in de footer, is de toetsenbordfocus niet zichtbaar op de volgende links: "Privacybeleid", "Beheer cookies".
De toetsenbordfocus moet altijd zichtbaar zijn op interactieve elementen zoals links, knoppen en invoervelden die met het toetsenbord focus kunnen krijgen. Bezoekers die met het toetsenbord navigeren moeten goed kunnen zien op welke plek van de pagina ze zijn. Anders weten ze niet op welk moment ze op Enter moeten drukken om een knop of link te bedienen.
Hetzelfde probleem is waarneembaar bij alle knoppen en links die eruitzien als knoppen. Wanneer ze toetsenbordfocus krijgen, flitst de rand een seconde en keert daarna terug naar de normale staat.
Hier zijn enkele voorbeelden, maar dit is geen uitputtende lijst:
de knoppen “Alles toestaan” en “Alles weigeren” in de cookiebanner,
Volgens succescriterium 2.4.7 moet een websitebezoeker op elk moment visueel kunnen bepalen waar de toetsenbordfocus zich bevindt.
Oplossing:
Zorg dat de toetsenbordfocus zichtbaar is op de genoemde elementen.
SC 4.1.2 Dialoogvenster heeft geen toegankelijke naam
Op veel pagina’s van de website verloopt de sessie wanneer een bezoeker begint met het invullen van een formulier en vervolgens gedurende 15 minuten geen acties uitvoert. In dat geval wordt een dialoogvenster met de melding “Je sessie vervalt binnenkort” weergegeven. Dit dialoogvenster heeft geen toegankelijke naam.
Hetzelfde probleem wordt waargenomen voor het dialoogvenster "Opslaan en later verdergaan" dat kan worden geopend door de knop "Tussentijds opslaan" te activeren op elke volledig of gedeeltelijk voltooide stap.
Oplossing:
Voeg een aria-label aan het dialoogvenster toe met een duidelijke beschrijving van de inhoud.
SC 2.4.11 Focus is bedekt door een sticky footer
Wanneer de website wordt verkleind naar een lagere resolutie, bedekt een sticky header een deel van de pagina-inhoud. Onderaan de meeste stappen van de formulieren bevindt zich een “Volgende”-knop. Wanneer zo’n pagina wordt ingezoomd tot 400% en de bezoeker met behulp van Shift Tab terug omhoog navigeert (van onder naar boven), krijgt de “Volgende”-knop toetsenbordfocus, maar de focusindicator is verborgen door de sticky header. Hierdoor is het onmogelijk om te zien waar de focus zich bevindt.
Zorg ervoor dat de sticky header geen interactieve elementen of hun focusindicatoren bedekt. Je moet hiervoor bijvoorbeeld de z-index aanpassen, elementen herpositioneren of de header/footer dynamisch verkleinen op kleinere schermen.
SC 2.4.3 Volgorde toetsenbordfocus is niet logisch
Wanneer pagina’s op een klein scherm worden bekeken, wordt het zijbalkmenu samengevouwen onder een knop met dezelfde naam als de hoofdheading van de pagina, bijvoorbeeld “Aanvraag inlogcode eParkeren voor bedrijven”. Deze knop wordt direct onder het logo geplaatst, maar de toetsenbordfocus verspringt niet naar deze knop; in plaats daarvan gaat de focus direct naar de pagina-inhoud. Deze volgorde van toetsenbordnavigatie is niet logisch. Voorbeelden hiervan zijn te zien op de volgende pagina’s:
Als bezoekers met het toetsenbord door de website navigeren, moeten interactieve elementen zoals knoppen en links op een logische volgorde toetsenbordfocus krijgen. Logisch betekent dat het aansluit op de volgorde die de elementen hebben in de visuele vormgeving. Anders kunnen bezoekers die alleen een toetsenbord gebruiken, minder makkelijk door de pagina navigeren. Het gaat dan bijvoorbeeld om mensen met een motorische of visuele beperking of een leesstoornis.
Oplossing:
Zorg dat het activeren van de knop de toetsenbordfocus verplaatst naar het volgende logische element in de reeks.
SC 2.4.3 Toetsenbordfocus gaat buiten het mobiele menu
Wanneer pagina’s op een klein scherm worden bekeken, wordt het zijbalkmenu samengevouwen onder een knop met dezelfde naam als de hoofdheading van de pagina, bijvoorbeeld “Aanvraag inlogcode eParkeren voor bedrijven”. Op dit moment kunnen bezoekers, wanneer het menu is geopend, met het toetsenbord uit het menu navigeren. De toetsenbordfocus verschuift dan naar de onderliggende pagina, terwijl het menu geopend blijft.
Voorbeelden hiervan zijn te zien op de volgende pagina’s:
Bij dit soort menu’s moet je de toetsenbordfocus goed instellen. Als het menu actief is, moet de focus binnen het menu blijven, en mag deze niet op de onderliggende pagina terechtkomen. Dit kun je op een van de volgende manieren oplossen:
Hou de focus binnen het menu totdat de bezoeker op de sluitknop heeft geklikt of op de ESC-toets heeft gedrukt.
Sluit het menu automatisch op het moment dat de toetsenbordfocus eruit gaat.
SC 2.4.7 Toetsenbordfocus is niet zichtbaar
Wanneer pagina’s op een klein scherm worden bekeken, wordt het zijbalkmenu samengevouwen onder een knop met dezelfde naam als de hoofdheading van de pagina, bijvoorbeeld “Aanvraag inlogcode eParkeren voor bedrijven”. Op dit moment is, wanneer het menu geopend is en bezoekers met het toetsenbord terug navigeren naar deze knop, de toetsenbordfocus niet zichtbaar.
Voorbeelden hiervan zijn te zien op de volgende pagina’s:
De toetsenbordfocus moet altijd zichtbaar zijn op interactieve elementen zoals links, knoppen en invoervelden die met het toetsenbord focus kunnen krijgen. Bezoekers die met het toetsenbord navigeren moeten goed kunnen zien op welke plek van de pagina ze zijn. Anders weten ze niet op welk moment ze op Enter moeten drukken om een knop of link te bedienen.
Oplossing:
Zorg dat de toetsenbordfocus zichtbaar is op de genoemde elementen.
SC 2.4.4 Linktekst is niet duidelijk genoeg
Advies: Op alle pagina’s is er een zijmenu met links naar de verschillende stappen. De toegankelijke namen van deze links bevatten momenteel alleen de zichtbare tekst, bijvoorbeeld naam: “Startpagina”. Wanneer een stap is afgerond, verschijnt er een vinkicoon met verborgen tekst “Voltooid”. Voeg deze verborgen tekst toe aan de toegankelijke naam van de link, zodat het doel van de link duidelijker wordt voor gebruikers van ondersteunende technologie.
Voorbeelden hiervan zijn te zien op de volgende pagina’s:
Linkteksten die meerdere keren op een pagina voorkomen of nietszeggend zijn (zoals ‘lees meer’), geven de bezoeker geen duidelijke aanwijzingen over hun bestemming.
Oplossing:
Zorg dat duidelijk is waar een link naartoe leidt, bijvoorbeeld door een tekst als ‘lees meer’ aan te vullen met de paginatitel. Als visueel duidelijk is bij welk onderdeel de link hoort, kan deze aanvullende tekst visueel verborgen worden. Bijvoorbeeld: ‘lees meer (over het project)’ of ‘lees meer (in onze blog)’.
SC 1.3.5 Invoervelden voor persoonlijke gegevens hebben geen autocomplete-attribuut
In de stap "Gegevens" staat een formulier met invoervelden voor persoonlijke gegevens (bijvoorbeeld achternaam, e-mailadres, telefoonnummer). Sommige velden missen het autocomplete-attribuut.
Invoervelden voor persoonlijke informatie zoals achternaam, e-mailadres of telefoonnummer moeten het autocomplete-attribuut hebben. Hierdoor kunnen browsers en hulpsoftware helpen bij het invoeren. Bijvoorbeeld door de velden al automatisch in te vullen. Gebruik het autocomplete-attribuut voor alle velden waar persoonlijke informatie in moet worden gevuld. Op deze pagina staat meer informatie over autocomplete en welke waardes verplicht gebruikt moeten worden: https://www.w3.org/Translations/WCAG22-nl/#input-purposes.
Vergelijkbare problemen komen ook voor in formulieren op andere pagina’s, zoals:
Veel van de problemen op deze pagina, met name binnen het formulier op de "Locatie" stap, zijn al gedocumenteerd in het gedeelte voor de "Aanvraag subsidie wijk-, buurt- en dorpsbudget" pagina.
SC 4.1.3 Aantal resterende tekens wordt niet automatisch voorgelezen door schermlezers
In dit formulier, in stap 5 (Omschrijving), zijn er twee tekstvelden: “Wat wilt u plaatsen?” en “Welke werkzaamheden gaat u uitvoeren?”. Onder elk van deze tekstvakken staat een teller die aangeeft hoeveel tekens er nog over zijn.
Deze teller is een statusmelding. Hoewel de informatie dynamisch wordt bijgewerkt, wordt dit niet doorgegeven aan screenreaders. Hierdoor missen gebruikers van ondersteunende technologieën belangrijke feedback over de invoerlimiet.
Statusberichten moeten automatisch voorgelezen worden door schermlezers zodra ze verschijnen of veranderen, maar de code die dit mogelijk maakt is nog niet toegevoegd.
Hetzelfde probleem in dit formulier bij stap "Locatie" met het veld "Wat is de locatie?".
Oplossing:
Voeg bijvoorbeeld aria-live="polite" aan de teller toe. Deze code moet er al staan op het moment dat de pagina wordt geladen.
Bezwaar maken tegen genomen besluit van de gemeente
SC 1.3.1 Visueel meerdere alinea’s, in de code maar één
In dit formulier wordt bij stap 4 (Soort vergunning), nadat de optie "150 - 500" of "Meer dan 500" is geselecteerd, hieronder extra tekst weergegeven. Dit blok tekst met drie paragrafen is onjuist gemarkeerd als een enkel p-element.
Visueel lijkt de tekst uit meerdere alinea’s te bestaan: blokjes tekst met witruimtes ertussen. Deze structuur moet ook in de code staan.
Oplossing:
Plaats elke alinea in een eigen p-element. Het aantal alinea’s dat je visueel ziet, moet dus gelijk zijn aan het aantal p-elementen in de code.
De problemen die op deze pagina zijn gevonden, zijn vergelijkbaar met of identiek aan de problemen die op andere pagina's en onderdelen van de website zijn gedetecteerd en beschreven.
PDF Schoolverklaring leerlingenvervoer
Link naar pagina: https://formulier.s-hertogenbosch.nl/leerlingenvervoer/introductie
In dit formulier staat bij stap 5 (Aanvraag) onder kopje "Selecteer de wijk" een keuzelijst (combobox-element) met het label "Wijk of dorp:". De toegankelijke naam ontbreekt. Dit voldoet ook niet aan het SC 2.5.3 omdat dit element niet met stem te bedienen is.
Oplossing:
Geef het combobox-element een toegankelijke naam.
SC 1.3.1 label-element is niet gekoppeld aan invoerveld
In dit formulier staat bij stap 5 (Aanvraag) onder "Selecteer de wijk" een keuzelijst (combobox-element). Het label-element met "Wijk of dorp:" is niet expliciet gekoppeld aan het bijbehorende invoerveld.
label-elementen moeten gekoppeld zijn aan de bijbehorende invoervelden. Hierdoor krijgt het invoerveld een toegankelijke naam, en heeft het label een groter klikgebied. Dit maakt het formulier toegankelijker. Omdat het invoerveld op dit moment geen toegankelijke naam heeft, wordt deze bevinding ook bij succescriterium 4.1.2 vermeld.
Oplossing:
Koppel de label-elementen aan hun bijbehorende invoervelden door het for attribuut op het label-element te gebruiken. In dit attribuut zet je het id van het invoerveld waar het label bij hoort.
SC 2.4.6 Naam van de knop beschrijft niet wat de knop doet
In dit formulier staat bij stap 5 (Aanvraag) onder "Selecteer de wijk" een keuzelijst (combobox-element) met het label "Wijk of dorp:". Na het selecteren van een optie verschijnt de knop met een X. De knop heeft de functie om de geselecteerde optie te verwijderen, maar de toegankelijke naam is "Remove item: '2', wat de functie niet nauwkeurig beschrijft. Dit voldoet ook niet aan SC 3.1.2 omdat een lokaal taalwissel ontbreekt.
Een blinde bezoeker weet daardoor niet wat deze knop precies doet.
Oplossing:
Zorg ervoor dat de toegankelijke naam de tekst van de geselecteerde optie bevat. Bijvoorbeeld: "Verwijder item: Boschveld" of simpelweg "Boschveld verwijderen".
SC 3.3.2 Invoerveld voor zoekopdrachten heeft geen permanent label en een onjuiste toegankelijke naam
In dit formulier, stap 5 (Aanvraag), onder “Selecteer de wijk”, verschijnt er een zoekveld wanneer het combobox-element wordt geopend. Dit invoerveld heeft meerdere toegankelijkheidsproblemen:
Er ontbreekt een permanente, zichtbare label. Het veld is afhankelijk van de placeholdertekst (“Typ om te zoeken”), wat in strijd is met SC 3.3.2 (Labels of Instructions), aangezien de placeholder verdwijnt zodra de gebruiker begint te typen.
Het invoerveld heeft een hardcoded toegankelijke naam van “false” (via aria-label="false"). Deze naam beschrijft het doel van het veld niet en vormt een schending van SC 2.4.6 (Headings and Labels).
De zichtbare placeholdertekst (“Typ om te zoeken”) komt niet overeen met de programmatische naam (“false”). Dit schendt SC 2.5.3 (Label in Name) en belemmert spraakbesturing, omdat gebruikers het veld niet kunnen activeren via de zichtbare tekst.
Deze combinatie van problemen veroorzaakt aanzienlijke drempels. Gebruikers kunnen de context verliezen zodra de placeholder verdwijnt. Screenreadergebruikers horen een betekenisloze naam (“false”) en gebruikers van spraakbesturing kunnen het veld niet betrouwbaar aanroepen.
Oplossing:
Implementeer een correcte, permanente label voor het zoekveld. Aangezien de zoekcontext visueel al duidelijk is, kan een visueel verborgen label hier een uitstekende oplossing zijn.
Voeg een <label>-element toe dat via for/id is gekoppeld aan het zoekveld.
Geef het label een duidelijke, beschrijvende tekst, bijvoorbeeld: “Zoek wijk of dorp”.
Verberg het label visueel met een CSS-klasse zoals sr-only of visually-hidden, zodat screenreaders het nog kunnen lezen.
Verwijder het attribuut aria-label="false" uit het invoerveld, zodat de nieuwe <label> de toegankelijke naam kan leveren.
SC 4.1.3 Melding over aangepaste zoekresultaten wordt niet automatisch voorgelezen door schermlezers
In dit formulier, stap 5 (Aanvraag), onder “Selecteer de wijk”, bevindt zich een dropdownlijst (combobox-element) met het label “Wijk of dorp:”. Wanneer deze wordt geopend, verschijnt er een zoekveld. Als er geen resultaten worden gevonden, verschijnt er een melding zoals “Geen resultaten gevonden” — dit gebeurt zonder dat de pagina wordt herladen.
Deze melding is een statusmelding, maar wordt niet aangekondigd door screenreaders. Hierdoor missen gebruikers van ondersteunende technologie cruciale feedback over het resultaat van hun zoekopdracht.
Oplossing:
Statusberichten moeten automatisch voorgelezen worden door schermlezers, maar de code die dit mogelijk maakt is nog niet toegevoegd. Je lost dit op door aria-live-attribute aan de melding toe te voegen.
SC 4.1.2 & 2.4.3 Niet-interactief element (<div>) krijgt toetsenbordfocus
In dit formulier, stap 5 (Aanvraag), wordt na het selecteren van een optie in het “Wijk of dorp:” combobox-element de geselecteerde waarde weergegeven. De implementatie van deze “geselecteerde item”-status is onjuist en leidt tot meerdere gerelateerde WCAG-overtredingen:
Onjuiste focusbeheer (SC 2.4.3 - Focus Order):
De toetsenbordfocus komt terecht op een niet-interactieve <div> met tabindex="0", in plaats van op een daadwerkelijk interactief element, zoals een <button>. Dit zorgt voor een onlogische focusstop en verwarring bij toetsenbordgebruikers.
Onjuiste roltoewijzing (SC 4.1.2 - Name, Role, Value):
Het element dat de geselecteerde optie weergeeft, functioneert feitelijk als een knop (het openen van de lijst bij klikken), maar is geïmplementeerd als een <div>. Het ontbreekt aan role="button", waardoor screenreaders de bedoeling en functionaliteit niet correct kunnen overbrengen.
Ongeldige ARIA-toepassing (SC 4.1.2):
De <div> met de geselecteerde waarde gebruikt ten onrechte aria-selected="true". Deze eigenschap is niet geldig op <div>-elementen en kan leiden tot onvoorspelbaar gedrag in screenreaders.
Deze combinatie van fouten zorgt voor een verwarrende en ontoegankelijke ervaring.
Toetsenbordgebruikers raken gefocust op een element waarmee ze niets kunnen, en screenreadergebruikers ontvangen foutieve informatie over rol en status. Hierdoor is het onduidelijk hoe ze de selectie kunnen wijzigen of verwijderen.
Oplossing:
Het “geselecteerde item” moet worden aangepast zodat semantiek en focusbeheer kloppen.
Gebruik een <button>:
Vervang de focusbare <div> door een semantisch correcte <button>. Dit lost zowel het focusprobleem als het rolprobleem op.
Geef een beschrijvende toegankelijke naam:
Verwijder onjuiste attributen:
Verwijder tabindex="0" van niet-interactieve containers en gebruik geen aria-selected op elementen die daar niet geschikt voor zijn.
SC 1.3.1 strong-element in plaats van kop-element
In dit formulier op stap 6 (Motivatie) is de tekst "Draagvlak" ten onrechte gemarkeerd met strong in plaats van met een heading-element.
Het strong-element is niet bedoeld om koppen mee te markeren. Je moet dat altijd doen met een kop-element, zoals h2. Koppen gebruik je om een tekst te structureren. Alleen als je ze als kop markeert met een kop-element, begrijpt hulpsoftware die betekenis.
Oplossing:
Verwijder het strong-element en gebruik het juiste kop-element om deze kop te markeren, zoals h3 of h4.
SC 1.3.1 Kop is niet gemarkeerd als koptekst
In dit formulier op stap 8 (Overzicht) zijn de volgende teksten niet gemarkeerd als koppen: "Persoonsgegevens", "Adresgegevens" en andere soortgelijke rubrieken.
Bezoekers die hulpsoftware gebruiken hebben niets aan een (tussen)kop die er wel uitziet als kop, maar niet als kop is gemarkeerd. Via de koppen op een pagina kunnen gebruikers van hulpsoftware de inhoud scannen of snel naar een bepaalde sectie springen. Maar dat kan alleen als de kop ook echt in de code staat. Als koppen alleen visueel als kop zijn vormgegeven (bijvoorbeeld vetgedrukt), ontstaat bovendien nog een ander probleem: de structuur van de informatie in de code wijkt dan af van de visuele structuur.
Een vergelijkbaar probleem doet zich voor in de stap “Overzicht” in andere formulieren, bijvoorbeeld op de volgende pagina’s:
Dit voorkom je door koppen altijd te markeren met het juiste HTML-element, op het juiste kopniveau: h1, h2, h3, h4, h5 of h6. Meestal kun je het kopniveau kiezen via de content-editor in je CMS. De HTML-code voor de kop wordt dan automatisch toegepast.
SC 1.3.1, 2.4.6, 2.5.3: Invoerveld heeft placeholder tekst als label
In dit formulier, in stap 5 (“Kaartgegevens”) (nadat op stap 3 “Gehandicaptenparkeerkaart” de optie “Ja, een Europese gehandicaptenparkeerkaart” is geselecteerd), is het <label>-element met de tekst “Wat is de vervaldatum van de kaart?” niet expliciet gekoppeld aan het bijbehorende invoerveld via overeenkomende for- en id-attributen. Dit voldoet niet aan SC 1.3.1 (Informatie en relaties).
Er zijn meer toegankelijkheidsproblemen in dit element:
Doordat de koppeling ontbreekt, gebruikt de browser de placeholdertekst “dd-mm-jjjj” als toegankelijke naam van het veld. Deze naam is niet beschrijvend en voldoet daarom niet aan SC 2.4.6 (Koppen en labels).
De toegankelijke naam (“dd-mm-jjjj”) bevat de zichtbare labeltekst “Wat is de vervaldatum van de kaart?” niet. Dit faalt SC 2.5.3 (Label in Name) en verhindert dat gebruikers het veld met spraakopdrachten kunnen activeren via de zichtbare tekst.
Vergelijkbare problemen doen zich voor op andere pagina’s:
https://formulier.s-hertogenbosch.nl/aanvraag-gebruik-gemeentegrond (stap “Locatie”) – velden: “Van” en “Tot en met”
En vergelijkbare problemen zijn aanwezig op andere pagina’s.
Oplossing:
Koppel het <label>-element aan het bijbehorende invoerveld door het for-attribuut te gebruiken. De waarde van for moet gelijk zijn aan de id van het input-element waar het label bij hoort.
SC 3.3.2 Geen instructie over de schrijfwijze van de datum
In dit formulier, stap 5 ("Kaartgegevens"), vereist het datuminvoerveld "Wat is de vervaldatum van de kaart?" een specifiek datumformaat (dd-mm-jjjj). Deze instructie wordt echter alleen gegeven als plaatshouder.
Hierdoor moet een bezoeker allerlei schrijfwijzen uitproberen om te ontdekken op welke manier de datum moet worden ingevuld. Dit is ontoegankelijk voor veel bezoekers, omdat de placeholder-tekst verdwijnt zodra de bezoeker begint te typen.
Hetzelfde probleem doet zich ook voor op de volgende pagina’s:
https://formulier.s-hertogenbosch.nl/aanvraagformulier-incidentele-informatiestandplaats/startpagina (stap “Gegevens standplaats”) bij het veld “Datum waarop de activiteit begint”
https://formulier.s-hertogenbosch.nl/evenement-melden bij de velden “Datum & tijd”
https://formulier.s-hertogenbosch.nl/aanvraag-gebruik-gemeentegrond (stap “Locatie”) bij de velden “Van” en “Tot en met”
Een vergelijkbaar probleem komt ook voor op andere pagina’s.
Oplossing:
Zorg dat de instructie over de schrijfwijze van de datum altijd zichtbaar is op de pagina. De beste manier is om de formaatvereiste (bijv. 'dd-mm-jjjj') als permanente hinttekst direct onder of naast het invoerveld te plaatsen. Voor de beste toegankelijkheid moet deze hinttekst programmatisch worden gekoppeld aan het invoerveld met het aria-describedby-attribuut.
In dit formulier, in stap 4 (Melding), verschijnt er een extra gedeelte nadat je op de knop “+ Nog één toevoegen” klikt. Wanneer er een datum wordt geselecteerd, verschijnen er twee knoppen: één met een potlood-icoon (bewerken) en één met een prullenbak-icoon (verwijderen).
Deze knoppen hebben geen toegankelijke naam. Daardoor is het voor screenreadergebruikers niet duidelijk wat de knoppen doen of waar ze voor bedoeld zijn.
Alle knoppen moeten een toegankelijke naam hebben die duidelijk beschrijft wat de functie is.
Oplossing:
Geef deze knoppen een toegankelijke naam, bijvoorbeeld via beschrijvende tekst of een aria-label, of een andere passende techniek.
Voldoet of niet van toepassing: 43
Voldoet niet: 12
