Section 508 makes ICT accessibility a lifecycle procurement requirement

Accessibility follows the ICT through its lifecycle

The direct answer in the U.S. Access Board's Revised 508 Standards is that ICT procured, developed, maintained, or used by federal agencies must conform to the standards. Procurement is one point in that lifecycle, not the end of the accessibility decision. The public scope includes computers, telecommunications equipment, multifunction office machines, software, websites, information kiosks and transaction machines, and electronic documents.

A procurement record should therefore connect the applicable accessibility requirements to the actual ICT, version, configuration, content, interfaces, integrations, documentation, support, acceptance evidence, changes, and operating owner. A product-level statement made during sourcing cannot establish that every configured workflow, document, integration, update, or support service remains accessible after award.

The requirement map depends on the component

The standards do not treat ICT as one undifferentiated object. They separately address electronic content, hardware, software, and support documentation and services. Covered electronic content must conform to WCAG 2.0 Level A and Level AA Success Criteria and Conformance Requirements, subject to stated exceptions. Hardware that transmits information or has a user interface points to Chapter 4, while software points to E207 and Chapter 5.

A useful evaluation maps each product component and user journey to the applicable provision instead of attaching one accessibility status to the supplier account. Buyers can test authentication, configuration, authoring, approvals, search, reporting, exported documents, mobile or device interfaces, help content, and support interactions with representative users and assistive technologies. The source requirements and their exceptions should remain visible beside the evidence.

Exceptions are documented decisions, not missing fields

E202.6 addresses undue burden or fundamental alteration. It requires the responsible agency official to document the basis in writing, including why and to what extent conformance would create the burden or alteration, and requires an alternative means that meets identified needs where the exception applies. E202.7 addresses ICT that is not commercially available in a conforming form and directs the agency to procure the option that best meets the standards consistent with its business needs.

The best-meets provision also requires written documentation of non-availability, the market research performed, the provisions that cannot be met, and the basis for the selection. A procurement platform should preserve the applicable exception, decision owner, evidence, scope, unmet provisions, market research, alternative means, approval, review date, and affected users. It should not convert an empty conformance field or supplier assertion into an approved exception.

Acceptance must test the delivered operating boundary

A buyer can use a representative end-to-end task to examine the delivered system rather than only the standard configuration. The test should retain the product and version, configuration, requirement mapping, environment, content, assistive technology, steps, expected result, observed result, defect, severity, owner, remediation, retest, exception if any, and acceptance decision. Changes after go-live need a defined trigger for reassessment.

This analysis does not determine whether Section 508 applies to a particular acquisition, whether ICT conforms, whether an exception is available, or what testing is sufficient. Federal agencies must apply the current law, acquisition rules, official instructions, standards, contract terms, technical facts, user needs, and responsible accessibility, procurement, program, technology, security, legal, and oversight judgment.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Procurement Technology Current will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.