Pro Tools has partial VoiceOver support, but plugin parameters and startup status are inaccessible. I worked out how they should behave with VoiceOver and directed the code that exposes them.
What this project shows
I use Pro Tools, so I knew what VoiceOver needed to reach.
I decided how plugin parameters and startup status should behave, went back and forth on the code until it did that, and tested the controls and announcements in real Pro Tools sessions.
My contribution
- Identified and reproduced the inaccessible workflows
- Defined roles, labels, values, organization, and announcement behavior
- Directed technical investigation and implementation
- Tested the integration repeatedly with VoiceOver inside Pro Tools
What the project implements
There are two parts to it.
Plugin parameter access
Third-party audio plugins in Pro Tools expose their visual controls to sighted users but provide no accessibility information to VoiceOver. The implementation discovers hidden plugin parameters and presents them as VoiceOver-readable sliders with real-time value readback. That made 39 controls VoiceOver couldn't see before reachable.
Startup status announcements
When Pro Tools launches, it displays a splash screen with loading status messages that are invisible to VoiceOver. The integration captures those messages from the framework method that updates the splash screen text, then surfaces them to screen reader users during startup.
Why I built it
I use Pro Tools for mixing and mastering. Every inaccessible plugin parameter means stopping what I'm doing and finding a workaround. These fixes let me stay in the session.
Technical approach
Accessibility element construction
Each discovered plugin parameter becomes a fully specified NSAccessibilityElement with the correct role (slider), label (parameter name), value (current setting), and position. VoiceOver treats these elements as native controls.
Framework interposition
Startup status messages are captured by interposing on the internal framework method that updates the splash screen. This approach reads the text as it changes without modifying the application's behavior or visual presentation.
Domain-informed design
Decisions about which parameters to surface, how to label them, and how to organize the accessibility hierarchy come from years of using Pro Tools myself. The goal was for it to be organized the way an audio engineer already thinks about a plugin.
My role
What my part was
I found the problem as someone using Pro Tools, worked out what VoiceOver should get, understood the technical approach well enough to direct it, and decided whether each version actually worked.
Implementation uses
- Objective-C and macOS Accessibility APIs
- NSAccessibility protocol implementation
- Framework method interposition
- Runtime introspection for UI element discovery
Want to see more of my work?
The portfolio includes web and mobile accessibility audits alongside these technical projects.