Most pages on your site are trying to persuade. An accessibility statement is trying to disclose. That difference is why testimonials go wrong here more often than anywhere else — a marketing quote dropped into a compliance document reads as a company trying to talk its way past a problem it should be documenting.
But the page is not off-limits. Three very different people land on it, and two of them are asking a question your own prose cannot answer.
- A procurement officer checking whether your product will survive a VPAT review.
- A disabled user deciding whether it is worth signing up or whether they will hit a wall on day three.
- A lawyer or auditor looking for gaps between what you claim and what you shipped.
The lawyer wants nothing from you but accuracy. The other two want evidence that someone like them actually used the thing. That is what a testimonial is for, and it is why the placement question is worth getting right rather than avoiding.
The rule that governs every slot on this page
A testimonial on an accessibility statement may describe experience. It may never substitute for a conformance claim.
"Our customers say it's fully accessible" is not a WCAG conformance statement, and putting it near one implies it is. That is the failure mode auditors punish and disabled users resent. Keep the two registers physically and visually separate: conformance claims in the structured section, lived experience in a clearly labeled block below it.
If you only take one thing from this piece, take that.
Slot 1: below the conformance summary, not above it
The top of the page belongs to the facts: which standard, which level, which version, date of last audit, who performed it. Nothing goes above that. A quote in the hero position reads as deflection.
Directly under the summary, one short block works well:
"I use NVDA with Firefox for six hours a day. Setting up a workspace took me about ten minutes with no sighted help, and the table views announce column headers correctly — which is rare enough that I noticed." — Data analyst, public sector
Why this one works:
- It names the assistive technology and browser. "Screen reader user" is vague. "NVDA with Firefox" is checkable, and a reader who uses the same stack knows exactly how much weight to give it.
- It describes a task, not a feeling. "Setting up a workspace" is a specific flow that a prospect can map to their own job.
- It is bounded. It praises table headers. It does not claim the whole product is perfect, which would contradict the known-issues section further down the page.
That last point is the one teams skip. If your quote is more enthusiastic than your own conformance report, you have created a credibility gap on a page that exists to close one.
Slot 2: inside the known issues section, as context — not as cover
Every honest accessibility statement has a known-issues list. This is the most-read part of the page for a user with a disability, and the most dangerous place to put a testimonial.
Done wrong, it looks like burying the problem under a happy customer. Done right, it tells a reader how much the gap actually matters in practice:
"The legacy report builder is still keyboard-hostile and we avoid it. Everything we do day to day is in the new builder, which works fine. It's a real limitation, not a dealbreaker for our team." — Accessibility lead, insurance
The quote acknowledges the same issue you just disclosed. It does not deny it or soften it. Its only job is to supply the scope a prospect cannot infer from a one-line defect description.
Rules for this slot:
- The quote must reference the disclosed issue directly. A generic positive quote next to a defect list is spin.
- It must come from someone affected by that issue, not from an able-bodied administrator.
- If you do not have such a quote, leave the slot empty. This is the one page where an empty slot beats a weak fill.
For more on the general principle of pairing a testimonial with a limitation rather than against it, see why your testimonials sound fake and the edits that fix it.
Slot 3: next to the feedback and contact mechanism
Accessibility statements are required — under most frameworks and plainly by good practice — to tell users how to report a barrier. That block usually gets ignored because people assume nothing happens when they write in.
A quote about the response, not the product, fixes that:
"I reported a focus-trap bug in the date picker on a Tuesday. Someone replied the same day with a workaround and it shipped fixed about three weeks later. I didn't have to explain what a focus trap was." — Accessibility consultant
Three details do the work here: a specific bug class, a concrete timeline, and the sentence about not having to explain the vocabulary. That last one is the strongest signal on the entire page — it tells a reader your support staff are trained, which no amount of first-party copy can establish.
Slot 4: the procurement anchor, near the VPAT or conformance report link
Procurement readers come to this page for a document to hand to their own compliance team. Right where you link the VPAT or ACR, a quote from someone who has already run that gauntlet removes a perceived risk:
"Our accessibility review is a hard gate — three vendors failed it last year. Their ACR was current, filled out properly, and the two gaps it listed were the two gaps our own testers found. That matched, which is more than I can say for most." — Procurement manager, state agency
Note what is being praised: the document's accuracy, not the product's perfection. That is the highest-value claim available on this page, and it is only credible coming from a third party.
If you want the version of this argument for the page procurement lands on first, see where to place testimonials on a security page — the structure is nearly identical, because both pages are read defensively.
What never goes on this page
- "Fully accessible." Nobody is. A customer saying it in quotes does not make it true and does not protect you.
- Inspiration framing. Quotes that position a disabled user as inspiring rather than as a professional doing a job are condescending, and the people you are trying to reach will spot it instantly.
- Anonymous accessibility quotes. On other pages, "Director, Fortune 500" is acceptable shorthand. Here, a quote with no named assistive technology and no role is worthless — the specificity is the evidence.
- Carousels. An auto-rotating testimonial widget on an accessibility page is self-refuting. If you use more than one quote, stack them as static blocks.
- Quotes that outrank the disclosure. If your testimonial section is visually larger than your known-issues section, the page is doing the opposite of its job.
A layout that holds up
- Conformance summary — standard, level, date, auditor. No quotes.
- One short experience quote naming AT and browser.
- Scope of the statement — what is and is not covered.
- Known issues — with at most one contextual quote from an affected user, or none.
- Feedback mechanism — with one quote about response time.
- VPAT / ACR link — with one procurement quote about document accuracy.
- Date of last review and contact details.
Four quotes maximum on the whole page. Most companies should ship with two.
How to collect quotes like these
You will not get them from a generic NPS follow-up. The people who can speak credibly here are a small, identifiable group: customers who have contacted you about accessibility, customers whose procurement process included an accessibility review, and customers whose admin console shows heavy keyboard-only navigation.
Ask them directly, and ask for the specifics you need — which assistive technology, which browser, which task, how long it took. A general request produces a general quote, and a general quote is the one thing this page cannot use.
Related reading: how to ask for a testimonial after a successful product migration covers the same principle of asking a narrow question to get a usable answer.