The project team at a public sector institution I used to work for was very excited by the software vendor’s presentation of their e-government solution. Their service would greatly improve the process members of the public needed to go through to transact business with our agency. The price was right, and the vendor had a number of state and local governments listed as references. Everything seemed to be on the right track except for one issue: when we ran our accessibility testing tool on the vendor’s demo site, it reported a significant number of errors and warnings. We weren’t too concerned, however, because our Request for Purchase had specified that the solution needed to be compliant with all relevant laws related to accessibility.
When this accessibility matter came up in the pre-contract meeting, the vendor representatives seemed caught off-guard and became defensive. They claimed that no other customer had ever brought this topic up before and that re-writing their application to be compliant would be “too much work” and were not in the scope of the proposal. Instead, they suggested that since only a small percentage of users have accessibility needs, we should just direct them to call in and transact business over the phone instead of trying to use the website.
Needless to say, the contract with that vendor did not get executed; another solution was selected and implemented after a protracted delay.
What follows is a brief overview of digital accessibility and why it matters for e-government projects. This article intends to raise awareness for software developers and vendors about the accessibility requirements that their government customers have, and why falling short on accessibility can (and should) cost them a contract.
"Taking digital accessibility seriously and doing the work to both ensure and demonstrate compliance with published accessibility standards represents a big step in that direction"
I’ve overseen digital projects in the public sector for over 20 years. The topic of accessibility is frequently overlooked, misunderstood, or deprioritized by web and software developers and vendors who seek to do business on e-government projects.
According to the W3C, web accessibility means that “websites, tools, and technologies are designed and developed so that people with disabilities can use them.” Furthermore, Section 508 of the Rehabilitation Act (29 USC § 794d) and related laws require government agencies to maintain digital resources that are accessible to people with disabilities.
It is not difficult to design websites and web applications to be accessible. The W3C’s Web Content Accessibility Guidelines (WCAG) outline a comprehensive set of technical specifications for websites and web applications that, when followed, ensure that compliant web browsers and other adaptive technologies can successfully parse a rendered web page and adapt the content to a user who requires screen magnification, higher contrast, text-to-speech dictation, or alternative input methods.
Web developers also have access to a number of tools that can check websites and web-based application content against the WCAG standards and report out on errors. Typically, the errors are easy to correct - for example, adjusting the contrast between text color and background, adding alternative descriptions to images and links, and ensuring that page structures conform to HTML standards.
Government organizations care about accessibility, not only because it’s required. It is also good practice - and good public policy - for all users to have equitable access to the same information, services, and resources. It is not an option for governments to meet accessibility requirements and goals by offering a less convenient service option to users with disabilities. Government organizations cannot do a cost-benefit analysis and decide to exclude a particular constituency because of their relatively small numbers. Those are all considerations that may not be evident to software developers and vendors who do not routinely deal with government customers.
The public sector organization I described earlier had done its due diligence and had taken its own steps to ensure the digital accessibility of products it was considering. For developers and vendors bidding on e-government projects, some simple proactive steps can be taken to ensure better that accessibility requirements are met and that your government customers don’t have to assume the entire burden of satisfying their objectives with regard to digital accessibility.
1. Design digital products to be compliant to WCAG standards and include a statement of conformance in responses to RFPs (whether or not it’s asked for).
2. Test your products not only with automated tools but with actual adaptive technologies such as screen readers and magnifiers. Ideally, enlist users of those technologies in UX testing.
3. Provide to potential customers an accurate, completed Voluntary Product Accessibility Template (VPAT), which is available from the US government’s Section 508 website (section508.gov).
4. Provide potential customers access to a live version of the product that is under evaluation and invite them to run an accessibility validation tool against it. Agree to resolve any issues and errors that might be reported.
5. Following each new version release, re-validate your product and provide government customers with the validation results and updated conformance documentation.
Government customers hear all the time that e-government solution providers want to be considered “partners” and not just vendors. Taking digital accessibility seriously and doing the work to both ensure and demonstrate compliance with published accessibility standards represents a big step in that direction.