The Wagon Method is built for people carrying a lot. That includes caregivers with disabilities, tired eyes, sensory sensitivities, and every kind of body and mind on the trail. We want the platform to feel calm, predictable, and welcoming whether you are using a screen reader, a keyboard, a switch device, or just trying to read through exhaustion. This page explains how we work to make that true.
Our commitment
We build the platform to conform with the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA. We also apply trauma-informed design principles that go beyond WCAG, because accessibility for our community means more than technical compliance. It means safety, predictability, and the ability to pause at any point.
What this looks like in practice
Visual design
- Body text is at least 16 pixels, with a comfortable line height and a maximum line length near 70 characters for easy reading.
- All text meets at least a 4.5 to 1 contrast ratio against its background. Large headings meet 3 to 1 or better.
- We never use text opacity below 70 percent, and we never use gold text on a dark background.
- Color is never the only way we communicate meaning. Every status, alert, or badge also carries a text label or icon.
- We use semantic color tokens throughout, so high contrast and dark modes stay consistent.
Motion and animation
- We respect the operating system setting
prefers-reduced-motion. When it is on, animations are removed or replaced with gentle fades. - There are no sudden camera moves, flashing content, or parallax effects that can trigger motion sickness or seizures.
- No video or sound ever plays automatically. Every media player has clear controls.
- Interactive elements use soft transitions, not sharp or rapid changes.
Keyboard and focus
- Every interactive element can be reached and operated using only a keyboard.
- Focus rings are always visible and designed to stand out without feeling harsh.
- Tab order follows the visual flow of the page. Skip links let you jump straight to the main content.
- Modals and menus trap focus appropriately and return it to a sensible place when closed.
Screen readers and assistive tech
- We use semantic HTML first. Headings, lists, landmarks, and buttons are marked up correctly so assistive tech can navigate the page.
- Every meaningful image has descriptive alt text. Decorative illustrations are marked as decoration so they do not interrupt a screen reader flow.
- Form inputs have visible labels, error messages linked via ARIA, and helpful hints.
- Dynamic updates use ARIA live regions so you hear important changes without having to re-scan the page.
- We test with VoiceOver, NVDA, and JAWS on modern browsers.
Touch and pointer
- Touch targets are at least 44 by 44 pixels so they are easy to hit on a phone or with a tremor.
- Interactive elements have enough space around them to avoid accidental taps.
- We do not require any gesture that cannot be performed with a single finger or an equivalent accessible input.
Trauma-informed accessibility
- Assessments can be paused at any point. Your answers are saved so you can come back when you have the capacity.
- Error messages are warm, not clinical. We write things like "We could not save that, want to try again?" rather than all-caps failure warnings.
- We keep exits obvious. A safety exit link is always available on any page that covers heavy content.
- Navigation is predictable. The same menu is in the same place on every page, and important actions never jump around.
- Before a page touches sensitive material, we tell you what is coming so you can choose whether to continue.
Where we are not yet fully accessible
We will always tell you the truth about where we fall short. Some older illustrations still need richer alt text. A few community features are still being audited with screen readers. Video captions are complete for our educational modules, but full audio descriptions are still in progress. We are actively working on all of these and track them in an open accessibility backlog.
How we test
Accessibility is part of our regular development work, not a one-time audit.
- Automated checks run on every pull request using axe-core and Lighthouse.
- Manual keyboard and screen reader testing on critical flows before each release.
- Real caregivers using assistive technology help us test major new features before launch.
- Periodic third-party audits against WCAG 2.1 AA with remediation plans for any findings.
Report a problem
If something on the platform is not working for you, please tell us. Write to accessibility@thewagonmethod.com and include the page you were on, what you were trying to do, and what happened. We will acknowledge your note within two business days and do our best to resolve the issue quickly. If you prefer, you can also report the issue from the help menu on any page.
You matter to us, and so does your experience here. Thank you for helping us make the platform better.