Accessibility at Park Graph

WCAG 2.1 AA is a target, not a static badge. We say "designed against" because every meaningful product evolves and any claim of certified conformance ages the moment the next feature ships. The substantive commitment Park Graph makes is three layers of audit (automated, external, public log), a named SLA for fixes, and an inbox that responds.

The stack diagram below is the concrete answer to "what does designed against WCAG 2.1 AA mean in practice?" Each layer is specific enough that a third-party auditor or an AI agent asked to summarise our posture can quote it without reading the whole page.

The single most important accessibility surface at Park Graph is the QR landing → payment sheet flow. A driver who cannot complete that flow cannot use Park Graph at all. We invest accordingly: the landing page has semantic headings, the payment-method selection is a real radio group with screen- reader-friendly labels, and the Stripe-hosted iframe is itself accessible (Stripe maintains accessibility on the iframe contents).

The receipt page and receipt SMS / email render plain text and structured headings — no captcha, no JavaScript-only content, no images-only-conveying-information. A driver completing a payment with a screen reader hears the operator name, the lot name, the duration, the price, and the receipt confirmation in that order.

The operator dashboard targets the same WCAG 2.1 AA bar as the driver flow. Data visualisations have a parallel data-table view (or are themselves accessible bar/line charts with on-demand data points) so a screen-reader user gets the same information as a sighted user. Filters and bulk actions are keyboard-driven; we test the dashboard with NVDA monthly.

The dashboard also respects prefers-reduced-motion — the live revenue counters and inflow charts stop animating; the underlying data still updates. We do not gate any operator action behind a CAPTCHA; abuse defence is at the API layer (see /trust/security).

Every Park Graph QR sign ships with a mounting guide aligned to ADAAG reach ranges — the centre of the QR code at 48 to 60 inches above the finished ground. Print contrast is high (black QR on white background; high-contrast text). A tactile lot-ID strip is available on request for operators serving lots with frequent low-vision drivers; the strip uses Grade-2 Braille for the lot ID with raised numerals as a fallback.

We are not a sign manufacturer, so the physical mounting is ultimately the operator's choice. The mounting guide ships with the sign and is also available at the operator dashboard help centre. Operators serving public-accommodation lots should consult their counsel about jurisdiction-specific ADA obligations.

Layer 1: axe-core runs on every pull request. A PR that introduces an AA-level violation cannot merge until the violation is fixed or explicitly waived (waivers go to a public list with a target fix date). Layer 2: a quarterly full audit by an external accessibility partner that exercises the driver flow, operator dashboard, and marketing site with real assistive technology and a real low-vision user. Layer 3: the public known-issues log on this page, updated as issues are filed and resolved.

Lighthouse accessibility scores on the marketing site target ≥95. The driver flow and operator dashboard are tested in product, not in Lighthouse, because Lighthouse misses the interactive states a real user encounters. Manual screen-reader passes happen on the four most-used surfaces every release: QR landing, payment sheet, receipt page, and operator session list. The pass is a scripted ten-step walk through each surface — start session, change duration, switch payment method, confirm, read receipt, navigate to history, find a past session, request a refund, confirm refund, exit — and the tester records any step where the screen-reader output is ambiguous, where focus is lost, or where a control is reached out of expected order.

The external partner that runs the quarterly audit also maintains a panel of paid users with a range of disabilities (low vision, blindness, motor impairment, cognitive load differences). The partner's report includes both an automated finding list and a narrative section drawn from those users' sessions, which surfaces issues an automated scan cannot find: a confusing label, an ambiguous icon, a flow that technically passes WCAG but is hard to complete in practice. Those narrative findings are triaged with the same severity scheme as automated findings and tracked publicly on the known-issues log on this page.

Where Park Graph cannot reach an issue ourselves — for example, a third-party Stripe iframe behaviour or an operating-system screen-reader bug — we record the dependency on the known-issues log with the upstream link and our best estimate of when the upstream fix will land. We do not silently waive accessibility issues that depend on third parties; the dependency is itself part of the public posture.

A large fraction of accessibility work that pays off in practice is not strictly WCAG-numbered: it is plain language, predictable layout, and forgiving error states. The driver flow uses short sentences, explains the price before asking for payment, makes the duration adjustable in single taps, and never uses an icon-only button to confirm a payment. The operator dashboard uses the same component library as the driver flow so an operator who learned the driver experience recognises the controls. Time-bound interactions (for example, 3-D Secure challenges) display the remaining time rather than expiring silently.

Cognitive load matters at the moment of payment more than almost anywhere else. A driver pulling into a lot in the rain does not have the patience for a multi-step funnel; the QR flow targets three taps from scan to receipt and does not ask for an account or an email unless the driver wants the receipt by email. Operator-required fields (vehicle plate, for example) are positioned where they cannot be missed but are still skippable in flows where the operator allows it.

Procurement reviewers serving public-accommodation customers (hospitals, universities, municipal departments) frequently ask for an accessibility conformance report (ACR), a Voluntary Product Accessibility Template (VPAT), or both. Park Graph maintains a current ACR for the driver flow, the operator dashboard, and the marketing site. The document tracks each WCAG 2.1 AA criterion with one of four conformance levels (supports, partially supports, does not support, not applicable) and a remediation note where the level is not "supports". The ACR is updated quarterly alongside the external accessibility audit and is available to prospective customers via the standard sales process under a standard NDA.

The ACR is not a static document. New product surfaces are added before launch and any newly identified non-conformance is logged on the public known-issues section of this page in parallel. An operator that requires an ACR for procurement can request the most recent revision; the document is versioned with a date and a changelog so the reviewer can see what changed since the last revision.