Toegankelijkheid in Hyvä-thema's

Toegankelijkheid was vroeger een “leuk als het lukt”-punt onderaan het projectplan van een Magento-project. In Europa is dat veranderd. De European Accessibility Act geldt sinds juni 2025 voor veel webshops en verwijst naar de WCAG-richtlijnen als praktische norm.

Los van de wet is toegankelijkheid gewoon goed voor je bedrijf. Een webshop die werkt met een toetsenbord, een schermlezer of een ingezoomd scherm, werkt ook beter voor iedereen op een kleine telefoon.

Dit artikel bekijkt wat Hyvä je geeft, wat niet, en hoe we toegankelijkheid controleren als we een Hyvä-webshop bouwen of migreren.

Waarom Hyvä een goed vertrekpunt is

De frontend van Luma leunt op RequireJS, KnockoutJS en jQuery-widgets. Veel onderdelen van de interface worden in de browser door JavaScript aangemaakt, waardoor ze lastiger te inspecteren en te repareren zijn.

Hyvä vervangt dit door HTML die op de server wordt gerenderd, Alpine.js voor kleine interactieve onderdelen en Tailwind CSS voor de opmaak. Dat heeft een paar directe voordelen voor toegankelijkheid:

• De HTML staat in de template. Wat je in het .phtml -bestand ziet, ligt dicht bij wat hulptechnologie leest.
• Minder JavaScript. In onze benchmark laadden Hyvä-pagina's ongeveer 26 KB JavaScript tegenover 463–524 KB bij Luma. Minder script betekent minder kans dat de focus verloren gaat.
• Tailwind-hulpmiddelen. Utilities zoals sr-only, focus-visible: en motion-reduce: maken goede gewoontes makkelijk toe te passen.
• De state van Alpine.js is zichtbaar. State zoals open of gesloten kun je in de markup direct aan ARIA-attributen koppelen.

Wil je de technische achtergrond, lees dan hoe Alpine.js en Tailwind RequireJS en Knockout vervangen.

Wat Hyvä niet voor je kan doen

Een thema is alleen een vertrekpunt. De meeste toegankelijkheidsproblemen die we in Magento-webshops vinden, komen uit onderdelen die het thema niet beheerst:

• Maatwerktemplates die een div met een click handler gebruiken in plaats van een button.
• Extensies van derden met hun eigen pop-ups, sliders en formulieren.
• Merkkleuren met te weinig contrast.
• Productafbeeldingen zonder bruikbare alt-tekst.
• CMS-content met koppen die gekozen zijn op grootte, niet op volgorde.
• Cookiebanners en chatwidgets die de toetsenbordfocus vasthouden.

Tijdens een migratie wordt elke extensietemplate toch al herschreven of vervangen. Dat is het juiste moment om deze problemen op te lossen, in plaats van ze mee te nemen naar het nieuwe thema. Onze extensiechecklist legt uit hoe we modules een voor een doorlopen.

Toegankelijke Alpine.js-componenten

Veel webshopcomponenten zijn eenvoudige uitklapelementen: een filtergroep, een mobiel menu, een antwoord in de FAQ. Het patroon is altijd hetzelfde. Een echte button bedient een gebied, en die button vertelt hulptechnologie of het gebied open is.

<div x-data="{ open: false }">
  <button type="button"
          @click="open = !open"
          :aria-expanded="open.toString()"
          aria-controls="filter-size">
    Maat
  </button>
  <div id="filter-size" x-show="open">
    ...
  </div>
</div>

Modals en off-canvas menu's vragen meer zorg. De focus moet naar het dialoogvenster gaan als het opent, erin blijven zolang het open is, en terugkeren naar de trigger als het sluit. De Escape-toets moet het sluiten.

We toetsen elk interactief component aan deze regels, vooral de componenten die uit extensies komen.

Kleur, contrast en focus

Contrast is het meest voorkomende probleem dat we zien, en vaak is het een merkkeuze, geen bug in de code. Lichtgrijze tekst op wit ziet er elegant uit, maar valt door contrastcontroles en is buiten op een telefoon moeilijk te lezen.

Focusstates zijn het op één na meest voorkomende probleem. Sommige ontwerpen halen de focusrand weg omdat die “rommelig oogt”. Toetsenbordgebruikers zien dan niet meer waar ze zijn. Met Tailwind toont een duidelijke focus-visible: -stijl de rand voor toetsenbordgebruikers zonder hem bij elke muisklik te laten zien.

Als je team kleuren vanuit de admin kan wijzigen, vraagt contrast extra aandacht. Hoe we dat aanpakken, leggen we uit in kleuren van een Hyvä-thema aanpassen vanuit de beheeromgeving.

Formulieren en checkout

In de checkout komen toegankelijkheid en conversie samen. Elk formulierveld heeft een zichtbaar label nodig, niet alleen een placeholder. Foutmeldingen moeten zeggen wat er misging en voorgelezen worden door schermlezers.

Betaalmethoden verdienen speciale aandacht. Veel betaalproviders laden hun eigen velden in een iframe, dus hun toegankelijkheid ligt deels buiten jouw invloed. Test ze met een toetsenbord in elke markt waarin je verkoopt.

Onze eigen checkouttemplates in 2 stappen, 3 stappen en op één pagina zijn gebouwd op Hyvä, en dezelfde regels gelden ervoor. Lees meer in ons artikel over of Hyvä Checkout het waard is.

Hoe we testen

1. Geautomatiseerde scan. Lighthouse en vergelijkbare tools vinden ontbrekende labels, ontbrekende alt-tekst en contrastproblemen. Ze vinden maar een deel van de problemen.
2. Alleen toetsenbord. We gaan van homepage tot orderbevestiging met de toetsen Tab, Enter, spatie en Escape.
3. Schermlezer. We controleren koppen, landmarks, productopties en checkoutstappen met een schermlezer op desktop en op een telefoon.
4. Zoom en tekstgrootte. We zoomen in op de pagina en vergroten de tekst om te controleren dat niets overlapt of verdwijnt.
5. Minder beweging. Sliders en animaties moeten de instelling voor minder beweging van de gebruiker respecteren.

Geautomatiseerde tools zijn een goed eerste filter. De toetsenbordtest vindt meestal de problemen die klanten echt tegenhouden om te kopen.

Veelgestelde vragen

Voldoet mijn webshop met Hyvä aan de European Accessibility Act?

Geen enkel thema kan dat in zijn eentje regelen. Hyvä geeft je een schonere basis dan Luma, maar of je voldoet hangt af van je templates, extensies, content en checkout. Sommige zeer kleine bedrijven zijn vrijgesteld, dus laat je eigen situatie toetsen door een juridisch adviseur.

Is een Lighthouse-toegankelijkheidsscore van 100 genoeg?

Nee. Een score van 100 betekent dat de geautomatiseerde controles geslaagd zijn. Veel problemen, zoals een kapotte focusvolgorde of een verwarrende checkout, vind je alleen door handmatig te testen.

Kan toegankelijkheid na een Hyvä-lancering nog worden verbeterd?

Ja. De meeste oplossingen zijn wijzigingen in templates en content. Toch is het goedkoper om ze tijdens de migratie in te bouwen dan ze achteraf te repareren.

Plan je een Hyvä-webshop of -migratie en wil je toegankelijkheid vanaf het begin inbouwen? Bekijk onze dienst voor Hyvä-themaontwikkeling, of neem contact met ons op om je webshop te bespreken.