ComplianceAccessible Software Procurement in 2026: Section 508, ACRs, and WCAG 2.2 Buyer Questions
A current public-sector buyer guide to Section 508 requirements, Accessibility Conformance Reports, workflow testing, WCAG 2.2, acceptance criteria, and post-award accessibility evidence.
Reviewed for accuracy by Kodi C.
Updated September 2, 2026: Accessibility belongs in software procurement before the demo, not in remediation after go-live. For U.S. federal agencies, Section 508 requires information and communication technology that agencies procure, develop, maintain, or use to conform to the Revised 508 Standards unless an applicable exception is documented. GSA’s current Section508.gov guidance continues to frame accessibility as an acquisition-lifecycle responsibility spanning requirements, market research, solicitation language, vendor evidence, evaluation, acceptance, and post-award validation. Buyers should treat an Accessibility Conformance Report as evidence to examine—not a checkbox that ends the review.
Start with the legal baseline, then define the product standard you actually need
Federal acquisition teams should distinguish the Revised 508 Standards from newer web accessibility guidance. Section508.gov’s materials describe the Revised 508 technical requirements as aligned with WCAG 2.0 Level A and Level AA. WCAG 2.2 is a newer W3C Recommendation and adds success criteria including Focus Not Obscured, Dragging Movements, Target Size, Consistent Help, Redundant Entry, and Accessible Authentication. W3C recommends using the latest WCAG version where possible, but that does not mean a buyer should rewrite the federal legal baseline as if Section 508 itself simply equals WCAG 2.2.
A strong solicitation separates mandatory requirements from additional accessibility goals. Identify which Revised 508 provisions apply to each ICT component, document any legitimate exception analysis, and then state any additional contract requirements the agency wants the solution to satisfy. If WCAG 2.2 AA is a contractual or design objective beyond the incorporated federal baseline, say so explicitly and define how it will be tested. Clear requirements reduce disputes later about whether a vendor promised legal conformance, broader best-practice conformance, or both.
This distinction also improves market research. Vendors may publish ACRs based on different VPAT editions and different technical standards. Compare the report’s stated standard, product version, module, and evaluation date to the actual solicitation. An impressive accessibility landing page does not prove that the specific version, configured implementation, mobile experience, authoring workflow, or integration being purchased meets the agency’s requirements.
Request an ACR, but evaluate what is inside it
Section508.gov advises federal buyers to request accessibility information from vendors and contractors. For standard commercial or government off-the-shelf ICT, an ACR provides a structured way to describe conformance. Buyers should read the product name, version, report date, scope, evaluation methods, applicable standards, and remarks before treating the conformance labels as meaningful.
Pay particular attention to Partially Supports, Does Not Support, Not Applicable, and similar entries. The remarks should identify the affected function, the condition under which the barrier appears, and any workaround or remediation path. A report containing uniformly positive conclusions but little test detail deserves more scrutiny, not less. The buyer should be able to tell what was actually evaluated.
Freshness matters because software changes continuously. Ask what product build the report covers, whether material interface changes occurred after the report, and what event triggers an updated ACR. For SaaS, accessibility evidence maintenance belongs in the ongoing contract relationship. A report for a materially different interface is historical evidence, not proof of the current service.
Use the newer ACR supplement to ask better defect questions
Section508.gov’s Government ACR Supplement, reviewed in August 2026, gives buyers a more operational model for accessibility gaps. It asks for the affected product area or workflow, impacted user group, workaround, and related defect context instead of relying only on a conformance label. That is a useful procurement pattern even when the exact supplement is not contractually required.
When a vendor discloses a gap, ask four questions: what user task is affected, which users experience the barrier, whether a realistic workaround exists, and when the product team expects to remediate and retest the problem. A defect such as unlabeled form fields, an inaccessible address workflow, or a keyboard trap should be described in terms of functional impact rather than buried in generic remarks.
This also helps buyers compare risk across vendors. One product may have more disclosed defects but better evidence, clearer ownership, and dated remediation. Another may report near-perfect conformance with little test detail. Procurement scoring should reward evidence quality and realistic remediation governance rather than incentivizing vendors to disclose less.
Test the workflow, not only isolated pages
Accessibility problems often appear at the boundaries between components: authentication, modal dialogs, file upload, document preview, tables, charts, date pickers, search filters, notification banners, generated PDFs, rich-text editors, or third-party integrations. A procurement evaluation should therefore use representative end-to-end workflows rather than checking only a landing page.
Choose tasks that matter to actual users. For a records system, that may include signing in, finding a record, filtering a table, opening an attachment, editing metadata, completing a form, receiving validation feedback, exporting a report, and signing out. For a public portal, include search, pagination, document access, form submission, status messages, and mobile use. For an internal workflow application, include keyboard-only operation and assistive-technology interaction with the highest-volume and highest-consequence tasks.
Automated scanning is useful but cannot establish full conformance. Combine it with keyboard review and appropriate manual or assistive-technology testing. Document the test environment, browser, platform, assistive technology where used, product build, test steps, expected result, actual result, severity, and disposition. The evidence should be reproducible enough that agency and vendor reviewers are discussing the same defect.
Use accessibility as an acceptance criterion, not only a pre-award promise
Section508.gov frames procurement as a lifecycle that continues after award. Put measurable accessibility acceptance criteria into the statement of work, quality plan, backlog definition of done, or other appropriate contract artifact. Define what must be tested before release, who performs the testing, which evidence the contractor supplies, which severity levels block acceptance, how remediation is tracked, and how retesting occurs.
Configured and custom solutions deserve special attention. A platform can provide accessible components while an agency or implementation partner creates inaccessible forms, documents, labels, reports, or extensions. Conversely, accessible source content can become inaccessible when rendered by the product. The contract should identify ownership for standard components, configured workflows, authored content, integrations, generated documents, training, and final acceptance.
Accessibility should also appear in quality surveillance. If a release materially changes navigation, authentication, core workflows, document output, or a major UI component, define whether that change triggers regression testing or an updated ACR. Treating accessibility as part of normal release governance is more sustainable than reopening a one-time compliance project after users report barriers.
Ask about remediation and product governance before you need them
No mature buyer should assume a complex product will never have an accessibility defect. The procurement question is how the vendor finds, prioritizes, communicates, and fixes defects. Ask for the accessibility intake path, severity model, remediation targets, release process, regression approach, customer-notification practice, and product owner. Ask whether accessibility findings live in the same product-management system as other defects or disappear into an unowned compliance queue.
For known gaps, request a remediation plan identifying the affected function, user impact, workaround, target release, owner, and validation method. Avoid undated commitments. If a gap affects a core task, determine before award whether an alternate means of access is realistic for the user population and operational setting. Section508.gov’s procurement guidance discusses best-meets situations where no technically acceptable commercial alternative fully conforms, but that is a documented acquisition decision—not a blanket waiver of accessibility expectations.
Governance should survive product change. Contract terms can require notice when a release materially changes an accessibility claim, replaces a major component, or causes an ACR to be updated. The agency should have a named accessibility owner or review function that receives those changes and determines whether new testing is required.
WCAG 2.2 strengthens evaluation without changing the legal label
WCAG 2.2 provides useful additional tests for modern interfaces. Focus Not Obscured is relevant to sticky headers and overlays. Dragging Movements matters when essential functions depend on drag-and-drop. Target Size matters for dense interfaces and mobile use. Accessible Authentication matters when login flows introduce cognitive-function tests or other avoidable barriers. These are practical design and procurement signals even when the mandatory Section 508 baseline remains tied to the Revised 508 Standards.
If an agency chooses to require WCAG 2.2 AA contractually, define scope: standard product, configured implementation, public content, internal administration, mobile web, native applications, generated electronic documents, or all of them. Then define testing and acceptance. A sentence that says ‘must be WCAG compliant’ is ambiguous because it omits version, level, product scope, exceptions, and evidence.
For non-federal public-sector buyers, the controlling legal requirements may differ by jurisdiction. The evidence discipline remains useful: identify the applicable rule, define scope, request a conformance statement, test material workflows, document gaps, and place remediation and regression expectations into the operating relationship.
A buyer evidence pack for accessible software
Ask each shortlisted vendor for the current ACR covering the product and version proposed, the methods used to produce it, known accessibility defects affecting material workflows, remediation governance, and the accessibility product contact. For custom development or configuration, request the accessibility test plan, development standards, component or design-system practices, and evidence that accompanies each release.
During evaluation, preserve the ACR version and date, workflow-test notes, demonstrations, defect list, vendor clarifications, remediation commitments, exception decisions, and scoring rationale. Connect those items to the procurement record rather than storing them in an isolated accessibility folder that reviewers never see during award.
Zeph Tech’s Accessibility Procurement Checklist can structure that evidence request. The Software Evaluation Scorecard makes accessibility findings visible alongside security, implementation, support, and exit risk, while the Public-Sector Technology Procurement Toolkit carries the same evidence through a broader acquisition lifecycle.
Questions for the next software evaluation
- Which Revised 508 provisions apply to each ICT component being purchased?
- What exact product version and technical standard does the ACR cover?
- Which material workflows were manually tested, and can the vendor demonstrate them with keyboard and assistive technology?
- For each known gap, what task is affected, which users are impacted, what workaround exists, and what dated remediation commitment is recorded?
- Are we intentionally requiring WCAG 2.2 beyond the federal baseline, and have we defined scope and acceptance?
- Who owns accessibility for custom configuration, third-party components, generated content, documents, and integrations?
- What product change triggers an ACR update or agency retest?
- Will accessibility defects affect acceptance, quality surveillance, and contractor performance after award?
An ACR is valuable because it creates a structured starting point for the conversation. It is not a substitute for requirements, workflow testing, acceptance, or ongoing oversight. The strongest procurement process makes accessibility visible from market research through post-award operations, preserves evidence at each stage, and distinguishes clearly between the legal baseline and any higher design standard the agency chooses to require.
Continue in the Compliance pillar
Return to the hub for curated research and deep-dive guides.
Latest guides
-
Third-Party Compliance Oversight Guide
Operate evidence-based third-party compliance oversight after vendor selection: obligations, monitoring, control evidence, findings, incidents, reassessment, concentration signals…
-
Privacy Enforcement Readiness Guide
Build an evidence-based privacy enforcement readiness program around current EU GDPR priorities, California CCPA regulations, U.S. sensitive-data restrictions, rights operations…
-
SOX and ICFR Modernization Guide
Modernize Sarbanes-Oxley internal-control operations with current SEC management guidance, PCAOB AS 2201, COSO 2013, technology controls, evidence design, and the December 2026…
Coverage intelligence
- Published
- Coverage pillar
- Compliance
- Source credibility
- 40/100 — low confidence
- Topics
- Section 508 · Accessibility Conformance Report · WCAG 2.2 · Accessible Procurement · Public Sector Software · VPAT
- Sources cited
- 6 sources (section508.gov, 3.org)
- Reading time
- 9 min
References
- Buy Accessible Products and Services — Section508.gov / GSA
- Accessibility in Procurement I: Pre-Solicitation — Section508.gov / GSA
- Request Accessibility Information from Vendors & Contractors — Section508.gov / GSA
- Section 508 Government ACR Supplement — Section508.gov / GSA
- Web Content Accessibility Guidelines (WCAG) 2.2 — W3C
- What's New in WCAG 2.2 — W3C WAI
Source feedback
Editorial
Found a factual issue, superseded source, broken citation, or important context we should review? Send the specific claim and supporting source through the correction path so it can be evaluated against the article record.