VPAT for software
Desktop applications, web applications, and products made of several parts.
"Software" in an ACR covers more than a web page, and the edition you choose changes which chapters you have to answer. A desktop application and a browser-based one are evaluated against overlapping but different requirements.
Which chapters apply
In the Revised Section 508 edition, the chapters are the structure of the document:
| Chapter | Applies to |
|---|---|
| Chapter 3 — Functional Performance Criteria | Everything. Outcome-level requirements, used where the technical criteria do not resolve a question. |
| Chapter 4 — Hardware | Only if you ship physical hardware. Most software vendors mark this not applicable. |
| Chapter 5 — Software | Installed and platform software: your desktop app, your installer, your CLI. |
| Chapter 6 — Support Documentation and Services | Your docs, your help centre, your support channels. Frequently forgotten, and frequently the weakest section. |
WCAG criteria apply to web content, and also to any software user interface reached through a browser. A desktop application additionally has to answer the Chapter 5 requirements about platform accessibility services — that it exposes its UI to the operating system's accessibility APIs rather than drawing controls a screen reader cannot see.
Products made of several parts
Most software is not one thing. A typical product has a web console, an installed agent or desktop client, an API, and documentation. Decide early whether you are producing one ACR covering the suite or separate ones per component.
Separate documents are usually better: they let you scope each one honestly and revise them on different schedules. One document covering a suite tends to average out into statements that are true of nothing in particular.
Do not forget the documentation
Chapter 6 asks whether your support documentation is itself accessible and whether it describes your product's accessibility features. If your docs are PDFs generated from a design tool, that section is probably where your worst findings are. It is also the cheapest to fix.
For the web-delivered parts of your product
We scan your product's public pages, collect the evidence, and hand back a draft ACR in the ITI structure: detected failures with the rule and the markup that triggered them, and a specific question for every criterion a machine cannot judge. Your reviewer makes the calls and signs it. $299 per product, or $249/month to have it re-run every quarter and on release.
Our automated pass covers web-delivered interfaces. For an installed desktop client we can cover its web components and flag the rest for your reviewer, but we will not pretend to have tested a native binary.