If you find it difficult to prevent and resolve accessibility issues throughout your software development lifecycle (SDLC), you aren’t alone. Integrating accessibility into your software development lifecycle can be challenging if you do so without proper commitments and accountabilities. There can be obstacles when launching or updating a website page or application, even without considering these assets’ accessibility. Layering in additional quality standards and testing for accessibility can easily slow your operations if you’re testing for accessibility before deploying your digital assets. But fortunately, there is a better way. By utilizing a continuous accessibility strategy, you’ll discover accessibility issues early on before launch.
Register for the on-demand webinar on how to embed accessibility tests into your continuous integration pipeline today:
https://www.tpgi.com/webinar-april-7-enabling-an-accessible-sdlc-people-process-and-technologies/
What is continuous accessibility?
Continuous accessibility refers to incrementally integrating accessibility into all stages of the software development lifecycle so that your DevOps can consistently and efficiently produce and maintain accessible code. 
View text version
The alternative is retroactively checking for accessibility at the end of a sprint. This is a less than desirable outcome because this process tends to require code changes.
The most efficient way to build a house is to start with a strong foundation, add walls, some windows, doors, and eventually a roof. And the work must be inspected before the contractors move on to the next stage of construction. Contractors, like software developers, construct buildings logically. If they didn’t operate within a framework, they might have to take the roof and the walls down to ensure that the foundation is strong or the walls are sturdy. This would waste time and money. Much like contractors, software developers leverage a framework (in this case, the software development lifecycle) to work logically, strategically, and efficiently. The last thing you want to do is to run an accessibility audit only after all your agile sprints are completed and your website is ready to be deployed because that could surface errors that could have been addressed during the build process. Accessibility needs to be considered a core component of your software development process. Much like the planning, analysis, and design phases, accessibility tests need to be conducted at each of the five stages of the software development lifecycle.
A critical factor in adopting an accessible DevOps process
Getting a commitment from the software engineers on your development team and senior leadership (who control the budgets and manage overall resourcing) is critical for integrating accessibility into your DevOps process. Without a commitment to the necessary instrumentation or prioritizations or the ability to enact accountability, you’ll struggle to achieve your goals.
How to enable continuous integration of accessibility testing in your development pipeline
Integrating accessibility isn’t really all that different from testing for any other quality standard, like cross-browser compatibility or other bugs. Take a look at the five key elements required to support your efforts:
- Policy – Start by establishing your accessibility goals, then prioritize the importance (which is helpful for future sprint planning). Define these in your policies so that you can use them to measure your successes and understand where you need improvements. ARC’s Accessibility Testing Initiatives are a great way to define your policy (when using automated testing), easily track progress, and measure success.
- 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 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 software like Jira or Aha that let you 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 to solve accessibility failures. Without access to our KnowledgeBase or an alternate 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 smoothly with fewer disruptions.
- Accountability – Accessibility analytics establish accountability. How effective are your DevOps 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.
Accessibility testing tools the TPGi DevOps team use
At TPGi, accessibility for all is embedded in our ethos. Our development team has a refined, accessible software development process that, first and foremost, leverages the ARC platform, which provides our team with a host of DevOps tools. ARC’s KnowledgeBase, Tutor, Analytics, and HelpDesk let you and your team scan, track, test, and remediate accessibility errors using the WCAG 2.0 and WCAG 2.1 criteria. Whether you’re on a small or large development team at any size organization, 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. Learn how to seamlessly embed accessibility tests into your continuous integration pipeline by registering for the on-demand webinar: “Enabling an Accessible SDLC—People, Process, and Technologies”. Access the on-demand webinar today: https://www.tpgi.com/webinar-april-7-enabling-an-accessible-sdlc-people-process-and-technologies/
