Toegankelijkheid (a11y) in Hyvä UI

Toegankelijkheid (a11y) in Hyvä UI

WCAG 2.1 AA is geen optie meer voor webshops met meer dan 50 werknemers of overheidscontracten — het is een wettelijke eis. Hyvä UI levert een solide basis: keyboard-navigatie, focus-management en ARIA-attributen zitten standaard in de componenten. Maar "solide basis" is niet hetzelfde als "WCAG-compliant out of the box". Dit artikel legt uit wat Hyvä UI voor je regelt, en waar je zelf nog werk hebt.

Wat Hyvä UI standaard regelt

De componenten die Hyvä UI levert, hebben de volgende a11y-patronen standaard ingebakken:

• Modals en dropdowns zijn volledig bedienbaar via Tab, Shift+Tab, Enter en Escape.
• Focus-trap in modals: Tab blijft binnen het geopende dialoogvenster totdat je sluit.
• Accordions en tabs reageren op pijltjestoetsen volgens het ARIA Authoring Practices Guide (APG) patroon.

• aria-expanded, aria-controls en aria-hidden worden dynamisch gezet via Alpine.js.
• Modals gebruiken role="dialog" met aria-modal="true" en een gekoppelde aria-labelledby.
• Form-componenten koppelen aan input via for/id, met aria-describedby voor foutmeldingen.

• Bij het openen van een modal verschuift focus automatisch naar de eerste interactieve element.
• Bij sluiten keert focus terug naar de trigger-knop.
• Skip-link patroon is beschikbaar als utility-component.

Dit zijn niet triviaal. De meeste custom-built Magento 2 themes falen op al deze punten. Luma doet het ook niet goed — keyboard-navigatie in de Luma checkout is een gevecht.

De gaten: wat je zelf moet doen

Eerlijk zijn: Hyvä UI is geen complete WCAG-oplossing. De componenten zijn toegankelijk gebouwd, maar een volledig WCAG 2.1 AA-conformant project vraagt meer.

Hyvä UI levert design tokens en een Figma Community-bestand. De standaard kleurpaletten zijn niet automatisch WCAG-compliant. Contrast ratio voor normale tekst moet minimaal 4.5:1 zijn, voor grote tekst 3:1.

Controleer dit altijd zelf:

# Gebruik een tool als axe-core in je CI/CD pipeline
npm install --save-dev @axe-core/cli
npx axe https://jouwshop.nl --include "main" --exit

Of integreer axe in je Playwright/Cypress tests zodat contrast-fouten je build breken.

De standaard browser-focus ring is in veel Tailwind-setups uitgeschakeld via outline-none of focus:outline-none. Hyvä UI gebruikt focus-visible utility classes, maar als jij of je designer deze overschrijft, is het weg. Controleer elke interactieve component op zichtbare focus.

Product images, banners, CMS-blokken: Hyvä UI regelt de HTML-structuur, maar de alt-teksten moet je content-team zelf invullen. Dit is organisatorisch, niet technisch.

Hyvä UI koppelt labels aan inputs, maar de foutmeldingsteksten die je checkout of formuliervalidatie genereert, moeten zelf ook voldoen: beschrijvend, gekoppeld via aria-describedby, en niet alleen via kleur aangegeven.

Als je AJAX-resultaten inlaadt (zoekautocomplete, filterresultaten), moet je aria-live regions inzetten zodat screenreaders de update aankondigen. Dit is een patroon dat Hyvä UI niet automatisch voor je bouwt — het hangt af van je specifieke implementatie.

Vergelijking: Hyvä UI vs. standaard Magento 2 (Luma)

De conclusie: Hyvä UI scoort op componentniveau significant beter dan Luma. Maar WCAG 2.1 AA is een project-breed oordeel, geen componentniveau-oordeel.

Hoe je een WCAG-audit aanpakt met Hyvä UI

Wij zien bij klanten dat de meeste toegankelijkheidsfouten niet in de componentbibliotheek zitten, maar in de implementatie en content. Een praktische aanpak:

1. Geautomatiseerde scan — axe-core of Lighthouse op alle kritieke pagina's (homepage, categorie, product, checkout, contact). Dit pikt ~30-40% van de problemen op.
2. Handmatige keyboard-test — Tab door de hele checkout zonder muis. Lukt dat zonder struikelblokken? Kom je in alle dropdowns en modals?
3. Screenreader-test — NVDA (Windows, gratis) of VoiceOver (Mac, ingebouwd). Test de productpagina en checkout flow.
4. Kleurcontrast-check — Gebruik de Colour Contrast Analyser van TPGi op alle tekst/achtergrond-combinaties in je Figma-bestand voordat je bouwt.
5. Content-audit — Alle alt-teksten, formulierlabels, foutmeldingen. Dit is handwerk.

De Figma Community-bestanden van Hyvä UI helpen hier: design tokens en componenten matchen 1-op-1 met de code. Dat betekent dat je contrast-problemen al in Figma kunt opsporen, niet pas na de build.

Alpine.js en ARIA: een eerlijk beeld

Alpine.js is de JavaScript-laag in Hyvä UI. Het is minimaal (~95% minder JavaScript dan Luma), maar het beheert wel alle dynamische ARIA-states. Dat werkt goed voor de standaard-componenten.

Waar het mis kan gaan:

• Je bouwt een custom component in Alpine.js zonder de ARIA-patronen over te nemen.
• Je kopieert een component en haalt de x-bind:aria-expanded eruit omdat je de logica niet begrijpt.
• Je gebruikt een derde Alpine-plugin die de focus-management overschrijft.

De oplossing: zorg dat je development team de ARIA Authoring Practices Guide kent. Niet elk detail, maar de patronen voor de meest gebruikte widgets: modal, disclosure, tabs, combobox.

Wanneer Hyvä UI niet de juiste keuze is

Hyvä UI is een sterke keuze voor teams die zelf bouwen en de controle willen over hun HTML. Maar er zijn situaties waarin het niet passend is:

• Je hebt een extern accessibility-bureau dat een specifiek component-framework vereist. Sommige bureaus werken alleen met React-gebaseerde design systems die ze al gevalideerd hebben (zoals Radix UI of Headless UI). Hyvä UI past daar niet in.
• Je wilt een plug-and-play WCAG-gecertificeerd systeem. Dat bestaat niet echt — WCAG-conformance is altijd projectspecifiek. Maar als je verwacht dat een componentbibliotheek jou automatisch compliant maakt zonder implementatiewerk, stelt Hyvä UI (en elke andere library) je teleur.
• Je werkt buiten Magento 2, Laravel of een HTML-gebaseerde stack. Hyvä UI is framework-agnostisch en bruikbaar in statische sites en headless setups, maar als je volledig in een React of Vue SPA werkt, zijn er alternatieven die beter passen bij die ecosystemen.
• Je hebt WCAG 2.2 AAA als eis. AA is al ambitieus; AAA vereist aanpassingen die Hyvä UI niet standaard levert en die soms niet haalbaar zijn voor commerciële webshops.

Licentie en kosten in relatie tot a11y-investering

Hyvä UI kost eenmalig ongeveer 250 euro per ontwikkelaar of project — geen abonnement. Dat is een verwaarloosbaar bedrag vergeleken met de kosten van een externe WCAG-audit (vaak 2.000-5.000 euro voor een serieuze audit) of een juridisch geschil.

De componentbibliotheek neemt een fors deel van het implementatiewerk weg. Maar reken in je project altijd apart tijd in voor:

• Kleurcontrast-iteraties met je designer.
• Handmatige keyboard- en screenreader-tests.
• Content-training voor je redacteam (alt-teksten, foutmeldingen).
• Een geautomatiseerde axe-scan in je CI/CD pipeline.

De componentkosten zijn laag. De implementatietijd is reëel.

Conclusie

Hyvä UI levert een toegankelijker fundament dan bijna elke Magento 2 standaard-theme. Keyboard-navigatie, focus-management en ARIA-attributen zitten standaard goed. Dat bespaart je aanzienlijk tijd.

Maar WCAG 2.1 AA is meer dan correcte componenten. Kleurcontrast, alt-teksten, foutmeldingen en dynamische live regions vallen buiten wat een componentbibliotheek voor je kan regelen. Die verantwoordelijkheid ligt bij het development team en de organisatie.

Wil je weten waar jouw Magento 2 of custom webshop nu staat op het gebied van toegankelijkheid en performance? Wij doen een gratis Tech Check via /contact — geen salesgesprek, maar een directe technische analyse van wat er nu niet klopt en wat het kost om het te fixen.