Accessibility statement

We target the Web Content Accessibility Guidelines (WCAG) 2.1 at level AA across the platform. This is the standard referenced by the Americans with Disabilities Act and most government accessibility procurement criteria. We also follow the WAI-ARIA Authoring Practices for our custom components.

• Keyboard navigation. Every interactive element is reachable via Tab/Shift-Tab and operable with Enter or Space. Skip-to-content links are present on full pages.
• Visible focus. All focusable elements show a high-contrast outline when reached via keyboard. Focus is moved deliberately when dialogs open and returned when they close.
• Screen-reader semantics. Headings, landmarks (header, nav, main, aside, footer), lists, and form labels are marked up correctly. Dynamic content — like server errors and toast notifications — announces via aria-live regions.
• Forms. Every input has a programmatic label, error states are linked via aria-describedby, and required fields are marked both visually and semantically.
• Color and contrast. Body text and interactive elements meet 4.5:1 contrast minimum; large text and graphical elements meet 3:1. Information is never conveyed by color alone.
• Responsive layouts. Pages reflow cleanly at 320px width and at 200% zoom without loss of content or function.
• Motion. Animations respect prefers-reduced-motion. Auto-playing content does not exist on the platform; all videos require an explicit click to play.
• Images. All meaningful images have alternative text. Decorative images use empty alt attributes so screen readers skip them.

• The interactive map view in search relies on a visual-spatial paradigm that's hard to translate to assistive technologies. We always ship the same results in the list view, which is fully accessible.
• Some user-uploaded images may have generic or missing alt text. We prompt hosts to add captions but don't require them yet.
• The mobile apps are still catching up to the web on a few specialized components. We track parity in our public roadmap.

We audit the platform with automated tools (axe, Lighthouse) on every pull request and run manual screen-reader testing (NVDA on Windows, VoiceOver on macOS and iOS, TalkBack on Android) on a quarterly cadence. We work with people who use assistive technology in the wild — if you'd like to be part of that program, write to the address below.

If you hit something on Wheelhouse that doesn't work for you, please tell us. Email accessibility@getwheelhouse.com with the URL, a short description, the device or assistive tech you're using, and a screenshot if relevant. We respond within five business days and treat accessibility reports as urgent.

If we can't fix the issue right away, we'll offer an alternate path to complete what you were trying to do.