How can we help you?

Stark’s VPAT automation gives you a credible starting point, not a finished artifact. This guide walks through how to turn a Stark-generated draft into a truthful, defensible VPAT you can confidently share with customers, procurement teams, or federal agencies.

The work Stark completed for you

When you generate a VPAT draft in Stark, our platform has already:

Run automated Accessibility testing

Stark evaluates your product against WCAG [2.2] A & AA success criteria using automated rules. This produces:

• Pass/fail counts per criterion
• Initial conformance levels (Supports / Partially Supports)
• Machine-generated remarks tied to detected issues

This data populates the WCAG tables you see in your draft automatically.

Structured the VPAT correctly

Stark outputs a VPAT that:

• Follows VPAT® 2.4Rev formatting
• Includes correct WCAG versioning
• Uses standard conformance terminology
• Is suitable for enterprise and public-sector review

This eliminates formatting errors and structural rework.

Scoped the report to what was tested

The draft reflects:

• What was scanned
• What criteria were evaluated
• Where automation can and cannot determine conformance

The great news is you’re not starting from a blank document or an opinion-based assessment!

What the draft intentionally leaves for you

The remaining blanks and “Needs Review” sections exist for a reason. They mark human, legal, and organizational accountability—areas software cannot truthfully assert on your behalf.

Below is how to interpret and complete each one:

Step 1: Fill in product & ownership details

These sections establish who stands behind the VPAT.

Fields you must complete

• Contact Information → Name, role, email for accessibility or compliance inquiries
• Notes → Scope clarifications, known limitations, or usage assumptions

Step 2: Confirm evaluation methods (and be honest)

Your draft currently states:

“Evaluation Methods Used: Stark Tooling – Automated Testing”

This is accurate—but incomplete for a final VPAT unless automation is truly the only method used.

You need to clarify if you also did:

• Manual QA?
• Screen reader testing?
• Design or content reviews?

If yes → add those methods explicitly.

If no → leave it as-is, but be prepared to explain the scope.

Step 3: Review every “Blank” success criterion

Empty rows in the WCAG tables do not mean failure. They mean:

“This criterion cannot be automatically evaluated.”

Common examples include:

• Captions (live or prerecorded)
• Audio descriptions
• Keyboard behavior across complex flows
• Error handling and messaging
• Authentication flows

What do you do in this situation? For each blank row, given the above:

1. Decide whether the criterion applies to your product
2. Assign one of:
   • Supports
   • Partially Supports
   • Not Applicable
3. Add a short, plain-language explanation

Step 4: Resolve “Needs Review” items

You’ll see entries like:

Needs Review – indeterminate issues

These indicate places where automation flagged uncertainty—often related to:

• Visual meaning
• Sensory instructions
• Contextual relationships

You (and your team) are responsible to:

• Manually inspect those areas
• Decide the final conformance level
• Update the remarks to reflect human judgment

This step is essential for credibility.

Step 5: Validate “Partially Supports” Claims

Where Stark reports failures (e.g., contrast, focus order, parsing), you must decide:

• Are these issues known and accepted?
• Are they in progress?
• Are they out of scope for this release?

Then reflect that reality in the remarks.

Step 6: Review the Legal Disclaimer

The legal disclaimer is intentionally generic. Best practice is to:

• Replace it with your company’s standard VPAT disclaimer
• Or have legal approve the default text before shipping

Step 7: Final check before shipping

Before sending the VPAT externally, confirm:

• All placeholders are filled
• Every WCAG row has a conformance value
• Remarks are accurate and defensible
• The scope matches the product version named
• The date reflects the evaluation window

How to position this externally

Utilization of the VPAT is a requirement making itself known in the sales funnel more frequently, in the same light as privacy and security documentation. With that, give tips to your sales team. In order for them to not just sell but establish a foundationally healthy customer relationship, there are baseline tasks that need to be brought over the line. Providing them with a strong and honest VPAT...

• Builds trust with procurement
• Speeds up security + accessibility review
• Signals operational maturity

Anyone on the sales team can position it as:

“Here’s a transparent snapshot of our current accessibility posture which is monitored and actioned on — proactively and continuously.”