Plugins for the visually-impaired users- Att. all developers!

[gorangrooves]

I just had my mind blown away. I was fortunate to have had a very informative and transformative meeting with one of our customers who is blind.

I think it is safe to assume that many (if not most) of you are just as ignorant as me regarding how visually impaired people use DAWs and plugins. "What? There are blind people making music!? Are you serious? How?"
I think there are far more such people out there than we are aware of, and most of them just put up with whatever is out there, made by us for us. It doesn't have to be that way, and it should not be that way.

So, as we advance, I want to encourage every one of you software developers to build your plugins to be 100% accessible to all. A little more effort on our behalf can make a massive difference to many. I am starting this thread for all of us to get better informed of this entirely different dimension to make better tools for more people.

Here are some things I learned today (edited).

• The text label for each HISE component that usually inherits the name of the element ID actually gets read by screen readers, and that is what blind users navigate by, even though it is not shown on the GUI. So, don't just leave the text as is. Please give it a meaningful name like kick volume, main volume, etc.
• Blind users listen to screen readers at surreal talkback speeds. When naming elements, start with the unique identifier. For example, instead of calling it "slider kick," name it "kick volume" so they can quickly scroll through the elements without waiting and listening to the common word between multiple elements.
• The screen readers detect the element type, so those don't need to be included in the names. For example, there is no need to include the word "button" in the text for such an element. The screen reader will let that user know it is a button when reading the name of that element.
• Most users will navigate through elements using TAB (forward) and SHIFT+TAB (back).
• Values of elements should be adjustable by using the arrow keys up/down and, ideally, also Page Up/ Page Down and Home / End for large increments.
• To test how your plugins function in a screen reader, use VoiceOver on Mac and NVDA for Windows systems. If they work well on those, they will work just as well on other systems.

While I discovered things I could quickly fix in my plugins, some issues will require @Christoph-Hart 's help.

• BUG: Slider values can not be adjusted using arrow keys, nor page up/down, home/end.
• BUG: The defaultValue of a slider (e.g., "0.845") is presented to a screen reader as the element's name instead of the text field value (e.g., "kick slider").
• BUG: Buttons are read as "checkbox" element type. Can you please change this to say "button"?
• Can we have the ability to exclude specific elements from being read by screen readers, such as icons? For example, I have many icons behind buttons that blind users must scroll through to access functional elements.
• A nice touch would be a visual highlight of some sort for the element which has been selected using TAB. I know it is not for the Blind, but it would improve overall usability.

That's it for now. I am excited by the idea of being able to make my products fully usable without even seeing them.

[d.healey]

@gorangrooves said in Plugins for the visually-impaired users- Att. all developers!:

I just had my mind blown away. I was fortunate to have had a very informative and transformative meeting with one of our customers who is blind.

I think making plugins accessible is very important, also making them multi-lingual (but that's another topic).

• The text label for each HISE component that usually inherits the name of the element ID actually gets read by screen readers, and that is what blind users navigate by, even though it is not shown on the GUI. So, don't just leave the text as is. Please give it a meaningful name like kick, main, etc.

That's difficult because we often use the text property for other things. I like to use it to set the icon name for a button, then in my script I just get the svg path that matches the text. It would be better if the screen reader could read the automation ID.

• BUG: The defaultValue of a slider (e.g., "0.845") is presented to a screen reader as the element's name instead of the text field value (e.g., "kick slider").

@Christoph-Hart If you fix this use the automation ID or add a screen reader ID field, I'm already abusing the text field too much to change my ways.

• Can we have the ability to exclude specific elements from being read by screen readers, such as icons? For example, I have many icons behind buttons that blind users must scroll through to access functional elements.

What do you mean by "icons"? Are these buttons you attached images to, or drawn on a panel, or something else?

[gorangrooves]

@d-healey As long as we can somehow specify text that screen readers can use, it doesn't matter where that is inputted, as far as I am concerned.

By icons, I meant images, which could also be any elements that serve an essential visual purpose but only get in the way of screen readers. Just having some checkbox to exclude elements from being read by screen readers would go a long way.

[ScottChesworth]

@gorangrooves said in Plugins for the visually-impaired users- Att. all developers!:

I just had my mind blown away. I was fortunate to have had a very informative and transformative meeting with one of our customers who is blind.

The feeling is mutual dude. It's been a long time since I met with a dev who was so keen to learn about accessibility that they jumped straight into their code still on the call!

Just popping in here to clarify/add a few details...

• The screen readers detect the element type, so those don't need to be included in the names. For example, there is no need to include the word "button" in the text for such an element. The screen reader will let that user know it is a button when reading the name of that element.

Yes and no. Screen readers will speak labels, roles and states of each control as we navigate. For example, when navigating a proper accessible GUI we might hear something like "Awesome sauce check box unchecked" if we haven't enabled the awesome sauce yet, but there's no detection in the equation per se. Those labels, roles and the available states for each role need to be set correctly and communicated by whichever development environment is being used to build the GUI. HISE is already doing this to an extent, but hopefully there's potential for some refinement.

• Values of sliders should be adjustable by using the arrow keys up/down and, ideally, also Page Up/ Page Down and Home / End for large increments.

Convention would be Up/Down for fine adjustment, PageUp/PageDown for larger increments, Home/End for maximum/minimum values. If those keystrokes could work automatically set to sensible default values, but also have the increments of movement customizable per project, that would be the ideal scenario.

• To test how your plugins function in a screen reader, use Narrator on Mac and NVDA for Windows systems.

VoiceOver is the screen reader for Mac OS and iOS. On Mac, you can toggle it on/off by hitting Command+F5. On iOS, go to Settings -> Accessibility (or just tell Siri to "turn VoiceOver on"). Note that in both cases, navigating with VoiceOver will require you to get familiar with a few new concepts, there's good docs at https://apple.com/accessibility, or feel free to shoot me a PM on here if you get stuck.

Narrator is the screen reader that comes built into Windows. It's a decent reader nowadays, but hasn't managed to shake off a longstanding reputation from the many years where it wasn't any good, and consequently it doesn't have much real-world adoption. You can toggle Narrator on/off with Control+Win+Enter, but as Goran said above, I'd encourage you to test on Windows using a free and open source screen reader called NVDA instead, it's got the widest adoption and is under much more active development.
NVDA can be grabbed from https://www.nvaccess.org/download/

Lastly, the quickest way to learn about accessibility will be observing actual screen reader users. There are plenty of us who are happy to help, I administrate a couple of super active groups around this stuff and am in contact with hundreds of people all over the world every day who are hankering for more accessible tools. If you've got something in development that you want feedback on, feel free to reach out.

• BUG: Slider values can not be adjusted using arrow keys, nor page up/down, home/end.

This one can be a real showstopper. @Christoph-Hart, anything you can do here would be a huge help.

• BUG: The defaultValue of a slider (e.g., "0.845") is presented to a screen reader as the element's name instead of the text field value (e.g., "kick slider").

Just to clarify, it is useful to hear screen readers speak the default value, we do need a way to associate a label/textual name for the slider in addition though, otherwise it's not possible to know what a slider will adjust.

• BUG: Buttons are read as "checkbox" element type. Can you please change this to say "button"?

The NVDA log tells me HISE buttons are currently Role.CHECKBOX. These need to be given role.PUSHBUTTON instead. Off the top of my head I don't know the equivalent role over on the Mac side, can find out if needs be, or you can probably just compare it to a standard Mac OS button in Apple's Accessibility Inspector tool to find out the expected role.

• Can we have the ability to exclude specific elements from being read by screen readers, such as icons?

I understand why you'd want this, it would give you more control over the UX, but right now it would be kinda dangerous in practice. Reason being, we're not at a stage where a GUI being accessible is the norm yet, and there are often times where using more advanced screen reader navigation tricks to read everything we can get at is the only way to figure out how a partially usable GUI is supposed to work.
IMO, a neater approach would be providing some way to easily build a tab order and control what is included in it. That way, users can navigate easily whenever a dev does provide a tab order, but there's still a chance to poke around and figure out workarounds when that's not the case.

• A nice touch would be a visual highlight of some sort for the element which has been selected using TAB. I know it is not for the Blind, but it would improve overall usability.

Big +1 on this. Clarity around what's selected is just good UX across the board.

Hmm, that turned out to be longer than expected... :)

[gorangrooves]

@ScottChesworth Thanks a lot for clarifying those details. I edited my original post to fix some obvious errors

Regarding hiding specific elements for screen readers, here is what I am thinking.
No element would be hidden by default. So, if a developer goes about hiding particular elements, this would be done strategically with the intention of better usability for blind users. Therefore, they will most likely make an effort to properly label and organize other elements. I don't think this would be a dangerous issue in practice.

For example, I have a whole bunch of icons (which you came across) that serve no other purpose but to indicate the instruments to users looking at the GUI. These elements only add clutter and don't indicate anything to you. As you experienced, you are having to scroll through a whole lot of them to get to a usable element. You are not able to tell that a kick icon is directly below the kick audition button, so those icons serve no purpose to you.
Removing them from being accessed by the screen reader would clean up the layout and only leave the functional elements: buttons, sliders, knobs, etc.

Does that make sense, or am I missing something not obvious to me?

HISE already has a structure where we can group elements by placing them within panels or other elements. I think this would serve the same purpose as tab order. We have to test how certain HISE structures and element groups translate to screen readers.

What I would start with is being able to hide elements. I think that with that and those bug fixes, I would be able to tweak my plugins to be fully accessible to you in an easy and logical manner.

If it turns out that it is not possible to both group elements visually and have them function equally well with screen readers, the next step would be the implementation of a dedicated tab order.

[ScottChesworth]

@gorangrooves said in Plugins for the visually-impaired users- Att. all developers!:

While I discovered things I could quickly fix in my plugins, some issues will require @Christoph-Hart 's help.

Bumping this as Goran is getting near to a new release, but accessibility doesn't seem to have gotten any love yet...

[gorangrooves]

@ScottChesworth Thank you, Scott. I have faith in @Christoph-Hart . He has quietly delighted and delivered many times in the past.