Pro Tools has partial VoiceOver support, but plugin parameters and startup status are inaccessible. I defined the accessible behavior and directed a macOS implementation that exposes them.
What this project shows
I use Pro Tools every day. I knew what VoiceOver needed to expose, and I tested a working solution.
I specified how plugin parameters and startup status should behave, directed iterations on the implementation, and validated the resulting 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
- Deep domain knowledge in professional audio workflows
What the project implements
Two distinct accessibility improvements for Pro Tools, each solving a different kind of gap.
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. This turns 39 previously invisible controls into accessible, navigable interface elements.
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 this work matters
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
Platform-level integration using macOS accessibility frameworks.
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 are informed by over a decade of daily Pro Tools use. The accessibility layer matches the mental model a working audio engineer already has.
Broader context
This kind of work lives in the space between accessibility evaluation and engineering implementation.
This project shows the bridge I can provide: recognizing the gap as a real user, defining the correct experience, understanding the proposed technical approach, directing a prototype, and deciding whether the result actually works with assistive technology.
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.