Accessibility in an Agile lifecycle

When you first started reading about Scrum, Kanban, or one of the other Agile frameworks, you probably came across topics like user stories, sprint planning, minimum viable product, and continuous integration. Each Agile framework has its own set of terms, lingo, and way of doing things which can make learning what and when to do something a challenge.

What is important to understand, is that all Agile frameworks have one thing in common; a desire to help you manage the risk associated with building something. This is why Agile frameworks like Scrum work really well when applied to software development projects.

In fact, Agile and Accessibility really should go hand-in-hand, but for some reason, even the most ardent practitioners of Agile can have a hard time figuring out how and when to include accessibility.

Before we start talking about how frameworks like Scrum can help us be better at accessibility, let’s step back and get to know what started it all, the Agile Manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

While the secondary concerns are important, the primary concerns are more critical to success.

For decades, when a software development team came together to build something it was known that everyone had a role and a job to do. What changed with Agile was that it broke down the barriers that separated developers, business analysts, UX, and QA. Agile did this by establishing a set of principles that brings everyone together starting at the project kickoff to talk and collaborate on what and how a product should be built.

This is the same process that accessibility professionals have advocated for many years. Remove the wall that reserves the accessibility professional for testing at the end of the project after everything has been built and instead make us a member of the team from the start. We’ll talk with the analysts, collaborate with developers, provide guidance to UX, and test alongside QA so that, we the team, have a better understanding of how persons with disabilities can and will use assistive technology to interact with our software in browsers and mobile devices. We even have a few guidelines that, with a basic understanding, will help everyone on the team begin writing better user stories, code, and test cases, that help the team build software that not only works and accomplishes the needs of the business, but is usable by everyone.

Over the next few weeks we’ll take a deeper dive into Agile frameworks, like Scrum and Kanban, to provide practitioners with some ways they can improve the way they talk about and work with accessibility when building software.