I read VPATs the way some people read a used car’s service history. Not because I enjoy it. Because the document quietly tells you whether the thing you’re about to buy is going to leave you stranded on the side of the road at the worst possible moment.
For an independent hotelier, the worst possible moment looks like a demand letter from a law firm you’ve never heard of, claiming a guest who uses a screen reader couldn’t complete a reservation on your site. And here’s the part that makes me grind my teeth: the broken checkout usually isn’t your code. It’s your booking engine vendor’s code. But you’re the hotel the guest was trying to book, so the exposure lands on you anyway.
So before I let a client sign with any booking engine, metasearch widget, or “book now” plugin, I ask one boring question: can I see your current VPAT? What comes back, and how it’s written, tells me almost everything.
What a VPAT actually is (and what it isn’t)
VPAT stands for Voluntary Product Accessibility Template. It’s a standardized document a software vendor fills out to describe how well their product meets accessibility standards, usually the Web Content Accessibility Guidelines (WCAG).
Two words in that name matter more than the rest. Voluntary, and self-reported. Nobody audits a VPAT before it’s published. The vendor writes it about their own product. That doesn’t make it worthless. A company that takes the time to produce an honest, detailed VPAT is showing you something about how seriously they treat accessibility. But it does mean you read it like a sales document with useful technical content buried inside, not like a certificate of safety.
Here’s my one-line mental model:
A VPAT is the vendor telling you, in their own words, where their product helps disabled guests and where it gets in the way. Your job is to find the gaps they admitted to, and then test for the ones they didn’t.
The conformance levels, decoded
The heart of any VPAT is a set of tables mapping individual WCAG “success criteria” to a conformance rating. There are only a handful of ratings, and once you know them, you can skim a 40-page document in ten minutes.
| Rating | What it really means | How I react |
|---|---|---|
| Supports | The product meets this criterion. | Good. Move on. |
| Partially Supports | Some of it works, some doesn’t. | Read the notes. This is where the truth hides. |
| Does Not Support | The product fails this criterion. | Stop. Is this on the booking path? |
| Not Applicable | This criterion doesn’t apply to the product. | Usually fine, but I sanity-check it. |
| Not Evaluated | They didn’t test it. | Red flag if it’s a Level A or AA item. |
Then there are the WCAG levels themselves: A, AA, and AAA. Level A is the floor, the most basic stuff. AAA is the aspirational ceiling almost nobody hits across the board. AA is the bar that matters. Most US web accessibility expectations point at WCAG Level AA, and it’s the practical standard I hold any booking engine to.
So when a vendor hands me a VPAT, the first thing I do is filter mentally to the Level A and Level AA rows and ask: how many of these say something other than “Supports”? A booking engine that’s mostly Supports at A and AA, with a few honest Partially Supports and clear notes, is a vendor I can work with. One that’s littered with Does Not Support and Not Evaluated on the rows that matter is a vendor whose lawsuit I’d be inheriting.
Which WCAG version are we even talking about?
Check the version on the cover. WCAG 2.0 is old. 2.1 added criteria that matter enormously for mobile and for guests with low vision or motor differences — things like reflow, pointer gestures, and target size. 2.2 went further. If a booking engine’s VPAT is still proudly reporting against WCAG 2.0 in 2026, that’s not a deal-breaker by itself, but it tells me the document is stale and the product probably is too. I want to see 2.1 AA at minimum, ideally 2.2.
The criteria I check first, because they’re where bookings break
I don’t read every row with equal attention. I go straight to the success criteria that, in my experience, actually stop a guest from completing a reservation. If these are weak, the rest of the VPAT is decoration.
- 1.3.1 Info and Relationships — are form fields, dates, and room options coded so a screen reader announces them correctly? A date picker that’s just a grid of unlabeled divs is a booking-killer.
- 2.1.1 Keyboard — can you complete the entire booking using only a keyboard, no mouse? Calendar widgets are the usual disaster here.
- 2.4.3 Focus Order — does the tab order move through the form in a sane sequence, or does it jump around the page?
- 3.3.1 / 3.3.2 Error Identification and Labels — when a guest forgets a field, is the error announced and tied to the right input, or does it just turn a box red?
- 4.1.2 Name, Role, Value — do custom components (those fancy room-type carousels) expose what they are to assistive tech, or are they invisible black boxes?
- 1.4.13 Content on Hover or Focus (2.1) — those “rate details” tooltips that vanish the second you move — can a keyboard or screen reader user actually read them?
If a VPAT rates those as Supports, I still test them live, but at least the vendor is claiming the right things. If they’re Partially Supports or worse, I want a specific, dated remediation note. “Planned for a future release” is not a date. I’ve watched “future release” mean three years.
Red flags that mean keep shopping
Over enough procurement calls, you start to see the same tells. Here’s what makes me close the PDF and email the next vendor on my list.
1. The VPAT has no date, or it’s years old. Software changes constantly. A VPAT from 2021 describing a product that’s shipped 200 updates since is fiction. I want one dated within the last 12 to 18 months.
2. Everything says “Supports.” A perfectly clean VPAT with zero gaps across hundreds of criteria isn’t impressive — it’s suspicious. Real products have rough edges. A VPAT that admits none of them usually means nobody actually tested; somebody just typed “Supports” down the whole column.
3. The remarks column is empty. The conformance rating is half the value. The notes are the other half. “Partially Supports” with no explanation is useless. I need to know what partially works so I can judge whether it’s on the booking path.
4. Booking-critical criteria are marked Not Evaluated. If a vendor didn’t bother testing keyboard operation (2.1.1) on a product whose entire job is taking keyboard-and-card reservations, that tells me where accessibility sits on their priority list.
5. They can’t produce a VPAT at all. Not “we’ll send it over” followed by silence. If a booking engine company in 2026 has never created one, they have likely never seriously thought about whether disabled guests can book with them. That’s the whole risk in one data point.
6. The VPAT covers a different product than the one you’re buying. Vendors sometimes hand you the VPAT for their flagship platform when you’re buying the lightweight embedded widget. Different code, different gaps. Confirm it covers the exact component that will live on your site.
A booking engine’s VPAT is the closest thing you’ll get to a vendor putting their accessibility claims in writing. If they won’t put it in writing, assume the answer is no.
Why this is squarely an SEO and conversion problem, not just a legal one
You might be wondering why an SEO shop is this deep in compliance docs. Two reasons, and they’re both about money you can actually see.
First, an inaccessible booking engine leaks direct bookings. Every guest who can’t finish your form is a guest who either gives up or bounces to an OTA listing that they can navigate — and now you’re paying that 15–25% commission for a booking you could have taken yourself. Accessibility is conversion-rate optimization wearing a lawyer’s suit. It’s the same fight I’m always having on the book-direct side: keep more of your demand on your own site instead of feeding the OTA mix. (If the OTA-versus-direct math is fuzzy, I broke it down in this post on commission cost.)
Second, the technical hygiene that makes a page accessible — proper headings, labeled controls, sane structure, real semantic markup — is a huge overlap with what makes a page legible to search crawlers and to AI answer engines. Clean, well-structured booking flows are easier for everyone to parse, including Google and the LLMs now sending people to hotels. I think about this constantly on the technical hotel SEO work and the AI visibility work, because the same semantic discipline pays off in three places at once: humans, crawlers, and assistive tech.
So no, vetting a VPAT isn’t a side quest. It’s me protecting the direct-booking funnel I’m hired to grow, while also keeping a demand letter off your desk. Reducing OTA dependence and shipping an accessible site are the same project viewed from two angles.
My actual procurement checklist
Here’s the short version I run on every booking engine, metasearch widget, or checkout vendor before a client signs. Steal it.
- Ask for the VPAT before the demo, not after. How fast and cleanly they respond is itself a signal.
- Confirm it covers the exact product/component going on the site, and that it’s dated within ~18 months.
- Check the standard: WCAG 2.1 AA at minimum, 2.2 preferred.
- Filter to Level A and AA rows. Count the non-”Supports” ratings.
- Read every Partially Supports note on the booking-critical criteria above.
- Don’t trust the document alone — test the live flow. I tab through a real booking with the mouse unplugged and run a screen reader. The VPAT says what the vendor believes; the live test says what’s true.
- Get remediation commitments in writing, with dates, for any gap on the booking path.
That last point is where I earn my keep. A VPAT gap isn’t automatically disqualifying — most products have a few. The question is whether the vendor will fix the ones that touch the reservation, and whether they’ll commit to it in the contract. A vendor who says “yes, that calendar keyboard issue is real, here’s our Q2 fix and it’s in the MSA” is more trustworthy to me than one with a suspiciously perfect VPAT and no willingness to commit to anything.
Where this fits in the bigger trust picture
Accessibility is one leg of a stool. The other legs are the trust signals search engines and AI assistants now weigh heavily — accurate business information, real reviews, consistent NAP data, and a site that loads and behaves predictably. I treat all of it as one body of work under content and reputation, because a guest (or an AI summarizing your hotel) doesn’t separate “can I book this place” from “can I trust this place.” They’re the same judgment.
If you’re standing at the procurement table right now, staring at a booking engine contract and a VPAT you’re not sure how to read, that’s exactly the moment to get a second set of eyes on it. Send me the VPAT and the live booking URL. I’ll tell you where the gaps are, which ones will actually cost you bookings or invite a complaint, and what to make the vendor commit to before you sign. Book a working session and let’s read it together — better to catch the inherited lawsuit on the page than in your inbox.