Accessible Procurement

What Accessible Procurement Means

Accessible procurement is the practice of building accessibility into the way an organization buys technology, so that the websites, software, platforms, and devices it acquires can be used by the people with disabilities who will depend on them. It treats accessibility as a requirement of the purchase, like security or price, rather than as a problem to solve after the product arrives.

It applies to any organization that buys information and communication technology, often shortened to ICT: school districts, colleges and universities, public agencies, employers, health providers, and nonprofits. Once a product is installed and people have been trained on it, changing course is slow and expensive. Before a contract is signed, the organization can still compare products, test claims, and write expectations into the agreement.

Accessible procurement is a process, not a single document. Accessibility has to move through every stage: defining the need, writing requirements, soliciting offers, evaluating and testing responses, selecting a product, negotiating the contract, accepting delivery, implementing, monitoring, and deciding whether to renew or replace. For how to read the accessibility reports vendors provide, see VPAT and Accessibility Conformance Reports. This page covers the purchasing process around those reports.

Know Which Requirements Apply

Legal obligations depend on who the buyer is, and they differ between organizations. It helps to separate three things that are often blended together. A legal requirement is something a statute or regulation actually requires of a particular type of organization. A best practice is a method that experienced organizations and government guidance recommend. A procurement strategy is a choice an organization makes about how to meet its obligations, such as its scoring method or contract terms. Most of this page describes best practice and strategy, not a procedure that federal law prescribes step by step.

State and local governments and their agencies, including public school districts, public colleges and universities, libraries, and courts, are public entities under Title II of the Americans with Disabilities Act (ADA). A Department of Justice regulation now sets a technical standard for the web content and mobile apps they provide, described in the next section.

Organizations that receive financial assistance from the U.S. Department of Health and Human Services are subject to a separate Section 504 regulation that requires their web content and mobile apps to conform to Level AA of the Web Content Accessibility Guidelines (WCAG) 2.1. It applies because of that funding, not because an organization works in health care, and its compliance dates differ from the Title II dates: May 11, 2027 for recipients with fifteen or more employees and May 10, 2028 for smaller recipients.

Employers covered by Title I of the ADA must not discriminate against applicants and employees with disabilities and must provide reasonable accommodation to qualified individuals, unless doing so would cause undue hardship. For businesses open to the public under Title III, the Department of Justice has not issued a regulation setting detailed web standards, although its guidance states that the ADA's general requirements apply to their websites. A number of states have their own ICT accessibility laws or policies, and grant conditions, institutional policies, and customer contracts can also name a standard. An organization should confirm which of these apply to it before writing requirements, and seek qualified advice where the answer is unclear.

Title II and Public Sector Purchasing

The Department of Justice rule in 28 CFR part 35, subpart H, requires public entities to make the web content and mobile apps they provide or make available conform to the Level A and Level AA success criteria and conformance requirements of WCAG 2.1. An interim final rule published on April 20, 2026 extended the compliance dates. A public entity with a total population of 50,000 or more, other than a special district government, must comply by April 26, 2027. A public entity with a total population of less than 50,000, and any special district government, must comply by April 26, 2028. These are Title II compliance dates for covered public entities. They are not general procurement deadlines, and they do not apply to organizations outside Title II.

The rule matters for purchasing because it covers content a public entity provides or makes available directly or through contractual, licensing, or other arrangements. Content delivered through a licensed learning platform, a vendor-run payment portal, or a contractor-hosted permit system is covered in the same way as content the entity builds itself. The rule's exception for third-party content applies only to content posted by others who are not acting under such an arrangement, such as a member of the public commenting on a page. Its other limited exceptions depend on the type and age of content, such as certain archived material and older documents, and are described on the State and Local Governments page.

The rule places the obligation on the public entity and does not, by itself, divide responsibility or cost between an entity and its vendors; that is a matter for the contract. Department of Justice guidance lists approaches some entities have found helpful, such as requesting detailed accessibility information before signing, including warranties of conformance, not allowing vendors to disclaim those warranties, seeking indemnification for breaches of those warranties, and testing products independently. The Department also states that different approaches work for different entities and that it does not recommend or endorse any particular approach.

Two planning points follow. Many systems bought or renewed now will still be in use when the compliance dates arrive, so today's purchasing decisions affect how much remediation remains later. The Department has also said it plans future rulemaking related to the rule's substantive requirements. That is a reason to check the current regulation, and the review date on a page like this one, before a solicitation relies on a specific requirement.

Section 508 and Its Procurement Tools

Section 508 of the Rehabilitation Act requires federal agencies to make the ICT they develop, procure, maintain, or use accessible. Its technical requirements, the Revised Section 508 Standards issued by the U.S. Access Board, incorporate WCAG 2.0 Level A and Level AA for electronic content and software and add requirements for hardware, support documentation, and other ICT.

Section 508 does not, on its own, apply to state and local governments, school districts, private businesses, or nonprofits. It affects companies as sellers: because agencies must procure conforming ICT, vendors are asked to show that the products and services they offer to agencies conform. A company's own internal systems are not covered merely because it sells to the federal government. Some states have modeled their own ICT accessibility laws or policies on Section 508, but those are state laws with their own scope.

Even where Section 508 does not control, the federal Section 508 program maintained by the U.S. General Services Administration publishes detailed free procurement guidance. It walks through determining requirements, market research, solicitation language, requesting vendor information, evaluating proposals, and validating conformance after award, and it offers an Accessibility Requirements Tool, a Solicitation Review Tool, and sample contract language. A school district or nonprofit can borrow this structure while substituting the standard that actually applies to it. Using these tools is a choice. It does not make federal procedures legally binding on an organization that is not otherwise subject to them.

Define Users and Essential Tasks

Requirements are easier to write and to evaluate when the organization knows who will use the product and what they must accomplish with it. A student information system has parents, students, teachers, and office staff. A human resources platform has applicants, employees, managers, and administrators. Each group has tasks it cannot avoid, such as submitting an application, completing an assignment, viewing a paycheck, or paying a bill.

Listing these essential tasks turns a general goal into something that can be checked, and shows where the risk is. A barrier on a rarely used settings screen matters less than a barrier on the login page or a form every user must complete.

This is also where accessibility and accommodation separate. Accessibility is built into the product for everyone. Accommodation is an individual adjustment for one person, often after a barrier has appeared. Accommodation remains essential, but relying on it alone means solving the same barrier repeatedly, one person at a time. Choosing an accessible product reduces how often individual workarounds are needed.

Write Accessibility Into the Requirements

A requirement that a product "must be ADA compliant" gives vendors nothing specific to respond to and evaluators nothing to measure. Useful requirements name a standard, a version, and a conformance level, and say what they cover.

For web content and software this usually means WCAG at Level AA, in the version required by the applicable law or policy. For a Title II entity, WCAG 2.1 Level AA is the regulatory requirement. Many organizations target WCAG 2.2 Level AA, which the World Wide Web Consortium (W3C) describes as backward compatible with WCAG 2.1 and which adds criteria on keyboard focus, pointer targets, and accessible login. Where a law or contract names WCAG 2.1, the W3C notes that the one WCAG 2.1 criterion removed from WCAG 2.2 may still need to be tested and reported. For documents and non-web software, the W3C's WCAG2ICT, an informative Group Note, explains how WCAG applies. WCAG 3 is still a working draft and should not be written into requirements as a standard.

Requirements should state what is in scope, such as the public interface, administrative screens, mobile apps, generated documents, notifications, and any content the vendor will create. They can require accessibility documentation with the response and exclude it from page limits so vendors are not forced to shorten it. Whether the vehicle is a request for proposals, a request for quotation, a bid specification, or a purchasing checklist, the test is the same: two evaluators reading the same response should reach the same conclusion about whether the requirement was met.

Market Research and Vendor Documentation

Market research, before the solicitation is issued, is the best time to learn whether accessible options exist. Asking several vendors for accessibility information early shows which products are strongest, which vendors understand the subject, and whether draft requirements are realistic. Useful questions include which platforms and versions are supported, whether a current conformance report exists for the version offered, whether there is an accessibility roadmap with dates for known gaps, and how customer-reported problems are handled. Peer organizations can often share what they learned from testing the same products.

The solicitation should then say exactly what to submit. For commercial products the usual document is an Accessibility Conformance Report based on the Voluntary Product Accessibility Template, covering the exact product and version offered and stating its date, the standard used, and the evaluation methods. For important purchases, organizations often also ask for a description of known limitations and their effect on users, remediation plans with dates, a named accessibility contact, and, for platforms that people will use to create content, a demonstration that accessible content can be produced. For custom development, the equivalent is a description of how the vendor will build and test for accessibility. A response that describes limitations honestly is usually more useful than one claiming full conformance without explanation.

Evaluate Accessibility as Part of Selection

Accessibility documentation accomplishes little if it does not affect the decision. Accessibility should be evaluated alongside functionality, security, and cost, by people who know what to look for.

Organizations use different methods. Some treat complete accessibility documentation as a pass or fail requirement. Others score accessibility as a weighted factor or use it to decide between otherwise close offers. Guidance for federal agencies describes both pass or fail and trade-off approaches, and it raises a question every buyer faces: how much more, if anything, it is willing to pay for a more accessible product. The Title II rule sets a conformance standard but does not prescribe how bids are scored; how factors are set and weighted is governed by each organization's own procurement rules and policies.

Whatever the method, barriers in essential, high-frequency, or high-consequence tasks should weigh more heavily than barriers in rarely used features. A product with a few documented gaps and a credible remediation plan may be a better choice than one that claims full support but fails a basic check. Comparing products on the same tasks, by the same method, keeps the evaluation fair.

Test Before You Buy

A vendor's report is the vendor's own account of its product, so checking the claims that matter most before selection is one of the most useful steps a buyer can take. Guidance for federal agencies calls for validating accessibility claims whether a product is commercial, open source, or custom built.

Testing during procurement does not have to be a full audit. A structured check of the essential tasks reveals a great deal: completing them with the keyboard alone, confirming that focus is visible, listening to key screens with a screen reader, enlarging the page, and running an automated checker for common technical issues. A solicitation can reserve the right to test a demonstration or trial account for this purpose. For what each method can and cannot find, see Accessibility Testing and Evaluation.

Include People Who Use Assistive Technology

A product can look compliant on paper and still create real barriers for the people expected to use it. Standards describe what content must do, but people experience a product through their own assistive technology and ways of working. Including people with disabilities in the evaluation, where practical, shows how the essential tasks actually go.

Screen reader users need controls that are announced correctly and a logical reading order. People using magnification need layouts that reflow and stay readable when enlarged. Keyboard-only users need every function to be reachable, with visible focus and no traps. Switch users, whose access usually depends on keyboard-style navigation or scanning, are affected by long navigation sequences, time limits, and pointer-only controls. Voice input users need each control's visible label to match the name assistive technology receives, so that a spoken command using that label works. People using alternative pointing devices benefit from larger targets and alternatives to precise dragging. Where a product depends on spoken interaction, such as a voice-only phone menu, people who use augmentative and alternative communication (AAC) may need another way to complete the task. Login steps, puzzle tests such as CAPTCHAs, and verification codes deserve particular attention, because a barrier there blocks everything behind it.

User testing complements standards-based evaluation; it does not replace it. The W3C advises combining user involvement with conformance evaluation and cautions against assuming that one person's experience represents all users with disabilities. A trial to inform a purchase is also different from an individual assistive technology assessment for one person, although each can inform the other.

Contract Terms That Support Accessibility

The contract turns expectations into commitments, and once it is signed the buyer's leverage usually drops until renewal. Contract language should be developed with the organization's procurement office and legal counsel, because appropriate terms depend on the law, the product, the organization's purchasing rules, and the market. The topics below are common considerations, not model language.

Common provisions name the applicable standard, version, and conformance level; require that accessibility be maintained through updates and new releases, not only at delivery; require disclosure of known accessibility defects; set expectations and timelines for correcting defects, often by severity; require cooperation with the buyer's testing; require updated accessibility documentation after major releases; and address regression, including repair or replacement of nonconforming items. Sample language published for federal agencies, for example, provides that installation, configuration, maintenance, and hosting services must not reduce an existing level of conformance. Contracts can also set out how accessibility problems are reported to the vendor, how quickly the vendor responds, and who tracks each issue.

Acceptance Testing

Acceptance is the point at which the organization confirms that what was delivered matches what was promised. Where possible, accessibility should be checked before final acceptance along with functionality. Guidance for federal agencies describes reserving the right to test before acceptance and requiring remediation where the product does not match the vendor's conformance claims.

Discrepancies are common and do not always mean bad faith. The delivered version may differ from the one in the report, configuration may change how a feature behaves, or a claim may have been optimistic. What matters is finding differences between the vendor's claims, the report, and the product's actual behavior while correction can still be required, and recording the findings and agreed fixes.

Implementation Can Create or Remove Barriers

Buying an accessible product does not guarantee an accessible result. Implementation decisions can preserve accessibility or undo it.

Configuration affects color contrast, themes, time limits, and which features are enabled. Integrations can introduce barriers through single sign-on pages, embedded third-party components, chat tools, and payment processors. Templates, forms, and documents created in the product are the organization's own content and need to be accessible too. Training staff who create content, keeping help materials and support channels usable, and making sure users know how to report a barrier all help keep accessibility from eroding. Implementation is also the time to plan how an accessible alternative will be provided quickly if a barrier appears.

Monitoring, Updates, and Renewal

Most technology keeps changing after it is bought. Cloud software updates continuously, browsers and operating systems change, and vendors add features. Each change can fix problems or introduce new ones.

Monitoring can be simple: periodic checks of the essential tasks, requesting updated reports when versions change, tracking promised remediation, and listening to users. Guidance for federal agencies calls for retesting when products are updated during a contract, which is a sensible rule for any buyer. Feedback from people who use assistive technology is often the earliest warning that something has changed.

Every renewal is a chance to raise expectations. Before renewing, an organization can review the vendor's record on accessibility commitments, compare alternatives, and add terms that were missing the first time. The same reconsideration applies at a major version change, when use expands to a new group, or when a product is being replaced. A system acceptable for a small staff group may not be acceptable once students or the public must use it. For public entities, contracts renewing before the Title II compliance dates are especially important opportunities.

When No Fully Accessible Product Is Available

Sometimes no available product fully meets the requirements. The rules for that situation depend on which law applies, and one law's exception framework should not be assumed to apply to another.

For federal agencies, the Revised Section 508 Standards allow an agency to procure the product that best meets the standards, consistent with its business needs, when conforming products are not commercially available. They also limit the requirement to the extent that conformance would impose an undue burden or fundamentally alter the nature of the ICT. In both cases the agency must document the basis for its decision in writing and provide access to the information and data by an alternative means. These provisions belong to Section 508 and are not a general rule for other buyers.

For public entities, the Title II web rule has no best meets provision and no separate exception for buying an inaccessible product because nothing better is on the market. It requires compliance unless the entity can demonstrate that compliance would fundamentally alter a service, program, or activity or impose undue financial and administrative burdens. That decision must be made by the head of the entity or a designee, after considering all resources available, with a written statement of the reasons, and the entity must still comply to the extent it can without such an alteration or burden and take other steps to ensure that people with disabilities receive its benefits or services to the maximum extent possible.

The Title II rule separately allows conforming alternate versions only where technical or legal limitations prevent content from being made directly accessible, permits alternative designs that provide substantially equivalent or greater accessibility, and, in limited circumstances, treats an entity as compliant where it can show that nonconformance has so minimal an impact that people with disabilities can still use the content with substantially equivalent ease.

For other organizations, Section 504, Title I, Title III, and state laws each have their own frameworks, which should not be assumed to match either of these. Whatever law applies, good practice is similar: choose the most accessible option that meets the need, obtain the vendor's commitment to fix identified gaps, plan how people will get equivalent access in the meantime, and revisit the decision at renewal. Outside the specific provisions that allow them, an alternative way to get information or complete a task is a mitigation, not a substitute for an accessible product.

Document Procurement Decisions

Documentation connects the stages of the process. A useful record shows which requirements applied, what market research found, what the vendor represented, how accessibility was evaluated and tested, which gaps were accepted and why, what remediation was promised, and what alternative access was planned.

Some laws require specific documentation, such as the written statements described in the previous section. Beyond those requirements, a record is good practice: it supports accountability if a decision is questioned, gives staff who inherit a system what they need to monitor it, and shows at renewal whether the vendor kept its commitments.

A Practical Procurement Workflow

Before the solicitation, identify users and essential tasks, confirm which requirements apply, include accessibility in market research, and write requirements that name a standard, version, and level.

During selection, request current accessibility documentation for the exact version offered, evaluate it as seriously as other requirements, test the essential tasks, include people who use assistive technology where practical, and document the reasons for the choice.

At contract and delivery, write accessibility commitments into the agreement, including maintenance through updates and a process for fixing defects, and check accessibility before final acceptance.

After purchase, implement the product accessibly, train staff who create content in it, provide a clear way to report barriers, retest after significant changes, track remediation, and reconsider accessibility at every renewal, upgrade, and replacement.

Smaller purchases deserve attention in proportion to their use. Many barriers enter through tools adopted outside the formal process, such as software bought on a purchasing card or a free application adopted by one office. Guidance for federal agencies notes that small agency purchases remain subject to Section 508, and the same principle is sound practice for any organization.

Related AssistiveTechnology.org Resources

For how the Department of Justice rule applies to public entities, see ADA Title II Digital Accessibility for State and Local Governments, and for the K-12 context, see ADA Title II Digital Accessibility for Public Schools. For how employers encounter these questions, see Digital Accessibility for Employers. For how vendor accessibility reports work and how to read them, see VPAT and Accessibility Conformance Reports. For how accessibility is evaluated in practice, see Accessibility Testing and Evaluation. For what the guidelines are and how conformance levels work, see WCAG Overview, and for how WCAG relates to specific United States laws, see WCAG vs ADA vs Section 508. For documents in every format, see Accessible Documents. For a general orientation to the subject, see Digital Accessibility, and for further reading across topics, see Resources.

Request accessibility services

Authoritative Sources

U.S. Department of Justice: 28 CFR part 35, subpart H, Web and Mobile Accessibility, sections 35.200 through 35.205; the interim final rule extending the compliance dates, 91 FR 20902, April 20, 2026; the Fact Sheet on the rule; and First Steps Toward Complying with the Title II Web and Mobile Application Accessibility Rule, including its discussion of vendors and contracts.

U.S. Department of Justice: Guidance on Web Accessibility and the ADA, March 18, 2022, for the Department's position on businesses open to the public.

U.S. Equal Employment Opportunity Commission: Enforcement Guidance on Reasonable Accommodation and Undue Hardship under the ADA.

U.S. Department of Health and Human Services: interim final rule extending the Section 504 web and mobile accessibility compliance dates for recipients of Departmental financial assistance, 45 CFR part 84, 91 FR 25496, May 11, 2026.

U.S. General Services Administration, federal Section 508 program: guidance on buying accessible products and services, including the Accessibility Requirements Tool, requesting accessibility information from vendors, defining accessibility criteria in contracts, evaluating proposals and validating conformance after award, Section 508 exceptions, and micro-purchases; and its summaries of Section 508 applicability and state-level accessibility laws and policies.

U.S. Access Board: Revised Section 508 Standards, including E101.2 equivalent facilitation, E202.4 federal contracts, E202.6 undue burden or fundamental alteration, E202.7 best meets, and the incorporation of WCAG 2.0 Level A and Level AA.

World Wide Web Consortium: Web Content Accessibility Guidelines (WCAG) 2.1 and 2.2, W3C Recommendations; WCAG2ICT, W3C Group Note; the WCAG 3 introduction; and Involving Users in Evaluating Web Accessibility.

Last Regulatory Review

Last regulatory review: September 24, 2026. On that date the Title II compliance dates, population thresholds, technical standard, vendor and third-party content provisions, exceptions, and fundamental alteration and undue burden procedure described on this page were verified against the current text of 28 CFR part 35 and current Department of Justice publications. The Section 504 compliance dates for recipients of Department of Health and Human Services financial assistance, the scope of Section 508, the Revised Section 508 Standards exceptions, and the federal Section 508 program guidance were verified against current federal sources.

About This Page

This page provides general educational information about accessible procurement of information and communication technology. It is prepared by The Accessibility Clinic Inc. as educational information only. VPAT is a registered service mark of the Information Technology Industry Council. This page is not legal advice, it does not provide contract language for any particular purchase, and it does not guarantee that any product, website, application, or document meets a particular standard or legal requirement. Obligations differ by type of organization and jurisdiction. Organizations should evaluate their own obligations in light of their specific circumstances and consult their procurement office and qualified counsel when needed. Regulations change; the last regulatory review date above indicates when the statements on this page were most recently verified against primary sources.