Governments increasingly deliver public services through third-party SaaS platforms they do not directly control.
Residents use vendor-managed software to pay utility bills, apply for permits, register for community programs, submit service requests, and access public records. Public universities rely on similar platforms for admissions, financial aid, course registration, housing, and student account management.
This reliance creates a significant government accessibility challenge: What happens when a public entity is responsible for equal access, but the digital barrier exists within vendor-controlled software?
A VPAT Does Not Prove Software Accessibility
A Voluntary Product Accessibility Template, or VPAT, is used to produce an Accessibility Conformance Report. The report describes how a software product supports specific accessibility standards and criteria. However, a VPAT does not prove that the deployed platform is accessible.
An accessibility report may:
- Apply to an outdated software version.
- Exclude authenticated features and user portals.
- Rely heavily on automated accessibility testing.
- Omit administrative or mobile interfaces.
- Exclude embedded payment or identity-verification tools.
- Identify accessibility limitations without providing a remediation timeline.
For this reason, public entities should examine when, how, and by whom the product was actually tested. They should also determine whether the evaluation included keyboard navigation, screen readers, mobile layouts, critical transactions, and direct participation by people who use assistive technologies.
A VPAT can support vendor accessibility evaluation, but it should start the review rather than serve as final proof of compliance.
Test the Configured SaaS Platform
Government software accessibility depends on more than the underlying product.
Municipalities and universities frequently configure colors, navigation, page layouts, field labels, forms, workflows, and uploaded content. Even when the core SaaS platform was designed to be accessible, local implementation decisions can introduce new barriers.
Third-party integrations create additional accessibility risks. During a single transaction, a resident may move between separate systems for identity verification, online payments, GIS mapping, electronic signatures, document uploads, and customer support.
Each transition can introduce different interface patterns, accessibility limitations, and keyboard behaviors.
Accessibility testing should therefore evaluate the deployed government service and all connected tools. A vendor demonstration environment cannot reliably represent the accessibility of a customized, integrated implementation.
Focus Accessibility Testing on Essential Transactions
The most important measure of digital accessibility is whether a person with a disability can complete an essential government service independently, securely, and efficiently.
End-to-end accessibility testing should cover critical tasks such as:
- Creating an account
- Recovering account access
- Completing identity verification
- Entering information into forms
- Correcting validation errors
- Uploading required documents
- Making an online payment
- Receiving transaction confirmation
- Checking an application or request status
- Finding support or accommodation options
A platform may appear accessible at the page level but still fail during a critical transaction. One inaccessible control, such as an unlabeled upload button, keyboard focus trap, or silent form error, can prevent a user from completing the entire process.
Testing complete user journeys provides a more accurate view of third-party SaaS accessibility than reviewing isolated pages or automated scan results.
Strengthen Accessibility Requirements in Procurement
General contract language requiring compliance with applicable laws may not provide enough detail to hold vendors accountable.
More effective accessibility procurement requirements identify:
- The applicable technical accessibility standard
- The product modules and user roles included in testing.
- Required VPATs and accessibility documentation
- Approved manual and automated testing methods
- Known accessibility defects
- Remediation priorities and deadlines
- Notification requirements following major software updates
- Responsibility for configuration-related barriers
- Access to testing or staging environments
- Contractual remedies for unresolved accessibility issues
Accessibility oversight should continue after implementation. Software releases, redesigned components, authentication changes, and replacement integrations can introduce accessibility regressions long after the original procurement process is complete.
Specific, testable contract language gives public entities a stronger foundation for monitoring SaaS accessibility throughout the vendor relationship.
Treat Accessibility as Part of Vendor Governance
Using third-party software does not transfer the public entity’s accessibility obligations to the vendor. Instead, it makes digital accessibility a core component of vendor governance.
Public entities need a repeatable process for:
- Evaluating software accessibility before procurement
- Reviewing the accuracy and scope of vendor accessibility claims
- Validating the configured system before launch
- Monitoring essential workflows after deployment
- Documenting accessibility defects
- Enforcing remediation requirements during the contract
Vendor claims can begin the accessibility review, but they should not end it. Government software accessibility needs to be demonstrated through the actual service to residents, students, and other members of the public.
The Department of Justice’s Title II rule generally requires state and local government web content and mobile applications to meet WCAG 2.1 Level AA. These requirements can also apply when a government arranges for another organization or private company to provide the digital service.
Referenced in this article: Department of Justice fact sheet on Title II web and mobile application accessibility
