In our last article on Accessibility in an Agile Lifecycle, we began talking about the importance of including all members of the software development team in the process of building accessible software. In many Agile methodologies, teams are meant to be self-organizing in order to allow team members to take those tasks that best fit their particular skillset. For example, a front-end developer might take on the HTML, CSS and JavaScript tasks for a story while a Database Administrator might take on the database related tasks. This allows the team to leverage the strengths of individuals to complete more tasks with lower risks during the sprint.
The question you’re probably asking yourself then is, if teams are self-organizing, then doesn’t that mean that the person with the accessibility knowledge ends up with all of the accessibility related stories?
On some teams, this is likely the case. However, what if we flip this question around to ask a slightly different, but related question? If teams are self-organizing, then doesn’t that mean that the person with the security knowledge ends up with all of the security related stories?
That sounds crazy, right? In today’s world of Cross-site Scripting (XSS), Cross-site Request Forgery (CSRF) and RansomWare attacks (to name a few), shouldn’t the whole team be aware of how to write and test their code so that they don’t release an insecure product? You probably have a Security Person or Team that’s responsible for validating the product and they probably even have some special tools they use for making sure the product is secure against the latest threats that the development team hasn’t had time to learn about yet. If you’ve been in accessibility for any amount of time, that scenario probably sounds rather familiar. This is why the same idea goes for developing something so that it is accessible as it does for secure. Once the commitment is made by the organization and the development team to build something that is accessible, the team, not individuals, is responsible for seeing that commitment through to its success.
So how do we do this?
My favorite way is to demystify accessibility by talking to team members in each role on how the various accessibility laws and guidelines will affect their work. By the end of your chat, you want your developers to know that they can still use cutting edge tools like AngularJS and React. Designers and UX professionals will be happy to hear that building something that is accessible doesn’t mean it’s going to be ugly or have a clunky UI. I also make sure to explain accessibility to the Database Administrators, backend developers, the security folks, and whomever else has is part of the development team, so that they begin thinking of how accessibility might affect their role.
Once the team has a better understanding of what accessibility is and how it effects their role, it is usually much easier to get them to take on accessibility related tasks. You’ll still need to check their work and perform your usual accessibility testing, but over time you’ll begin noticing fewer and fewer accessibility issues make it to your desk as the team, not just the accessibility professional, becomes responsible for developing an accessible product.