RealLens

Know what's ahead. RealLens turns real-time road, weather, and transit data into spoken guidance so Gainesville's blind and low-vision community can commute with confidence.

Comment

Inspiration

As a sighted student, I often see blind and low-vision students navigating campus with white canes. Gainesville’s campus and city sidewalks are not always flat or predictable, and sudden rain can quickly leave puddles and muddy areas along a route. I can see these changes and step around them. Someone who cannot see them may receive little or no warning.

One moment stayed with me: I watched a blind student step directly into a rain puddle without enough time to react. It was a small environmental change, but it disrupted a normal commute. That made me realize that most travel tools tell people where to go, but they do not always explain what conditions may be waiting along the way.

I decided to build RealLens for Gainesville’s blind and low-vision community. RealLens brings together weather conditions, environmental context, official closures, and local transportation updates, then presents them through clear text and optional voice. It does not replace a white cane, guide dog, mobility training, or turn-by-turn navigation. It adds a layer of preparation, helping people understand what is confirmed, what is uncertain, and what may be ahead so they can make informed travel decisions and feel more in control of their commute.

What it does

RealLens helps blind and low-vision travelers understand changing conditions before commuting around UF and Gainesville. A user selects a starting point, destination, departure time, and expected outdoor duration. RealLens then creates a journey briefing that combines:

  • Time-matched National Weather Service forecasts and alerts
  • Published UF campus closures near the mapped study line
  • Dated Sentinel-2 vegetation context based on the EMERGE NDVI method
  • RTS rider alerts, with an optional route-number filter

Every briefing is available as readable text, downloadable text, and optional speech. The map is secondary and is not required to understand the information. RealLens also identifies when data is historical, stale, unavailable, or unverified instead of presenting uncertain conditions as facts.

RealLens is a preparation tool. It is not turn-by-turn navigation, obstacle detection, live bus tracking, or a guarantee that a route is safe.

How we built it

I built RealLens as a multi-page web application using HTML, CSS, JavaScript, Vite, and Vercel. I began by researching the problems that changing weather, uneven outdoor conditions, campus closures, and transit disruptions can create during a commute. I then designed the experience around preparation, clear language, and access without requiring users to interact with a map.

OpenStreetMap geometry provides the mapped study lines. Copernicus Sentinel-2 imagery provides historical vegetation data, processed using the NDVI method from EMERGE Textbook 1. Server-side functions retrieve National Weather Service forecasts, published UF closure notices and GIS polygons, and public RTS rider-alert posts.

I added optional speech recognition and narration while keeping every important feature available through text and standard form controls. Voice requests require confirmation before changing a journey or retrieving new conditions. I then tested the interface across desktop and mobile layouts, large-text and high-contrast settings, unavailable data, stale requests, and source failures before deploying the prototype through Vercel.

Challenges we ran into

The biggest challenge was combining several kinds of information without creating false confidence. A weather forecast, a dated satellite observation, an official closure notice, and an unknown sidewalk condition do not have the same meaning. I had to keep those categories separate and clearly explain what each source can and cannot prove.

Voice interaction created another challenge. Campus names can be misheard, microphone access can fail, and a late response should not change an old journey. I added explicit confirmation, typed fallback, cancellation, timeout handling, and protections against stale requests.

Public data sources can also be delayed, incomplete, or temporarily unavailable. RealLens preserves earlier information as stale, shows when a source was last checked, and reports unknown conditions instead of treating missing data as evidence that nothing is wrong.

The most important remaining limitation is that RealLens has not yet been tested with blind or low-vision participants or orientation-and-mobility professionals. Automated accessibility testing cannot replace that feedback.

Accomplishments that we're proud of

I am proud that RealLens became a working public prototype rather than only a design concept. A user can prepare a campus journey, read or listen to the briefing, check weather and official closures, review RTS updates, inspect the original sources, and understand the limitations of the information.

The current build passed 161 automated Node tests. Browser testing included 66 layout assertions and 24 workflow assertions across desktop, mobile, large-text, and high-contrast views. Automated axe scans found no WCAG-tagged violations in the tested states. These results do not prove real-world usability, but they produced a stronger and more stable prototype for future user testing.

I am also proud that the product does not hide uncertainty. RealLens explains when vegetation data is historical, when a route has not been field-audited, when a source is stale, and when a condition remains unknown.

What we learned

I learned that accessibility is not achieved by adding a voice button to a visual product. Users need control over when audio starts, a complete typed alternative, clear confirmation before changes, understandable status messages, and access to the same essential information without interacting with a map.

I also learned that being honest about data limitations is part of the product experience. Near-real-time does not mean instant, a published alert does not describe every physical condition, and the absence of a report does not mean that a route has no barriers.

Most importantly, I learned that the next stage cannot rely only on what I assume blind and low-vision travelers need. Direct feedback from the community must shape the product.

What's next for RealLens

The next priority is testing RealLens with blind and low-vision students and orientation-and-mobility professionals. Their feedback should guide the language, voice workflow, information order, and which environmental details are genuinely useful during a commute.

After validating the current preparation experience, I want to develop RealLens into an opt-in journey companion that stays with the user throughout the trip. With explicit location permission and reliable route and transit data, RealLens could provide step-by-step guidance, announce approaching transit stops, and notify the user when new official conditions affect the journey.

This will require accurate positioning, accessible route information, rerouting, low-signal handling, clear audio controls, and extensive real-world testing. Text controls and the ability to pause or stop guidance will remain available so users stay in control.

I also want to expand beyond the six-location pilot, add verified entrances and sidewalk information, improve recognition of Gainesville place names, and test with real screen readers and mobile devices. The long-term goal is for RealLens to support people before and during more journeys across Gainesville without claiming more certainty than its data can provide.

Built With

Share this project:

Updates

Submission history