Content-audit digitale toegankelijkheid van website iburgerzaken.amersfoort.nl

Samenvatting

Wij hebben de content op de website iburgerzaken.amersfoort.nl onderzocht op 2 juli 2026. We keken naar twee processen: het aanvragen van een huwelijk en het aanvragen van een uittreksel BRP. In dit rapport lees je welke punten verbetering behoeven en hoe je deze kunt aanpakken.

Dit onderzoek richt zich op de content van de website. Technische aspecten zoals toetsenbordbediening, responsiveness en JavaScript-functionaliteit zijn niet onderzocht.

- 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
In opdracht van
gemeente Amersfoort
Leverancier techniek
iBurgerzaken
Datum rapport
2 juli 2026
Standaard
WCAG 2.2
Methodologie
WCAG-EM

Scope van het onderzoek

  • De content op de website iburgerzaken.amersfoort.nl

Buiten scope:

  • Technische aspecten van de website (JavaScript, toetsenbordbediening, responsiveness, etc.)
  • De overzichtspagina, omdat deze niet openbaar toegankelijk is
  • PDF's die als bevestiging door het systeem worden gegenereerd
  • 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 148
  • Google Chrome, versie 148
  • 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
  • SVG
  • WAI-ARIA

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.

Gevonden problemen

Filter bevindingen op:
Impact:
Type:

Link naar pagina: https://iburgerzaken.amersfoort.nl/gaas-web/server/continue/StartHuwelijk

#1 - Kop heeft niet de juiste opmaak

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

In stap 1 van het proces, waar de locatie kan worden gekozen, zijn enkele tussenkopjes niet als kop opgemaakt. Het gaat om "Omschrijving", "Grootte" en andere tussenkopjes bij de locatiekeuze. Deze teksten zijn visueel opgemaakt als kop, maar in de code is dat niet het geval: ze staan in <dt>-elementen, terwijl het omliggende <dl>-element ontbreekt. Daardoor zijn het noch correcte koppen, noch een correcte definitielijst.

Als tekst functioneert als kop maar de juiste opmaak mist, verliest die zijn semantische betekenis en wordt die ontoegankelijk voor bezoekers die afhankelijk zijn van hulpsoftware zoals schermlezers. Koppen zijn essentieel om de inhoud te navigeren en de structuur ervan te begrijpen.

User story

Als bezoeker lees ik de website met een schermlezer. Als ik een pagina op koppen navigeer, mis ik koppen die alleen visueel zijn opgemaakt. Ik verwacht dat alle zichtbare koppen door mijn schermlezer als kop worden herkend.

Hoe te testen

Snelle controle met onze tool: gebruik de Heading Structure Checker. Plak de pagina-URL en bekijk de lijst met koppen. Loop langs elke tekst op de pagina die er visueel uitziet als een kop (groter, vetter, een afwijkende kleur of nadrukkelijke positionering). Staan ze allemaal in de lijst van de Heading Structure Checker? Zo niet, dan zijn ze niet opgemaakt met h1 tot en met h6. Controleer met een schermlezer: navigeer met H (NVDA, JAWS) of de rotor (VoiceOver). Elke visuele kop moet als kop worden aangekondigd.

Oplossing

Zorg dat deze teksten worden opgemaakt met de juiste kop-elementen (h1 tot en met h6) om hun rol en hiërarchie in de inhoud weer te geven.

#2 - Onderstreepte tekst lijkt op een link

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

Op deze pagina staat een tekstblok waarvan de eerste zin is onderstreept. Het gaat om de zin die begint met "kosteloze ceremonie is alleen mogelijk ...". Onderstreepte tekst binnen lopende tekst wekt de indruk dat het om een link gaat. Dat is verwarrend voor bezoekers, en zeker voor bezoekers met een cognitieve beperking, omdat ze verwachten dat ze erop kunnen klikken.

User story

Ik ben gewend dat onderstreepte tekst in lopende tekst een link is. Ik klik op deze tekst, maar er gebeurt niets.

Hoe te testen

Klik op de onderstreepte tekst. Is het geen link? Verwijder dan de onderstreping.

Oplossing

Verwijder de onderstreping. Wil je deze tekst extra aandacht geven? Gebruik dan een kop, of maak enkele belangrijke woorden vet met de knop B in de tekstverwerker.

#3 - Informatieve afbeeldingen zonder tekstalternatief

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

Op deze pagina staat onder "Kies een locatie, ambtenaar of beschikbaarheid" een carrousel met twee afbeeldingen: een blauwe zaal en een gele zaal. Deze foto's hebben geen tekstalternatief. Voor een inwoner van de gemeente kan het belangrijk zijn om te weten wat het verschil tussen de twee ruimtes is. In de begeleidende tekst staat alleen dat er twee zalen met een klassiek interieur zijn.

User story

Als ik de foto's niet kan zien, weet ik niet hoe de twee zalen van elkaar verschillen. In de beschrijving op deze pagina lees ik alleen dat er twee zalen met een klassiek interieur zijn.

Hoe te testen

Inspecteer de HTML (de broncode) van de pagina of gebruik een schermlezer om te controleren of de afbeeldingen een tekstalternatief hebben.

Oplossing

Beschrijf de ruimtes in tekst. Bij deze carrousel is het technisch niet mogelijk om een tekstalternatief aan de foto's zelf toe te voegen.

Link naar pagina: https://iburgerzaken.amersfoort.nl/gaas-web/server/continue/StartAanvraagUittrekselBRP

#4 - Nadruk-elementen gebruikt voor opmaak in plaats van betekenis

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

Op deze pagina worden de elementen <strong> of <em> gebruikt om tekst visueel te laten opvallen, terwijl de inhoud zelf geen nadruk vereist. Schermlezers kunnen deze elementen met een andere klemtoon aankondigen. Daardoor krijgen woorden nadruk die niet bedoeld is, wat de betekenis van de tekst kan vertekenen.

User story

Ik lees de website met een schermlezer. Als ik een tekst beluister, klinken willekeurige woorden ineens benadrukt terwijl dat niet de bedoeling is. Ik verwacht dat alleen woorden die echt belangrijk zijn een andere klemtoon krijgen.

Hoe te testen

Loop de pagina door en kijk naar alle vetgedrukte en cursieve woorden. Vraag je per stukje vet of cursief af: is dit woord echt belangrijk, of zou je het in spraak benadrukken? Zo niet, dan hoort er geen <strong>- of <em>-element omheen, maar CSS-opmaak. Inspecteer de HTML: klik met de rechtermuisknop op het vetgedrukte of cursieve woord en kies "Inspecteren". Staat het woord in een <strong>- of <em>-element terwijl er geen semantische reden voor nadruk is? Dan klopt de opmaak niet.

Oplossing

Gebruik de knoppen B en I in de tekstverwerker alleen als een woord of zinsdeel echt belangrijk is of in spraak benadrukt zou worden. Wil je tekst alleen visueel laten opvallen? Gebruik dan CSS, bijvoorbeeld een eigen class met font-weight: bold of font-style: italic. Je kunt ook tussenkopjes toevoegen om aandacht te trekken.

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.