How to read a VPAT

A VPAT can run to thirty pages of tables, but you only need a few parts of it to judge a product. This guide walks through a completed VPAT in the order you should read it.

First, check you have the right document

A VPAT (Voluntary Product Accessibility Template) is a form. What you want is the form filled in by the vendor, which is properly called an Accessibility Conformance Report, or ACR. Most people call both a VPAT.

Make sure you have not been sent an accessibility statement instead. A statement says the vendor cares about accessibility. A VPAT reports on each requirement, one row at a time. If there are no tables with a conformance level on every row, it is not a VPAT.

1. Read the front page

The first page tells you whether the rest is worth trusting. Look for five things:

• Report date. Software changes constantly. A report more than a year old may describe a product that no longer exists in that form.
• Product name and version. Check it matches what you are buying. A report for the web app says nothing about the mobile app.
• Evaluation methods. This says how the product was tested. Testing with assistive technology such as screen readers, by people who use it, is the strongest sign. “Internal review” with no detail is the weakest.
• Standards covered. Which version of WCAG, and whether Section 508 or the European standard EN 301 549 is included.
• Contact details. You will need someone to send questions to.

2. Find the WCAG tables

The heart of the document is the WCAG tables. WCAG, the Web Content Accessibility Guidelines, sorts its requirements into three levels:

Read Level A first, then Level AA. For WCAG 2.1 that is 50 requirements in total; for WCAG 2.2 it is 55.

3. Read each row across

Every row has three cells:

• Criteria. The requirement, with a number such as 1.4.3 and a name such as “Contrast (Minimum)”.
• Conformance level. The vendor’s claim: Supports, Partially Supports, Does Not Support, Not Applicable or Not Evaluated.
• Remarks and explanations. The vendor’s own words about the claim. This is where the useful detail is.

Do not stop at the middle column. A row marked “Supports” whose remarks say “except in the reporting module” is really a partial failure.

4. Look for the warning signs

• Every row says Supports, with no remarks. Almost no real product meets every requirement. A perfect, unexplained report usually means nobody tested carefully.
• Many rows say Not Applicable with no reason. “Not Applicable” is correct for captions if the product has no video. It needs explaining if the product clearly does.
• Requirements are missing. If the report covers WCAG 2.0 and you need 2.1, twelve Level A and AA requirements are simply absent.
• The same vague remark is pasted on many rows. It suggests the form was filled in without testing each requirement.

5. Decide what to do

List every row that is not a clean “Supports”. For each one, ask the vendor what is affected, when it will be fixed, and what your users can do until then. Weigh Level A failures most heavily, because they block people outright.

Remember what a VPAT is: the vendor’s own account of its product. It is a starting point for questions, not proof that the product is accessible.