Accessware | Devpost

Inspiration

SpartaHack's theme pushed us toward social impact. During brainstorming, we asked: who tests the tools designed for the people who need them most? Accessibility hardware: joysticks, adaptive controllers, buttons, are designed and tested by able-bodied engineers. The gap between how they think users interact and how users actually interact stays invisible. We wanted to make that gap visible.

What it does

Accessware is a QA platform that uses a robotic arm to physically test accessibility hardware. It runs scripted test sequences: pushing joysticks, gripping buttons, simulating limited mobility and fatigue. Then it visualizes the difference between the designed path (how engineers intended the interaction) and the actual path (what really happened). We call this gap the desire path, like the worn grass on a lawn that shows where the sidewalk should have been.

The web dashboard shows a real-time 3D model of the arm synced to the physical hardware, with trail overlays highlighting divergence. Tests can be authored in JSON, recorded from the UI, or selected from a bundled library.

How we built it

Firmware: Arduino Nano (ATmega328P) with custom servo control via AVR timer interrupts, serial command protocol (MOVE,s1,s2,s3,s4,speed)
Backend: Python FastAPI + pyserial bridge, WebSocket streaming, motion interpolation mirroring firmware math
Frontend: Next.js 14, React Three Fiber for 3D visualization, Tailwind CSS + shadcn/ui with a Warm Industrial design system
Hardware: 4-servo arm kit, dual joysticks, buzzer for feedback

Challenges we ran into

Hardware was the biggest battle. Getting the Arduino, serial bridge, and web frontend to all talk reliably in real-time was brutal: timing bugs, serial port flakiness, servo jitter. Time pressure forced tough cuts.

Accomplishments that we're proud of

The "desire path" concept: turning an abstract accessibility gap into something you can see on a screen. And the landing page narrative that communicates the problem in seconds: "Who tests the tools designed for the people who need them most?"

What we learned

Hardware-software integration is unforgiving. Firmware math has to be mirrored exactly in the backend or the 3D visualization drifts. Also: the best project ideas come from asking who's being left out, not what's technically impressive.

What's next for Accessware

More test primitives (force sensing, timing analysis), a library of accessibility device profiles, and community-contributed test suites so teams can share and benchmark across different hardware.