Developing an accessible software development life cycle (SDLC) requires a commitment to inclusion from everyone at the beginning of every project. By committing to developing accessible products, you will avoid costly and timely remediation prior to deployment at the end of your product roadmap.
Creating An Accessible Software Development Life Cycle (SDLC)
An accessible SDLC is one in which accessibility is integrated into every stage from planning through maintenance. This includes accessibility policy, automated testing against that policy, incorporation into your QA processes as well as verifying and documenting conformance requirements such as voluntary product accessibility template (VPAT) creation.
Integrating accessibility isn’t really all that different from testing for any other quality standard, like cross-browser compatibility or other bugs. Here are the five key elements required to support your efforts:
Policy – Start by establishing your accessibility goals, then prioritize based on importance (which is helpful for future sprint planning). Define these goals and priorities in your policies so that you can use them to measure your successes and understand where you need improvements.
Automated and Manual Testing – Automated testing works by using software to scan your digital assets—whether in production, dev or staging—with an accessibility rules engine to check for errors. It can quickly and efficiently catch machine-detectable web content accessibility guidelines (WCAG) failures—the accessibility standard—that engineers can fix during the development process. Automated testing can be performed in many ways; however, the approach that will work best for you will depend on the level of integration that your DevOps team can facilitate. Manual assessments are far more comprehensive than automated scans. They also take essential user experiences into consideration, and they can catch errors far beyond what is machine-detectable today.
Integrated User Story Development or Continuous Integration/ Continuous Deployment (CI/CD) – Once you’ve found the failures, what do you do with them? They should be treated like any other bug or glitch that prevents customers from accessing or using your website or application. You’ll want to capture this information in your ticket tracking system. Many organizations use agile sprints and project management software to create tickets, which are then fed into the development pipeline and prioritized, assigned and completed. Finding a solution that will let you easily convert WCAG failures into user stories (either manually or, better yet, through automation) is key for feeding a prioritized pipeline of work to be done.
Knowledge and Resources – There are specific development techniques used to solve accessibility failures. Without access to a comprehensive library of accessible code techniques, developers will spend a lot of time scouring the web for solutions. Yes, you can find good solutions if you look long enough, but even so, how do you know whether that solution is legitimate or optimal for your case? Having the relevant solutions for an issue at your fingertips (negating the need to do a ton of online research) lets your DevOps team work more smoothly with fewer disruptions.
Accountability – Accessibility analytics establish accountability. How effective are your DevOps teams at reducing WCAG failures? Tracking failures across your digital properties on a defined cadence lets you see and document trends over time. You can also track activities like the volume of tickets that are tagged as accessibility remediation or bugs, or new features or capabilities to represent active efforts.
Whether you’re on a small or large development team at any size organization, adopting an accessible SDLC by implementing continuous accessibility checks at each phase of your development cycle is the most efficient and effective strategy to ensure that your website or applications are WCAG and ADA conformant.