Start with accessibility.
Building accessibility directly into design and development workflows from the beginning rather than retrofitting later saves time, reduces costs, and ensures consistency. Embedding accessibility considerations into the early stages of the product life cycle—a practice known as “shifting left”— creates a strong foundation that sets teams up for success, while developing a repeatable process that minimizes accessibility gaps.
Design to Development Handoff
The transition from design to development is crucial to the outcome of an accessible product, as both teams must work in unison to ensure a successful handoff. This can be achieved by employing techniques such as:
- Detailed design assets: Provide specifications around color contrast, font sizes, and interactive elements that meet WCAG standards and accessibility best practices.
- Accessibility annotations: Annotate components for accessibility, including structural elements (landmarks, heading hierarchy), interactive elements (buttons, links), form elements (labels, field type), tab order, and other important information.
Collaboration and Prototyping
Collaboration between designers and developers ensures accessibility across the product lifecycle, especially when addressed early. Prototyping enables both teams to test and iterate on accessible features in real time:
- Create accessible prototypes: Make a coded prototype, even a simplified one, as early as possible to test with assistive technology users, and do manual and automated accessibility testing early.
- Incremental checks: Establish regular check-ins between design and development to discuss potential accessibility issues and create solutions.
Accessibility in Acceptance Criteria
Accessibility as part of the acceptance criteria—or definition of done—ensures that accessibility checks are embedded in both design and development workflows:
- Clear acceptance criteria: Define specific accessibility requirements within acceptance criteria. For example, “All interactive elements must be navigable via keyboard” or “Color contrast must meet a minimum of 4.5:1.”
- Accountability: Make meeting accessibility criteria a shared commitment, with design and development shouldering responsibility.
How We Know We’re Doing This
- Our accessibility annotations cover important accessibility information that cannot be conveyed alone visually to guide development
- We are using accessible prototypes as tool in our toolbelt to help guide design decisions
- Our acceptance criteria includes accessibility requirements for both design and development
- We are using a design system to ensure consistency across products
- We are regularly discussing accessibility during our project work
How We Know We’re Coming up Short
- Our accessibility issues are caught late in the process, leading to fixes or rework that could’ve been avoided
- Our design assets lack clear accessibility annotations, leaving developers to interpret accessibility requirements on their own
- Our acceptance criteria overlooks accessibility, resulting in inconsistent accessibility checks across products
- Our prototypes and design specs miss accessibility considerations, causing issues with interaction or UI accessibility within products
- We are retrofitting accessibility into a nearly finished product instead of designing with it from the start.