Government agencies and federally funded organizations in Massachusetts require vendors to document the accessibility of their software and digital services. A Voluntary Product Accessibility Template (VPAT) acts as a standardized conformance report outlining how well a product aligns with Section 508 and WCAG standards. Completing this report allows vendors to participate in municipal and educational procurement processes where accessibility is a strict purchasing criterion.
The document template was originally created by the Information Technology Industry Council (ITI) to assist federal procurement officers in meeting Section 508 requirements. Over time, the template has evolved to address changing technical standards and international guidelines.
The standard template is currently maintained in several versions, reflecting different regulatory structures:
- VPAT WCAG: This version focuses exclusively on the Web Content Accessibility Guidelines, which are the international standard for web content. It is typically used for websites, web applications, and digital documents.
- VPAT Section 508: Mapped to the federal requirements of the Rehabilitation Act of 1973, this version is required for federal agencies and vendors bidding on federal contracts.
- VPAT EN 301 549: Designed to align with European Union accessibility standards for public procurement, this version is used by organizations operating internationally.
- VPAT INT: A master template that combines the WCAG, Section 508, and European standards into a single reporting format for global vendors.
When an organization completes the template based on a technical audit of their product, the resulting document is called an Accessibility Conformance Report (ACR). It is this final report, rather than the blank template, that procurement officers review during the purchasing process.
An Accessibility Conformance Report is structured as a series of tables that correspond to the success criteria of the target standard. For each criterion, the evaluator must record a conformance level and provide detailed remarks.
The template defines four distinct levels of conformance:
- Supports: The functionality of the website or application conforms to the accessibility criterion without exception.
- Partially Supports: Some parts of the product conform to the criterion, but other parts do not. The evaluator must document the specific exceptions and describe the barriers a user might encounter.
- Does Not Support: The majority of the product functionality fails to meet the criterion, representing a significant barrier for users with disabilities.
- Not Applicable: The criterion does not apply to the product. For example, guidelines regarding video content do not apply to an application that only displays text.
The “Remarks and Explanations” column is the most critical part of the report. Technical assessors use this column to detail the specific testing methods, code locations, and user flows evaluated. For example, if a criterion relates to contrast (WCAG Success Criterion 1.4.3), the remarks should specify the actual ratios tested, such as “tested body text color #333333 on background #ffffff, yielding a 12.6:1 contrast ratio, which exceeds the required 4.5:1 ratio.” If exceptions are found, they must be listed specifically, such as “all body text meets the contrast requirements except for the secondary footer link (gray #888888 on dark gray #222222, yielding a 2.3:1 ratio).” Vague statements (such as stating that a product is accessible without offering evidence) are often flagged by procurement officers, who require specific documentation to verify compliance.
In Massachusetts, public sector organizations (including municipal governments, local school districts, and state universities) are legally bound to ensure their digital tools do not discriminate against individuals with disabilities. When these entities purchase software, learning management systems, or website templates, they must verify that the vendor products meet WCAG 2.2 Level AA standards.
Bidders who submit proposals without an ACR are frequently disqualified during the initial evaluation phase. When multiple vendors compete for a contract, the entity with a verified, independent ACR has a distinct competitive advantage. Procurement officers favor third-party audited reports because they reduce the agency’s liability under Title II of the Americans with Disabilities Act.
A completed ACR also protects the vendor by documenting the current state of the product. It establishes clear expectations regarding product accessibility, preventing post-sale disputes regarding product functionality. By being transparent about limitations, vendors can coordinate expectations and plan remediation timelines with the client.
Completing a reliable ACR requires a detailed audit of the product’s codebase and user interfaces. Self-assessments are common, but they carry significant liability risks. If an organization asserts that a product supports a criterion when it actually contains barriers, the vendor can face legal disputes or contract cancellation.
An audit typically utilizes the Department of Homeland Security (DHS) Trusted Tester methodology, which provides a structured process for manual evaluation. The DHS Trusted Tester process is a highly structured methodology developed by the Office of Accessible Systems and Technology. It outlines a set of repeatable testing steps that ensure consistency. Instead of relying on subjective opinions about whether a button is clear, the Trusted Tester process uses binary tests: does the button have a programmatically determinable name? Can the user trigger the action using only the Enter or Space keys? Is the focus state visually distinct? By using this standard, organizations can ensure that their evaluations are consistent across multiple reviewers.
The testing process combines automated scanners (which identify syntax issues and contrast violations) with manual keyboard reviews and screen reader testing. Manual testing is essential because automated tools cannot evaluate user interaction flows, focus patterns, or screen reader announcements.
To ensure the document stands up to procurement review, organizations can verify their conformance and document Section 508 alignment by procuring professional ADA website compliance services in Boston to conduct formal reviews.
Once the ACR is compiled, it serves as a technical roadmap for the vendor’s development team. The report highlights every area where the product “Partially Supports” or “Does Not Support” the standards, allowing developers to prioritize issues that block core user tasks.
Remediation typically begins with template-level changes, such as correcting heading structures, improving form labels, and restoring keyboard focus indicators. Once these global template issues are resolved, developers can address page-specific errors.
Because software development is an iterative process, any update can introduce new accessibility barriers. Establishing a recurring audit process ensures that the ACR remains accurate and that the product maintains its compliance posture over time. This ongoing attention helps vendors protect their existing contracts and remain ready for future public sector bidding opportunities.