61
Feature Suggestions / Re: Accessibility for blind and low vision users
« Last post by Gary on October 16, 2024, 07:45:42 PM »Excellent observation!
Recent Posts
62
Feature Suggestions / Re: Accessibility for blind and low vision users
« Last post by SemlerPDX on October 16, 2024, 01:20:08 PM »I feel that if any hotkeys are added to the main application window of VA such as arrow and tab keys, it should be a check-box style option that is off by default. This would avoid potential issues with users who have bound keys that would otherwise be used for Windows Navigation to voice commands, including TAB and directional arrows, etc.
63
Feature Suggestions / Re: Accessibility for blind and low vision users
« Last post by Rauderberg69 on October 13, 2024, 08:05:38 PM »Thank you very much forthe quic response,I will shoot that email off today. Appreciate your willingness for the changes.
64
Feature Suggestions / Re: Accessibility for blind and low vision users
« Last post by Gary on October 13, 2024, 07:06:44 PM »Thank you so much for taking the time to write this. I will take all of these into consideration in further updates.
If you would like to assist in this endeavor, would you mind emailing me over at support@voiceattack.com? I have some specific questions I would like to ask and would need your input.
If you would like to assist in this endeavor, would you mind emailing me over at support@voiceattack.com? I have some specific questions I would like to ask and would need your input.
65
Feature Suggestions / Accessibility for blind and low vision users
« Last post by Rauderberg69 on October 13, 2024, 05:41:11 PM »Greetings,
As a member and leader of the Blind Gaming Club, a community of blind and low-vision gamers and content creators, I’m reaching out regarding the accessibility challenges we’ve encountered with Voice Attack. Personally, I've been using Voice Attack for over eight years and find it to be an excellent tool with versatile applications. I’ve enthusiastically recommended it to many of our members, but due to some accessibility limitations, most have hesitated to purchase it, as they can’t fully utilize the software.
I am writing this report to highlight some of the key accessibility issues and propose solutions that would significantly improve the experience for blind and low-vision users. Thank you for taking the time to review these points.
Main Window Accessibility Issues
Issue 1: When navigating the main window using Tab or arrow keys, nothing is read aloud by the screen reader. While I can tell that there’s some movement within the window, it’s not clear where the focus is, as I have limited vision. Occasionally, I notice the cursor moving up and down the list of recent voice commands, but this isn’t consistently accessible.
Issue 2: The list of recent voice commands that Voice Attack has heard is not read aloud by the screen reader. This makes it difficult to verify what Voice Attack is hearing or responding to, limiting the usability of the software.
Issue 3: The dropdown list for profiles isn’t navigable with Tab or arrow keys, and when I do manage to open the list, my screen reader does not read out the available profiles as I scroll through them.
Issue 4: Although there are shortcut keys for editing, importing, and exporting, the buttons on the right-hand side of the main window are not accessible through keyboard navigation. This is especially problematic for accessing the settings button, which I haven’t found a way to reach without using sight.
Profile Editing Window
The profile editing window is navigable with a screen reader, though there are still some accessibility challenges.
Issue 1: Several buttons in the window are unlabeled, with the screen reader simply announcing them as “Button.” I believe these buttons are located to the left of the Apply button near the bottom.
Issue 2: When these buttons are highlighted, a tooltip appears, but the screen reader does not read it out. This seems to be a common issue throughout the program, where tooltips are inaccessible.
Command Editing Window
While the command editing window is generally accessible and easy to navigate, there is a significant issue related to selecting key presses.
Issue 1: When setting up a key press (e.g., SHIFT+A), there is no way to finalize the selection without disrupting the input. If I attempt to confirm the selection using the shortcut for the OK button (ALT+O), it changes the key press to ALT+O instead. A possible solution could be adding a setting to automatically confirm key selections after a short delay (e.g., 15 seconds), or perhaps the development team might have a better approach to solve this.
Settings/Options Window
The settings and options window is accessible with a screen reader, and I was able to navigate through all the tabs without encountering any issues. The main challenge is accessing this window from the main interface, as mentioned earlier.
Conclusion
Voice Attack is a highly valuable tool with reasonable accessibility in some areas. However, the main window's accessibility issues make the software nearly unusable for blind users. With a few targeted improvements, Voice Attack could become a fantastic asset for the blind and low-vision community, empowering them to utilize voice commands effectively. I hope this report provides helpful insights, and I’m eager to discuss any potential solutions that could make Voice Attack more inclusive.
Thank you for considering these suggestions, and I look forward to hearing from you.
As a member and leader of the Blind Gaming Club, a community of blind and low-vision gamers and content creators, I’m reaching out regarding the accessibility challenges we’ve encountered with Voice Attack. Personally, I've been using Voice Attack for over eight years and find it to be an excellent tool with versatile applications. I’ve enthusiastically recommended it to many of our members, but due to some accessibility limitations, most have hesitated to purchase it, as they can’t fully utilize the software.
I am writing this report to highlight some of the key accessibility issues and propose solutions that would significantly improve the experience for blind and low-vision users. Thank you for taking the time to review these points.
Main Window Accessibility Issues
Issue 1: When navigating the main window using Tab or arrow keys, nothing is read aloud by the screen reader. While I can tell that there’s some movement within the window, it’s not clear where the focus is, as I have limited vision. Occasionally, I notice the cursor moving up and down the list of recent voice commands, but this isn’t consistently accessible.
Issue 2: The list of recent voice commands that Voice Attack has heard is not read aloud by the screen reader. This makes it difficult to verify what Voice Attack is hearing or responding to, limiting the usability of the software.
Issue 3: The dropdown list for profiles isn’t navigable with Tab or arrow keys, and when I do manage to open the list, my screen reader does not read out the available profiles as I scroll through them.
Issue 4: Although there are shortcut keys for editing, importing, and exporting, the buttons on the right-hand side of the main window are not accessible through keyboard navigation. This is especially problematic for accessing the settings button, which I haven’t found a way to reach without using sight.
Profile Editing Window
The profile editing window is navigable with a screen reader, though there are still some accessibility challenges.
Issue 1: Several buttons in the window are unlabeled, with the screen reader simply announcing them as “Button.” I believe these buttons are located to the left of the Apply button near the bottom.
Issue 2: When these buttons are highlighted, a tooltip appears, but the screen reader does not read it out. This seems to be a common issue throughout the program, where tooltips are inaccessible.
Command Editing Window
While the command editing window is generally accessible and easy to navigate, there is a significant issue related to selecting key presses.
Issue 1: When setting up a key press (e.g., SHIFT+A), there is no way to finalize the selection without disrupting the input. If I attempt to confirm the selection using the shortcut for the OK button (ALT+O), it changes the key press to ALT+O instead. A possible solution could be adding a setting to automatically confirm key selections after a short delay (e.g., 15 seconds), or perhaps the development team might have a better approach to solve this.
Settings/Options Window
The settings and options window is accessible with a screen reader, and I was able to navigate through all the tabs without encountering any issues. The main challenge is accessing this window from the main interface, as mentioned earlier.
Conclusion
Voice Attack is a highly valuable tool with reasonable accessibility in some areas. However, the main window's accessibility issues make the software nearly unusable for blind users. With a few targeted improvements, Voice Attack could become a fantastic asset for the blind and low-vision community, empowering them to utilize voice commands effectively. I hope this report provides helpful insights, and I’m eager to discuss any potential solutions that could make Voice Attack more inclusive.
Thank you for considering these suggestions, and I look forward to hearing from you.
66
Issues / Re: "Wait for Mouse Button Press" is not blocking mouse scroll events
« Last post by Pfeil on October 12, 2024, 02:00:52 AM »Both the action and commands use the same Windows features to hook mouse input, so yes, it's a matter of how the game retrieves input, which effectively circumvents the normal workings of the Windows mouse APIs.
67
Issues / Re: "Wait for Mouse Button Press" is not blocking mouse scroll events
« Last post by Jeremiah on October 12, 2024, 01:58:17 AM »It is the same behavior.
68
Issues / Re: "Wait for Mouse Button Press" is not blocking mouse scroll events
« Last post by Pfeil on October 12, 2024, 01:48:32 AM »Then it could be down to how the game's input system works.
VoiceAttack is using standard Windows API functions to intercept mouse input, but if the game uses a method that isn't affected by that, it would still detect the input.
Have you tested assigning the scroll input to the "When I press mouse" option of a command? Does that exhibit the same behavior?
VoiceAttack is using standard Windows API functions to intercept mouse input, but if the game uses a method that isn't affected by that, it would still detect the input.
Have you tested assigning the scroll input to the "When I press mouse" option of a command? Does that exhibit the same behavior?
69
Issues / Re: "Wait for Mouse Button Press" is not blocking mouse scroll events
« Last post by Jeremiah on October 12, 2024, 01:45:51 AM »I'm testing with the game Rust.
70
Issues / Re: "Wait for Mouse Button Press" is not blocking mouse scroll events
« Last post by Pfeil on October 12, 2024, 01:43:14 AM »Are you testing with normal desktop applications, or with games?