Building Accessible Components at Scale: Lessons From Flowdesk

Accessibility isn't a feature — it's a requirement. At Flowdesk, we've learned that building accessible products at scale requires more than good intentions. It requires systems.

Our Accessibility Stack

Every component in our design system goes through a four-stage accessibility pipeline:

Automated testing — We run axe-core on every component in CI. Any accessibility violation blocks the PR. This catches about 30% of issues.

Manual keyboard testing — Every interactive component must be fully operable with keyboard alone. We have a keyboard testing checklist that covers focus management, tab order, and shortcut conflicts.

Screen reader testing — We test with VoiceOver, NVDA, and JAWS. Each component has expected screen reader behavior documented alongside its visual specs.

User testing — Quarterly, we run testing sessions with assistive technology users. These sessions consistently reveal issues that no automated tool catches.

Lessons Learned

Aria labels are not a substitute for good semantics. We went through a phase of slapping aria-label on everything. It made the screen reader experience worse, not better. Native HTML semantics should always come first.

Focus management is the hardest problem. In a complex app like Flowdesk, managing focus across modals, popovers, drag-and-drop, and dynamic content is incredibly challenging. We built a centralized focus manager that tracks context and restores focus predictably.

Color is never the only indicator. Every state change that uses color also uses shape, icon, or text. This was a hard habit to build but it makes the product better for everyone — including users in bright sunlight.

We're open-sourcing our accessibility testing toolkit next month. Stay tuned.