Accessibility from the Start with Shift Left A11y

Aktios
Sep 5
3 min read

The Shift Left A11y methodology focuses on integrating accessibility into every stage of the software development lifecycle—from planning through maintenance—rather than leaving it for the final phases.

What does Shift Left A11y mean?

“Shift Left” literally means to “move left,” and “A11y” (commonly pronounced Ally) is the numeronym for “Accessibility,” where the “11” represents the eleven characters between “a” and “y.”

Therefore, this methodology essentially means “shifting accessibility left” on a software development workflow diagram.

Common Accessibility Issues

The most common scenario is discovering accessibility issues once a product is already in production—at which point fixing them is costly and time-consuming.

How can something be released without being accessible? Simply because accessibility was never considered in earlier stages. According to a study by Deque, 67% of accessibility issues originate during the design phase.

The earlier accessibility is integrated, the less expensive it is to correct errors.

Solutions with Shift Left A11y

The purpose of this methodology is to avoid accessibility issues from the earliest stages. This allows us to:

Reduce costs: Detecting and fixing accessibility issues early is far more cost-effective than doing so at the end.
Improve efficiency: Considering accessibility from design and technical requirements helps bridge the gap between design and development, boosting efficiency.
Increase quality: Accessible products that comply with current standards improve the user experience for everyone.
Foster inclusion: An estimated 15% of the global population has some form of disability.

Implementing Shift Left A11y in Stages

Within the process, we can identify three major stages: Sprint, Deploy, and Next Release. This methodology is circular, meaning the project is in constant evolution.

Sprint

During the sprint, we follow the classic sub-stages of the design process:

Planning: The PM must include accessibility requirements in the project scope. Definition of Done (DoD) criteria should cover accessibility compliance.
Early prototype review: Designs should be reviewed against an accessibility checklist to identify issues in layout and execution as early as possible.
Automated QA review: Running checks against WCAG 2.2 conformance criteria before release prevents costly fixes later.
Manual and automated code review: Use both methods to catch issues beyond WCAG compliance, ensuring accessibility exceeds legal requirements.
User testing: Automated testing cannot replace manual tests and real feedback from users with disabilities.

Deploy

Production maintenance: Monitor and correct issues in live environments. Analytics and KPIs should be tracked (e.g., via Google Analytics) to maintain and improve accessibility.

Next Release

Begin the next release cycle starting again with the first sprint step.

Steps to Implement Shift Left A11y

Awareness: The first step is to raise awareness of accessibility across design, development, and the entire organization. Everyone should understand what digital accessibility is and why it matters.
Training: Teams must be trained to design, build, and test accessible software to remain competitive.
Early integration: Accessibility should be integrated from the earliest stages of the software development lifecycle—not added as a late requirement.
Tools and techniques: Identify and use the right accessibility tools and techniques at each stage.
Accessibility testing: Run accessibility tests regularly throughout the lifecycle to identify and resolve issues.
Collaboration: Encourage collaboration between developers and accessibility specialists to prevent issues from escalating.
Continuous evaluation: Accessibility must be continuously evaluated throughout the lifecycle.

Measuring Success

The success of Shift Left A11y can be measured using key performance indicators (KPIs) that assess the impact of accessibility practices on product quality and user satisfaction:

Number of accessibility issues detected: An increase may indicate better detection and awareness.
Percentage of issues resolved: Tracks how effectively issues are addressed during development.
User satisfaction level: Measures improvements in product quality from the perspective of accessibility.
Time and cost of issue resolution: A decrease suggests improved efficiency in fixing accessibility problems.

Conclusion

Implementing Shift Left A11y requires a cultural shift across the organization, from designers to developers, to fully commit to accessibility. By fostering a culture of inclusion, organizations can create products that are truly useful and usable for everyone.