Accessibility – An Essential Ingredient in the Batter or the "Icing" on the Cake?

At Peerigon, web accessibility isn't just a nice-to-have. It's an integral part of creating inclusive, functional digital products. Starting mid-2025, websites and apps in Germany must comply with the Barrierefreiheitsstärkungsgesetz (BFSG), which mandates accessibility standards. This legislation implements the European Accessibility Act (EAA) across the EU. The underlying regulations closely follow the Web Content Accessibility Guidelines (WCAG), ensuring that digital services are accessible to everyone.

Updating our own app, Konsens, showed us how important web accessibility is at every stage of development. In this post, we’ll walk you through our journey, the lessons we learned, and why web accessibility is not "just a task" but an ongoing process.

Konsens began as an internal project at Peerigon during a software apprenticeship. The initial Vue 2 application was used for learning, experimentation and sharing knowledge with team members. Web accessibility was considered from the start, with the introduction of a pie chart that used colours and patterns to make results more readable. However, the app's primary focus was on functionality rather than achieving full accessibility compliance.

This phase taught us that even when web accessibility is part of the initial design, maintaining that focus requires ongoing effort and attention. It is an essential factor in web app development, alongside performance, user experience, and security — all of which work together to shape a successful product.

When it was time to migrate Konsens from Vue 2 to Vue 3, the scope expanded quickly. It wasn’t only about updating the framework — it was a full redesign to incorporate a more modern look and add new functionality. Key requirements emerged:

• Migration to Vue 3 with TypeScript
• Implementation of a fresh redesign aligning the web with the mobile app design
• Web accessibility improvements for both mobile and desktop

Early on, we decided to use the Composition API in Vue 3 and selected Headless UI and Tailwind CSS for the component design. Storybook became vital for testing web accessibility and visual consistency. During this phase, web accessibility was still a priority, and we made sure to integrate accessibility-focused decisions in collaboration with the design team.

At this stage, we put effort into researching a suitable UI component library. Up to this point we used mainly Chakra UI for our React base projects. The field of frontend development is an ever evolving and changing field. When Vue 3 was released, options for compatible, fully customizable, and accessible UI component libraries were limited.¹ As such, we decided to go with the pragmatic approach to focus on fundamental accessibility practices as well as using Headless UI as a base for more complex components.

When it comes to accessibility in our fast-paced era, keep in mind to make pragmatic decisions with the best possible outcome. For us, this meant the decision to go with Headless UI.

As the project progressed, the team composition changed, and the focus increasingly shifted toward completing the new design and implementing all features. As a result, some accessibility tasks were deferred until shortly before the release, while others were deliberately planned for after the release. However, this decision led to challenges that might have been avoided with a more proactive approach.

For instance, recurring issues with color contrast were addressed before the release, requiring time-intensive fixes across various areas of the application. At the same time, we consciously decided to postpone addressing certain known accessibility issues – such as a UI component that did not yet meet standards – for a future iteration. This deliberate prioritization allowed us to meet the release deadline without losing sight of the goal of improving accessibility in the long term. These outstanding issues were transparently documented in the accessibility statement.

Such situations are common in web development – as team members change and priorities shift, it’s easy to lose focus on accessibility. People join and leave the project, priorities and even skillsets change over time. It's important to not get discouraged or lose sight of web accessibilty in these phases. Let's see how we remedied and refocused our efforts towards our inital goals.

After the major features were implemented, our focus shifted back to ensuring web accessibility. And with me rejoining the team after a client project was wrapped up, we carried out extensive accessibility audits at both the manual and automated levels.

We manually tested on multiple platforms, including MacOS, Windows, and Chrome, Firefox, and Safari browsers. This included testing with keyboard-only navigation and screen readers like VoiceOver and NVDA. Both ensure a smooth experience for users relying on assistive technology.

Additionally, we integrated end-to-end (e2e) tests using Playwright and Axe to automate web accessibility testing throughout the app. By automating tests, we improved the app's ability to meet accessibility standards as it evolves.

In the lead-up to the release of Konsens, we took a pragmatic approach by focusing on fixing the most critical issues in the app. This ensured that the core functionality was accessible to a broad range of users. However, we recognized that web accessibility is not something that can be fully achieved with a one-time effort. As the app evolves, ongoing efforts to improve accessibility are essential.

To communicate this commitment to our users, we included an accessibility statement within the web app. The statement provides transparency about the current state of accessibility, outlines the known limitations, and informs users that accessibility improvements are an ongoing priority. It also offers users a way to provide feedback, ensuring that accessibility remains a central focus as the app grows and adapts to new requirements and user needs.

Our experience with Konsens highlighted several important truths about web accessibility in development:

• Web Accessibility Is Ongoing
  Web accessibility isn’t something you can check off a list. It’s a continuous process that requires ongoing assessment and updates. New features and design changes can inadvertently introduce new accessibility issues.

• The High Cost of Downstream Web Accessibility
  It’s far more expensive — in terms of both time and resources — to fix web accessibility issues after the development process is complete. Integrating web accessibility from the beginning saves effort later on and prevents costly revisions. This is common knowledge when it comes to functional bugs but rather neglected when it comes to accessibility.

• The Challenge of Knowledge Silos
  Web accessibility knowledge was concentrated among a few team members, making consistency harder to achieve. This is a common issue in development teams and one we’re committed to addressing through better training and knowledge sharing.

• Automation Can’t Catch Everything
  While automated testing tools help catch obvious issues (like non-semantic HTML or poor color contrast), they don’t cover everything. Manual review is often needed for complex user flows. They may have nuanced accessibility issues, like poor keyboard navigation.

At Peerigon, we’ve taken these learnings to heart. For future projects, we’re committed to:

• Embed web accessibility checks at every stage of development, not just at the end.
• Share knowledge across the team so web accessibility isn’t dependent on a few specialists.
• Ensure accessibility is a core part of the project mindset, not just a checkbox on the roadmap.

As a visual thinker and an avid baker I really resonated when I read about the blueberry muffin analogy for web accessibility in one of Marcy Sutton's blog posts.

Upon research the full analogy describes bringing muffins to a birthday party and on the way there realising they were supposed to be blueberry muffins, so you start forcing the blueberries into the muffins. But it is not the same as if they were incorporated into the batter. ³

Web accessibility is like baking—whether it’s chocolate chips in a cookie or blueberries in a muffin, it needs to be mixed in from the start, not sprinkled on top later. Although adding them afterward might technically yield a similar result, it’s not the same experience. By incorporating accessibility throughout every layer of development, rather than rushing to add it later, we create a more inclusive, robust product.

This belief is more than theoretical for us. Some of our own colleagues benefit directly from web accessibility. Whether it’s for color-blindness or hidden cognitive challenges that come with chronic illness or neurodivergence. Or even as parents juggling work and young children, who appreciate the ease of use that accessible apps provide. For them, and for millions of others, accessible design isn’t just about compliance – it’s about making everyday life easier.

Konsens exemplified both the challenges and rewards of making accessibility a core priority. While we’re proud of the progress made, we’re always striving to improve. In the end, it’s all about creating better, more inclusive digital experiences — because accessibility benefits everyone.

If you want to know more about our approach to accessibility or are interested in how we can help your project, get in touch with us at Peerigon. We’re always happy to chat!

Footnotes

1 | Since then, the team behind Chakra UI has released another library called Ark UI, which is compatible with React, Svelte, and Vue that I can recommend.

2 | JavaScript and Civil Rights | Article by Marcy Sutton

3 | Baking Accessibility In | Talk by Cordelia McGee-Tubb

Cover art based on blueberry muffin photo by Aneta Voborilova on Unsplash

Photo of blueberry muffins resting on cooling rack by Aneta Voborilova on Unsplash