This content originally appeared on DEV Community and was authored by Grace Harders
When I say “agile and accessibility,” some developers may pause. Have you ever heard a story about a developer delivering a product and later discovering that it has major accessibility issues? Cue the firestorm of bug fixes at the last second.
There are numerous myths and negative stereotypes surrounding the implementation of accessibility in software projects. This negative connotation can stem from an issue with the agile process. If your team doesn’t prioritize accessibility from the start, fitting it into your agile workflow later can feel painful, inefficient, and worst of all: SLOW. What if I told you that I learned how to change that?
This year I attended an amazing talk at AxeCon – Speed without Sacrifice: Building an Accessibility-First Culture in Agile Teams by John Sweet and Andrew Walker. In this article I’ll detail what I learned from this talk and the major takeaways I think we can implement in our company.
1. Will accessibility slow our agile process?
This question is posed frequently by developers as we are pushed to “move fast and break things” in agile development. The truth is that, yes, if implemented poorly, adding accessibility WILL slow you down. We can avoid slowing by implementing accessibility from the beginning and throughout our agile cycle.
Frequently, accessibility requirements appear late in the development cycle, but we can change that. We can add accessibility to our designs, way before any engineer starts coding. If designers AND engineers are trained in accessibility, then the entire team can think of possible accessibility issues before they appear in production.
In the Axecon talk, it was noted that we want our products to be “born accessible”. If our product is accessible from the start, then our process will continue like a fine-tuned machine. Developers, product managers, and designers can be aligned on accessibility requirements from the start. This approach will eliminate wasted time by developers in that “firestorm of bug fixing” I mentioned at the beginning of this article.
2. Train your staff
Training your staff in accessibility will look different for every company. If your company has the financial resources to invest, an accessibility expert could be hired to train your staff. Other options are enrolling your staff in online courses or holding office hours with accessibility experts to encourage discussion and collaboration.
Regardless of resources, every company should develop a standards library to state how different components can be added into designs. At the company I work for, Asurion, we have a UI library that sets the standards for our various UI components. The components are already accessible, so accessibility integration becomes a breeze. The challenge is promoting and enforcing these design standards throughout your company.
In Conclusion
To create accessible products, you don’t need to compromise on agile practices! Instead, bring in accessibility standards from the beginning to ensure smooth product delivery and happy engineers.
TLDR:
- Accessibility should be incorporated from the beginning of development
- Look into training opportunities for your staff
- Create accessibility standards across your company
This content originally appeared on DEV Community and was authored by Grace Harders