Audit digitale toegankelijkheid van website forms.pzhacc.nl

Samenvatting

Wij hebben de website forms.pzhacc.nl onderzocht op 16 maart 2026. In dit rapport lees je welke punten verbetering behoeven en hoe deze kunnen worden aangepakt.

- Voldoet
- Afgekeurd
55 Totaal
- voldoet
Impact
Klein: 0 Medium: 0 Groot: 0
Type
Content: 0 Techniek: 0
Score per richtlijn (goed)
Waarneembaar - van 20
Bedienbaar - van 20
Begrijpelijk - van 13
Robuust - van 2
Deze SC zijn afgekeurd:
Over dit onderzoek
Onderzocht door
Proper Access
Opdrachtgever
provincie Zuid-Holland
Datum rapport
16 maart 2026
Standaard
WCAG 2.2
Methodologie
WCAG-EM

Scope van het onderzoek

  • Alle formulieren op de website forms.pzhacc.nl

Buiten 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 143
  • Google Chrome, versie 143
  • Apple Safari, versie 18
  • 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
  • DOM

Voortgang opgeloste bevindingen

Samenwerken met je team

Exporteer alle bevindingen als CSV-bestand. Je kunt het in een (online) spreadsheet inladen om met je team samen te werken.

Importeer in Jira

Exporteer alle bevindingen als Jira-compatibel CSV-bestand. Je kunt het direct importeren via Jira > Issues > Import issues from CSV.

Zelf bijhouden in de browser

Houd per bevinding bij of het is opgelost. Je voortgang wordt opgeslagen in jouw browser. Niemand anders kan je resultaat zien.

Plan van aanpak

Het plan van aanpak is voor dit rapport niet beschikbaar.

Gevonden problemen

Filter bevindingen op:
Impact:
Type:

Link naar pagina: https://forms.pzhacc.nl/contact

#1 - Kop niet gemarkeerd als kop

Impact: Medium Type: Content WCAG: 1.3.1 EN: 9.1.3.1

Op deze pagina is de volgende tekst niet als kop gemarkeerd in de code: "Inleiding". Voor bezoekers die hulpsoftware gebruiken, is tekst die visueel als kop is vormgegeven maar niet als kop is gemarkeerd in de code niet bruikbaar. Deze bezoekers navigeren via koppen om de inhoud te scannen of snel naar een specifieke sectie te gaan. Dit is alleen mogelijk wanneer koppen ook in de code als kop zijn vastgelegd. Wanneer koppen uitsluitend visueel zijn vormgegeven, bijvoorbeeld door vetgedrukte tekst, wijkt de informatiestructuur in de code af van de visuele structuur van de pagina.

Oplossing:

Markeer koppen met het juiste HTML-element en gebruik daarbij het correcte kopniveau (h2 tot en met h6).

#2 - Huidige stap alleen aangegeven met kleur

Impact: Groot Type: Code WCAG: 1.4.1 EN: 9.1.4.1

Op deze pagina wordt de actieve stap uitsluitend aangegeven door een verschil in achtergrondkleur van de knop. Er wordt geen ander visueel kenmerk gebruikt, zoals een onderstreping, een ander letterformaat of een rand. Bezoekers die kleurverschillen niet kunnen waarnemen, kunnen daardoor niet bepalen welke stap op dit moment actief is.

Oplossing:

Voeg een extra visueel kenmerk toe aan de actieve stap naast het kleurverschil, zoals een onderstreping, rand of vetgedrukte tekst.

#3 - Validatiestatus alleen visueel aangegeven

Impact: Medium Type: Code WCAG: 1.3.1, 4.1.3 EN: 9.1.3.1, 9.4.1.3

Op deze pagina staat bij de stap "Je persoonlijke gegevens" een formulier met invoervelden. Wanneer een veld correct is ingevuld, wordt de geldige status alleen visueel aangegeven door een groene rand en een vinkjesicoon. Deze statuswijziging wordt niet programmatisch doorgegeven aan hulpsoftware. Hierdoor worden gebruikers van schermlezers niet geïnformeerd dat het invoerveld succesvol is gevalideerd. Hetzelfde geldt voor de stap "Je vraag". Hetzelfde probleem doet zich voor op de pagina https://forms.pzhacc.nl/digid_eform_schadeclaim-indienen bij de stap "Aanvrager".

Oplossing:

Zorg ervoor dat statuswijzigingen van de validatie programmatisch worden doorgegeven, zodat hulpsoftware ze kan detecteren en aankondigen. Mogelijke oplossingen:

  • bied een programmatisch gekoppelde tekststatus voor het veld, bijvoorbeeld via aria-describedby
  • kondig validatieresultaten dynamisch aan met een aria-live-regio
  • toon zichtbare statustekst naast het veld, niet alleen een vinkje en kleur

#4 - Afbeelding heeft geen tekstalternatief (alt-attribuut ontbreekt)

Impact: Medium Type: Techniek WCAG: 1.1.1 EN: 9.1.1.1

Op deze pagina opent bij de stap "Je vraag" de knop met een i-icoon extra inhoud. Deze inhoud bevat een i-icoon dat als img-element is toegevoegd zonder alt-attribuut. Een img-element moet altijd een alt-attribuut hebben. Bij een decoratieve afbeelding die geen betekenis overdraagt, laat je dit attribuut leeg. Dan staat er alt="". Bij een informatieve afbeelding voeg je een duidelijke beschrijving van de afbeelding toe. Hetzelfde probleem doet zich voor op de pagina https://forms.pzhacc.nl/digid_eform_schadeclaim-indienen bij de stap "Aanvrager", met dezelfde iconen.

Oplossing:

Voeg het alt-attribuut toe aan het img-element. Omdat het hier waarschijnlijk om een decoratieve afbeelding gaat, laat het alt-attribuut leeg.

#5 - Opsomming onjuist gemarkeerd

Impact: Medium Type: Content WCAG: 1.3.1 EN: 9.1.3.1

Op deze pagina opent bij de stap "Je vraag" de knop met een i-icoon extra inhoud. Deze inhoud bevat een lijst met 2 items die niet correct is gemarkeerd in de code. Daardoor is de structuur van de informatie niet correct vastgelegd en kan hulpsoftware niet herkennen dat het om een opsomming gaat. Schermlezers kondigen in dat geval niet aan hoeveel items een lijst bevat. Dit maakt het voor gebruikers van een schermlezer lastiger om de hoeveelheid informatie in te schatten.

Oplossing:

Zorg ervoor dat alle opsommingen correct worden gemarkeerd in de HTML-structuur, bijvoorbeeld met een <ol>-element (genummerde lijst) of <ul>-element (opsomming met opsommingstekens). Meer informatie over het belang van correcte HTML-lijsten is te vinden op: https://www.properaccess.nl/blog/waarom-correcte-html-lijsten-het-verschil-maken-in-toegankelijkheid/.

#6 - Icoon 'opent in nieuw browsertab' heeft geen tekstalternatief

Impact: Medium Type: Content WCAG: 1.1.1 EN: 9.1.1.1

Op deze pagina staat bij de stap "Gegevens controleren" een link naar "https://www.zuid-holland.nl/algemeen/privacyverklaring" met een icoon dat aangeeft dat de link in een nieuw browsertab wordt geopend. Dit icoon heeft geen alternatieve tekst, waardoor gebruikers van schermlezers niet weten dat de link in een nieuw venster opent. Een gebruiker van een schermlezer weet niet dat deze link een nieuwe browsertab zal openen. Dit is belangrijke informatie die als tekst aanwezig moet zijn, zodat een schermlezer het kan voorlezen. Hetzelfde probleem doet zich voor met dezelfde link op de pagina https://forms.pzhacc.nl/digid_eform_schadeclaim-indienen bij de stap "Controleren en verzenden", onder de kop "Akkoord".

Oplossing:

Voeg de informatie dat de link een nieuwe browsertab opent toe als visueel verborgen tekst die wel toegankelijk is voor schermlezers.

#7 - Tekst als afbeelding geplaatst met afwijkend tekstalternatief

Impact: Medium Type: Content WCAG: 1.1.1, 1.4.5 EN: 9.1.1.1, 9.1.4.5

Op deze pagina staat na het succesvol verzenden van het formulier, onderaan de pagina, een afbeelding met de ingesloten tekst "Elke dag beter. Zuid-Holland". Het tekstalternatief ("Provincie Zuid-Holland motto") komt niet overeen met de zichtbare tekst. Hierdoor wordt aan verschillende gebruikersgroepen verschillende informatie overgebracht. Dit voldoet niet aan succescriterium 1.1.1 (Niet-tekstuele inhoud). Daarnaast beperkt het insluiten van tekst in afbeeldingen de toegankelijkheid, omdat bezoekers de tekst niet kunnen vergroten, herstijlen of aanpassen aan hun behoeften. Dit voldoet niet aan succescriterium 1.4.5 (Afbeeldingen van tekst).

Oplossing:

Het is beter om deze tekst als gewone tekst op de pagina te plaatsen en te stylen met CSS. Op die manier kunnen mensen de grootte, kleur of het lettertype aanpassen zodat het voor hen leesbaarder wordt. Als de tekst in de afbeelding zit gebakken, kunnen ze dit niet doen.

#8 - Bij 400% [/320px breedte] zoom is een horizontale scrollbar aanwezig

Impact: Groot Type: Techniek WCAG: 1.4.10 EN: 9.1.4.10

Wanneer deze pagina wordt bekeken op een schermresolutie van 1280 bij 1024 pixels en ingezoomd tot 400% [320px breedte], verschijnt er een horizontale scrollbar bij de stap "Je vraag". Horizontaal scrollen op de hele pagina is niet toegestaan, ook niet als de viewport is ingesteld of ingezoomd op 320 CSS-pixels breed (voor verticale inhoud) of 256 CSS-pixels hoog (voor horizontale inhoud). Zorg ervoor dat de tekst binnen het scherm past. Alleen als scrollen in beide richtingen echt nodig is voor de betekenis of het gebruik van de inhoud mag het wel. Uitzonderingen zijn tabellen, informatieve afbeeldingen, presentaties, video en kaarten. Deze moeten leesbaar blijven, dus binnen deze elementen mag je wel scrollen. Hetzelfde probleem doet zich voor op de pagina https://forms.pzhacc.nl/digid_eform_schadeclaim-indienen bij de stappen "Bijlagen" en "Controleren en verzenden".

Oplossing:

Zorg ervoor dat de pagina-inhoud zich aanpast aan kleinere schermen. Verwijder de horizontale scrollbar op de hele pagina en behoud deze alleen binnen de tabel onder de tekst "Geüploade bestanden".

Link naar pagina: https://forms.pzhacc.nl/digid_eform_schadeclaim-indienen

#9 - Betekenis van verplicht-symbool niet uitgelegd

Impact: Medium Type: Content WCAG: 3.3.2 EN: 9.3.3.2

Op deze pagina staat bij de stap "Aanvrager" een formulier met meerdere verplichte velden die met een asterisk zijn gemarkeerd. Wanneer een asterisk wordt gebruikt om verplichte velden aan te geven, moet er boven het formulier een instructie staan zoals "Velden gemarkeerd met * zijn verplicht".

Oplossing:

Voeg een instructie toe boven het formulier, zoals "Velden gemarkeerd met * zijn verplicht".

#10 - autocomplete-attribuut ontbreekt bij invoervelden voor persoonsgegevens

Impact: Medium Type: Techniek WCAG: 1.3.5 EN: 9.1.3.5

Op deze pagina staat bij de stap "Aanvrager" een formulier met invoervelden voor persoonsgegevens. De invoervelden voor telefoonnummers "Telefoonnummer 1" en "Telefoonnummer 2" bevatten geen passend autocomplete-attribuut om het doel van het veld programmatisch vast te leggen. Dit maakt het voor browsers en hulpsoftware lastiger om automatisch invullen te ondersteunen en gebruikersgegevens correct te interpreteren.

Oplossing:

Voeg passende autocomplete-attributen toe aan beide telefoonnummervelden. Mogelijke oplossingen:

  • als het twee gelijkwaardige telefoonnummers zijn, gebruik dan autocomplete="tel" voor beide velden
  • als het van toepassing is, maak onderscheid met specifiekere waarden zoals tel-mobile, tel-home of tel-work. Meer informatie over autocomplete en welke waarden je verplicht moet gebruiken: https://www.w3.org/Translations/WCAG22-nl/#input-purposes.

#11 - De kleur van de rand van invoervelden heeft niet genoeg contrast

Impact: Medium Type: Techniek WCAG: 1.4.11 EN: 9.1.4.11

Op deze pagina staan bij de stap "Schadeclaim" twee textarea-elementen met de labels "Hoe is de schade ontstaan?" en "Waarom bent u van mening dat de provincie aansprakelijk is?" De contrastverhouding tussen de grijze rand (#EBEBEB) en de witte achtergrond van de pagina is 1,2:1. De randen van interactieve elementen zoals invoervelden moeten minimaal een contrast van 3,0:1 hebben met de achtergrond. Hetzelfde probleem geldt voor "Beschrijf de schade aan uw voertuig" bij dezelfde stap, wanneer de optie "Voertuig" is geselecteerd bij "Waaraan heeft u schade?".

Oplossing:

Zorg ervoor dat de contrastverhouding tussen de randen van de invoervelden en de achtergrond hoger is dan 3,0:1. Pas de randkleur aan zodat deze beter zichtbaar is tegen de achtergrond.

#12 - Informatief icoon heeft geen tekstalternatief

Impact: Groot Type: Content WCAG: 1.1.1 EN: 9.1.1.1

Op deze pagina heeft de voltooide stap een vinkjesicoon naast de knop, bijvoorbeeld naast "Aanvrager". Dit is een informatief icoon dat betekenis overdraagt aan ziende bezoekers, maar geen tekstalternatief heeft dat toegankelijk is voor schermlezers. Gebruikers van schermlezers kunnen de betekenis van het icoon daardoor niet achterhalen. Voeg een alternatieve tekst toe via bijvoorbeeld een aria-label, aria-labelledby of visueel verborgen tekst. Vergelijk dit met de implementatie op de pagina https://forms.pzhacc.nl/contact, waar vergelijkbare iconen wel een tekstalternatief hebben.

Oplossing:

Voeg een tekstalternatief toe aan het icoon, bijvoorbeeld met een aria-label of een visueel verborgen <span> met beschrijvende tekst.

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.

Hoe werkt dit rapport?

Bevindingen bekijken en filteren

Alle gevonden toegankelijkheidsproblemen staan onder Gevonden problemen. Je kunt de bevindingen filteren op:

  • Impact (Groot, Medium, Klein, Advies) — hoe ernstig is het probleem voor de gebruiker?
  • Type (Content, Techniek) — moet de inhoud of de techniek worden aangepast?
  • Status (Open, Opgelost) — welke problemen zijn al verholpen?

Voortgang bijhouden

Je kunt je voortgang op twee manieren bijhouden:

  • CSV-export — exporteer alle bevindingen als CSV-bestand en laad het in een (online) spreadsheet om met je team samen te werken.
  • Jira-export — exporteer alle bevindingen als Jira-compatibel CSV-bestand. Importeer het via Jira > Issues > Import issues from CSV. Bevindingen worden aangemaakt als bugs met prioriteit op basis van impact.
  • Registreer in de browser — activeer deze optie om per bevinding bij te houden of het is opgelost. Je voortgang wordt opgeslagen in je browser. Niemand anders kan je resultaat zien. Let op: de voortgang is gekoppeld aan je browser. Als je een andere browser of een ander apparaat gebruikt, begint de telling opnieuw.
  • Plan van aanpak — download een geprioriteerd plan van aanpak om de gevonden problemen stap voor stap op te lossen. Dit is beschikbaar bij audits vanaf maart 2026.

Link naar een specifieke bevinding delen

Bij elke bevinding verschijnt een link-icoon wanneer je er met de muis overheen gaat. Klik op dit icoon om de directe link naar die bevinding te kopiëren. Je kunt deze link plakken in een e-mail of chatbericht, bijvoorbeeld om een vraag te stellen aan Proper Access over een specifiek punt.