[Hackathon 1/3] SF Hacks 2026 — GatorAccess Campus Accessibility Navigator

Hackathon Series 1/3 — SF Hacks 2026

This is the first of three stories about my hackathon projects. On October 2, 2026, I joined the SF Hacks x GDG AI Hackathon at San Francisco State University (SFSU).

Our four-person team built GatorAccess in one day and submitted it as SFSU Gator Accessibility Navigation in the Build with AI for Social Good track. I served as project lead and handled Firebase integration.

Checking in at the venue that morning.

Project Overview

GatorAccess is a web application for finding campus routes, reporting accessibility barriers, and reaching support services. Its core journey is find a route → report a barrier → get support.

For wheelchair users or students using crutches, a route needs to be passable, not just short. The project aims to help students discover broken elevators or blocked ramps before reaching them, and share barriers they encounter with others.

Event · Submission · GitHub repository · Team demo

Team and My Contribution

Alongside leading the project, I focused on Firebase integration: connecting submitted reports to stored data and the information used across the application. Peter handled the frontend and Gemini integration, Satyam the backend, and Omar the site and user experience design.

Development around lunchtime and preparation before submission. The shared task was to connect the map and AI features into one service.

1. The Problem — A Short Route May Still Be Inaccessible

Ordinary walking directions do not capture every user’s mobility needs. Stairs at an entrance, a broken elevator, or an obstruction can make the same route usable for one person and impossible for another.

Reporting a barrier also takes effort. Requiring technical facilities vocabulary or a lengthy written explanation makes it harder to submit a report. GatorAccess uses a photo to describe the situation, followed by an AI-generated draft that the user reviews.

2. Implementation

Campus Map and Directions

The React interface combines Google Maps with campus buildings and accessibility information. Users select an origin and destination, request walking directions, and see the route drawn on the map.

The implementation first tries the browser’s Google Maps directions service and then a server API if that fails. It also includes elevation-gain lookup; failed or timed-out lookups remain unavailable rather than receiving an invented value.

Obtaining walking directions and verifying wheelchair access are separate tasks. Suggested detours still require reliable slope information and confirmation of conditions on site.

Team demo at 00:23: destination cards, the map, and the Gemini voice assistant.

Camera Input and Gemini Hazard Analysis

Reporting follows photo input → location confirmation → AI analysis → review and editing → submission. The submitted demo shows image upload and entry into the live-camera workflow. The server receives the image and location and asks Gemini for the hazard type, severity, and a summary.

The server checks for missing images, unsupported formats, and oversized input. It distinguishes errors such as missing API keys, exhausted quotas, and timeouts.

Analysis is not treated as a final report automatically. Users can edit the result before submitting. The repository also includes handling and tests for unclear images and incomplete model responses.

Team demo at 00:46: the input stage, with the analysis, review, and reporting steps shown above it. This is not an analysis-result screenshot.

My Contribution — Firebase and Report Data

Submitting a report creates a report ID and a facilities work-order ID. Hazard details, location, photos, and recommended actions are collected in a record and reflected in the application’s report list. Elevator-failure reports with a building ID can also update that building’s elevator state.

The intended flow stores reports in Firebase and connects them to facilities-status views. The public server code attempts Firestore storage when configured and uses an in-memory demo mode if configuration is missing or storage fails. Generating a work-order ID inside the app does not establish integration with the university’s actual facilities system.

Interface Accessibility

The interface includes high contrast, larger text, visual alerts, browser speech synthesis for directions, and entry points to mobility and campus support.

The code also caches campus buildings and initial reports through the browser Cache API. That alone does not guarantee current facilities information or full offline map functionality.

Gemini Voice Assistant

The voice assistant connects a spoken request to the relevant screen or action. The submitted scenario routes a student who is having trouble reaching Student Services to navigation, then suggests mobility or accessibility support when needed.

This gives users a way to explain their difficulty in words as well as selecting a destination on a map. Peter implemented the frontend and Gemini integration for this feature.

3. Architecture and Technology

The browser collects and confirms the image and location. Express validates the request and calls Gemini. After user review, a submitted report is reflected in storage and the app’s report list for use by the map and facilities views.

4. Engineering Considerations

What a Photo Can Establish

A photo may reveal an obstacle without establishing its exact slope or whether an entrance is usable. Users therefore need to review both the analysis and the estimated location, with uncertainty visible when evidence is insufficient.

The analysis tests cover clear paths, unclear photos, incomplete responses, and network failures. They verify response handling, not model accuracy on real campus photographs.

Shared State Across Views

A barrier submitted in one screen should mean the same thing on the map and facilities dashboard. Reports therefore include building IDs, coordinates, status, and work-order IDs in addition to hazard descriptions. Connecting user input to mapped facilities is central to the data model.

External-Service Failures

Directions fallback, image validation, AI error classification, and elevation time limits help distinguish failures at different stages. Users should be able to retry or review the information rather than receive a fabricated result.

5. Submission and Scope

The team submitted the project on October 2, 2026, at 4:44 PM. The submission records a four-person team in the Build with AI for Social Good track.

Our submission page at the event.

The submission lists Firebase Authentication, Cloud Firestore, Firebase Hosting, and Firebase Cloud Messaging. This article focuses on my integration role and the storage flow visible in the code; it does not claim that every listed service’s deployment and notification delivery were verified.

Before real operation, the prototype needs reliable facilities data, field-verified routes, storage and permission review, and testing with users and assistive technology. Ride requests and ETAs are simulated, and BART alerts use a mock feed; both need actual service integrations.

6. Looking Back at the First Hackathon

The central task was connecting discovery, review, and sharing of a real-world barrier. The map, camera, location, and report data need to work together before a user can decide what to do next.

Building an accessibility service made information reliability and failure behavior as important as feature count. It was a chance to apply web technology and multimodal AI to campus mobility while identifying what separates a prototype from an operational service.

A photo after the event.

This is part 1/3 of my hackathon series, beginning with project leadership and Firebase integration.

Next: Hackathon 2/3 — ExecuTorch Hackathon, IDK Button

Final part: Hackathon 3/3 — Cal Hacks 13.0, Drigil