Evaluate your software platform against WCAG 2.1 Level A & AA standards, track conformance levels, and export a standardized Accessibility Conformance Report for enterprise and government procurement.
Work through the 28 WCAG 2.1 Level A and AA criteria one at a time. Each one is explained in plain language, so you can mark it Supports, Partial, Does not support or Not applicable, add the evidence, and export a finished ACR. Nothing you leave unanswered is reported as a pass.
Everything runs in your browser and saves to this device only. Nothing is uploaded, so you can draft a report before talking to anyone. Budget 30 to 60 minutes if you have to check the product as you go. Skip to the checklist.
These five fields become the header of the exported ACR. You can change them later.
Each card explains the criterion in plain language and shows how to check it. Supports means it fully meets the criterion. Partial means it mostly does, with gaps you can describe. Does not support means it fails today. Not applicable means the criterion cannot apply to your product. Anything you skip stays "not assessed".
On a phone this list opens on one pillar at a time. Use the pillar buttons above to move between them, or choose All pillars to see all 28 criteria.
Showing 28 of 28 criteria.
Every image, icon, chart and logo needs a short text description, unless it is purely decorative.
Inspect the code for descriptive alt attributes on img tags and aria-label or title on inline SVGs. Decorative images must use alt="".
If you publish audio-only files, link a full transcript. If you publish silent video, provide a described version.
Verify that standalone audio files have full text transcripts linked nearby and that video clips have descriptive audio or text summaries.
Any video with sound needs captions that match the speech and the important background sounds.
Check embedded video players for accurate open or closed caption tracks (.vtt files) synchronized with dialogue and sound effects.
Headings, lists, form labels and data tables must be marked up in code, not just styled to look like headings and tables.
Ensure headings use sequential h1 to h6 tags, form inputs have matching label elements, and data tables use th with scope attributes.
The order of elements in the code must match the order a person reads on screen.
Test in a screen reader or disable CSS to confirm DOM order matches the logical reading order.
Never use color alone to carry meaning. Add text, an icon or a pattern.
Check form validation errors, charts and link states. Ensure icons, underlines or text labels accompany color coding.
Body text needs a contrast ratio of at least 4.5 to 1 against its background. Large text needs 3 to 1.
Use a contrast checker on body text and headings against their real background colors, in every theme you ship.
Zooming text to 200 percent must not cut off, overlap or hide content.
Zoom the browser to 200 percent text zoom. Verify no text overlaps, truncated words or hidden content boxes.
At 320 pixels wide, which is a phone at 400 percent zoom, content must reflow into one column without sideways scrolling.
Set browser width to 1280px at 400 percent zoom, the 320px equivalent, and check that no horizontal scrollbar appears.
Buttons, input borders, focus rings and meaningful icons need at least 3 to 1 contrast against their surroundings.
Verify border contrast of inputs, radio buttons, checkboxes, custom focus rings and active button icons.
Every action must be possible with a keyboard alone. Nothing should require a mouse.
Navigate the whole interface using only Tab, Shift+Tab, Enter, Space and the arrow keys.
If the keyboard can move focus into a component, it must also be able to move focus back out.
Test modals, date pickers, dropdown menus and custom widgets. Escape or Tab must exit the component.
Add a skip link so keyboard users can jump past the repeated header and menu.
Press Tab immediately on page load and confirm a visible skip to main content link appears first.
Tab order must follow the visible layout, moving top to bottom and left to right.
Tab through the page and confirm focus moves in an order that matches the visual layout.
Link text must make sense on its own. "Read more" and "Click here" are not enough.
Review every link. Replace generic text with descriptive anchor text or an aria-label that explains the destination.
Every heading and field label must say clearly what the section or the field is for.
Review section headings and form labels. Each one should give distinct, clear context on its own.
A visible outline must show where keyboard focus is, and it must never be removed with outline: none.
Tab through the interface and confirm every focused element has an obvious visible indicator.
If a button shows the text "Submit form", its accessible name must contain those same words.
Compare visible button text with the accessible name. Voice control users speak the visible label.
Declare the page language in the html tag so screen readers pronounce content with the right rules.
Check the root html element for a valid lang attribute, for example lang="en".
Moving focus onto an element must not trigger a surprise, such as submitting a form or opening a new page.
Tab through inputs and buttons. Focus should never submit forms, launch popups or redirect.
Changing a setting must not submit the form or navigate away without telling the user first.
Selecting a radio button or checkbox should not redirect the page without an explicit submit action.
When a form field fails, say in text which field failed and what went wrong, and tie that message to the field.
Submit an incomplete form. Errors must be listed in text and linked to their inputs with aria-describedby.
Tell people what a field needs before they type, including any required format such as MM/DD/YYYY.
Ensure required fields state formatting rules in visible labels or accessible helper text.
When a fix is possible, tell people how to correct the error, not just that it happened.
Verify invalid email or date entries get specific correction advice, not only an error flag.
For payments, legal agreements or deleted data, give people a review or confirmation step before the action is final.
Test checkout, account deletion and other irreversible flows for a review, confirmation or undo step.
Markup must be valid: no unclosed tags, no duplicate id values, and no broken nesting.
Run the HTML validator and confirm there are no duplicate ids or unclosed elements.
Custom widgets such as tabs, modals and accordions must expose their name, role and state to assistive technology.
Inspect custom components for appropriate ARIA roles such as role="dialog" and state such as aria-expanded.
Messages such as "Saved" or "3 results found" must be announced to screen readers without moving focus.
Check toasts, alerts and result counts for role="status" or aria-live="polite".
The report below is generated from your answers. Incomplete criteria are exported as "Not assessed" so nobody mistakes them for a pass.
28 criteria still have no level. They are exported as "Not assessed". Buyers usually treat an incomplete report as a failure, so finish them before sending it. .
# Accessibility Conformance Report (VPAT 2.4, WCAG Edition)
**Name of product:** [Product name]
**Version:** [version]
**Vendor:** [Vendor]
**Report date:** 2026-11-09
**Contact:** [contact email]
**Standard:** WCAG 2.1 Level A and Level AA
**Criteria assessed:** 0 of 28
> This report is incomplete. 28 of 28 criteria have no conformance level and are listed as "Not assessed". They must not be presented as conformant.
**Not yet assessed:**
- WCAG 1.1.1 Non-text Content
- WCAG 1.2.1 Audio-only and Video-only (Prerecorded)
- WCAG 1.2.2 Captions (Prerecorded)
- WCAG 1.3.1 Info and Relationships
- WCAG 1.3.2 Meaningful Sequence
- WCAG 1.4.1 Use of Color
- WCAG 1.4.3 Contrast (Minimum)
- WCAG 1.4.4 Resize Text
- WCAG 1.4.10 Reflow
- WCAG 1.4.11 Non-text Contrast
- WCAG 2.1.1 Keyboard Operability
- WCAG 2.1.2 No Keyboard Trap
- WCAG 2.4.1 Bypass Blocks
- WCAG 2.4.3 Focus Order
- WCAG 2.4.4 Link Purpose (In Context)
- WCAG 2.4.6 Headings and Labels
- WCAG 2.4.7 Focus Visible
- WCAG 2.5.3 Label in Name
- WCAG 3.1.1 Language of Page
- WCAG 3.2.1 On Focus
- WCAG 3.2.2 On Input
- WCAG 3.3.1 Error Identification
- WCAG 3.3.2 Labels or Instructions
- WCAG 3.3.3 Error Suggestion
- WCAG 3.3.4 Error Prevention (Legal, Financial, Data)
- WCAG 4.1.1 Parsing
- WCAG 4.1.2 Name, Role, Value
- WCAG 4.1.3 Status Messages
## Conformance summary
| Result | Criteria |
| :--- | :--- |
| Supports | 0 |
| Supports with Exceptions | 0 |
| Does Not Support | 0 |
| Not Applicable | 0 |
| Not assessed | 28 |
## Table 1: WCAG 2.1 Level A and AA success criteria
| Criteria | Level | Conformance | Remarks and explanations |
| :--- | :--- | :--- | :--- |
| WCAG 1.1.1 Non-text Content | A | Not assessed | No remarks provided. |
| WCAG 1.2.1 Audio-only and Video-only (Prerecorded) | A | Not assessed | No remarks provided. |
| WCAG 1.2.2 Captions (Prerecorded) | A | Not assessed | No remarks provided. |
| WCAG 1.3.1 Info and Relationships | A | Not assessed | No remarks provided. |
| WCAG 1.3.2 Meaningful Sequence | A | Not assessed | No remarks provided. |
| WCAG 1.4.1 Use of Color | A | Not assessed | No remarks provided. |
| WCAG 1.4.3 Contrast (Minimum) | AA | Not assessed | No remarks provided. |
| WCAG 1.4.4 Resize Text | AA | Not assessed | No remarks provided. |
| WCAG 1.4.10 Reflow | AA | Not assessed | No remarks provided. |
| WCAG 1.4.11 Non-text Contrast | AA | Not assessed | No remarks provided. |
| WCAG 2.1.1 Keyboard Operability | A | Not assessed | No remarks provided. |
| WCAG 2.1.2 No Keyboard Trap | A | Not assessed | No remarks provided. |
| WCAG 2.4.1 Bypass Blocks | A | Not assessed | No remarks provided. |
| WCAG 2.4.3 Focus Order | A | Not assessed | No remarks provided. |
| WCAG 2.4.4 Link Purpose (In Context) | A | Not assessed | No remarks provided. |
| WCAG 2.4.6 Headings and Labels | AA | Not assessed | No remarks provided. |
| WCAG 2.4.7 Focus Visible | AA | Not assessed | No remarks provided. |
| WCAG 2.5.3 Label in Name | AA | Not assessed | No remarks provided. |
| WCAG 3.1.1 Language of Page | A | Not assessed | No remarks provided. |
| WCAG 3.2.1 On Focus | A | Not assessed | No remarks provided. |
| WCAG 3.2.2 On Input | A | Not assessed | No remarks provided. |
| WCAG 3.3.1 Error Identification | A | Not assessed | No remarks provided. |
| WCAG 3.3.2 Labels or Instructions | A | Not assessed | No remarks provided. |
| WCAG 3.3.3 Error Suggestion | AA | Not assessed | No remarks provided. |
| WCAG 3.3.4 Error Prevention (Legal, Financial, Data) | AA | Not assessed | No remarks provided. |
| WCAG 4.1.1 Parsing | A | Not assessed | No remarks provided. |
| WCAG 4.1.2 Name, Role, Value | A | Not assessed | No remarks provided. |
| WCAG 4.1.3 Status Messages | AA | Not assessed | No remarks provided. |
---
Generated with the Veduis VPAT 2.4 checklist (https://veduis.com/compliance-solutions/vpat-checklist-guide/). A self-issued ACR is a starting point, not a substitute for an independent audit where one is required.Compliance Note: This interactive self-assessment workbench provides technical guidance for authoring a self-issued Accessibility Conformance Report (ACR). For high-stakes federal procurements, enterprise RFPs, or strict compliance audits requiring independent third-party certification, request our certified audit services below.
The Information Technology Industry Council (ITI) defines four official terms for reporting conformance in an Accessibility Conformance Report:
The functionality of the product has been verified to meet the success criterion without exceptions. Source code structures, ARIA attributes, and keyboard flows fully satisfy WCAG requirements.
Some functionality of the product does not fully meet the success criterion, but workarounds exist or only specific secondary modules are affected. Technical remarks must detail the exact exception.
The majority of product functionality fails the success criterion, or key user flows are blocked for assistive technology users. Remarks should detail remediation plans.
The success criterion does not apply to the product. For example, audio caption criteria on a web application that contains zero audio or video media.
Copy this pre-formatted GFM markdown table directly into your GitHub repository documentation or software release notes:
# Accessibility Conformance Report (VPAT® 2.4 Edition)
**Product Name:** [Your Product Name]
**Product Version:** [1.0.0]
**Report Date:** [YYYY-MM-DD]
**Contact Email:** [[email protected]]
**Evaluation Standard:** WCAG 2.1 Level A & Level AA
## Table 1: WCAG 2.1 Level A & AA Success Criteria
| Criteria | Conformance Level | Remarks and Explanations |
| :--- | :--- | :--- |
| **1.1.1 Non-text Content** (Level A) | Supports | All non-text UI elements have text equivalents or aria-labels. |
| **1.3.1 Info and Relationships** (Level A) | Supports | Page landmarks, form labels, and heading hierarchy are semantic. |
| **1.4.3 Contrast (Minimum)** (Level AA) | Supports | Body text maintains minimum 4.5:1 contrast ratio against background. |
| **2.1.1 Keyboard** (Level A) | Supports | All interactive components are navigable via keyboard interface. |
| **2.4.7 Focus Visible** (Level AA) | Supports | Visible outline focus rings are enforced across all controls. |
| **3.3.1 Error Identification** (Level A) | Supports | Form validation errors are described in text to screen readers. |
| **4.1.2 Name, Role, Value** (Level A) | Supports | Custom ARIA widgets expose correct roles, states, and properties. |Procurement officers for federal agencies (GSA, DoD, VA), state universities, and Fortune 500 enterprises review dozens of ACRs monthly. A common mistake SaaS founders make is submitting a self-authored VPAT that marks every single criterion as "Supports" without detailed technical remarks.
Procurement evaluators recognize blanket self-assessments as red flags. If a product claims full support without explaining how keyboard focus or screen reader parsing is handled, procurement teams routinely pause procurement or demand a certified third-party audit report.
We conduct manual and automated WCAG 2.1 AA audits and author certified, legally defensible VPAT 2.4 ACR reports for your procurement deals.
Clear answers to technical and procedural questions about VPAT 2.4 compliance and ACR authoring.
VPAT (Voluntary Product Accessibility Template) is the blank template document created by the Information Technology Industry Council (ITI). An ACR (Accessibility Conformance Report) is the completed report produced after auditing a specific software product against VPAT criteria.
There are four VPAT 2.4 editions: WCAG Edition (WCAG 2.1 Level A & AA for commercial/global SaaS), 508 Edition (US Federal agencies under Section 508), EU Edition (European Union under EN 301 549), and International Edition (combines all three standards).
For US Federal government procurement under Section 508 and state government / public higher-education institutions, a completed ACR is mandatory. Commercial enterprise procurement teams also require an ACR to verify vendor risk under ADA Title III.
Marking 'Supports with Exceptions' is normal and expected for real-world software. Procurement teams prefer honest exception reporting with clear remediation timelines over unverified claims of 100% compliance.
Yes, software teams can complete a self-issued ACR internally. However, for high-value government contracts or strict enterprise procurement, buyers frequently require an independent third-party audit to verify claims.
An ACR should be updated whenever a major software version is released, key UI components are redesigned, or new feature modules are added to the platform.
Our team conducts comprehensive WCAG 2.1 AA audits, fixes code-level violations, and authors official ACR documentation for your buyers.
Request Your Audit Package