@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 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 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 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... :)