A recent Deque case study found that 67% of accessibility issues originate in design (Deque). This statistic underscores a critical reality: accessibility must begin at the design stage to prevent costly and time-consuming fixes later. Design systems are how organizations scale most efficiently, and prioritizing accessibility in these systems can lead to sweeping improvements. Something as simple as color contrast adjustments can have a broad impact, ensuring that designs accommodate all users from the outset.

Why Design is the Blueprint for Accessibility

Design serves as the blueprint—the plan that dictates the final product. If that plan fails to include people with disabilities, the end result inevitably excludes them as well. The gap between design and implementation is where WCAG failures occur. When accessibility issues are not identified in the design phase, they lead to products that are inaccessible from the beginning.

Designing with accessibility in mind requires a fundamental shift in who we design for. Are products designed solely for mouse users? Touch users? Keyboard users? Are they designed for blind users, deaf users, users with cognitive impairments? If we don’t consider how people with disabilities will interact with digital products, we risk excluding them entirely.

Using Design Annotations to Ensure Accessibility

One of the most effective ways to integrate accessibility into the design phase is through design annotations. These annotations serve as documentation that communicates specific design decisions, accessibility requirements, and implementation details to designers, developers, and stakeholders.

At Zenyth, we believe that design annotations are essential to creating born accessible products. However, as Eric W. Bailey points out in his article on accessibility annotation kits, simply adding annotations is not enough. Annotations must go beyond superficial tagging and ensure that the underlying design decisions support accessibility from the start. Annotations should not be a bandaid for poor design—they should be an integral part of the design process, reinforcing best practices and encouraging teams to think critically about who they are designing for and why.

Beyond Annotations: Building Accessibility into the Design Process

Many annotation kits focus solely on marking up designs without addressing the root cause of accessibility barriers. This approach can create a false sense of security, leading teams to believe they’ve addressed accessibility when critical issues remain unresolved. To truly support born accessible design, we advocate for a multi-phase approach that integrates accessibility into the design process itself.

Phase One: Annotating Figma Boards for Design Adjustments

Identifying and resolving accessibility issues early is key. During this phase, we annotate Figma boards to catch and correct issues such as:

• Text color contrast (for both large and regular-sized text)
• Non-text contrast issues (such as iconography and graphical elements)
• Touch target size and spacing
• Missing elements (headings, buttons, necessary controls, instructions)
• Form labeling and status messages
• Error messaging clarity
• Resize and reflow considerations
• Text spacing and legibility
• Complex components that may require alternative accessible solutions
• Focus order, reading order, and meaningful sequence

By addressing these issues in the design phase, we can prevent accessibility barriers before they even make it to development.

Phase Two: Annotating Figma Boards for Developer Handoff

Once the initial accessibility concerns are resolved, we move on to the developer handoff phase. In this stage, we ensure that the final design files contain an accessibility layer that acts as a roadmap for developers. This includes:

• Named landmarks for clear navigation
• Accessibility annotation tags to indicate semantic HTML elements (e.g., headings, buttons, links, images)
• Written annotation notes on the first instance of key elements, providing requirements and recommendations
• Identification of complex components and potential accessibility challenges
• Guidance on focus management, keyboard interactions, and screen reader behavior

By incorporating these details, we bridge the gap between design and development, ensuring that accessibility is not lost in translation.

Accessibility is a Team Effort

Creating born accessible products requires investment and collaboration from stakeholders, designers, auditors, and developers. No single team member can carry the weight of accessibility alone—it must be embedded in the entire process. Most developers are not accessibility experts, so they need clear guidance, instructions, and annotations to build accessible experiences correctly from the start.

Accessibility cannot be an afterthought. If it is, organizations find themselves in an endless loop of costly fixes, redesigns, and lawsuits—a “break fix cycle” that never ends.

By committing to born accessible design, we create digital products that work for everyone, ensuring that accessibility is a fundamental, non-negotiable aspect of every project. At Zenyth, we don’t just design for today—we design for inclusion, equity, and usability in every future interaction.