At Amiqus, accessibility isn’t an afterthought; it’s part of our values. That foundation shaped how we approached one of our newest products. We’re now halfway through our five-stage development plan, and accessibility has been non-negotiable at every step. Not because we have to do it, but because we believe in doing it. It reflects our values and who we design for.
Common barriers to accessibility
Before diving into our process, it’s worth remembering the real-world challenges users face:
- Visual: Users who are blind or have low vision rely on screen readers and keyboard navigation. Missing alt text or focus issues equals instant blockers
- Hearing: Deaf or hard-of-hearing users need captions and visual alternatives to audio cues
- Motor: Users with limited mobility may use adaptive tech like switch devices, eye tracking, or alternative keyboards. Tasks that require precision clicking or drag and drop can be extremely difficult or even impossible for them
- Cognitive: Clean layouts, consistent navigation, and plain language are essential for users with learning differences or neurodivergent needs
Why did we start with accessibility?
In the planning phase, we saw a clear opportunity: integrate accessibility from day one rather than adding it on at the end. It wasn’t just the right thing to do, it was the smart thing to do.
By investing early, we’ve already saved time, avoided costly rework, and built better, frictionless experiences for everyone, not just those with accessibility requirements.
Accessibility isn’t a “fix it later” task. It’s a core part of good design, solid UX, and product quality. Our goal has always been to meet WCAG 2.2 AA standards, and we partnered with AbilityNet to help us stay on track.
How Amiqus built accessibility into the process
We started strong with full team accessibility training. Our team attended accessible mobile development, accessibility for designers and how to do inclusive usability testing. That built a shared language and made accessibility part of how we think, not just how we fix.
We partnered with AbilityNet to audit each build as it progressed, addressing accessibility issues in real time rather than waiting until the end. This allowed us to continuously improve the user experience and ensure compliance throughout the development process.
Here’s what our process has looked like so far:
- Training: Everyone on the team completed foundational accessibility training
- Audits: Each build was reviewed by AbilityNet against WCAG 2.2
- Workshops: After every audit, we regrouped to review findings together and create shortcut tickets
- Iteration: We fixed accessibility issues wherever they appeared, not just in one feature or screen
- Recheck: Every fix is reaudited to make sure it’s properly resolved
Results so far
It’s working; with each build, fewer tickets are raised. Duplicate issues are also dropping off, which shows that we’re not just fixing; we’re learning.
We’re not done yet, but progress is real. In our first audit, 16 accessibility issues were flagged. By the next build, that number had dropped to just 10.
More importantly, our team is changing. We spot potential accessibility issues sooner, fix them faster, and embed what we’ve learned across the product. Accessibility isn’t just a checklist item anymore; it’s baked into how we build.
What can you start doing today to improve accessibility?
Put accessibility upfront. Don’t wait until launch.
Here’s how to get started:
- Work with experts like AbilityNet to audit your builds.
- Train your team on accessibility basics.
- Use screen readers like NVDA or VoiceOver to test your product.
- Check your content for common issues. According to WebAIM, the most common failures across websites are:
| Issue | % of home pages |
| Low contrast text | 86.3% |
| Missing image alt text | 66% |
| Empty links | 59.9% |
| Missing form input labels | 53.8% |
| Empty buttons | 28.7% |
| Missing document language | 28% |
One of the most frequent issues we encountered was interactive elements not being accessible to screen readers. Users can get stuck if your buttons or forms can’t be focused on or read properly. Addressing these issues early will make a significant difference to accessibility.
Looking ahead
We’ve got one final accessibility recheck to go, but we’re already confident in our direction. This product will meet its goals, but more importantly, it’s laying a foundation for how we’ll build inclusively going forward.
We’ve learned that when accessibility is built in from the beginning, everyone benefits. The experience is seamless, the dev process is faster, and the product is way more usable.
On this Global Accessibility Awareness Day (GAAD), we’re proud to share our journey not as a finished story but as an ongoing commitment. Building for everyone should always start on day one.
