Please consider screenreader accessibility

[henning]

I am a blind linux user desperately searching for an usable DAW for years. Once per year I install the recent version of Ardour and try how far I can get with only using the keyboard and using Orca, the screen reader for the blind on Linux.

As stated in the manual, nearly every action in Ardour is supposed to be controllable from the keyboard, which sounds verry promising in theory, although there are several obstacles preventing me from getting productive with Ardour:

• The tab and arrow keys are grabbed by Ardour and key presses are not passed to the operating system. This does not only apply to i.e. the editor window, where tab seems to be used to set a mark, but also to the preferences window, where the tab key has no practical effect, but blocking of the keys prevents me from navigating in the settings dialog with the keyboard. Another example of a dialog which can’t be navigated with the keyboard is the key bindings editor.
• to become more accessible with a screen reader, Ardour’s ui elements need to be focusable and controllable with the keyboard and need to implement accessibility information such as textual describtions of graphical elements and object relations.
• The mixer and editor windows are stronly based on visual elements which are just non-existent for screen readers if there is no semantic information provided via the accessibility interfaces. For example I can not tell whether one or more tracks are currently selected. Not to talk about midi or waveform editing.

I’m aware of older discussions here in the forum and the bug tracker and actually the reactions there were the reason why I haven’t posted earlier.

However from what I read it seems like you plan to rewrite or at least revisit parts of the UI in the not too distant future and I would like to take the oportunity to raise the awarenes for screen reader accessibility.

I understand you have limited developer resources and most probably a long todo list, but there are also lower hanging fruits such as not grabbing the tab and arrow keys if any possible and adding accessibility information here and there. And developing an accessible application is much less work if you care about the topic as early as possible. As a start, just put away your mouse and try how far you get with ardour.

I am not talking about creating an alternate (bliend-friendly) interface, but about making the existing interface usable for the blind, at least as far as possible. GTK/ATK includes everything it needs.

My developer skills are not sufficient to significantly work on the accessibility implementation myself, but I am able to compile Ardour from git and of course I would be available to test or try to answer accessibility related questions.

[x42 (Robin Gareus)]

Have you considered ecasound?

There are a few visually impaired users on the Linux Audio User email-list, who use ecasound and text-based GUI “Nama” with either a braille display or screenreader.

Sadly Ardour’s main GUI evolved in a way that is not suitable to be accessible, and highly depends on visual and mouse interaction.

[x42 (Robin Gareus)]

Ardour uses Gtk only for Dialogs, Window abstraction and layout.

Gtk offers nothing for a timeline editor, and the mixer. Those are all custom interfaces, and also use hardware graphics acceleration where applicable. ATK is not applicable.

Next problem are plugin GUIs…

[henning]

Yes, I think I know nearly all work-around and compromise solutions and also played around with Ecasound several years ago. However reading this as a reply to my request for considering accessibility in Ardour is quite frustrating.

The fact that an application uses graphical elements doesn’t mean it can’t be used efficiently by a blind user. A good example is Musescore, which became pretty usable for screenreader users since version 3. Audacity is pretty usable too, although only on Windows, as wxWidgets implemented full accessibility support only on windows. Reaper seems to be accessible as well, thanks to some 3rd-party plugin, but also only on Windows.

I am not expecting quick results and of course for full support of the timeline editor and other custom UI elements there is some work to be done. But as I wrote there are also lower hanging fruids. And if you are working on UI elements anyway, screenreader accessibility is something you could consider.

I am not asking for promises, though my hope is you don’t just discard the topic because of the assumption a blind user can not use (or take advantage of) a GUI based music/audio editing software.