Barrierefreiheit in Hyvä-Themes

Barrierefreiheit war früher ein “Nice-to-have” ganz unten im Plan eines Magento-Projekts. In Europa hat sich das geändert. Der European Accessibility Act gilt seit Juni 2025 für viele Onlineshops und verweist auf die WCAG-Richtlinien als praktischen Standard.

Abgesehen von den gesetzlichen Vorgaben ist Barrierefreiheit schlicht gutes Geschäft. Ein Shop, der mit Tastatur, Screenreader oder vergrößerter Ansicht funktioniert, funktioniert auch für alle anderen auf einem kleinen Smartphone besser.

Dieser Beitrag zeigt, was Hyvä Ihnen bietet, was nicht und wie wir die Barrierefreiheit prüfen, wenn wir einen Hyvä-Shop bauen oder migrieren.

Warum Hyvä ein guter Ausgangspunkt ist

Das Frontend von Luma basiert auf RequireJS, KnockoutJS und jQuery-Widgets. Viele Teile der Oberfläche werden erst im Browser per JavaScript erzeugt, was sie schwerer zu prüfen und zu korrigieren macht.

Hyvä ersetzt das durch serverseitig gerendertes HTML, Alpine.js für kleine interaktive Elemente und Tailwind CSS für das Styling. Das bringt einige direkte Vorteile für die Barrierefreiheit:

• Das HTML steht im Template. Was Sie in der .phtml Datei sehen, entspricht weitgehend dem, was assistive Technologien vorlesen.
• Weniger JavaScript. In unserem Benchmark luden Hyvä-Seiten rund 26 KB JavaScript gegenüber 463–524 KB bei Luma. Weniger Skript bedeutet weniger Gelegenheiten, bei denen der Fokus verloren geht.
• Tailwind-Helfer. Utilities wie sr-only, focus-visible: und motion-reduce: machen es leicht, gute Gewohnheiten umzusetzen.
• Der Alpine.js-Zustand ist sichtbar. Zustände wie geöffnet oder geschlossen lassen sich im Markup direkt an ARIA-Attribute binden.

Den technischen Hintergrund finden Sie in wie Alpine.js und Tailwind RequireJS und Knockout ersetzen.

Was Hyvä nicht für Sie leisten kann

Ein Theme ist nur ein Ausgangspunkt. Die meisten Barrierefreiheitsprobleme, die wir in Magento-Shops finden, stammen aus Bereichen, die das Theme nicht kontrolliert:

• Individuelle Templates mit einem div samt Klick-Handler statt eines button.
• Extensions von Drittanbietern mit eigenen Pop-ups, Slidern und Formularen.
• Markenfarben mit zu wenig Kontrast.
• Produktbilder ohne hilfreichen Alt-Text.
• CMS-Inhalte mit Überschriften, die nach Größe statt nach Hierarchie gewählt wurden.
• Cookie-Banner und Chat-Widgets, die den Tastaturfokus festhalten.

Bei einer Migration wird ohnehin jedes Extension-Template neu geschrieben oder ersetzt. Das ist der richtige Moment, diese Probleme zu beheben, statt sie ins neue Theme mitzunehmen. Unsere Extension-Checkliste erklärt, wie wir Module einzeln durchgehen.

Barrierefreie Alpine.js-Komponenten

Viele Shop-Komponenten sind einfache Aufklapp-Elemente: eine Filtergruppe, ein mobiles Menü, eine FAQ-Antwort. Das Muster ist immer gleich. Ein echter Button steuert einen Bereich und teilt assistiven Technologien mit, ob dieser Bereich geöffnet ist.

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

Modale Dialoge und Off-Canvas-Menüs brauchen mehr Sorgfalt. Der Fokus sollte beim Öffnen in den Dialog wechseln, dort bleiben, solange er geöffnet ist, und beim Schließen zum Auslöser zurückkehren. Die Escape-Taste sollte ihn schließen.

Wir prüfen jede interaktive Komponente anhand dieser Regeln, besonders die, die aus Extensions stammen.

Farbe, Kontrast und Fokus

Kontrast ist das häufigste Problem, das wir sehen, und oft eine Markenentscheidung statt eines Code-Fehlers. Hellgrauer Text auf Weiß wirkt elegant, besteht aber keine Kontrastprüfung und ist draußen auf dem Smartphone schwer zu lesen.

Fokuszustände sind das zweithäufigste Problem. Manche Designs entfernen die Fokus-Umrandung, weil sie “unordentlich aussieht”. Tastaturnutzer sehen dann nicht mehr, wo sie sich befinden. Mit Tailwind zeigt ein klarer focus-visible: Stil zeigt die Umrandung für Tastaturnutzer, ohne sie bei jedem Mausklick anzuzeigen.

Wenn Ihr Team Farben im Admin ändern kann, braucht der Kontrast besondere Aufmerksamkeit. Wie wir damit umgehen, erklären wir in das Ändern von Hyvä-Theme-Farben im Admin.

Formulare und Checkout

Im Checkout treffen Barrierefreiheit und Conversion aufeinander. Jedes Formularfeld braucht ein sichtbares Label, nicht nur einen Platzhalter. Fehlermeldungen sollten sagen, was schiefgelaufen ist, und von Screenreadern angesagt werden.

Zahlungsarten verdienen besondere Aufmerksamkeit. Viele Zahlungsanbieter laden ihre eigenen Felder in einem iframe, sodass deren Barrierefreiheit teilweise außerhalb Ihrer Kontrolle liegt. Testen Sie sie mit der Tastatur in jedem Markt, in dem Sie verkaufen.

Unsere eigenen Checkout-Templates mit 2 Schritten, 3 Schritten und als One-Page-Checkout basieren auf Hyvä, und für sie gelten dieselben Regeln. Mehr dazu in unserem Beitrag zur Frage, ob sich Hyvä Checkout lohnt.

So testen wir

1. Automatisierter Scan. Lighthouse und ähnliche Tools erkennen fehlende Labels, fehlende Alt-Texte und Kontrastprobleme. Sie finden aber nur einen Teil der Probleme.
2. Nur Tastatur. Wir gehen mit Tab-, Enter-, Leer- und Escape-Taste von der Startseite bis zur Bestellbestätigung.
3. Screenreader. Wir prüfen Überschriften, Landmarks, Produktoptionen und Checkout-Schritte mit einem Screenreader am Desktop und auf dem Smartphone.
4. Zoom und Textgröße. Wir zoomen die Seite und vergrößern den Text, um zu prüfen, dass sich nichts überlappt oder verschwindet.
5. Reduzierte Bewegung. Slider und Animationen sollten die Einstellung des Nutzers für reduzierte Bewegung respektieren.

Automatisierte Tools sind ein guter erster Filter. Der Tastaturtest findet meist die Probleme, die Kunden tatsächlich vom Kauf abhalten.

FAQ

Macht Hyvä meinen Shop konform mit dem European Accessibility Act?

Das kann kein Theme allein. Hyvä bietet Ihnen eine sauberere Basis als Luma, aber die Konformität hängt von Ihren Templates, Extensions, Inhalten und Ihrem Checkout ab. Manche Kleinstunternehmen sind ausgenommen, prüfen Sie Ihre eigene Situation daher mit einer Rechtsberatung.

Reicht ein Lighthouse-Barrierefreiheitswert von 100?

Nein. Ein Wert von 100 bedeutet, dass die automatisierten Prüfungen bestanden wurden. Viele Probleme, etwa eine fehlerhafte Fokusreihenfolge oder ein verwirrender Checkout, lassen sich nur durch manuelle Tests finden.

Lässt sich die Barrierefreiheit nach einem Hyvä-Launch verbessern?

Ja. Die meisten Korrekturen sind Template- und Inhaltsänderungen. Trotzdem ist es günstiger, sie während der Migration einzubauen, als sie nachträglich zu beheben.

Sie planen einen Hyvä-Shop oder eine Migration und möchten Barrierefreiheit von Anfang an einplanen? Werfen Sie einen Blick auf unsere Hyvä-Theme-Entwicklung, oder kontaktieren Sie uns um über Ihren Shop zu sprechen.