📅 Het traject in vogelvlucht

🔧 Wat we technisch hebben gedaan

1. Semantische HTML & landmarks

Generieke <div>-elementen zijn vervangen door betekenisvolle HTML-tags zoals <nav>, <main> en <button>. Hierdoor krijgen screenreaders een duidelijke en logische structuur.

2. Volledige toetsenbordondersteuning

Alle interactieve elementen—menu’s, dialogen, formulieren en knoppen—zijn volledig bedienbaar met alleen een toetsenbord (Tab, Shift+Tab, Enter, Spatie en pijltjestoetsen). We hebben daarnaast een duidelijke focusstijl toegevoegd zodat gebruikers nooit hun positie verliezen.

3. Doordacht gebruik van ARIA

Waar semantische HTML niet volstond, gebruikten we ARIA-attributen om extra context te bieden:

• aria-label voor knoppen met alleen een icoon.
• aria-live="polite" om dynamische updates (zoals statuswijzigingen) aan te kondigen.
• role="alert" voor belangrijke foutmeldingen.
• aria-describedby om foutmeldingen direct te koppelen aan formuliervelden.

4. Toegankelijke formulieren

Elk invoerveld heeft nu:

• Een correct gekoppeld <label>.
• Duidelijke foutmeldingen die direct verbonden zijn aan het betreffende veld.
• Logische focusnavigatie die gebruikers naar correcties leidt.

5. Kleurcontrast

Met tools als axe-core en de WebAIM checker hebben we alle contrastproblemen opgelost. Alle teksten en UI-componenten voldoen nu aan de WCAG AA-minimumvereisten (4,5:1 voor tekst, 3:1 voor grafische elementen).

6. PDF-toegankelijkheid

Voor downloadbare PDF’s voerden we aparte controles uit met de PDF Accessibility Checker (PAC 2021). Daarmee verzekerden we ons dat PDF’s:

• De juiste leesvolgorde en tags hebben.
• Toegankelijke lettertypen en tekstcodering gebruiken.
• Documentstructuur en metadata bevatten.

Na deze grote herstelronde kwamen we tot een cruciale realisatie: problemen achteraf oplossen is geen houdbare strategie. Toegankelijkheid moest ingebouwd worden in onze cultuur en processen, zodat issues niet telkens opnieuw ontstaan. Dat leidde tot een fundamentele verandering in onze werkwijze.

🧪 Hoe we onze workflow hebben aangepast

Om toegankelijkheid blijvend te waarborgen, hebben we het direct ingebed in ons ontwikkelproces.

✅ Elke Pull Request bevat nu een accessibility review

In elke PR hanteren we een verplichte checklist. Voordat code wordt gemerged, moeten ontwikkelaars bevestigen dat er is getest op:

• Geen axe-core overtredingen & een Lighthouse-score van 90+.
• Volledige toetsenbordnavigatie met zichtbare focusindicator.
• Heldere screenreader-aankondigingen (getest met NVDA/VoiceOver).
• Geverifieerde kleurcontrastverhoudingen.

🔍 Gestandaardiseerde tooling

Ons hele team werkt nu met:

• AI-integratie met Windsurf: Dit project toonde ons commitment om AI op slimme manieren in te zetten. Door Windsurf en zijn modellen te integreren in onze workflow, konden we complexe toegankelijkheidsproblemen automatisch detecteren en valideren. Deze AI-aanpak versnelde onze voortgang aanzienlijk en verhoogde de nauwkeurigheid.
• axe DevTools (browserextensie).
• Lighthouse-audits in Chrome DevTools.
• Screenreaders: VoiceOver (macOS) & NVDA/Narrator (Windows).

🎉 De resultaten

• ✅ Officieel WCAG 2.1 AA-gecertificeerd!
• ⚙️ Minder bugs: betere semantische markup resulteerde in robuustere code.
• 🧠 Betere onboarding: nieuwe developers hebben nu duidelijke richtlijnen.
• 🤝 Een inclusieve ervaring voor álle gebruikers, ook die met ondersteunende technologie.

🏁 Belangrijkste inzichten

Deze reis ging om meer dan het oplossen van een lijst problemen; het was een cultuurverandering. Het portaal is nu gecertificeerd, maar belangrijker: we bouwen voortaan standaard met toegankelijkheid in gedachten.

Ons succes benadrukt ook de kracht van de juiste technologie. Door AI-tools zoals Windsurf te omarmen, konden we sneller vooruitgang boeken en slimmer bouwen. Het is een perfect voorbeeld van hoe we uitdagingen bij ParQ aanpakken.

Toegankelijkheid is er niet voor uitzonderingen—het is er voor mensen. En het is een fundamenteel onderdeel van hoe wij software ontwikkelen.