VPAT Risk Triggers

Risk Trigger Matrix (Low / Moderate / High)

These are the most common, high-impact issues seen in WCAG, Section 508, and EN 301 549 reviews. Severity depends on whether the issue affects core workflows (login, forms, approvals, payments, uploads, reporting).

Risk Level	Common Criteria / Areas	Typical Trigger (Why it matters)
High	WCAG: 2.1.1, 1.3.1, 4.1.2, 3.3.1, 2.4.7, 4.1.3 508/549: software operability + functional performance; Clause 11 (Software)	Blocks independent use in key tasks (keyboard-only cannot operate, forms cannot be submitted, custom controls not announced, errors not announced, focus disappears/lost). Often equals “cannot complete workflow”.
Moderate	WCAG: 1.4.3, 1.4.10, 2.4.1, 2.4.4, 2.4.3, 2.2.1, 1.4.4 549: Clause 9 (Web) + Clause 12 (Documentation) partial gaps	Function exists but usability is degraded (contrast issues, reflow/zoom pain, missing skip links, poor focus order, timeouts without extend). Usually manageable with remediation plan or constraints/mitigations.
Low	WCAG: minor 1.1.1 alt edge cases, light structure inconsistencies, minor link text cleanup 508/549: cosmetic documentation issues that don’t block use	Non-blocking issues with limited workflow impact (cosmetic, low user harm, easy fixes). Still track, but typically not procurement-blocking.

High risk usually means: A user with a disability cannot complete a primary task independently.

Moderate risk usually means: Primary tasks can be done, but experience is degraded or inconsistent.

Quick scan criteria: 1.3.1 • 2.1.1 • 4.1.2 • 3.3.1 • 2.4.7 • 1.4.10 • 1.4.3 • 4.1.3 • 2.5.8 (2.2)

VPAT Credibility Risk Triggers

These triggers don’t prove the product is inaccessible — they indicate the report may not be reliable. Low credibility often requires vendor follow-up or an updated report.

Credibility Issue	Credibility Risk	What to Look For / Why it matters
Evaluation methods missing or vague	High	“Tested for accessibility” with no manual steps, AT, browsers, or scope = cannot validate claims.
Assistive tech not named	Moderate–High	“Screen readers were used” without specifying NVDA/JAWS/VoiceOver/TalkBack versions reduces confidence.
Browser/OS not listed	Moderate	Conformance depends on platform; missing info prevents replicability and scope clarity.
“All Supports” with thin remarks	High	Unrealistic; most complex products have some partial support. Indicates templated answers or lack of testing.
Blank rows in tables	High	Missing remarks = incomplete documentation; often signals the criterion wasn’t actually evaluated.
Too many “Not Applicable” entries	Moderate	Often misused instead of “Does Not Support”, especially for captions, keyboard, or forms.
Outdated report date	Moderate	If the product has changed significantly, the VPAT may not reflect current state.
Wrong terminology (“Pass/Fail”)	Moderate	Suggests the author isn’t familiar with VPAT conventions and may not be an accessibility specialist.
No remediation plan for PS/DNS	Moderate	Without a timeline, the “risk” remains open-ended; no ability to plan mitigations.

Credibility rule of thumb: If you can’t tell what was tested, how it was tested, and on which platforms, you can’t treat the VPAT as reliable evidence.

Immediate Escalation Triggers

If you see any of these, pause and request clarification or updated evidence.

Escalate immediately if:

Keyboard (2.1.1) fails in a core workflow
Forms are unusable (1.3.1 / 3.3.1 / 4.1.2)
Focus is invisible or lost (2.4.7) in primary navigation
VPAT is “all Supports” with generic or empty remarks
Evaluation methods omit manual + AT testing details

Escalate for follow-up if:

Too many “Not Applicable” entries for expected features
Report is old compared to product release cadence
“Partially Supports” lacks user impact explanation
EN 301 549 documentation/support clauses are missing where applicable

Print tip: Use “Save as PDF” for a shareable version.