User-facing accessibility claims audit
Issue #3293 (Risk L1, part of epic #3292).
Why
A converted PDF, or an ACR/VPAT/report marked “compliant” that isn’t, could expose a customer to a lawsuit — and they’d blame the tool. Every user-facing claim about the accessibility of a produced document, or of a product’s own output, must stay hedged and defensible: “passed our automated checks”, “no automated issues detected”, “built to WCAG 2.1 AA”. It must never state, unqualified, that a document is accessible / is compliant / meets WCAG / is WCAG 2.1 AA certified.
This follows the existing precedent set by PassedChecksBanner and the
“passed our automated checks” language already used on the file-detail page and in
the forms audit verdict dialog.
Policy (going forward)
- Report verdicts and success banners: “All automated checks passed. No WCAG
issues were detected by our automated checks. Manual review is still recommended to confirm conformance.” — never “This document meets WCAG requirements.” - Score interpretation (100%): “Passed all automated checks … not a guarantee of full conformance” — never “Fully compliant”.
- Marketing / product taglines: “built to WCAG 2.1 AA” — never “meets WCAG 2.1 AA”, “WCAG 2.1 AA certified”, or “fully accessible”.
- The word “accessible” as a product/process descriptor (“convert to an accessible layout”, “Accessible HTML output”) is fine — it names the product category, it is not a per-document conformance verdict.
- Industry-standard machine-verifier output (“Compliant with PDF/UA-1” bound to a veraPDF result) and standard VPAT terms (“Supports” / “Fully Supports”) are factual reports of a deterministic checker and remain acceptable.
Claims audit table
Legend: Changed = over-strong claim hedged. Acceptable = reviewed, left as-is.
| File | Claim (before) | Action |
|---|---|---|
apps/web/src/lib/report-utils.ts | ”This document meets WCAG {level} requirements.” (conformance report success banner) | Changed → “No WCAG {level} issues were detected by our automated checks. Manual review is still recommended…” |
apps/web/src/components/wizard/WizardStepUrlResults.tsx | ”This page meets WCAG {level} requirements.” | Changed → hedged (same) |
apps/web/src/components/dashboard/FlyerChoiceDialog.tsx | ”…so this counts as fully accessible.” (silenced-decorative-label note) | Changed → “…so this passes our automated checks.” |
apps/web/src/components/lti/CourseStats.tsx | Score-band label “fully accessible” + aria-label (100% files) | Changed → “passed all checks” / “passed all automated checks” |
apps/web/content/guides/wcag-reports.md | ”100% — Fully compliant.” | Changed → “100% — Passed all automated checks … not a guarantee of full conformance” |
apps/admin/src/lib/report-utils.ts | (mirror of web) | Changed → hedged |
apps/admin/src/components/wizard/WizardStepUrlResults.tsx | (mirror of web) | Changed → hedged |
apps/admin/src/components/dashboard/FlyerChoiceDialog.tsx | (mirror of web) | Changed → hedged |
apps/admin/src/components/lti/CourseStats.tsx | (mirror of web) | Changed → hedged |
apps/admin/content/guides/wcag-reports.md | (mirror of web) | Changed → hedged |
apps/web/src/data/guides.ts, apps/admin/src/data/guides.ts | build-generated from the guide .md above | Regenerated via generate-guides.mjs |
apps/audit/src/lib/utils.ts | ”This document meets WCAG {level} requirements.” (audit report banner) | Changed → hedged |
apps/remediate/src/lib/utils.ts | ”This document meets WCAG {level} requirements.” (report HTML) | Changed → hedged |
apps/remediate/src/components/ComplianceReport.tsx | ”This document meets WCAG {level} requirements.” | Changed → hedged |
apps/org-chart/src/app/(marketing)/page.tsx | ”Every output meets WCAG 2.1 Level AA.” | Changed → “built to target WCAG 2.1 Level AA, with built-in axe-core auditing” |
apps/org-chart/src/app/layout.tsx (OG description) | “…org chart that meets WCAG 2.1 AA…” | Changed → “…built to WCAG 2.1 AA…” |
apps/org-chart/locales/en.json (wcagDesc) | “Every output meets WCAG 2.1 Level AA.” | Changed → hedged (matches marketing page) |
packages/accessible-org-ui/src/products.ts (orgchart) | “…org chart that meets WCAG 2.1 AA…” | Changed → “…built to WCAG 2.1 AA…” |
packages/accessible-org-ui/src/products.ts (links) | “…link-in-bio page that meets WCAG 2.1 AA…” | Changed → “…built to WCAG 2.1 AA…” |
apps/links/src/app/page.tsx | ”WCAG 2.1 AA certified” + “Every … element meets WCAG 2.1 AA” | Changed → “Built to WCAG 2.1 AA” + “is built to WCAG 2.1 AA” |
apps/links/locales/en.json (hero subheadline) | “…page that meets WCAG 2.1 AA…” | Changed → “…page built to WCAG 2.1 AA…” |
apps/links/src/components/ui/AccessibilityBadge.tsx | aria-label “This page meets WCAG 2.1 Level AA…” | Changed → “…is built to WCAG 2.1 Level AA…” |
apps/forms/src/locales/en.json + apps/forms/src/lib/strings.ts (pdfHtml subtitle) | “fully accessible … with WCAG 2.1 AA compliance” | Changed → “functional HTML forms built to WCAG 2.1 AA” |
apps/forms/src/lib/strings.ts (formDetect.fallbackNotice) | “It is still fully accessible” | Changed → “It still passes our automated checks” |
apps/web/src/data/faqs.ts / content/faqs.md (“Is the output truly WCAG compliant?”) | Answer: “validated against WCAG 2.1 AA … auto-fix common issues … flag anything requiring manual review” | Acceptable — already hedged, does not claim output is compliant |
apps/web/src/app/landing/sample-report/page.tsx | ”…flagged for your review, not certified accessible” | Acceptable — already hedged |
workers/api/src/services/audit-report-renderer.ts | ”Compliant with PDF/UA-1” (bound to vera.passed) | Acceptable — factual report of the veraPDF machine verifier, not our own claim |
workers/api/src/services/acr-report-renderer.ts (line ~267) | “Color & contrast — text meets WCAG AA contrast ratios (4.5:1 …)” | Acceptable — describes what the check category tests, not a document verdict |
apps/vpat/locales/en.json (grade names: “Fully Accessible” / “Accessible” / …) | A–F grading-rubric tier names for an audited artifact | Acceptable — an explicit scored rubric (letter grade), not an unqualified guarantee; renaming tiers is a product decision beyond this pass |
apps/org-chart/src/app/(marketing)/legal/accessibility/page.tsx | ”The review interface is fully accessible.” | Acceptable — self-assessment inside our own accessibility statement about our own UI, standard practice |
| Various toasts/labels: “convert to an accessible layout”, “Accessible HTML”, “accessible fillable PDF” | product/process descriptors | Acceptable — names the product category, not a per-document conformance verdict |
| Code comments containing “guaranteed” / “is accessible by construction” (workers, packages) | internal engineering notes | Acceptable — not user-facing; per repo convention internal docs/comments are left alone |
Out of scope (human / legal step)
The issue also asks to “get a ToS liability disclaimer reviewed.” That is a
legal/human task, not a code change — no disclaimer text was written or invented here.
When it is drafted, the natural homes for it are the products’ Terms of Service and the
per-product accessibility statement pages (e.g. apps/org-chart/src/app/(marketing)/legal/accessibility/page.tsx),
and optionally a short footer note on the downloadable conformance report templates
(report-utils.ts / audit + remediate utils.ts). Flagging only — no legal text added.