Completing a VPAT (aka: ACR)

I recently went about completing my first Voluntary Product Accessibility Template (VPAT) and wanted to write down a few notes on what I experienced.

Screenshot of the Table 1 Success Criteria page in the VPAT

If you want to test your hand at what about the WCAG success criteria you know without having to look it up, this is a great way to quiz yourself in the context of a real example. 

First Steps:

  • I downloaded and read the whole thing
  • copy-pasted the instructions into a new Word doc so I could reference it easily and focus on the final product being its own thing
  • filled out the title page
  • removed sections that did not apply to the product I was filling it out for

Things I learned:

  • The easiest way to complete one is by first having some form of accessibility audit done on the platform to help address and break down problem areas
  • In the VPAT instructions, it says to break out a product into multiple reports that cover similar functionality if the product is too large or too complex for one report. However, some advice I was given from those who have completed and used them to audit products as a customer advises against this.
  • Once you fill it out, it needs to be submitted and tested to verify the criteria
  • You can use this as a living document to organize and push forward with making enhancements with your product team
  • If you ever reference on your site or in RFP's that you used a VPAT, you need to include the registered trademark to meet minimum compliance
  • The final format of the report must also be accessible
  • a "VPAT" is a specific format of Accessibility Conformance Report, but they are essentially the same thing

Where I got a little lost:

  • I had to reach out to the IAAP forum for advice on how to complete the Remarks and Explanations column. My options seemed to be: 1) complete the whole report tables for each page/URL of the site, or 2) reference the URL's within the Remarks and Explanations section when speaking to the conformance level.
  • I wasn't quite sure how detailed the Remarks & Explanations section was supposed to get, or if custom additions to the report were allowed. The instructions and format all seem incredibly strict, so I was worried about adding something to clarify certain functionality and becoming out of compliance with the format.

One report or multiple

Given the task of completing a VPAT for a vast, and multi-purpose browser-based software, I was immediately overwhelmed with how to approach it.

Looking at the site index, this would be upwards of 80-100 individual pages that would need to be documented and currently vary widely in any level of accessibility. So right off the bat, I know that the majority of the pages in the platform would be marked as "Not Supported."

Over this summer I was able to attend the AccessU virtual conference and made a point to join the VPAT topic. I actually asked, "Would we need to complete a full report per page in a platform of this size and complexity?" and the answer was essentially "yes." This seemed impossible, and there must have been a better way.

I posed the question on the IAAP discussion forum and got some great feedback. The overwhelming comment was the following:
  • Multiple reports for the same platform will be confusing and frustrating to sift through
  • Keep it in one report so they can clearly see the overall level of conformance for the platform
  • If you need to, include a legend or additional tables to point back to the details you'd need to elaborate on in the Remarks and Explanations section
  • The Remarks and Explanation section will get large if you need to specify detailed information in it, and that's ok.
  • If the product has several different focus areas of functionality, you can include those as their own section within the table to make it easier to reference and explain
  • If there's an overwhelming amount of information to document, you could recreate the VPAT into Excel and concatenate the data to generate a single VPAT
  • When certain criteria are "Partially Supported" or "Does Not Support" be as detailed as possible with specific locations of issues, who/how it impacts use, and what the plan is to address in the future
  • Appending additional reports, legends, or documentation to fully support the level of detail needed to assess liability is 100% acceptable and encouraged
All of this information really helped put in perspective the purpose of the report, how others have broken up the information to complete the report, and what the end-user of the report essentially expects when receiving one. Better yet, a sample of a well-done VPAT was provided for reference (which I had a very hard time finding on my own).

The strongest and most clear direction to take my next steps came from A.H. from the IAAP forum when they said, "Focus on the VPAT as a unified way to communicate the overall conformance levels and specific conformance limitations to your potential buyers, rather than a document where you're trying to line out every tiny detail of your conformance levels on a flow-by-flow or page-by-page basis."

Popular posts from this blog

Practice Site: Keyboard Accessible Tooltip Fail

Image
While reading about keyboard input methods and learning about the success criteria requiring custom keyboard instructions for any custom key commands, one method of accomplishing this was using a tool tip to present the instructions. It mentioned that the tooltip would have to be accessible via keyboard navigation and be able to be read by a screen reader. That reminded me that on my practice site, I spent a significant amount of time creating an example of success criteria for 3.1.3 to provide a definition of an unusual word when the user hovers over the text "affordance" displaying in a tooltip. I did not, however, make this accessible to keyboard-only users or screen readers. Turns out it wasn't even focusable until I gave it a tab index. More investigation into ARIA Practices for 3.24 Tooltip Widget call out specifically that the tooltip container requires role="tooltip" (which I did not have), and the element triggering the tooltip references the tooltip ...
Read more

Boiling the Ocean of Accessibility

Image
It can be daunting to look at an entire platform and be told, "Ok, now make it accessible." You don't need revolutionary planning, or exhaustive sprints to start. Including some accessibility work into regular sprint planning can offset any extra LOE, and you can start adding accessibility requirements right into each ticket. In a blog post for MediSked that I wrote in 2021, " Modular Accessibility for All Users ", I outline some easy ways to incorporate real accessibility into the SDLC, and start making progress to a completely accessible product as a whole. Some of the basics include: Using a third-party library of components that have accessibility built in. (Like Kendo UI for VUE or Deque Code Library )You'll still need to adjust and apply them right, but it will get you most of the way there. Include it in every ticket. Link to specific areas that apply to that ticket so engineers and testers know what to focus on. You can link right to the Deque chec...
Read more

Practice Site: Accessible Forms

Image
Today I finally bit the bullet and focused on creating a page on the practice site that would allow me to practice with form components, and live events based on actions. I have the basics down thanks to a friend of mine who walked me through the tools and resources that would be best for this very specific scenario and wrote the skeleton of the page that I could edit to make more accessible. She recommended using JQuery and JavaScript to avoid requiring a database or AJAX. Thanks to w3school.com for their amazing resources. My goal is to make the form fields clear on each submit, and post the data in a styled way on the page. I'd also like to make each submit speak a "success" message to alert the user of the new content, and of course, add labels to everything. Since this took the entire day, it will have to do for now. Luckily there are built-in focus states for the input and button elements by default. This was a productive day, but I may need to take a walk after ...
Read more