Building Accessibility Into Everyday Development: A Conversation with Henric from Happo

Author - Pauline Mialhe, COO of Happo (Last updated September, 16 2025)

Accessibility has always been an important topic at Happo. In our last article, we looked back at Joe Lencioni’s early contributions to accessibility and how that work shaped the foundations of our new tool, <A11y/> by Happo. Today, we continue the conversation with Henric, co-founder of Happo, to explore the technical side of accessibility testing and what this new tool means for developers.

Henric, could you explain why accessibility is such a central part of Happo now?

The intention to build accessible UIs is often there, but in practice it becomes an afterthought. Teams might check accessibility once, then move on and never revisit it. That’s where Happo changes things. By running accessibility tests continuously — on every pull request — accessibility is no longer optional. It becomes part of the development flow.

How does <A11y/> by Happo actually work in practice?

We built it so teams can use the same integrations they already know. If you’re working with Storybook, Playwright, or Cypress, you just add Happo on top. For us, accessibility is like adding another browser. Normally, Happo takes screenshots in Chrome, Safari, Firefox, or on mobile devices. With <A11y/>, instead of a visual screenshot you also get an accessibility snapshot — essentially what a screen reader would see.

So each test gives you two views: one visual, and one textual representation of the UI. On top of that, the system automatically checks your components against the WCAG standards and flags violations.

How should a team get started with it?

First, choose your integration — we usually recommend Storybook because it keeps tests isolated and clear. Then you update your Happo configuration file. Normally you’d list the browsers and screen sizes to test; now you also list one or more accessibility targets. Once that’s set up, every pull request automatically tracks accessibility.
You could find the updated documentation on Happo Docs : Accessibility Testing. 

You mentioned tracking accessibility. What does that look like?

We track violations across impact level — critical, serious, moderate, and minor. Each violation points directly to the affected component and links to documentation. For example, if a button’s text doesn’t have enough color contrast with its background, Happo will flag it, show you the ratio, and explain how to fix it.

So developers actually get instructions they can act on?

Exactly. Happo doesn’t write the code for you, but the guidance is clear enough that you know what to do. We’ve seen this in our own product — most fixes are straightforward once the violation is highlighted. And because the tests run on every pull request, progress is visible: you can literally watch the number of violations go down. Do you want a hard truth? Happo itself started with more than 1,400 accessibility violations. Not our proudest moment. But that’s exactly why <A11y/> exists — so you can show this progress to your team and leadership.

This graph shows how the number of violations dropped once we integrated continuous accessibility testing. It’s a good way to demonstrate progress, keep your team motivated, and make accessibility part of the daily workflow.

How do you see accessibility fitting into product development?

Accessibility by Happo complies with upcoming regulations like the European Accessibility Act. But our philosophy goes further: accessibility is a long-term practice, not a one-time effort. With the <A11y/> add-on by Happo, compliance becomes part of your development routine, helping your team continuously deliver products that meet standards and feel good to use.