← Back to all briefings
Compliance 8 min read Published Updated Credibility 100/100

Accessible Software Procurement in 2026: Section 508, ACRs, and WCAG 2.2 Buyer Questions

A public-sector buyer guide to Section 508 requirements, Accessibility Conformance Reports, workflow testing, WCAG 2.2, acceptance criteria, and post-award accessibility evidence.

Kodi C.

Editor & Research Lead

Reviewed for accuracy by Kodi C.

Compliance pillar illustration for Zeph Tech briefings
Compliance controls, audit, and evidence briefings

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. In 2026, GSA’s Section508.gov guidance continues to emphasize requirements definition, market research, solicitation language, vendor accessibility information, proposal evaluation, and post-award validation as one acquisition lifecycle. Buyers should treat an Accessibility Conformance Report as evidence to examine, not a checkbox that ends the review.

Federal acquisition teams should distinguish the Revised 508 Standards from newer web accessibility guidance. Section508.gov’s current quick-reference 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 such as Focus Not Obscured, Dragging Movements, Target Size, Consistent Help, Redundant Entry, and Accessible Authentication. That does not mean a buyer should casually rewrite the federal legal baseline as WCAG 2.2 is Section 508. They are related standards with different status and procurement implications.

A strong solicitation therefore 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 being requested as 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 editions of the VPAT and different technical standards. A procurement team should compare the report’s stated standard and product version to the actual solicitation. An impressive accessibility page does not prove that the specific version, module, mobile experience, authoring workflow, or configured implementation being purchased meets the agency’s requirements.

Request an ACR, but evaluate what is inside it

Section508.gov tells federal buyers to request accessibility information from vendors and contractors. For standard commercial or government off-the-shelf ICT, its guidance calls for a written Accessibility Conformance Report for each ICT item and describes supplemental information that helps explain evaluation methods, accessibility features, inaccessible core functions, configuration needs, and—where relevant—support for producing accessible content.

The quality of an ACR matters. Read the product name, version, report date, evaluation scope, methods used, applicable standards, and remarks before reading the conformance labels. Look for vague statements that repeat the success criterion without explaining what was tested. Pay close attention to Partially Supports, Does Not Support, Not Applicable, and similar entries. The remarks should tell reviewers which function is affected, under what condition, and what workaround or remediation exists. A report that contains uniformly positive conclusions but little test detail deserves more scrutiny, not less.

Freshness matters too. Software changes continuously. Ask what product version the report covers, whether major interface or component changes have occurred since the report, and what event triggers an updated ACR. For SaaS, include accessibility evidence maintenance in the ongoing contract relationship. If a vendor releases frequently, a report from a materially different interface may be a historical artifact rather than useful evidence for the current service.

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 the public home page.

Choose tasks that matter to the actual users. For a records system, that may include signing in, locating 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 can identify useful classes of defects, but it cannot establish full conformance. Combine automated checks 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 a vendor and agency reviewer can discuss the same defect rather than arguing from screenshots without context.

Use accessibility as an acceptance criterion, not a pre-award promise

Section508.gov frames procurement as a lifecycle that continues after award. Its acquisition guidance includes post-award validation of contractor compliance, and its solicitation/post-solicitation guidance connects accessibility to quality surveillance and contractor performance. That is important because configured and custom solutions can drift away from the accessible state described during proposal evaluation.

Put measurable accessibility acceptance criteria into the statement of work, quality plan, or other appropriate contract documents. Define what must be tested before an initial release, who performs the testing, what evidence the contractor supplies, what severity levels block acceptance, how remediation is tracked, how exceptions are handled, and how retesting occurs. For iterative delivery, define accessibility as part of the completion standard rather than a separate project that begins after functional acceptance.

Also define responsibilities for content and configuration. A platform can provide accessible components while an agency or implementation partner creates inaccessible forms, documents, labels, reports, or custom extensions. Conversely, an agency can supply accessible content that becomes inaccessible when rendered by the product. The contract and governance model should identify which party owns component accessibility, configured workflows, authored content, integrations, training, and final acceptance.

Ask about remediation and product governance before you need them

No mature buyer should assume that 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 defect intake path, severity model, remediation targets, release process, regression testing approach, and customer notification practices. Ask whether accessibility defects are tracked with other product defects or disappear into a separate queue with no product owner.

For known gaps, request a remediation plan with the affected function, user impact, workaround where one exists, target release, owner, and validation method. Avoid accepting an undated promise to improve accessibility. 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 when no technically acceptable commercial alternative fully conforms, but such circumstances require disciplined documentation rather than a blanket waiver of accessibility expectations.

Governance should survive product change. Contract terms can require notice when a release materially changes an accessibility claim, when a major component is replaced, or when an ACR is updated. The agency should have a named accessibility owner or review function that receives those changes and decides whether retesting is needed.

WCAG 2.2 can strengthen product evaluation without confusing the requirement

WCAG 2.2 gives buyers useful additional tests for modern interfaces. Focus Not Obscured is relevant to sticky headers, overlays, cookie controls, and complex application chrome. Dragging Movements matters when essential functions depend on drag-and-drop. Target Size matters for dense controls and mobile interactions. Accessible Authentication matters when login flows introduce cognitive-function tests or interactions that create avoidable barriers. These criteria are practical design signals even where the procurement’s mandatory Section 508 baseline remains tied to the Revised 508 Standards.

If an agency chooses to require WCAG 2.2 AA contractually, specify the scope. Does it apply to the vendor’s standard product, the configured implementation, public content, internal administration, mobile web, native applications, generated electronic documents, or all of them? State the testing and acceptance mechanism. A broad sentence such as must be WCAG compliant creates ambiguity because it omits version, level, scope, exceptions, and evidence.

For non-federal public-sector buyers, accessibility obligations and standards can differ by jurisdiction. The same evidence discipline still applies: identify the controlling requirement, define the product scope, request a conformance statement, test material workflows, document gaps, and place remediation and regression expectations into the operating relationship. Legal interpretations should be confirmed for the buyer’s jurisdiction rather than inferred from a federal procurement guide.

A buyer evidence pack for accessible software

Ask each shortlisted vendor for the current ACR covering the product and version proposed, the evaluation methods used to produce it, a list of known accessibility defects that affect material workflows, the remediation process, and the accessibility contact or product owner. For custom development or configuration, ask for the accessibility test plan, supported development standards, component or design-system practices, and the evidence that will accompany each release.

During evaluation, preserve the ACR version and date, test notes, demonstrations, defect list, vendor clarifications, remediation commitments, exception decisions, and scoring rationale. Connect those items to the procurement scorecard rather than storing them in an isolated accessibility folder no one sees during award. Accessibility should influence technical acceptability and risk in a visible way.

After award, keep the evidence current. Retest high-value workflows after material interface changes, review updated ACRs, track unresolved defects, and verify remediation before closing findings. If the product is used to create documents or web content, include sample outputs in the accessibility program because an accessible editing interface does not guarantee accessible output.

Questions for the next software evaluation

  • Which Revised 508 provisions apply to each ICT component we are buying?
  • What product version and technical standard does the vendor’s ACR actually cover?
  • Which material workflows have been manually tested, and can the vendor demonstrate them with keyboard and assistive technology?
  • What known gaps affect core tasks, and what dated remediation commitments exist?
  • 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, and integrations?
  • What release or 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, 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.

Related articles

Curated signals from the same pillar or overlapping topics.

Continue in the Compliance pillar

Return to the hub for curated research and deep-dive guides.

Visit pillar hub

Latest guides

  • Global Privacy Enforcement Readiness Guide

    Build privacy programs that withstand GDPR, CPRA, LGPD, and Singapore PDPA enforcement by integrating regulator expectations, data governance, and cross-border response playbooks.

  • Compliance Operations Control Room

    Implement cross-border compliance operations that satisfy Sarbanes-Oxley, DOJ guidance, EU DORA, and MAS TRM requirements with verifiable evidence flows.

  • SOX Modernization Control Playbook

    Modernize Sarbanes-Oxley (SOX) compliance by aligning PCAOB AS 2201, SEC management guidance, and COSO 2013 controls with data-driven testing, automation, and board reporting.

Coverage intelligence

Published
Coverage pillar
Compliance
Source credibility
100/100 — high 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
8 min

References

  1. Buy Accessible Products and Services — Section508.gov / GSA
  2. Request Accessibility Information from Vendors & Contractors — Section508.gov / GSA
  3. Accessibility in Procurement I: Pre-Solicitation — Section508.gov / GSA
  4. Accessibility in Procurement II: Solicitation & Post-Solicitation — Section508.gov / GSA
  5. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C
  6. Laws and Policy Quick Reference Guide — Section508.gov / GSA
  • Section 508
  • Accessibility Conformance Report
  • WCAG 2.2
  • Accessible Procurement
  • Public Sector Software
  • VPAT
Back to curated briefings

Comments

Community

We publish only high-quality, respectful contributions. Every submission is reviewed for clarity, sourcing, and safety before it appears here.

    Share your perspective

    Submissions showing "Awaiting moderation" are in review. Spam, low-effort posts, or unverifiable claims will be rejected. We verify submissions with the email you provide, and we never publish or sell that address.

    Verification

    Complete the CAPTCHA to submit.