Accessibility in Hyvä themes

Accessibility used to be a “nice to have” item at the bottom of a Magento project plan. In Europe that has changed. The European Accessibility Act has applied to many online shops since June 2025, and it points to the WCAG guidelines as the practical standard.

Beyond the law, accessibility is simply good business. A shop that works with a keyboard, a screen reader or a zoomed screen also works better for everyone on a small phone.

This post looks at what Hyvä gives you, what it does not, and how we check accessibility when we build or migrate a Hyvä store.

Why Hyvä is a good starting point

Luma’s frontend relies on RequireJS, KnockoutJS and jQuery widgets. Many interface parts are created in the browser by JavaScript, which makes them harder to inspect and fix.

Hyvä replaces this with server-rendered HTML, Alpine.js for small interactive parts, and Tailwind CSS for styling. That has a few direct benefits for accessibility:

• The HTML is in the template. What you see in the .phtml file is close to what assistive technology reads.
• Less JavaScript. In our benchmark, Hyvä pages loaded around 26 KB of JavaScript against 463–524 KB on Luma. Less script means fewer chances for focus to get lost.
• Tailwind helpers. Utilities like sr-only, focus-visible: and motion-reduce: make good habits easy to apply.
• Alpine.js state is visible. State such as open or closed can be bound directly to ARIA attributes in the markup.

If you want the technical background, read how Alpine.js and Tailwind replace RequireJS and Knockout.

What Hyvä cannot do for you

A theme is only a starting point. Most accessibility problems we find in Magento stores come from parts the theme does not control:

• Custom templates that use a div with a click handler instead of a button.
• Third-party extensions with their own pop-ups, sliders and forms.
• Brand colours with too little contrast.
• Product images without useful alt text.
• CMS content with headings chosen for their size, not their order.
• Cookie banners and chat widgets that trap keyboard focus.

During a migration, every extension template is rewritten or replaced anyway. That is the right moment to fix these issues, instead of carrying them into the new theme. Our extension checklist explains how we go through modules one by one.

Accessible Alpine.js components

Many shop components are simple disclosures: a filter group, a mobile menu, an FAQ answer. The pattern is always the same. A real button controls a region, and the button tells assistive technology whether the region is open.

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

Modals and off-canvas menus need more care. Focus should move into the dialog when it opens, stay inside while it is open, and return to the trigger when it closes. The Escape key should close it.

We check every interactive component against these rules, especially the ones that came from extensions.

Colour, contrast and focus

Contrast is the most common issue we see, and it is often a brand decision, not a code bug. Light grey text on white looks elegant, but it fails contrast checks and is hard to read on a phone outside.

Focus states are the second most common issue. Some designs remove the focus outline because it “looks untidy”. Keyboard users then cannot see where they are. With Tailwind, a clear focus-visible: style shows the outline for keyboard users without showing it on every mouse click.

If your team can change colours from the admin, contrast needs extra attention. We explain how we handle that in changing Hyvä theme colours from the admin.

Forms and checkout

Checkout is where accessibility and conversion meet. Every form field needs a visible label, not only a placeholder. Error messages should say what went wrong and be announced to screen readers.

Payment methods deserve special attention. Many payment providers load their own fields in an iframe, so their accessibility is partly outside your control. Test them with a keyboard in every market you sell to.

Our own 2-step, 3-step and one-page checkout templates are built on Hyvä, and the same rules apply to them. Read more in our post on whether Hyvä Checkout is worth it.

How we test

1. Automated scan. Lighthouse and similar tools catch missing labels, missing alt text and contrast issues. They find only part of the problems.
2. Keyboard only. We go from home page to order confirmation with the Tab, Enter, Space and Escape keys.
3. Screen reader. We check headings, landmarks, product options and checkout steps with a screen reader on desktop and on a phone.
4. Zoom and text size. We zoom the page and increase the text size to check that nothing overlaps or disappears.
5. Reduced motion. Sliders and animations should respect the user’s reduced motion setting.

Automated tools are a good first filter. The keyboard test usually finds the problems that actually stop customers from buying.

FAQ

Does Hyvä make my store compliant with the European Accessibility Act?

No theme can do that on its own. Hyvä gives you a cleaner base than Luma, but compliance depends on your templates, extensions, content and checkout. Some very small businesses are exempt, so check your own situation with a legal adviser.

Is a Lighthouse accessibility score of 100 enough?

No. A score of 100 means the automated checks passed. Many issues, such as a broken focus order or a confusing checkout, can only be found by testing manually.

Can accessibility be improved after a Hyvä launch?

Yes. Most fixes are template and content changes. Still, it is cheaper to build them in during the migration than to fix them afterwards.

Planning a Hyvä store or migration and want accessibility built in from the start? See our Hyvä theme development service, or contact us to discuss your store.