Plugins for the visually-impaired users- Att. all developers!
-
@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... :)
-
@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.
-
@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...
-
@ScottChesworth Thank you, Scott. I have faith in @Christoph-Hart . He has quietly delighted and delivered many times in the past.
-
Any updates on this? Any new additions in commit, or can anyone provide some tips for making my software accessible
-
@cassettedeath there's the initial work done for the NKS implementation so something is being done. And you can manually create keypress call backs for moving the sliders.
-
@aaronventure yup, NKS is maybe the best route for good accessibility - if you setup your plugin to be controllable through the NKS interface then there are lots of options for visually impaired users (at least that's what the NKS docs say).
I'll make sure that the NKS integration follows the accessibility guidelines from NI.
-
@Christoph-Hart Doesn't really help everyone else who doesn't use an NKS compatible keyboard - or a keyboard at all - and just wants basic screen reader support.
-
Yes! I've been trying to keep this in mind throughout development. Also the colourblind. A lot of UIs use 4-8 key colours that differentiate notes/instruments/drum types etc and it's really important to give a colourblind option for these. Very easy to set up too
-
This is awesome! I did my Music Technology Honours research on accessible music tech / Komplete Kontrol and found there’s a great community of Blind KK users.
Chris Ankin runs https://kk-access.com/ which is an awesome resource - I’m sure he will be stoked to hear Hise is moving in this direction and I’m sure he’d be happy to review any hise plug-ins built with this in mind.
Super promising. Thanks Christoph!
