The page people look for when something breaks
When a resident cannot submit a form or a student cannot read a syllabus, they look for a way to tell you. If the only option is a generic contact page, the complaint goes nowhere, and you lose a chance to fix the barrier before it becomes a bigger problem.
An accessibility statement is that way in. A VPAT, or Voluntary Product Accessibility Template, is how you hold vendors to the same standard. Under Title II, both matter more than their length suggests.
On April 20, 2026, the Department of Justice extended the Title II web and mobile app compliance dates. State and local government entities with a total population of 50,000 or more now have until April 26, 2027. Entities under 50,000, and every special district government, now have until April 26, 2028. The technical standard did not change: WCAG 2.1 Level AA. Source: the DOJ interim final rule extending the Title II compliance dates (91 FR 20902).
What a good accessibility statement includes
- Your commitment and standard. Name WCAG 2.1 Level AA.
- Known limitations. Be honest about what is not fixed yet and when you expect to fix it.
- A feedback channel. Email and phone at minimum, with a named team and a response time you can meet.
- Alternative access. How someone can get the information another way while a fix is in progress.
- A review date. When the statement was last updated.
What to leave out
Do not claim full conformance unless a named audit supports it. “We are committed to” plus a real plan is more credible than “fully compliant” without evidence.
Ask vendors for an ACR, then read it
A completed VPAT is called an Accessibility Conformance Report, or ACR. Ask every vendor whose product your users touch for one: calendars, forms, payment portals, learning tools, video platforms.
When it arrives, check:
- Which version of WCAG it reports against. You need 2.1 AA.
- The date. An ACR from four versions ago does not describe the product you are buying.
- “Partially supports” entries. These are the real list of problems.
- Who did the testing and how.
Write it into the contract
Ask counsel about contract language that requires conformance to WCAG 2.1 AA, a current ACR, and a remediation timeline for defects you find. This turns a sales document into an obligation.
Keep both documents alive
Review the statement at least yearly and after major releases. Re-request ACRs at renewal. Route feedback from the statement into the same backlog as your remediation work, so reports turn into fixes.
A hypothetical: a statement that does its job
Imagine a community college whose accessibility statement names WCAG 2.1 AA, lists two known issues with a target date for each, and gives an email and phone number staffed by a named office. A student reports that a scholarship application PDF cannot be read by their screen reader. The office sends an accessible version the same week and logs the issue for the remediation backlog. The barrier was real, but the student got what they needed, and the fix got scheduled.
Accessibility statement checklist
- Standard named: WCAG 2.1 Level AA.
- Scope stated: which sites and apps the statement covers.
- Known limitations listed, with target dates where you have them.
- Contact methods: at least email and phone, with a named team.
- A response time you actually meet.
- How to request content in another format.
- Last reviewed date.
- Linked from every page footer.
Reading an ACR: red flags
- It reports against an older WCAG version than 2.1.
- It is several years old or names an older product version.
- Every line says “supports” with no remarks.
- It does not say who tested or how.
- It covers only part of the product you are buying.
Common mistakes
- A contact that goes nowhere. A shared inbox nobody monitors turns a feedback channel into a liability.
- A conformance claim with no audit. “Fully compliant” invites scrutiny you may not be able to answer.
- A statement nobody updates. A review date from several years ago tells readers the commitment lapsed.
- ACRs filed and forgotten. The “partially supports” lines never reach the vendor or the backlog.
Frequently asked questions
Is an accessibility statement legally required under Title II?
Ask counsel about your specific obligations. Either way, it is a widely recommended practice and a practical feedback channel.
Should we publish our own VPAT?
VPATs were designed for products. Some institutions also document their website’s conformance in a VPAT-based report, but most publish an accessibility statement for their sites and request ACRs from vendors.
What if a vendor will not provide an ACR?
Treat that as a risk in procurement and ask how they test. Consider alternatives where you can.
Does a statement protect us from complaints?
No. It gives people a way to reach you and shows your plan. Fixing barriers is what matters.
Who should own the accessibility statement?
A named office with authority to route issues, often IT accessibility, disability services, or communications, working with the web team.
Should known issues be public?
Listing known limitations with a plan is a common practice and helps people find alternatives. Review the wording with counsel.
How quickly should we respond to a reported barrier?
Set a response time you can meet and publish it. Acknowledge quickly and offer an alternative format while the fix is scheduled.
Next step
The KWALL Accessibility & Compliance program page lists VPAT support, with an updated VPAT and accessibility statement, among its deliverables. If you need a statement or want help reading vendor ACRs, tell us what you are working on.
