Usable by everyone
on your response team.
A crisis exercise only works if every participant can take part. We aim to meet the Web Content Accessibility Guidelines (WCAG) 2.1 at level AA. This statement describes what is in place today, where we fall short, and how to tell us about a barrier.
Last reviewed: 27 September 2026
Conformance status
Target: WCAG 2.1 AA. Status: partially conformant.
Partially conformant means some parts of the platform do not yet fully meet the standard. This assessment is our own; it has not been verified by an independent auditor. It covers the public website and the client, facilitator and carrier portals.
What is in place
Measures we take today.
Accessibility checks on every change
Accessibility lint rules run on every pull request, including a rule that flags light-grey text classes known to fail WCAG AA contrast on light backgrounds. The client portal was swept to remove those classes.
Touch targets of at least 44 pixels
Buttons from our design system give every size a pointer target of at least 44 × 44 pixels, including compact toolbar buttons. An automated test fails the build if that changes.
Labelled form controls
Our engineering rules require every form input to have an associated label, and icon-only buttons to carry an accessible name. Where we have found unlabelled inputs, we have fixed them and added tests.
Screen-reader announcements in exercises
In the live exercise war room and the self-service exercise runner, each new inject is announced to screen readers through a live region, as is the facilitator assessment of your response in the self-service runner. In the war room a lost connection is announced as an alert and exercise progress is exposed as a labelled progress bar.
Small-screen checks
Every client portal page is checked at a 375-pixel viewport for horizontal scrolling and menu target size. This check is run by hand before releases, not automatically on every change.
Reduced motion and page language
If your system asks for reduced motion, animations and transitions are effectively switched off. Every page declares its language so assistive technology reads it correctly.
Known limitations
Where we fall short.
- We have not had an independent accessibility audit, we do not publish a VPAT, and we do not run an automated accessibility scanner. We therefore do not claim full conformance with WCAG 2.1 AA.
- There is no “skip to main content” link yet, so keyboard users move through the navigation on every page.
- Charts on the readiness and analytics dashboards present data visually and may not expose their values to screen readers.
- Downloadable PDF reports are not tagged PDFs and may be difficult to read with a screen reader.
- The small-screen check covers the client portal. The facilitator and carrier portals and the marketing site have not been systematically checked at that width.
- Live exercises run in real time. If a participant needs more time, the facilitator can pause the session.
- Payment checkout (Stripe) and meeting booking (Calendly) are provided by third parties and their accessibility is outside our control.
Feedback
Hit a barrier? Tell us.
Email info@afteraction.dev with the page address, what you were trying to do, and the browser and assistive technology you use. If a barrier is stopping you or your team from completing an exercise or getting a report, say so and we will work with you on it.