Accessibility Statement

Virtual Walk LLC is committed to ensuring digital accessibility for people with disabilities. We are continually improving the user experience for everyone, and applying the relevant accessibility standards to both the Walk The Distance mobile application (iOS and Android) and our website at walkthedistanceapp.com.

Our Commitment

Our goal is to conform with the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA. These guidelines explain how to make digital content more accessible for people with a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities.

Scope

This statement applies to the Walk The Distance product: the walkthedistanceapp.com website (including account flows, pricing, walk catalog, employer-resources pages, and policy pages) and the Walk The Distance mobile application on iOS and Android.

Third-party embeds (Loom video player, App Store and Google Play badges, etc.) are outside the scope of this statement; their conformance is the responsibility of the respective third parties.

Conformance Status

Walk The Distance is partially conformant with WCAG 2.1 Level AA. "Partially conformant" means that some parts of the content do not fully conform to the accessibility standard. We have completed a self-assessment using the Voluntary Product Accessibility Template (VPAT® 2.5 INT) and are actively working on a remediation roadmap to close the gaps we have identified.

Our self-assessed accessibility conformance report is available on request — please contact us using the details below.

Standards We Follow

• Mobile app — built in Flutter using Material Design 3 components, which provide accessible defaults for touch target sizes, focus order, color contrast, and screen-reader semantics. The app respects the operating system's accessibility settings, including system text scaling, dark mode, screen reader (VoiceOver, TalkBack), and reduce-motion preferences. There is no separate accessibility setting required inside the app.
• Website — built with Next.js using semantic HTML landmarks (<main>, <nav>, <footer>), descriptive alt text on meaningful images, ARIA attributes where appropriate, and keyboard-operable interactive controls.

Assessment Approach

We assess accessibility through a combination of:

• Manual testing with VoiceOver (iOS) and TalkBack (Android).
• Keyboard-only navigation testing on the website.
• Operating-system text-scaling and dark-mode testing on the mobile app.
• Color-contrast spot checks against the WCAG 2.1 AA contrast ratios.
• Automated checks using browser developer tools (planned: axe-core and Lighthouse accessibility checks in continuous integration).

Known Limitations

Despite our best efforts to ensure accessibility, the following known limitations exist and are tracked on our remediation roadmap:

• Mobile orientation lock. The mobile app is locked to portrait orientation. The live walking screen — where you hold the device while you walk and the map updates around you — relies on a stable orientation, which we treat as falling under the WCAG 1.3.4 "essential" exception. The remaining screens (leaderboards, trail detail, onboarding, settings) currently inherit the same lock as a product convention rather than because portrait is essential. We have not yet differentiated by form factor (tablets share the phone lock today). Allowing tablet rotation, and revisiting the per-screen lock on phones, are on our roadmap.
• Color contrast. Both platforms have completed a measured contrast pass. On the website, every helper-text shade was promoted to clear 4.5:1 on light backgrounds, the global input placeholder color was raised from gray-400 to gray-600 (~7.6:1 on white), and ad-hoc disabled:opacity-50 button states (which produced ~1.79:1 white-on-blended-fill) were replaced with explicitdisabled:bg-gray-300 disabled:text-gray-600 (5.13:1) on the primary CTA, with equivalent :disabled styles added to the shared .btn-primary and .btn-secondary component classes. Two semantic border tokens were added to the design system — one calibrated to ~3.1:1 vs white for soft card boundaries and one to ~4.83:1 for input borders — and every user-facing card and form-control border was migrated to these tokens, putting all identifying boundaries comfortably above the WCAG 1.4.11 3:1 threshold. On mobile, the legacy chocolate-grey text scale was retuned (the previously-failing "light" variant now clears 5:1 on white and 4.9:1 on our beige surface), the "incomplete" / "today" / "finished" map polylines were re-tuned against the Google Maps light-style backdrop so each border carries 3:1+ in a deliberate visual hierarchy, and a flutter_test suite asserts textContrastGuideline,labeledTapTargetGuideline, androidTapTargetGuideline, and iOSTapTargetGuideline against representative widgets so regressions fail the test suite.
• Mobile screen-reader semantics. Image semantics and grouping are applied across mobile screens — user, group, and company avatars announce a descriptive label everywhere they appear, leaderboard photos and search results expose names, decorative chrome (chevrons, hero backgrounds, premium icons, cover images) is excluded from the accessibility tree, meaningful imagery (badges, trail thumbnails, checkpoint and quiz photos, brand logos) carries labels, and custom layouts that visually pair a label with a value (leaderboard rows, stat tiles, route / team / group / org goal progress sections, trail-part progress cards, checkpoint rows, challenge-list cards) are wrapped in MergeSemantics so VoiceOver and TalkBack announce each row as a single phrase. The remaining custom InkWell / GestureDetector tap targets — image / avatar pickers, doodle-sheet tools, chat composer affordances, settings rows, modal back-and-close affordances, and quiz answer chips — are now wrapped in Semantics(button: true, label: …) so they expose the correct role and accessible name.
• Third-party audit. The current report is a self-assessment. A third-party accessibility audit is on our roadmap.

Feedback and Reporting

We welcome your feedback on the accessibility of Walk The Distance. If you encounter an accessibility barrier, or have a suggestion for improvement, please let us know. We will use your feedback to prioritize fixes.

Response Times

• We aim to acknowledge accessibility reports within 5 business days.
• We aim to provide a remediation plan or workaround within 30 calendar days of acknowledgment.
• Critical issues that block users from completing core tasks are expedited.

Accessibility Roadmap

The remaining work we are tracking:

Website

• Adding axe-core and Lighthouse accessibility checks to our continuous integration pipeline so contrast, ARIA, and structural regressions block future deploys.

Mobile app

• Allowing rotation on tablet form factors (the largest near-term win on WCAG 1.3.4 without re-validating every phone screen), then revisiting the per-screen lock on phones — keeping it on the live walking surface where it is essential and unlocking screens like leaderboards, settings, and community where portrait is a convention rather than essential.
• Wiring the flutter_test accessibility suite into the mobile-app continuous-integration job so contrast and tap-target regressions block merges.

Once the remediation above is complete, we will re-run our self-assessment and engage a third-party auditor to validate the result.

Compatibility with Browsers and Assistive Technology

Walk The Distance is designed to be compatible with the following technologies:

• Website — current versions of Chrome, Safari, Firefox, and Edge on macOS, Windows, iOS, and Android. Tested with VoiceOver (macOS, iOS) and TalkBack (Android). Compatible with NVDA and JAWS on Windows; we welcome reports of issues with these screen readers.
• Mobile app — iOS 14 and later (VoiceOver, Dynamic Type, Voice Control), and Android 8 (API 26) and later (TalkBack, system font scaling, Switch Access). The app respects system-level reduce-motion and dark-mode preferences.

The product is not actively tested against:

• Internet Explorer 11 and other unsupported legacy browsers.
• Browsers more than three major versions out of date.
• Operating systems no longer receiving vendor security updates.

Technical Specifications

Accessibility of Walk The Distance relies on the following technologies to work with the particular combination of web browser and any assistive technologies or plugins installed on your device:

• HTML
• WAI-ARIA
• CSS
• JavaScript
• Material Design 3 components (Flutter mobile app), which expose semantic role and state information to iOS and Android accessibility services.

These technologies are relied upon for conformance with the accessibility standards used.

Assessment Method

Virtual Walk LLC assessed the accessibility of Walk The Distance by self-evaluation. A third-party accessibility audit is on our roadmap. The most recent self-assessment is documented in our VPAT 2.5 INT report covering WCAG 2.1 Level A and AA, available on request.

Formal Approval of This Accessibility Statement

This Accessibility Statement is approved by:

John Zaccone, Founder, Virtual Walk LLC.