Most compliance questions in a technology purchase arrive through the funding: accept federal money and conditions follow it. Accessibility is not one of those. It attaches to a state or local government entity because of what the entity is, not because of where the money came from, and it reaches the work whether or not a contractor does it.
That makes it a procurement question rather than a design preference. If a supplier builds you a website, a portal or a mobile app under this contract, the obligation lands on your organization the day it goes live, and the only place to have dealt with it is the order.
What the obligation is
In April 2024 the Department of Justice issued a final rule revising the regulation that implements title II of the Americans with Disabilities Act. The rule sets a technical standard for the web content and mobile applications that state and local government entities offer to the public. Its text is published as 28 CFR part 35 in the Federal Register, and it is worth reading rather than taking second hand.
Three things in it matter for a purchase.
The standard is named. The rule requires conformance to WCAG 2.1 Level AA, the W3C's Web Content Accessibility Guidelines. That is a specific document with testable success criteria, not a general instruction to be accessible, and it is the version the rule incorporates. A specification that asks for a later or an earlier version is asking for something else.
The dates are fixed and they are close. The rule states that a public entity with a total population of 50,000 or more begins complying on 24 April 2026, and that an entity below that population, or any public entity that is a special district government, begins complying on 26 April 2027. Which of those applies to a particular organization, and whether it is a special district, is a determination for that organization and its counsel rather than for a supplier.
There are exceptions, and they are narrower than people hope. The rule sets out five: archived web content; preexisting conventional electronic documents, unless they are currently used to apply for or participate in services; content posted by a third party, unless that party posts under a contractual, licensing or other arrangement with the entity; individualized documents about a person or their account that are password protected; and preexisting social media posts. Separate limitations for fundamental alteration and undue burdens sit at section 35.204. None of this is a general escape, and the third exception is the one buyers most often misread.
What it means in practice
The rule reaches content the entity provides or makes available directly or through contractual, licensing, or other arrangements. That phrase recurs through the text, and it is the sentence that puts accessibility into a purchase order.
Read against the exception for third-party content, it produces a result worth being clear about. Content someone posts on your platform of their own accord is generally excepted. Content a vendor produces or hosts for you under a contract is not, because the vendor is posting under exactly the kind of arrangement the exception carves out. A site built by a supplier, a payments portal operated by one, an app published under your name: the rule treats all of them as yours.
So the practical consequences run to the specification rather than to the technology.
- The standard belongs in the scope, named and versioned, not in a covering email as an aspiration.
- It applies to what is delivered and to what is subsequently operated, which are frequently two different suppliers.
- Documents count. A conforming site that publishes board agendas as untagged scans has moved the problem rather than solved it.
- It reaches procurement of a thing already built, not just of bespoke work. Buying a platform commits you to its accessibility as surely as commissioning one does.
One consequence deserves stating on its own, because it changes what a purchase is for. The obligation is not confined to work commissioned from now on. Content already published and still in use is in scope by the compliance date, which means an organization with an ageing site is not choosing between a redesign and doing nothing; it is choosing between remediating what it has and replacing it. That is a budget conversation worth having before a supplier frames it, and it is the reason an accessibility requirement in a scope is often really a question about how much of the existing estate comes with the project.
Where federal money is also involved, other conditions attach on top and they attach for a different reason; those are covered in the terms a federally funded purchase brings with it. The two sets are independent, and satisfying one says nothing about the other.
Who is accountable
The rule is explicit, and it is the part most likely to surprise a buyer who assumed the risk had been passed along. The Department states that public entities have a responsibility to comply with their obligations even when their services, programs or activities are being offered through contractors.
Accountability, in other words, does not move with the work. A contract can allocate effort, cost and remedy between the parties, and it should. What it cannot do is make somebody else the entity responsible for the public's access to a public service.
That has a design consequence for the order. Requiring the supplier to indemnify you is not the same as requiring the supplier to deliver something conforming, and only the second reduces the chance of a complaint. Both are reasonable to ask for. Only one of them is about accessibility.
Inside your organization, name the person who signs off that the requirement was met. It is rarely the project sponsor and it is rarely the supplier's counterpart; somewhere in a public body there is usually a person who already answers complaints about access, and they are the right signature. Where the ordering documents are issued and who approves them is covered in how a requirement becomes an order.
How to evidence it
Suppliers document accessibility in a conformance report, often produced on the Voluntary Product Accessibility Template and titled an Accessibility Conformance Report. Ask for one. Then read it properly, because a report is evidence only in proportion to what it actually says.
- Which standard, and which version. A report written against Revised Section 508, which incorporates WCAG 2.0 AA, is a real document that does not by itself evidence the 2.1 Level AA conformance this rule requires. The federal policy landscape those standards come from is set out at Section508.gov. Version is the single most common gap between what is supplied and what is needed.
- Whether it is dated, and by whom. A conformance report with no date, no named evaluation method and no product version is a description rather than an assessment. Those elements are ordinary parts of the template and their absence is informative.
- What the entries actually say. Criterion-level answers usually read Supports, Partially Supports or Does Not Support. A report that is mostly "Partially Supports" is being honest, and it is also telling you there is work outstanding. Read the remarks column, which is where the exceptions live.
- What was not evaluated. Anything a report declines to assess is not covered by it.
- What happens to the gaps. Where a report is candid about shortfalls, ask for the remediation plan as a schedule: which criteria, by when, verified how. "We will address any issues identified" commits a supplier to nothing and gives you nothing to hold them to.
Then stop treating the report as the end of the matter, because it describes a product and you are buying an outcome. Put conformance in the acceptance test: what will be checked, against which criteria, by whom, and what happens if it fails. That is the same discipline any written deliverable needs, and it is covered in how a requirement becomes something you can accept. An accessibility clause with no acceptance step is a promise, and promises are not testable.
Finally, test something yourself before you sign it off. Keyboard-only navigation of the two or three journeys the public actually uses, checked by a person rather than a scanner, finds more in twenty minutes than a report does in forty pages. Automated tools are useful and they do not decide conformance.
Where this sits in the purchase
None of this is exotic drafting. It is a named standard with its version, applied to what is delivered and to what is operated, with an acceptance test, a named sign-off and a remediation route if the test fails. Written into the order it costs a paragraph; discovered after go-live it costs a rebuild, and by then the obligation is already the buyer's.
LABUSA publishes an accessibility conformance report for its IT augmentation services, which is the kind of document this page is telling you to ask any supplier for and to read closely. What LABUSA provides, and the roles a build is staffed from, is described on the arrangement LABUSA delivers this work through. This page is general information about a regulation and not legal advice; how the rule applies to a particular organization is a question for that organization and its counsel. If you have a build or a platform purchase coming and want the requirement written properly, you are welcome to send us the scope you are working from.