Ontwerpsystemen helpen bij toegankelijkheid, maar zijn niet de volledige oplossing.
Op 28 juni 2025 wordt digitale toegankelijkheid een wettelijke verplichting binnen de EU. Dat komt door de European Accessibility Act (EAA). Ook als je bedrijf buiten Europa zit maar wel diensten levert aan EU-gebruikers, moet je eraan geloven: de WCAG 2.2-regels gelden dan ook voor jou.
De nieuwe regels brengen extra succescriteria met zich mee, meer aandacht voor cognitieve toegankelijkheid en strengere eisen op WCAG AA-niveau. En de tijd tikt: als je na 28 juni 2025 niet voldoet, loop je het risico op juridische gevolgen en reputatieschade. Door nu al te starten kun je gericht plannen en gefaseerd verbeteren.
Bouw toegankelijkheid direct in je design system
Een goed design system helpt enorm om aan de toegankelijkheidseisen te voldoen. Door toegankelijke patronen direct in herbruikbare componenten te stoppen, leg je de basis voor een WCAG-conform product. Maar let op: dit is vaak niet genoeg. Het is belangrijk om te snappen wat je hiermee wél en niet oplost.
Ingebouwd op componentniveau
Elke UI-component moet bijdragen aan toegankelijkheid. Door herbruikbare oplossingen in je design system te standaardiseren, verklein je de kans op fouten. Een paar voorbeelden:
Semantische HTML genereren: Formuliervelden moeten een label hebben. Je kunt dat standaard in je component opnemen, zodat het automatisch goed gaat:
<FormField>
<FormFieldLabel>
Label
</FormFieldLabel>
<FormFieldHelperText>
Helper text
</FormFieldHelperText>
<TextInput />
</FormField>De HTML die dat oplevert:
<div class="form-field">
<label
class="form-field-label"
id=":r2r:"
for=":r2q:"
>
Label
</label>
<p
class="form-field-helper-text"
id=":r2s:"
>
Helper text
</p>
<input
class="text-inpu"
id=":r2q:"
aria-describedby=":r2s:"
>
</div>Zoals je ziet: alles is netjes gekoppeld, zonder dat de ontwikkelaar daar iets voor hoeft te doen. Beter voor de gebruiker én prettiger om mee te werken.
Automatische validatie: Sommige dingen kun je al in je systeem bouwen en automatisch laten checken. Bijvoorbeeld: afbeeldingscomponenten die verplicht alt-teksten nodig hebben (afgedwongen via TypeScript), of kleurtokens die tijdens de build gecheckt worden op voldoende contrast volgens WCAG.
Gestandaardiseerde interactiepatronen: Complexe elementen zoals dropdowns, modals of date pickers moeten goed werken met toetsenbordbediening, focusbeheer en ARIA-attributen. Je kunt hiervoor ‘headless components’ gebruiken, zoals van HeadlessUI of React Aria. Die hebben vaak al goede toegankelijkheidsfeatures ingebouwd (maar test het wel altijd even zelf na).
Interne tools delen
Soms heb je als ontwikkelaar net wat meer nodig. Wat als je de tools die intern in je design system worden gebruikt, ook beschikbaar maakt voor anderen?
Bijvoorbeeld: in je Button component zit een live region om loading states aan te kondigen. Waarom diezelfde utility niet aanbieden vanuit je library, zodat ook andere componenten (zoals dynamische lijsten) hier gebruik van kunnen maken?
import { addMessage, getContainerEl } from '@design-system/shared';
export const useLiveRegion = () => {
return {
announce(message: string, assertiveness: 'assertive' | 'polite' = 'polite') {
const containerEl = getContainerEl();
addMessage(containerEl, message, assertiveness);
},
};
};Grenzen en verwachtingen
Een goed design system legt een sterke basis, maar toegankelijkheid hangt niet alleen van techniek af. Menselijk inzicht en context zijn minstens zo belangrijk. Een paar voorbeelden:
- Inhoud en labels blijven mensenwerk. Je systeem kan dwingen dat er alt-tekst staat, maar of die ook duidelijk en relevant is, bepaal je zelf.
- Dynamische interacties zoals filters of tabellen met live-updates vragen vaak om maatwerk.
- Hoe componenten samen gebruikt worden doet ertoe. Los zijn ze misschien toegankelijk, maar samen kunnen ze alsnog verwarrend zijn voor gebruikers.
Daarom zeggen we: design systems maken toegankelijkheid mogelijk, maar garanderen het niet. Toegankelijkheid bereik je alleen als ontwerp, development, content en QA goed samenwerken.
Wat kun je nu al doen?
Met de EAA-deadline in zicht, hier onze aanbevelingen:
- Audit je design system op WCAG 2.2 AA-niveau: check kleurcontrasten, koppelingen tussen formuliervelden en labels, focus-states, toetsenbordbediening. Maar test ook met echte gebruikers die hulpmiddelen zoals screenreaders gebruiken.
- Standaardiseer patronen voor veelvoorkomende dingen: focusbeheer, live regions, foutmeldingen. Leg niet alleen uit hoe je ze gebruikt, maar ook wanneer en waarom.
- Documenteer je componenten goed, inclusief toegankelijkheidsrichtlijnen. Laat ook zien wat je níet moet doen (anti-patterns).
- Verzamel kennis in je organisatie: organiseer trainingen, doe regelmatige reviews en zorg dat teams makkelijk vragen kunnen stellen over toegankelijkheid. Het helpt als er experts of accessibility experts zijn binnen je team.
- Integreer automatische toegankelijkheidschecks in je CI-pipeline. Tools zoals axe-core, Lighthouse CI of pa11y helpen je om problemen vroegtijdig te detecteren en consistent te blijven. Deze checks zorgen ervoor dat je product een basisniveau van toegankelijkheid behoudt terwijl het groeit. Maar zie ze vooral als het startpunt – niet als het einddoel.
Benieuwd hoe jouw site ervoor staat?
Onze Accessibility Review helpt je site bruikbaar te maken voor iedereen—ongeacht beperking, apparaat of situatie. Met een grondige analyse, praktische aanpassingen en duidelijke uitleg zorgen we ervoor dat je voldoet aan de regels én een betere ervaring biedt aan je gebruikers.
