extending API to automate accessibility for screen reader users

[derek]

I’ve been exploring ways to improve the accessibility of RadioBoss for screen reader users like myself,particularly with NVDA. While the current approach of manually adding labels to each individual control works, I'm sure that it is a tedious, time consuming operation. However, that does not nullify the importance of accessibility. Having said that, I believe we could use the Remote Control API to achieve a more dynamic and scalable solution.

Rather than constantly pointing out unlabeled parts of radioboss, I was thinking of getting an NVDA addon written which could use the API to get missing information; However, The API would need to be extended to do this.

Could you create a function that would return the name of the currently focused control? This would make it straightforward for an NVDA add-on to provide accessible descriptions.

If so, the addon could check to see if a focused control has a label. If so, NVDA would behave normally. If the label didn't exist, the addon could get the name of the focused control from the API.

Alternatively, the NVDA addon could scan for missing labels every time a new window appears, then send information to the API to get the labels for the fields, then you wouldn't have to have a command that tracks the navigation of the user.

If the API were further extended to be aware of controls in the included applications, such as the track tool, and music library, that would be a massive time saver as well.

 

[djsoft]

Could you create a function that would return the name of the currently focused control? This would make it straightforward for an NVDA add-on to provide accessible descriptions.

This is actually what accessibility support in RadioBOSS already do - it provides the name of the focused control via a MSAA API. So if the control is named this way, it's already accessible.

 

[derek]

This is actually what accessibility support in RadioBOSS already do - it provides the name of the focused control via a MSAA API. So if the control is named this way, it's already accessible.

I should have been more clear. I was actually talking about the remote API. The idea was that the addon could query that with window handles or some sort of identifier, with the remote api returning the values. The addon would assimilate that information so that the experience for the end user is the same.

I'm working with a guy who is using the remote API to get status information for the mic. The addon will pass the f8 key through to radioboss, check the status of the microphone through the remote API, and then report if its on or off.

I was hoping that we could get labels from the remote API so that you didn't have to add code to each field in practically every window.

 

[djsoft]

The idea was that the addon could query that with window handles or some sort of identifier, with the remote api returning the values.

I'm not sure it will work. The purpose of the Remote Control API is completely different.

I'm working with a guy who is using the remote API to get status information for the mic. The addon will pass the f8 key through to radioboss, check the status of the microphone through the remote API, and then report if its on or off.

The mic API command allows changing and querying the current status of the microphone. There's no need to send F8 key to control the MIC, this can be done via the API command.

I was hoping that we could get labels from the remote API so that you didn't have to add code to each field in practically every window.

If API is to return this, we have to label it, and if we have to label it, we better do it for MSAA so any screen reader can read this as this is the standard approach for handling accessibility.
If you really need to get the controls inside the RadioBOSS window you can use Windows API e.g. EnumWindows and other functions. But this is going to be a lot of work.