We want every employee to be able to answer a pulse honestly, and every admin to run the product, regardless of how they see, hear, move, or navigate. This statement records the standard we hold ourselves to, where we stand against it, and how to tell us when we fall short.
1 Our commitment
PulsePoint targets WCAG 2.1 Level AA across the marketing site, the admin app, and — most importantly — the employee survey-taking flow, where participation must never depend on a particular ability. Accessibility is treated as part of "done", not a later pass.
2 Conformance status
Tracked against the four WCAG principles. Supported = met across current screens; Partial = met in most places, gaps listed in §4.
| Principle / criterion | Status |
|---|---|
| Perceivable — text alternatives, non-text contrast, 1.4.3 contrast (min) AA | Supported |
| 1.4.1 Use of colour — status never conveyed by colour alone (icon + label) | Supported |
| 1.4.10 Reflow · 1.4.4 Resize text — responsive to 320px / 200% zoom | Supported |
| 1.1.1 Non-text content — chart / heatmap data-table fallbacks | Partial |
| Operable — 2.1.1 Keyboard, 2.4.7 Focus visible, 2.4.1 Bypass blocks | Supported |
| 2.3.3 Animation from interactions — honours prefers-reduced-motion | Supported |
| Understandable — 3.3.1 Error identification, 3.3.2 Labels/instructions | Supported |
| Robust — 4.1.2 Name/role/value, 1.3.1 Info & relationships (semantic landmarks, ARIA) | Supported |
| 4.1.3 Status messages — toast/aria-live coverage on all async actions | Partial |
3 What's in place today
- Keyboard-operable throughout — every interactive control is reachable and usable without a mouse, with a visible :focus-visible ring.
- Status never by colour alone — alert bands, participation states, and pills pair colour with an icon and text label, which also protects colour-blind readers.
- Motion is optional — animations and transitions all collapse under prefers-reduced-motion: reduce.
- Semantic structure — landmarks (nav/main/aside), heading order, and ARIA roles on switchers and drawers.
- Contrast — body text and controls meet AA (4.5:1 / 3:1) in both light and dark themes.
4 Known limitations
We publish these rather than hide them:
- Chart & heatmap fallbacks — analytics visualisations need an equivalent accessible data table for screen-reader users (1.1.1). Tracked; not yet universal.
- Live-region coverage — some async confirmations toast visually but don't yet announce via aria-live (4.1.3).
- Third-party surfaces — the Razorpay checkout and any embedded content follow their vendors' conformance, which we don't control.
5 The pulse survey — accessible today, installable in future
Because participation is the whole point, the survey-taking flow gets extra care: fully keyboard-completable, labelled inputs, no time-outs that penalise slower interaction, and no reliance on colour to read a scale. An installable, offline-capable version of the survey is planned as a later enhancement — see our how it works page for how the flow works today.
6 How we test, and how to tell us
- Automated checks (axe-core) in CI, plus manual keyboard-only and screen-reader passes (NVDA / VoiceOver) on the survey and core admin flows.
- Contrast and reduced-motion verified across light and dark themes.
- Found a barrier? Email accessibility@pulsepoint.in — we aim to acknowledge within 2 business days and will offer an accessible alternative while we fix the underlying issue.