Page 52 - FCW, January/February 2021

50
January/February 2021 FCW.COM
Ideas
The need for
accessibility
compliance as code
By incorporating accessibility into automated compliance processes, government can move beyond box-checking to truly serve everyone
BY LUKE FRETWELL
Much of the conversation about government technology com- pliance 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 desig- nated expectations and regulatory con- trols. 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 acces- sibility conformance, there are Section 508 and the Web Content Accessibility Guidelines.
Although compliance doesn’t guar- antee 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 gov- ernments use to serve the public.
Technology compliance, particularly the authority to operate (ATO) process,
is extremely cumbersome. It’s a manu- al, expensive, elongated exercise with high potential for human error. Tech- nology projects are ever-changing, so this approach is detrimental to govern- ment 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 com- pliance as code, which scans controls in machine-readable formats to imme- diately determine if a technology prod- uct passes or fails compliance.
The importance of a machine-readable format Developed and managed by the Infor-
mation Technology Industry Council, the Voluntary Product Accessibility Template (VPAT) is a document that designates accessibility compliance for a particular information and communi- cations technology (ICT) product, such as software and hardware.
The VPAT format has promise but has largely been a procurement requirement and often closer to mar- keting. 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 pub- lic 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 rec- ommends (and many government con- tracts require) that vendors generate VPATs for technology products. In fact, GSA suggests on Section508.gov that agencies request accessibility informa- tion 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 evalu- ating proposals.”
Furthermore, “government solicita- tions which include ICT will specify accessibility requirements, indicat- ing 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 rec-