Search for any restaurant on any major platform. Look for accessibility information. You will find one of two things: a checkbox that says "Wheelchair accessible: Yes," or nothing at all.

That single binary data point is supposed to answer every question a wheelchair user has before leaving home. Can I get through the door? Is there a ramp, or are there stairs? Is the restroom actually accessible, or is it a single stall with a grab bar that hasn't been checked since it was installed? Is there parking I can use, or will I be circling the block hoping for the best?

" One checkbox. For all of that. And it's not even verified.

The result is that millions of Americans with disabilities are forced into the same routine: call the restaurant, hope someone picks up, describe your specific needs, ask if they're "really" accessible, interpret their uncertain answer, and then hope they're right when you arrive.

Nobody should have to call ahead to eat dinner. ROLLIN was built to solve that problem. Not with another checkbox, but with a system that learns.


The Checkbox Problem

The world runs on a checkbox. Every major mapping platform, every review site, every directory reduces wheelchair accessibility to a single binary field. Yes or no. Accessible or not.

That one field is expected to capture whether a building has a ramp, whether the doorways are wide enough, whether the restroom has grab bars and adequate turning radius, whether the parking lot has designated accessible spaces, and whether there's an elevator if the dining room is upstairs. All of that complexity, collapsed into a single bit of information that was probably entered once by someone who may not have known what they were looking at. And never updated.

The fundamental flaw is not that the checkbox exists. The flaw is that it pretends to be sufficient. When a wheelchair user sees "Wheelchair Accessible: Yes" and drives forty minutes to a restaurant, only to find three steps at the entrance and no ramp, the checkbox didn't just fail to inform. It actively misled.

Accessibility is not binary. It is a spectrum of physical features, each of which matters independently. A place can have level entry but no accessible restroom. It can have wide aisles but no accessible parking. The experience of visiting that place depends on which features matter most to you, and the only way to know is to have granular, verified, current information about each one.

That is what ROLLIN provides. Not a checkbox. A score.


Six Features, One Score

Every location in ROLLIN is evaluated across six independent physical accessibility features. Each one is tracked separately. Each one is weighted. And together, they produce a single 0-100 accessibility score that tells you, at a glance, how confident you can be about visiting a place.

Wheelchair entry is the front door question. Can you physically enter the building in a wheelchair? Is there a ramp, is the entrance level, or are there steps?

Accessible restroom is the question nobody asks online but everybody needs answered. Adequate space for a wheelchair, grab bars, accessible fixtures.

Level entry goes beyond the front door. Once you're inside, is the dining area on the same level? Are there changes in elevation between sections?

Wide aisles determines whether a wheelchair can actually navigate between tables once inside. It's one thing to get through the door. It's another to move freely once you're there.

Accessible parking includes designated spots, proper signage, and reasonable proximity to the entrance.

Elevator access matters for multi-level venues. If the restaurant, bar, or cafe is upstairs, is there an elevator that works?

Four of these are classified as critical features: wheelchair entry, accessible restroom, level entry, and wide aisles. The scoring system treats them differently than parking and elevators, because their absence fundamentally affects whether a wheelchair user can visit a venue at all.

" The system penalizes what it doesn't know instead of pretending everything is fine.

This is where the confidence cap comes in. If a venue has strong data across all six features, its score can reach the full 0-100 range. But for every critical feature that remains unverified, the maximum possible score drops. The more unknowns, the lower the ceiling. Each unknown also applies a penalty to the score itself, not just the cap.

The cap is the most important design decision in the entire scoring system. A restaurant could be excellent across every verified dimension, but if we cannot independently confirm that it has wheelchair entry, the score reflects that uncertainty. We refuse to tell someone a place is a 95 and have them show up to find stairs.

We would rather be cautiously right than confidently wrong.


Multi-Source Verification

ROLLIN does not rely on a single data source. Every location is processed through a proprietary multi-source pipeline that cross-references multiple independent signals. No single source is trusted alone.

The key word is independent. When two sources that don't talk to each other both report that a restaurant has a wheelchair ramp, that is stronger evidence than a single self-reported claim. When a third source confirms the same feature, confidence increases further. When sources disagree, the system flags the conflict for investigation rather than silently picking one answer.

Every signal in the pipeline has a weight. Every weight is earned through consistency and reliability over time, not assumed. The system continuously evaluates source quality by tracking how often a source's claims are confirmed or contradicted by other signals. Sources that prove reliable gain more influence. Sources that prove inconsistent lose it.

This approach solves a problem that plagues every accessibility dataset built from a single source: blind spots. Any individual data provider has gaps in coverage, biases in methodology, and limits on how frequently they update. By layering multiple sources and weighing them against each other, the pipeline produces a picture of physical accessibility that is more complete and more trustworthy than any individual source could provide alone.

The pipeline runs continuously. When a venue changes, whether a ramp is installed, a restroom is renovated, or construction closes a parking lot, the system detects the change as new signals arrive and the scores update. Nothing is static. The data is always moving toward accuracy.


Community Feedback

On top of the multi-source pipeline sits a community verification layer. Real users who visit real venues submit corrections and confirmations about what they find on the ground.

This is not a review system. There are no star ratings, no written opinions, no arguments about food quality. Community feedback on ROLLIN is structured and specific. A user can confirm that a feature exists ("Yes, there is a ramp at the entrance"), flag that a feature is missing ("No, the restroom is not accessible"), or report that conditions have changed ("The ramp was removed during construction").

Each submission is trust-weighted. A new user's confirmation counts, but modestly. A verified contributor with dozens of accurate past submissions carries significantly more weight. When enough trusted signals agree on a feature, the venue's score recalculates automatically.

The system also supports quick confirmations. A single tap that says "I've been here, and the data looks right." Quick confirmations are lower-signal than detailed feature-by-feature feedback, but at scale, they provide a meaningful confidence boost. When twenty people confirm that a place is accurately represented, that cumulative signal is powerful even if each individual confirmation is lightweight.

What the community layer accomplishes is something no pipeline can do alone: ground truth. A data source can tell you that a building has a ramp in its permit records. A community member who uses a wheelchair can tell you whether that ramp is actually usable. Both signals matter. Together, they are far more valuable than either one alone.


Trust Tiers

Not all feedback is weighted equally, and that is by design. ROLLIN's contributor system mirrors how trust works in real life: you build credibility through consistency.

New contributors start at a baseline trust level. Their feedback is accepted and processed, but it carries modest weight in the scoring system. As their reports are confirmed by other users and by pipeline data, their trust score increases. They move up through tiers: from new user to active, from active to established, from established to verified, and ultimately to expert.

Trust is earned through accuracy, not volume. A contributor who submits ten reports that are all confirmed by independent sources will earn more trust than one who submits a hundred reports with inconsistent accuracy. The system is watching for patterns. Consistent accuracy is rewarded. Inconsistency is not punished, but it does not earn promotion.

Higher-tier contributors have their feedback weighted more heavily in score calculations. An expert-tier contributor flagging that a restaurant has removed its wheelchair ramp will move the score more quickly than an anonymous first-time report of the same change. Not because we distrust new users. Because the expert has earned that influence through a track record of being right.

This creates a self-reinforcing quality system. Bad data gets corrected quickly by trusted contributors. Good data gets reinforced. And the overall accuracy of the system improves with every cycle of submission, verification, and trust adjustment.

" Nobody should have to call ahead to eat dinner.

The Data Flywheel

Search
Feedback
Verification
Better Scores
More Users
Repeat

Every interaction with ROLLIN makes the data smarter. This is the flywheel at the center of the system, and it is the reason the platform improves every single day without requiring manual intervention.

When someone searches for "accessible sushi in Brooklyn," that is a demand signal. It tells the system which locations matter most and where verification efforts should be prioritized. When a user visits a location page and spends time reading the accessibility breakdown, that is an interest signal. When they tap "I've been here" and confirm a feature, that is a verification signal weighted by their trust history.

When a developer queries the API to build an accessible restaurant finder, every user of that developer's application becomes a potential signal source. When a travel platform integrates ROLLIN scores into their listings, every traveler who views those scores and visits those venues generates validation data. Each integration extends the reach of the flywheel, bringing in signals from user populations the platform could never reach on its own.

The flywheel operates on a simple cycle. More users generate more feedback. More feedback improves data quality. Better data quality builds more trust. More trust attracts more users. And the cycle repeats, accelerating with each turn.

What makes this different from a static database is compounding. Every day, the scores are more accurate than they were yesterday. Every new piece of feedback builds on everything that came before it. The system is not just collecting data. It is learning from it -- learning which sources are reliable, which contributors are accurate, which features are most commonly misreported, and where the biggest gaps in coverage remain.

The goal is not to know everything about every venue. The goal is to be honest about what we know and what we don't. When data is strong, the score reflects confidence. When data is thin, the score reflects uncertainty. And over time, through the relentless operation of the flywheel, the uncertain scores become confident ones.

The result is the most accurate wheelchair accessibility dataset available today, covering tens of thousands of locations across a growing number of states. Every search, every feedback submission, every API call makes the data smarter. The system does not sleep. It does not take breaks. And the gap between ROLLIN's data and everything else gets wider every day.

If you use a wheelchair, try searching for a restaurant near you. If you are a developer, explore the API and build something that matters. If you run a restaurant, claim your listing and help us get it right. Every interaction makes the system better for everyone who comes next.