Evaluating an Accessible In-Vehicle Interface

Accessibility / Usability / Mixed Methods

I led a mixed-methods study of an in-vehicle interface to learn how the same design works for people with and without disabilities.

RoleLead researcher
MethodReal-road simulator, SCAS, SUS, interviews
Participants41 people across three locations
DomainAccessible autonomous mobility
Diagram of a real-road autonomous vehicle simulator and interface factors including accessibility, safety, verbosity, and adoption.

Project Objective

Autonomous vehicles could expand mobility for people with disabilities, but inclusive design is not just about adding accessibility features. A feature that is essential for one group can become distracting or unnecessary for another. For shared autonomous vehicles, that tension matters because the same in-vehicle interface may serve riders with very different abilities, expectations, and risk perceptions.

The project asked whether accessible iHMI features change acceptance factors such as perceived safety, reliability, ease of use, control, and intention to use autonomous vehicles.

Project Approach

1. PrototypeEvaluated an iHMI with voice interaction, touchscreen controls, route status, landmarks, safety updates, music, phone, lighting, and temperature controls.
2. ScenarioParticipants completed a 20-25 minute real-road ride in a modified minivan using the RRADS method.
3. MeasuresCollected pre/post Self-Driving Car Acceptance Scale responses and post-ride System Usability Scale responses.
4. InterviewsRan post-ride semi-structured interviews and analyzed transcripts in MAXQDA using thematic analysis.

Timeline

IRB approval~3 months Setup + sessions~3 weeks Analysis~2 weeks

* Human-subjects IRB approval extended the calendar timeline; once approval was in place, remote setup, data collection across three U.S. locations, and analysis moved quickly.

Tools

Prototype

Developed the iHMI prototype in TypeScript and used Llama 2 for AI-enabled interaction support.

Quantitative workflow

Used Qualtrics for structured measures and R for scale scoring, group comparisons, and statistical analysis.

Qualitative workflow

Used Otter.ai for transcription support and MAXQDA for interview coding and thematic analysis.

Field coordination

Coordinated the RRADS vehicle setup, tablet interface, speaker setup, and participant sessions across locations.

Method Alternatives and Choice

Alternative: Survey-only approach

A survey could compare attitudes toward autonomous vehicles, but it would not show how safety, control, voice feedback, and information load changed after an embodied ride experience.

Alternative: Desktop or VR simulation

Desktop and VR methods provide more experimental control, but they reduce the real-world cues that matter in vehicle trust: intersections, pedestrians, traffic, motion, stops, turns, and the feeling of being a passenger.

Alternative: Closed-course test

A closed course would improve safety and consistency, but it would remove everyday route complexity and would have been harder to run with remote disability-advocacy partners.

Chosen: RRADS mixed-method evaluation

The Real Road Autonomous Driving Simulator balanced ecological validity and safety. Pairing pre/post scales with interviews let me quantify acceptance shifts and explain why participants with and without disabilities reacted differently.

Project Artifacts

RRADS minivan exterior, in-vehicle partition monitor, and passenger-side tablet and speaker setup.
RRADS vehicle setup: a modified minivan, partition-mounted front-view monitor, and passenger-side tablet and speaker.
Internal human-machine interface screens showing vehicle status, in-vehicle settings, destination entry, and phone controls.
Prototype iHMI screens: home/status, settings, map and destination entry, and phone controls with touch and voice affordances.
Violin and jitter plots comparing pre and post responses for perceived reliability, ease of use, intention to use, and desire to let automation handle autonomous vehicles.
Self-Driving Car Acceptance Scale results across four factors. The plots compare participants with disabilities and participants without disabilities before and after the ride.

Quantitative Signal

Reliability increasedDisability group: 4.63 to 5.50, p = 0.0003. Non-disability group: 3.91 to 4.83, p = 0.0001.
Ease of use increasedDisability group: 5.20 to 5.94, p = 0.001. Non-disability group: 4.91 to 6.08, p < 0.001.
Use intent divergedPost-ride intention to use was higher for participants with disabilities: 5.79 vs. 3.35, p < 0.001.
Usability was comparableSUS scores did not differ significantly between groups, p = 0.29.

Representative Data

77.27%of participants with disabilities expected time and surroundings information during the ride.
57.89%of participants with visual impairments wanted control over how much information the iHMI provided.
68.4%of participants without disabilities thought only safety-related auditory information was essential.
89.4%of participants with visual disabilities liked the voice user interface.

"I felt safe because it was giving us warnings about upcoming safety signal lights."

D8, on situational-awareness feedback

"I liked the fact that I had control; if I wanted to go somewhere, I could give the command."

D10, on independence and control

"It gives you a lot of information and a little bit of time."

D2, on information overload

"The vehicle didn't move until there was absolutely no oncoming traffic."

N2, on cautious behavior and perceived safety

Key Insights

Safety

Safety meant different things to different riders.

Participants with disabilities often valued situational awareness and independence. Participants without disabilities focused more on cautious driving behavior at intersections, lane changes, and pedestrian scenarios.

Information load

Essential accessibility feedback could become overload without controls.

Time, route, and surroundings information helped riders with visual impairments orient themselves, but some riders without disabilities saw repeated auditory updates as redundant.

Voice interaction

Voice interaction increased access, but responsiveness and pacing shaped confidence.

Most participants liked voice control. Desired improvements included better recognition, slower pacing when needed, interruptibility, and options for voice style or pitch.

Adoption

For some users AVs are independence infrastructure; for others they are convenience technology.

This difference explains why the same interface feature can feel necessary, optional, or distracting depending on the user's mobility context.

Design Recommendations

Make verbosity adaptive

Let users control how much information is spoken, and make the system learn route familiarity, context, and user preference over time.

Separate safety-critical alerts from ambient awareness

Keep essential safety updates prominent while allowing optional landmark, route, and status details to be reduced or paused.

Design for shared vehicle realities

Profiles can help personal vehicles, but shared AVs need adaptive settings that work when riders have mixed abilities and preferences.

Treat control as a trust feature

Provide clear destination confirmation, emergency options, voice fallback, and recovery paths when commands are not recognized.

Outcomes

Research outcomeUsed a real-road simulation to study trust, control, safety, and information needs.
Accessibility findingShowed why teams should test accessible features with both disabled and non-disabled users.
Product relevanceProduced guidance for interfaces that adjust information and controls to different user needs.

Broader relevance: The findings also apply to shared devices and services that use voice, audio feedback, personalization, and safety alerts.