Proposal Accessibility Console
|Proposal pages help us get from feature requests into actual plans. This page is a proposal to improve Accessibility.|
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.
The Audacity User Interface is visual, designed for sighted people. It isn't by default that accessible. We use Accessibility methods to improve on that, for example to improve keyboard navigation for VI users.
- The design is certainly 'visual first', so for example we get very long sequences of key presses to navigate through the toolbars. A sighted user moves the mouse directly to the control on the toolbar they want to use.
- Only built-in widgets are automatically accessible. Any custom draw widgets that we create, such as the vital track panel, requires explicit coding to make them more accessible.
- Our accessibility code is fragile and on occasion poorly maintained. When accessibility on the platforms changes, we struggle to keep up.
Leverage the scripting feature (which is text based) to provide a fully user customisable text console, designed for accessibility, for driving Audacity.
- The accessibility console would be general purpose, not specific to Audacity, designed for running arbitrary python scripts in a highly accessible way. It would be customised for Audacity by a machine-readable description of the Audacity commands and options and shortcuts and how they correspond to scripting commands. That description can be updated to fine tune the correspondence.
- Menu structure and short and long prompts for different parts of the menu would be totally customisable.
- Numerical values would become dynamically 'bindable' so that you could bind the mouse wheel (and X and Y) or later MIDI controller, to parameters you wish to control.
Pros and Cons
- Code for creating and navigating menus carries over very naturally to a console. With a separate keyboard driven console we could have far more customisation of how the menus get read by screen readers.
- We can also have user selectable customised menus, e.g. for different workflows.
- The same console makes integrating with other tasks and other programs easier, giving a boost to VI users of other programs that support scripting too, and is especially useful when using several programs to achieve a task.
- We can give better Auditory feedback, e.g. by making a sound when a value has toggled on or off, and a sound for progress dialog.
- Not all features of Audacity are yet scriptable.
- We would need to fix this, but we need to fix that anyway.
- The GetInfo() commands return 'too much' information for speedy VI use.
- We will need new methods to extract relevant information from GetInfo() output.
- If poorly designed, the system could be too complex to use.
- We will need good defaults that provide a keyboard driven experience similar to the keyboard driven experience directly in Audacity.
- Some plug-in effects may be a bit harder to make accessible.