The need for accessibility compliance as code
- By Luke Fretwell
- Feb 04, 2021
Much of the conversation about government technology compliance is in an either/or context: addressing either accessibility or security requirements. The two tend to be separate in their communities of practice and also in their assessment and implementation.
Compliance is a system of checks to ensure a product adheres to designated expectations and regulatory controls. Compliance helps people trust complex systems so they don’t have to do this for themselves. It’s a brand promise that what you get will work.
For security compliance, controls include cybersecurity standards set by the National Institute of Standards and Technology or legal requirements in the Health Insurance Portability and Accountability Act. For digital accessibility conformance, there are Section 508 and the Web Content Accessibility Guidelines.
Although compliance doesn’t guarantee the best product accessibility or security, it is a common approach to meet a service-level agreement. Such compliance checklists ensure that accessibility and security are being baked into the technology that governments use to serve the public.
Technology compliance, particularly the authority to operate (ATO) process, is extremely cumbersome. It’s a manual, expensive, elongated exercise with high potential for human error. Technology projects are ever-changing, so this approach is detrimental to government modernization and innovation.
Efforts to streamline and humanize security compliance are nascent but gaining interest, especially around expediting the ATO process. The rapid ATO and continuous ATO are great examples of this.
A key aspect of these efforts is compliance as code, which scans controls in machine-readable formats to immediately determine if a technology product passes or fails compliance.
The importance of a machine-readable format
Developed and managed by the Information Technology Industry Council, the Voluntary Product Accessibility Template (VPAT) is a document that designates accessibility compliance for a particular information and communications technology (ICT) product, such as software and hardware.
The VPAT format has promise but has largely been a procurement requirement and often closer to marketing. VPATs could be foundational for prioritizing digital accessibility, and they also give agencies and vendors a baseline for how much a company prioritizes accessibility.
These documents often aren’t public and are generally not updated with even major releases. They rarely link to open-issue queues where progress can be tracked. They are largely static procurement documents rather than roadmaps for change.
Although it’s not a mandate, the General Services Administration recommends (and many government contracts require) that vendors generate VPATs for technology products. In fact, GSA suggests on Section508.gov that agencies request accessibility information from vendors and contractors for ICT, saying, “VPATs help federal agency contracting officials and government buyers to assess ICT for accessibility when doing market research and evaluating proposals.”
Furthermore, “government solicitations which include ICT will specify accessibility requirements, indicating which provisions are required to ensure the deliverable is accessible. A VPAT is a good way to address the accessibility requirements defined in the solicitation. We recommend that vendors generate a VPAT for any ICT that’s intended to be marketed to the federal government. Use the VPAT to make specific statements in simple recommended language to demonstrate how the features and functional characteristics of your product meet the Revised 508 Standards.”
Currently, the Information Technology Industry Council provides the VPAT as a “Microsoft Word file that can be used as is or reproduced in other formats.”
As identified above, documenting compliance in a proprietary, non-machine-readable format such as Word makes an already cumbersome process even more so. For product developers, it essentially relegates the VPAT to a requisite checklist annoyance that significantly impedes modernization and innovation.
To make the VPAT more desirable and easily integrated into the compliance process, the solution is to shift to a non-proprietary, machine-readable format. The YAML-based Jekyll VPAT created by Ben Balter, senior technical program manager at GitHub, is a great example of this.
Such a machine-readable format can then be easily incorporated into the compliance-as-code process and repurposed by others. By taking that approach, we eliminate an emphasis on format and instead focus solely on the data needed to process the VPAT. Digital product developers and compliance and accessibility professionals will save unimaginable amounts of time, money and energy.
Compliance doesn’t equal accessibility (and vice versa)
Although compliance is a noble requirement -- and an unavoidable reality for federal agencies and their industry partners -- we must remember that it isn’t a substitute for true security or accessibility.
As the Information Technology Industry Council says: “While a VPAT can be an essential aid in assessing the availability of ICT products with accessibility features, it is important to note that, even in cases where a product conforms to relevant standards and technical specifications, an end user may still encounter difficulties utilizing it due to the nature or severity of his or her disability. On the other hand, a product that may not fully conform to all technical requirements may still be perfectly accessible to an end user who has a disability but does not need a particular accessibility feature -- e.g., a large-button telephone handset for an individual with a hearing disability.”
Baking VPAT into the code-as-compliance process isn’t a panacea. But it is a humble beginning to prioritizing accessibility and making a cumbersome process less so. By shifting the mindset and approach to one of open principles, machine-readable accessibility can become equally important to security in the compliance process.
By doing this, we move closer to truly protecting and serving everyone.
Luke Fretwell is a member of the CIvicActions Accessibility team and is CEO of ProudCity.