Speculative redesign — educational purposes only. This is an unsolicited concept redesign of Moovit. It is not affiliated with, endorsed by, or produced in partnership with Moovit or Intel Corporation. All screenshots are from the public App Store listing and are the property of their respective owners. This case study is presented solely as a portfolio demonstration of UX research and accessibility design methodology.
Redesigning Moovit for low-vision and motor-impaired transit users
An unsolicited accessibility-first redesign of the Moovit transit app — built on participatory research with users with disabilities and a WCAG-grounded audit of every interaction in the current app.
Moovit reaches over 1.5 billion users globally and claims WCAG 2.1 AA compliance on web and VoiceOver/TalkBack support on mobile. But participatory research with disabled users revealed a gap between stated compliance and lived experience — 100% of screen reader participants failed the core navigation task on first attempt, and 2 of 3 motor-impaired participants abandoned mid-task.
AccessPath is a participatory-research-driven redesign of the Moovit experience — grounded in real co-research sessions with users with disabilities, a WCAG 2.1 AA audit, and an accessibility-first rethink of every core interaction.
8 of 9 research participants had never been consulted by a tech team. They had instead developed personal workarounds — alternative apps, sighted helpers, avoided routes — that compensated for the gaps in Moovit's accessibility.
Moovit has made accessibility investments — but participatory research found that the gap between WCAG compliance and real-world usability for disabled transit users remains significant. The redesign builds on Moovit's existing accessibility foundation and addresses the specific failure points surfaced by research with disabled users.
I don't need a perfect app. I need to know when to step off the bus without panicking.
Participant 04 · Low vision · Regular bus commuter
Unlike CareSync, AccessPath's outcomes are not projections — they are direct measurements from prototype re-testing with the same participants who tested the existing app. Here's what was observed and how each figure was recorded.
Baseline from existing app testing: All 4 low-vision participants and both participants with combined conditions (6 total) failed the core route search task on first attempt with the existing Moovit app. Failure was defined as inability to complete the task without researcher assistance. Screen recordings confirmed zero successful unaided completions.
Re-test with the AccessPath prototype: The same participants were given the identical task with the AccessPath hi-fi prototype. All 6 completed without assistance. Root cause was the missing ARIA landmark structure — the prototype's ARIA roles and landmark audio gave screen reader users the orientation cues the existing app entirely lacked.
Think-aloud validation: Participants narrated their navigation in both sessions. In existing app tests, every participant verbalised confusion at the custom map component. In the prototype re-test, none did — confirmed in coded think-aloud transcripts.
Tap-count audit of the existing app: The motor-impaired usability session included a tap-count log alongside screen recordings. The existing route search → results → select flow required a minimum of 7 sequential taps. Several targets were below 44×44px — Apple's HIG recommended minimum — making them particularly difficult for users with reduced motor control. WCAG 2.5.8 (AA, WCAG 2.2) sets a 24×24px floor; WCAG 2.5.5 (AAA) recommends 44×44px.
Prototype design constraint: The AccessPath interaction model was designed to the 3-tap target — swipe gesture shortcuts, persistent accessibility filter, and consolidated route cards all reduce sequential decisions. The 3-tap figure is the maximum path counted across all task scenarios in the hi-fi prototype, not an average.
Validated in co-design workshops: All 3 motor-impaired participants completed the route selection task in the prototype without abandoning — compared to 2 of 3 who abandoned entirely in the existing app session. One participant completed with a single swipe gesture.
The audit baseline: A full WCAG 2.1 AA audit of Moovit's three core flows — search, results, and active guidance — identified 23 distinct violations across all four POUR principles. The AI-assisted report (which reduced documentation effort by ~60%) organised them by severity and effort-to-fix to prioritise the redesign scope.
Violation-by-violation resolution: Each of the 23 violations was mapped to a specific design decision in the prototype — whether ARIA landmark structure, colour contrast ratios, tap target sizing, or ETA language clarity. Resolution was verified criterion-by-criterion during the handoff review, not claimed as a blanket pass.
Scope note: Compliance was verified at the prototype design level. A full engineering implementation would require additional automated and manual testing (e.g. axe-core, screen reader regression) before a live WCAG AA claim could be made.
Exit interview question: At the end of each hi-fi prototype session, participants were asked a single direct question: "If this were available as an app today, would you switch from your current transit app to use it?" 8 of 9 said yes without qualification. 1 said they would use both depending on journey type.
Context of the 9th response: The one participant who gave a qualified answer used Moovit specifically for its social trip-sharing feature — a feature not in scope for this redesign. Their hesitation was unrelated to accessibility functionality, and they rated the accessibility improvements as "much better" than the existing app.
Unprompted qualitative feedback: Multiple participants made unsolicited comments during testing — "this is what it should have been from the start," "I've never been able to do this without help before." These were not prompted responses and were coded separately from the exit interview question.
These results come from prototype testing with 9 participants — a small, purposive sample. They demonstrate that the design decisions resolved the observed failures for this cohort. Large-scale validation, automated accessibility testing on a live build, and longitudinal retention data would be required before these results could be generalised.
The WCAG audit found 23 violations. Participatory research found the anxiety of missing a stop, the shame of blocking the aisle, the workaround of calling a sighted friend. Neither alone would have been sufficient. Together, they produced a redesign that passed both tests.
Violations organized by POUR principle and severity using AI-assisted reporting reduced the audit documentation effort by ~60%, and let the time saved go into more research sessions. The AI wrote the report. The researcher decided what to fix first.