Adding accessibility to your busy sprints may be a challenge, but it is essential for inclusive digital experiences. Treating accessibility issues as technical debt can be a helpful perspective. Like any technical debt, you need to address accessibility systematically to avoid long-term complications. There are four steps you can take to incorporate accessibility into your agile sprints.

1. Recognize Accessibility as Technical Debt

Understanding that accessibility is a form of technical debt is crucial. It’s debt that your team did not realize they had until they learned about accessibility. Address this debt the same way you handle other technical debts, following agile thought leaders’ recommendations if your team is not already doing so. When making any change, the first step is awareness. Recognizing accessibility as technical debt is the team identifying there is something that you need to be talking about.

Agile Leaders on Technical Debt

Several agile thought leaders emphasize the importance of managing technical debt effectively. If we continue to ignore it, it will hurt the team’s progress, slowing it down.

• Martin Fowler accentuates the importance of managing technical debt like financial debt in his block post Technical Debt Quadrant. Ignoring it can lead to “interest payments” as increased development time and reduced quality. Regularly addressing accessibility issues, like any technical debt, is necessary to avoid accumulation.
• Mike Cohn recommends the use of the “Definition of Ready” and “Definition of Done” to manage technical debt. Including accessibility criteria in these definitions helps teams prioritize accessibility during development. Mike discusses Three strategies for fitting Refactoring into your Sprints.
• Lisa Crispin and Janet Gregory emphasize the importance of teams improving their processes and products in their book Agile Testing. This includes addressing technical debt, like accessibility issues. They offer that during each iteration, use tests to guide code, rework as necessary, and complete any missing automated tests. Increase your estimations to reflect this effort. The team will eventually move faster.

2. Gradual Implementation in Current Sprints

In accessibility, the balance between progress and perfection is crucial. Waiting for everything to be perfect before acting can hinder progress. Embrace the agile approach: deliver early, often, and in increments. Start integrating accessibility into your current sprints, even if it initially creates technical debt. Focus on steady, manageable progress by limiting work in progress. Prioritize critical business functionality, and the impact will be noticeable. In my experience, when people see a team prioritizing and moving forward, they’re more patient, understanding that we’re working to address everything efficiently.

3. Prioritize Accessibility Tasks by Role

When I talk to teams about integrating accessibility into their sprint, I use the analogy of working out. Not exercising followed by a sudden gym session results in waking up sore. Why? Because it has been a while since you worked out that muscle group. As you keep working out, the muscles get used to getting flexed, and the soreness disappears. You are creating muscle memory. Learn any new skill is the same. When first learn to do it, it takes time. We have to think about it. Watch instructional videos or undergo training. What we are doing it completely foreign to us. That is until we develop muscle memory.

To make the process manageable, prioritize accessibility tasks by role within your team. Here are four key practices spread across different roles:

Content Providers: Alternative Text for Images

Content providers should ensure that all images have appropriate alt text. Use resources to understand how to write effective alt text like”

• W3C Alt Text Guide.

Designers: Color Contrast

Ensure your design meets color contrast standards. Use tools to validate your color schemes against WCAG Guidelines like:

• Adobe Color,
• WebAIM: Color Contrast Checker, or
• Deque’s Color Contrast Checker.

Developers: Automated Testing

Automated accessibility testing helps identify common issues quickly. Integrate tools like axe-core or Pa11y into your development pipeline to catch issues early. You can also use interactive tools to check rendered code for common accessibility errors like:

• Lighthouse in Chrome Dev Tools, or
• Accessibility Insights.

Quality Assurance: Keyboard Control

Test for keyboard navigability. Ensure that QA checks if all active elements like form fields, radio buttons, check boxes, buttons, and links can be accessed with only the keyboard. The best rule of thumb to remember is if you can do it with a mouse, you should be able to do it with a keyboard.

• <Tab> – Moves you down the page to each interactive element.
• <Tab> + <Shift> – Moves you back up the page by each interactive element.
• <Arrow Keys> – Cycles you through related controls like checkboxes, radio buttons, etc.
• <Enter> – Selects links and buttons
• <Space Bar> – Selects controls like checkboxes and radio buttons
• <ESC> – Dismisses modal dialogs.

By giving importance to alternative text, color contrast, automated testing, and keyboard control, the team can pinpoint the most common errors in inaccessible pages.

4. Maintain Consistent Progress

By regularly reviewing and updating your accessibility procedures, you can continuously make small improvements to make your products more accessible. By incorporating accessibility into your sprint retrospective practices, you can identify areas where accessibility can be enhanced and make the necessary adjustments in an incremental manner. This approach allows you to maintain the momentum of your agile processes and ensures that accessibility remains a priority throughout your development cycle. It also enables you to address any accessibility issues or gaps that may arise during the course of your project, ensuring that your final product is more accessible to a wider range of users. By consistently improving accessibility in small steps, you can create a more inclusive and user-friendly experience for all users. 

Conclusion

Recognizing technical debt, starting in the current sprint, dividing the work, and maintaining progress may seem easy on paper. But based on my real experience, I can say that it works. Remember, it is a journey that takes time. So, celebrate every gain you make.Building accessibility in a product, regardless of what product it is, has the power to change the world. When you and your team take the time to recognize accessibility in your work, it can make a difference for someone. Your customer might learn something new because they now have access to it. They might be able to buy something they needed but could not before. Your customer might even get the job they always wanted because the product they rely on became more accessible.Building these four steps into your process was not a waste of time. It may have been challenging at first, but as your skills and understanding grew, it became easier again.

If you are interested in learning more about way, you can change the world for someone, look at the training we offer. It changes the world.

Michael Harshbarger is an experienced project manager and accessibility consultant. He is passionate about helping businesses create inclusive digital experiences. With over ten years of experience in project management and accessibility, Michael established AccessibilityFirst Solutions LLC. Michael believes in promoting accessibility as a core business value. He thinks that inclusive design benefits not only those with disabilities but also enhances the user experience for everyone. Michael holds a Master’s degree in Project Management. He has successfully implemented accessibility programs for Fortune 100 companies. In his free time, Michael enjoys exploring the outdoors with his family and playing tabletop role-playing games.