Screen Reader accessibility issues

[pitermach]

Hello,

I recently got set up with the goxlr-utility on Windows. I'm blind and use a screen reader and the official app is completely unusable due to it being written using an older version of Juce, so blind goXLR users have been resorting to reverse engineering and manually editing the profile XML files or asking someone to help make configuration changes. Having access to an alternative UI is an absolute game changer, and even now this web UI is way more usable than the official app!

That being said there are a few issues which make some things more difficult to do with a screen reader. I tried to write them down in order of severity, and since they're all accessibility related I'm putting them in this one ticket. If you later want me to open separate issues for these let me know.

• Slider adjustments from the keyboard don't take effect - If I look through the page with the screen reader or tab through I can see every slider control as both a slider and text field and can use the arrow keys to adjust it, and the label in the UI updates. However, these changes aren't sent to the GoXLR, that only seems to happen if I simulate a mouse click on the slider's location. Since the screen reader can only click in the center of a slider and not drag it anywhere this makes it impossible to make any adjustments from the keyboard
• Some buttons in the UI, particularly the controls for profile management as well as the checkboxes in the rooting section, are not exposed to accessibility at all. In the best case, I was able to pick them up as empty "clickable" items after turning on the reporting of lines that have onclick events in the screen reader, but by default these lines would just be ignored. If these buttons get both an aria-role of button (or checkbox for the routing controls) and appropriate labels to tell us what the buttons do then the screen readers would pick them up correctly.
• There is a similar issue with a number of the radio button type controls in the UI (IE selecting the microphone type or configuring the faders), though here the screen reader can see the text and announces it, but not which option is checked. Here a radio button role would be the most appropriate and also setting aria-checked on the ones which are selected.
• For the dialogs that you get IE when saving a profile or entering microphone setup, the dialog itself should get the dialog role and the first control inside it should get focused. That way the screen readers would announce that a new dialog asking for something just opened, because currently nothing happens and you have to look where the new controls popped up.
• Lastly, a few controls could be Read a bit more logically - For example, the button to close the mic setup is literarly just a letter "X", where it would be better if it was announced as a button labeled "close" or "Cancel". Similarly, when adjusting the various effects the ">" and "<" buttons to expose more advanced controls should probably be marked up as a button labeled something like "More Controls", and have aria-expanded set on it if the extra controls are visible - this would cause the screen reader to read it as "expanded."

There are a few more minor things that could be done to speed up navigation, like adding navigation landmarks to the tabs and grouping the different sections of controls into labelled regions (screen readers have dedicated hotkeys for region/landmark navigation), but the issues above are the most important - especially the first 2 can make performing some tasks impossible with a screen reader.

To reproduce these, run the web UI with any screen reader. I was testing with NVDA in Brave and Firefox, but Orca on Linux should also let you see them (probably easier to test in Firefox because chromium browsers on linux need some extra configuration to enable accessibility). When you navigate into the page, both NVDA and Orca treat the page like a document in a word processor, so you use down and up to navigate the page line by line, while pressing enter on a control will either cause it to be pressed or let you adjust it from the keyboard (like entering text into an edit field or adjusting sliders)

If you have any questions or need help testing I'll be more than happy to help. Like I said in the beginning, the work you did here is a game changer and I can see both myself and other blind streamers switching to goxlr-utility full time because of how the UI works here.

[FrostyCoolSlug]

Massive thanks for thedetailed feedback, I've not had much experience with accessibility on the web, so I appreciate the detailed recommendations, and advise on testing.

I'll take a look at the headline items described above and see if I can improve them for the upcoming 0.9.0 release, then put immediate focus onto improving it further for 0.10.0 :)

[FrostyCoolSlug]

Been going through some components and how they work, in a lot of cases simply changing a button list to a respective checkbox / radio box setup should be straight forward, same applies to the routing table (turning the into proper checkboxes), I do have a question in regards to the approach to the profile list.

Items in the profile list have 2 states, 'selected' is the currently selected item used in the buttons at the bottom (new, clone, delete, etc) and 'active' which is the currently active profile.With a mouse Single clicking selects a profile, where double clicking activates a profile. Visually they're represented by two separate colours

What would be the best way to relay this information to someone visually impaired? I could use a radio list for selecting, but I'd still need to have a way to activate a profile, and explain that a profile is currently active, hopefully you can help with some suggestions there :)

[pitermach]

Hmm. If this were a desktop app, the way I would imagine this is the profiles would be in a list that could be navigated with the arrow keys and that would determine which profile is selected and then pressing enter on one would activate it, that would also make the relationship between it and the other buttons obvious. But that would be much more complicated to implement ☺️

First idea that comes to mind is you can do the radio buttons like you suggested, and for the profile that's active just append the word "Active" to the end of its accessibility label, I think that would be clear enough. And maybe to make it more obvious that you need to double click a profile to activate it, for the profile which is selected but not yet active add something like "press again to activate" to its label.

[FrostyCoolSlug]

Thanks! Thinking about it more, it should be possible to acomplish the top case relatively easily.. The 'Active' profile is just a small flag which could apply a class for visual identification, and also add a tip for the visually impared when they reach it. For the radio list, I could have the page automatically select whichever entry has focus allowing for selection via arrows..

Items in the profile list have an extra 'menu' attached to the right of it with more options (primarily 'Load Colours Only')I might see if I can extend that menu to include other options and steer users towards that when they hit enter on an item, which will give them more direct access to things like Load / Clone / Delete, and instead limit the buttons at the bottom to simpler 'New' and 'Save' option, which would likely make more sense when interacting. Will give that some thought :)

Thanks again!

[FrostyCoolSlug]

Ok, busy night for me getting through these, but progress has been made:

• Sliders now correctly respond to keyboard input
• General Improvement
• • Routing Table has been switched to checkboxes, with each checkbox having an appropriate description
• • I've put in keyboard interaction with the submenu in Profile Management, so profiles can now be loaded
• Buttons on the Faders section of the Mixer are now keyboard interactive (There are still a LOT of other places where this needs to be changed, so at least initially I'm focusing on basic setup).

I still have modals to do, and of course, more descriptive other buttons, hopefully I'll get to them soon :)

If you have a few moments to test the work done so far and point out any obvious problems, it would be appreciated. It's been pushed to the dev-0.9.0 branch of the GoXLR Utility.

[pitermach]

Thanks for all your work, I didn’t expect to see improvements this quickly! ☺️I’m currently at work but I’ll test the changes as soon as I get home.Sent from my iPhoneOn 21 Dec 2022, at 10:22, Craig McLure ***@***.***> wrote: Ok, busy night for me getting through these, but progress has been made: Sliders now correctly respond to keyboard input General Improvement Routing Table has been switched to checkboxes, with each checkbox having an appropriate description I've put in keyboard interaction with the submenu in Profile Management, so profiles can now be loaded Buttons on the Faders section of the Mixer are now keyboard interactive (There are still a LOT of other places where this needs to be changed, so at least initially I'm focusing on basic setup). I still have modals to do, and of course, more descriptive other buttons, hopefully I'll get to them soon :) —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[FrostyCoolSlug]

I've created a 'Project' in the org specifically to handle accessibility issues, and to keep track of what I've done, and what needs to be done, also makes it easier to keep up-to-date on changes :)

https://github.com/orgs/GoXLR-on-Linux/projects/1/views/1