Accessibility

Our standard

Companion targets WCAG 2.2 Level AA on every user-facing surface. We treat accessibility as a merge-time gate for every new feature, not a follow-up ticket: full keyboard operability of every interactive element and full screen-reader coverage of every control and dynamic change are non-negotiable.

This standard covers UK PSBAR, the EU Accessibility Act (in force 28 June 2025), and US Section 508. Where we already meet WCAG 2.2 AAA (for example, touch-target size on interactive controls), we hold that higher bar.

Scope

This statement covers the Companion web application at this domain. Third-party plugins running inside Companion are covered by their own accessibility declarations — administrators can see per-plugin conformance information in the Control panel.

Known limitations

• Some data charts (trends, stacked bars, bar lists) do not yet provide a screen-reader-accessible summary of the data they show.

  WCAG 1.1.1 (Non-text Content), 1.4.1 (Use of Colour).

  Mitigation: Where a chart appears alongside a data table (e.g. audit views), the table conveys the same information. Otherwise the numeric values are available in the tenant export.

• Some asynchronous updates (chat message arrival, notification pills, background table refresh) may not be announced by every screen reader.

  WCAG 4.1.3 (Status Messages).

  Mitigation: Toasts and form errors are already announced. Users relying on assistive tech can refresh the view manually to force a re-read; we are progressively adding live regions to remove the need.

Report a barrier

If something on Companion is unusable, difficult to use, or excludes you, tell us — your report goes to the same backlog that drives the fixes above.

• Ask your Companion administrator to open a support ticket on your behalf; they will attach the details required for us to reproduce.
• Or email our support team at support@percayso.com. Include the page you were on, what you were trying to do, and the assistive technology you were using; a real person will read it and route it to the accessibility workstream.

How we test

Automated checks on every merge. An eslint-plugin-jsx-a11y pass runs across the whole codebase, and axe-core scans every design-system component story and the critical user-reachable routes as part of continuous integration. Serious or critical violations fail the build, so a regression cannot land unnoticed.

Manual checks before every release. A keyboard-only walkthrough and a screen-reader smoke test (NVDA with Firefox, and VoiceOver with Safari) are performed on the critical flows — sign-in, home, launcher, a composed plugin app, and a control-panel data table. Each surface that changed since the previous release is also verified under 200% and 400% zoom, dark theme, reduced motion, and forced-colour rendering.

Automated tools alone catch roughly a third to a half of WCAG issues; the manual pass catches the rest. Both are treated as merge-time gates, not follow-up tickets.