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.1 at Level AA. WCAG is the internationally recognized standard for web accessibility, developed by the World Wide Web Consortium (W3C).

We are working toward full compliance. As a small team, some areas are still being improved. We are honest about where we fall short, and we are actively closing the gaps. We test regularly and prioritize fixes that affect real users with real assistive technology needs.

Accessibility Features

Here is what we have built into the platform today:

• 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 -- Our map is built with Leaflet.js, which has limited screen reader support. Map markers and popups may not be fully announced or navigable with assistive technology. We are exploring ways to improve this, including providing list-based alternatives to the map view.
• 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
• Chrome Lighthouse audits -- we run automated accessibility audits 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
• Implement automated accessibility testing in our deployment pipeline so regressions are caught before they reach users
• Expand screen reader support for the interactive map by building complementary list views and improving ARIA markup on map components

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.