Proposal Audacity 4 Blind
|Proposal pages help us get from feature requests into actual plans. This proposal page is about accessibility for Audacity for blind users.|
Proposal pages are used on an ongoing basis by the Audacity development team and are open to edits from visitors to the wiki. They are a good way to get community feedback on a proposal.
- Note: Proposals for Google Summer of Code projects are significantly different in structure, are submitted via Google's web app and may or may not have a corresponding proposal page.
Instead of using wxAccessible to make controls within Audacity accessible for blind users, this proposal splits Audacity into an audio engine and a GUI. The GUI handles visual-only aspects, bitmaps and mouse clicks and drags. The underlying audio engine handles the audio and selections. The interface between the audio engine and GUI is defined in files that SWIG can use, allowing us to script Audacity. So Audacity 4 Blind is closely related to Scripting. There is a concept of a 'clutch'. When it is engaged the visual GUI will track requests and changes made to the underlying audio engine. The GUI is plug-in, so it does not have to be present. In principle we could plug-in different GUIs.
The above gets us about half way to where we want to be with Audacity 4 Blind. It gives us a script based interface that exposes all the features. Proposed refinements include:
- Value tweakers - the ability to temporarily bind a variable to keyboard so that (for example) left and right arrow increase and decrease the value, and the step size can be varied while listening to the audio (depends on real-time improvements such as the real-time looping).
- More sophisticated keyboard shortcut methods.
- Efficient audio help information. For example we want to be able to list the functions that can be applied, and the user should be able to navigate through this list quickly without having to listen to it all.