Support

How can we help you?

Get answers to all your Stark-related questions with
step-by-step guides from our Support center.

Using VPAT Report Generator

Automatically generate a VPAT based on your asset's latest report data


Using your latest report data, Stark can make the creation and completion of your VPAT (Voluntary Product Accessibility Template) reports quick and easy. Let's dive into how Stark creates the VPAT, what you'll need to fill out, and some best practices. 


Getting Started

Before generating your VPAT, let's go through a few things to ensure you're set up for success.

  1. Ensure you've selected your WCAG Version and Conformance Level - Go to Team Settings, scroll down to Project Specific Settings and then select your team's preferred WCAG Version and Conformance Level. The default is WCAG 2.2 AA.
  2. Verify your project name and description - Both items will be used for titling and describing your VPAT, so it's worth verifying they match the project's intent. From the sidebar, select the project from the list. At the top left, click Edit and then Edit Details.
  3. Make sure you have recent scan data - Good news: if you're using Stark, we take care of this for you. If you make tweaks after running the export, click the Scan Now button for the associated asset to flect your updates in the VPAT report.

Running the Report

Generating a VPAT can only be done within a URL asset.

  1. From the project page, select your URL asset.
  2. On the report breakdown page shown, click Generate VPAT in the top-right corner.
  3. A .docx file will be generated and downloaded to your computer.

Understanding the Report

Now that your report is generated, we can walk through all the parts and pieces of it.

Preliminary Info

Before getting to the actual report data, there's quite a bit of info explaining the document and how to read it.

  1. Title page - This will show the title of the report (your Project's title), its description, the WCAG version and conformance level it was run against, and the report the date was run.
  2. Report metadata page - Includes the same info above, but Stark helpfully calls out things to fill out such as contact information and evaluation methods used.
  3. Applicable standards page - Automatically filled out based on your WCAG version and conformance level selection.
  4. Terms page - How to read the report's terms for each of the criteria which we breakdown in the next section.

Reporting Data

This section is automatically filled out using your latest reporting data. That being said, it's worth reviewing for accuracy as Stark cannot currently check all of the criteria through automation. The following is a breakdown of how Stark evaluates the criteria:

  1. Supports - 100% passing with no violations or potential violations found.
  2. Partially supports - a mix of passing and violations were found.
  3. Needs review - potential violations found and should be reviewed.
  4. Does not support - Violations found with no checks passing.
  5. Empty/blank - There were no passing, violations, or potential violations found which means no automated checks were run against this criteria. Should be manually verified. 

Best Practices

VPAT's are, ultimately, voluntary and can be completed in numerous ways. Here are some best practices we recommend for accurate and easy to digest VPAT reports:

  1. Find sensible ways to split up your product/application and generate VPATs against those different project areas. If your product is large, doing a VPAT against the entire thing can draw out the process, and make the reports quite cumbersome.
  2. Initiate VPAT generation as close to the time you plan to do the manual testing as possible. Stark's VPAT generator takes the very latest scan results when it creates the report, so you want to make sure you have the latest changes you’ve made to your product.
  3. Don't skimp on details. If you find issues when doing your audit, don’t be shy about calling them out in the report. It’s always best to put them in the report rather than have them discovered later by a user. Even better if you can include a ticket reference as well, so people know you’ve already begun the process of addressing the issue.

Go back to articles