At the heart of every product development organization is the partnership between designers and engineers. This relationship is in many ways where the rubber meets the road, especially when it comes to accessibility. If this relationship works, designers hand off “intent,” developers understand well what needs to be done, and mistakes are avoided. But if it doesn’t – if these two worlds remain siloed – then the entire organization will be left to pick up the pieces sometime later in the development process.
Recently, we’ve come across two companies that have developed different strategies for preventing this divide, and using Evinced to do it.
Strategy 1: The designer as the accessible component architect
A major travel brand recognized that for a design system to be truly scalable, individual components – the often re-used pieces of a website that allow interactions and proper rendering – must be born accessible. They implemented an accessibility-first process in Figma, transforming the design phase.
For many teams, getting components completely right means a certain amount of suffering, with many high-friction round-trips between the accessibility and engineering teams . If there is an accessibility team in house, that team is often strapped and reviews can take weeks or months. If there isn’t an accessibility team in house, designers are left to fend for themselves with off-the-shelf tools that all too often are not sophisticated enough to truly handle accessibility issues.
Utilizing Evinced’s Design Assistant, however, our travel customer was able to change component design from a solely visual exercise into a complete technical handoff. Now, their designers:
- Define component-level interaction. Every component must have documented states (such as focus, error, loading, and disabled) before leaving the design phase.
- Establish the knowledge handoff. A common friction point is that engineers are often expected to know more about accessible engineering than they actually do. For example, without Design Assistant, an engineer might need to figure out for a given component all the ways in which it needs to behave to be accessible. But Evinced comes with pattern intelligence – that is, it already has Web Accessibility Initiative ARIA APG recommendations built in. Once the designer identifies the component type (as say, a “Modal” or “Combobox”), the knowledge about how to engineer that pattern accessibly is written directly into the handoff for the engineer’s convenience, expediting the engineering cycle.
Strategy 2: Going beyond static accessibility scans
While the design team sets the intent, a leading financial institution focused on how that intent survives the build process.
They discovered that relying solely on free static analysis tools like axe-core wasn’t enough to catch complex interaction bugs in their component library.
To solve this problem, they integrated Evinced’s Unit Tester into their CI/CD pipeline. This approach allowed them to:
- Uncover hidden problems. The customer’s internal design library relied on foundational open-source components considered accessible by axe-core, but Evinced Unit Tester identified critical accessibility failures in components that free tools missed.
- Simulate human interaction. Unlike static scans, the Unit Tester simulates keyboard operation and transitions across different component states, ensuring that accessible designs function properly for screen readers and other assistive technologies.
- Automated gatekeeping. By making these tests a requirement for code merges, they ensured that every update to their front-end library maintained a “baked-in” standard of accessibility. We like to call that #EvincedClear.
Strategy 3: Combining Strategies 1 and 2
Taken individually, either of these strategies can be a dramatic improvement. But combining them presents a whole other set of opportunities. After all, what organizations are shooting for on design-engineering handoffs is, as in the world of security, a unified chain of trust.
Consider what the travel brand, our Strategy 1 user, might gain from adding Unit Tester. Currently, they have handoffs that serve as perfect accessibility blueprints, but no automated way to prove that the code as executed in the build matches the original design intent. Adding Strategy 2 would provide them with in effect a continuous audit that prevents accessibility regressions as their library grows.
And our financial institution, on the other hand, would gain by adding Design Assistant. Currently, their engineers are catching bugs in the Unit Tester, but they are often forced to make determinations about how each component fits into the APG nomenclature. Adding Strategy 1 would give their engineers a clear roadmap, telling them exactly what the component is and how it should behave – eliminating the guesswork and reducing dev cycles.
Putting all of this together means teams can bridge the gap between design and engineering. In a perfect world, design system components can themselves carry all the accessibility intelligence needed to maximize inclusion. From the first pixel, to the final pull request.