Accessibility Statement

Our Commitment

ROLLIN exists to help wheelchair users find accessible restaurants, bars, and venues with confidence. We map ramps, restrooms, parking, and entryways so people can know before they go. That mission only holds up if the platform itself is usable by everyone, including people who rely on screen readers, keyboard navigation, alternative input devices, and other assistive technologies.

We hold ourselves to the same standard we ask of the businesses we evaluate. Accessibility is not a checkbox for us -- it is the reason this platform exists.

Conformance Status

ROLLIN targets conformance with the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. WCAG is the internationally recognized standard for web accessibility, developed by the World Wide Web Consortium (W3C).

Our current status is partially conformant: most of the platform meets WCAG 2.2 AA, and a small number of known exceptions are listed under Known Limitations below. In July 2026 we completed a full audit of every public page, combining automated testing (axe-core, run against the live site) with manual keyboard and screen reader checks, and shipped fixes across the entire site. We re-run these audits on an ongoing basis.

We are honest about where we fall short, and we prioritize fixes that affect real users with real assistive technology needs.

Display Preferences

These controls apply across joinrollin.com and are saved on your device. We also honor your operating system settings automatically: if your OS asks for reduced motion or increased contrast, the site respects that with no setup needed.

Accessibility Features

Here is what we have built into the platform today:

• Display preferences -- first-party controls for reduced motion, increased contrast, and larger text (see above), plus automatic support for the same preferences set at the operating system level
• Skip links on every page -- keyboard and screen reader users can jump straight to the main content past the navigation
• Motion that respects you -- all scripted and CSS animation completes instantly under reduced motion, and content always lands in its final, fully visible state; nothing on the site flashes
• Full zoom support -- pinch-zoom and browser zoom are never disabled, on any page
• Semantic HTML with proper heading hierarchy -- pages use meaningful heading levels (h1 through h4) so screen readers can navigate the document structure
• Keyboard navigable interface -- all core functionality can be accessed without a mouse, including search, filters, and location details
• Color contrast ratios meeting AA standards -- our dark theme was designed with readability in mind, using high-contrast text colors against dark backgrounds
• Visible focus indicators on interactive elements -- when navigating by keyboard, focused buttons, links, and form fields are clearly outlined
• Alt text on images -- meaningful images include descriptive alternative text; decorative images are marked appropriately
• Responsive design -- the platform works across screen sizes and devices, from mobile phones to desktop monitors, without losing functionality
• No auto-playing media or unstoppable animations -- we do not use auto-playing audio or video, and any motion on the page can be paused or does not interfere with usability
• Form labels and error messages -- input fields have associated labels, and form validation errors are communicated clearly
• ARIA labels where semantic HTML is insufficient -- for interactive components that go beyond standard HTML elements, we use ARIA attributes to convey purpose and state to assistive technology

Known Limitations

We believe in being straightforward about where the platform still needs work. These are the areas we know about and are actively addressing:

• Interactive map -- Map libraries have limited screen reader support, and markers and popups may not be fully announced or navigable with assistive technology. A rebuilt map experience is in active development with accessibility as a design requirement, and list-based views of the same data are available on the Explore and Search pages.
• Editorial text effects -- Some long-form pages use a scroll-driven effect where paragraph text brightens to full contrast as it enters the reading position. If you prefer that text at full strength at all times, the Increase Contrast preference above (or your OS contrast setting) renders it fully, and Reduce Motion disables the effect entirely.
• Admin dashboard visualizations -- Some data charts and complex visualizations in our internal admin tools may not be fully accessible to screen reader users.
• Third-party components -- Parts of the experience that rely on third-party services (Stripe for payments, Supabase for authentication) may have their own accessibility limitations that are outside our direct control. We choose vendors that take accessibility seriously, but we cannot guarantee full compliance for their embedded interfaces.
• Document exports -- PDF and other document exports are not yet available as accessible alternatives with proper tagging and structure.

If you find something we missed, please tell us. We would rather know than not.

How We Test

Accessibility testing is an ongoing process, not a one-time audit. Here is how we evaluate the platform:

• Manual keyboard navigation testing -- we tab through every page to verify that all interactive elements are reachable and operable without a mouse
• Screen reader testing with VoiceOver -- we use macOS VoiceOver to verify that content is announced correctly and navigation makes sense when you cannot see the screen
• Automated audits with axe-core and Lighthouse -- we run automated WCAG audits against the live site to catch common issues like missing labels, low contrast, and improper ARIA usage
• Contrast ratio checking -- we verify that text and interactive elements meet WCAG AA contrast minimums (4.5:1 for normal text, 3:1 for large text)

Automated tools catch a lot, but they do not catch everything. The most valuable feedback comes from people who actually use assistive technology day to day. If that is you, your input matters more than any audit tool.

Feedback and Contact

If you encounter an accessibility barrier on ROLLIN, we want to hear about it. Every report is taken seriously, and we aim to respond within 2 business days.

Email us at hello@joinrollin.com with the subject line "Accessibility Issue" and include as much of the following as you can:

• What you were trying to do -- the page you were on and the action you were attempting
• The assistive technology you were using -- screen reader, switch device, voice control, magnification, etc., along with the browser and operating system
• What happened -- describe the barrier you encountered
• What you expected to happen -- how things should have worked

You do not need to be technical. A simple description of the problem is enough. We will figure out the rest.

Continuous Improvement

This statement is reviewed and updated regularly as we improve the platform. Accessibility is not a destination -- it is ongoing work that evolves as our product evolves.

As ROLLIN grows, we plan to:

• Engage external accessibility auditors to identify issues our internal testing may miss
• Ship the rebuilt map experience with screen reader support and list-based alternatives as first-class design requirements
• Extend the display preferences as users tell us what else would help

We are a small team, but this work is central to who we are. If we are going to tell the world that accessibility matters, our own platform has to prove it.