Many people ask how U.S. Citizenship and Immigration Services (USCIS) ensures Section 508 compliance in Agile projects – especially when Section 508 testing is still largely manual.
The short answer is that we do this the same way we ensure the code works or that it meets security requirements: we test. And we do this as early in the process as possible. Then, we do whatever else works. Let’s talk about that.
As noted on the Section508.gov site, Section 508 of the Rehabilitation Act of 1973 is the law governing accessibility of information technology (IT) in the federal government. Agile development is a reference to the Agile methodology, in which software is developed and deployed incrementally, commonly in short iterations of two weeks or less.
Back in the day, when all of our work took place in waterfall development cycles, we had a development phase that was followed by a testing phase. Good teams always tested during development, but the real test came when code moved from the development environment to a production-like staging area. This is where independent verification and validation (IV&V), security, and Section 508 received their real testing. It was not unusual for teams to deliver several coding builds to successfully pass all tests. Unfortunately, Section 508 usually came dead last, at a time when everyone was itching to deploy. We generally held the line on major defects, but often went to production with minor defects and a remediation plan. This was no fun for anyone.
USCIS began adopting agile dev/ops around six years ago, and it has now become one of a handful of agencies where the development methodology is routine. The move to dev/ops at the agency received a further boost last year when USCIS achieved the ability to continuously deploy new software. USCIS is now moving even further into dev/ops by using microservices for each specific part of the verification effort.
When we adopted the Agile process, we learned that among its core principles was to move testing “left,” or earlier in the cycle; make development teams responsible for most testing; and automate testing as much as possible. So here’s what we did.
First, we began adding a requirement to all software development contracts that each team creating or modifying software would have a DHS-certified Section 508 Trusted Tester. For those who may not be familiar with it, the Trusted Tester certification program was developed and maintained by the DHS Office of Accessible Systems and Technologies (OAST). This very rigorous program ensures that testers know how to use the approved tools to conduct the test protocols defined by OAST for all DHS components. This program is so respected that many leading software companies send their people to it for training. This ensures that our development teams have a trained Section 508 resource to advise them early in the Agile cycle when requirements and design occur. Then, as code is developed, this Section 508-trained person can test it on the spot.
Next, we worked diligently to develop and maintain contact with new and prospective Trusted Testers. Because the Trusted Tester program is so rigorous, many people fail their first attempt at certification. By setting up certification study groups and mentors, we were able to forge ties with many people who then became Trusted Testers. We also arranged to receive notifications from DHS OAST as testers became certified. This told us which project teams had Trusted Testers. More importantly, it allowed me – the USCIS Section 508 coordinator – to introduce myself and my team, starting with a great big “congratulations!” As you might imagine, a congratulatory note that’s copied to your IT project manager and contracting officer representative generates a lot of good will. That gave my team a reason to engage with each Trusted Tester, determine where they might have questions as they began work on their projects, shore up potential weaknesses in the tester’s skills, and let them know where to turn for help.
While this was going on, we improved our training for User Interface (UI) developers. Long ago, we developed a “Top Ten 508 Issues for Software Developers” course, but interest had fallen off. We engaged the development teams to determine current and developing needs in the UI space and then updated our course to match those needs. As a result, teams began bringing emerging needs to us for review. In our most recent example, one of our teams wanted to use a new set of HTML attributes known as Accessible Rich Internet Applications specification, or ARIA. The problem was these attributes were not compatible with the standard OAST tests. Engagement with software developers at the training level helps to surface issues, such as this one, early by reinforcing our role as the first line of help for anyone with an accessibility issue.
We also launched a project to automate testing for the DHS 508 standards. This has been a very challenging effort – more than three years in the making and with more setbacks than success – but we are now on the cusp of a full-scale deployment. The tools we adopted allow developers to manually inspect UI code as it is being created, scan code in pipelines during a build, and scan entire Web sites from top to bottom. They only cover about 35 percent of the DHS test standards, but they are the standards that typically cover 60-70 percent of the UI requirements for a given project. These tools allow us to push much of the Section 508 testing as far left as it can go into the actual code writing process, free Trusted Testers up to focus on more complex testing, improve test reporting, and ensure greater uniformity of testing across projects.
Today, even as we continue these efforts, we are focusing on three other areas:
- We have engaged in the procurement process by meeting with contracting officer representatives at USCIS and DHS to discuss the new Section 508 standards, the increased need for strong market research, and Section 508 analysis in major software procurements. Heading off software products that don’t meet the 508 standards from the start saves everyone time, money, and significant pain later in the process.
- We are reaching out to content developers throughout USCIS in an effort to remediate accessibility problems in areas outside of our Office of Information Technology. This includes Microsoft Office documents, PDF documents, and videos. As more content moves from paper to electronic formats, USCIS needs to ensure that our content is fully accessible to applicants, petitioners, and others who may need it.
- We kicked off a new outreach effort to our Trusted Testers throughout USCIS by forming a community of interest with its first meeting in March. No one accomplishes much in isolation these days, and we produce better results when the bonds among us are strong.
I’m not saying this is the only way to ensure Section 508 compliance in Agile projects, but this is the way we are doing it at USCIS!