-
-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial accessibility #576
Conversation
Resource file modification to make ReaLearn usable with screen readers. (only rc file is updated, tested on Windows only)
Awesome, thanks. I still need to review the changes and see if they cause any issues, e.g. when using SWELL to make it work on macOS and Linux.
ReaLearn doesn't create dynamic controls, it only shows/hides existing ones. How would this be approached? |
I have forgotten shared group mapping panel.
Once I start modifying the code, I will check SWELL is happy with the changes under Linux. Unfortunately I don't have macOS. I better describe in details what I am doing, it is easy to break accessibility, so all GUI modifications should be done with that in mind.
So in my todo list for code changes: Other that these relatively minor changes, everything sounds good for me. Several users have replied they are willing to test. |
Spotted by SWELL under Linux
Works at Linux as intended, for some reason does not completely work on Windows. But in both cases the order is reasonable now.
…nto accessibility
I have somehow solved tab order problem (one call is not working on Windows... but the result is still ok there). Primary fix was in Window.move_to(). Without explicitly forbidding ZORDER change, "null" in the second parameter is interpreted as HWND_TOP, request to change tab order. |
Group elements are behind sliders, included into visibility controlling code. Tested on Windows and Linux. This time with rc_mac_dlg and bindings generated under Linux.
So, I will publish custom Windows build on RWP mailing list and wait reaction. I think I am done for now, till someone spot a bug. Please check it works on MacOS when you have time. I guess some of potential users will wait at least till some pre-release is published by you. |
Great PR, thanks a lot. |
I just had a quick test on macOS and everything seems to work. Really nice work! I'll boot up my Windows machine later today and make a test there including the narrator. But you tested that already so I think that should be fine. So I guess we can merge this today. |
Please don't merge yet. There is at least one problem with panels order... |
Okay. |
Since in the Mapping window the focus is positioned correctly in Linux and Windows, not that I understand why, default order is working better.
At least there are no known for me general problems now. The last change was just removing explicit ordering for the Mapping Header, it was bugging on Linux. I think in its current state this PR is safe for merging. |
Ah... sorry. I don't have that on Windows and Linux. The problem with original labels they are not groups. So visually they are "in the near", but screen readers are not so smart. There are just 2 ways to achieve good results:
I don't have good proposal to solve the problem without changes. Without these extra groups it will be very difficult to work accessible way. But extra labels on Mac are clear "no go". Can you check what will happened if the group is behind edit controls? it will be announced at less convenient place, but I think that still will give sufficient hint for what Min/Max in the near are. |
Thanks for your suggestions. Another way would be to remove those extra groups on macOS. I'm actually just working on a little build-time helper that allows me to generate the RC file from a simplified data structure. Then it would be very easy to just not add the groups on macOS. The reason I write this helper is that I'm not very satisfied having to use a resource editor to adjust the GUI layout. Yesterday I wanted to put all control elements a bit closer together and realized it's such tedious work if the resource editor doesn't provide specific support for it. When generating the RC file with code, this becomes trivial because one can just use variables and use scaling factors. Also it could be easier to enforce the accessibility requirements which you mentioned. It would be very easy to forget them when editing such a big dialog with a visual editor. Plus, I don't know any cross-platform resource editor. |
I have edited RC file as text to order things properly. Since you have controls under each other and it seems like current VS editor has no ways to order controls usable way (I mean I have not found something like Tab order Wisard in ResEdit), I think any solution will be better then VS editor... |
@AZSlow3 FYI, it's done. The canonical source of truth for the dialogs is now here: https://github.com/helgoboss/realearn/blob/master/dialogs/src/lib.rs So from now on, one needs to modify the Rust code instead of modifying the rc file directly. |
Resource file modification to make ReaLearn usable with screen readers.
(only rc file is updated, tested on Windows only)
Pre-words.
REAPER is primary DAW for visually impaired and blind musicians. But the number of accessible plug-ins and scripts is limited. Some developers support accessibility long time (Cockos), some have started to move in that direction recently (NI, iZotope, JUCE), other are "friendly", but don't have time/resources and yet there are many who simply ignore the problem.
There is (relatively) big REAPER community (RWP) which tries to improve the situation using all possible directions. I am (sighted) programmer which tries to help, with dedicated own projects (SIBIAC, AOSC), commiting to REAPER accessibility project (OSARA) and looking around what else can be done.
I am using ReaLearn myself (btw thanks!), and I think with limited effort (thanks to standard controls in UI) it is possible to make this plug-in natively accessible.
This pr is just the first step, but even that allows using the plug-in accessible way. Several more changes (in the code) are required to make the process convenient (primary fixing the order in which dynamic controls are created and explicitly moving focus in case current control is going to be disabled). If you agree, I will (slowly) move on, also I will try to find beta testers.
In case you want understand what it is all about, under Windows press Ctrl+Win+Enter to turn on Narrator. Navigate with Tab (between some controls with arrows) and listen what is reported. To press a button use Shift+Space (Space alone as you know is intercepted by REAPER). Apple also has build-in screen reader, but I don't have Apple and so I have no idea how to use it. REAPER under Linux is currently not accessible, so that platform is out of interest at the moment.