godot
godot copied to clipboard
godotengine
Implement screen reader support using AccessKit library.
Initial implementation of the AccessKit integration use C-API:
All base (non-editor) controls except GraphEditor should work now. UI behavior without active screen reader should be unchanged. When screen reader is running, some controls that normally do not can accept keyboard focus (Label, RTL, TabBar) and extra keyboard actions (switching tabs, selecting RTL paragraph and embedded images/tables, selecting embedded TreeItem buttons).
Additionally, provides access to some accessibility related OS settings (high contrast, reduce animation, reduce transparency and screen reader status)
Screen recordings (updated)
https://github.com/godotengine/godot/assets/7645683/05cdce13-f8c9-4655-a689-7c4a14984ab5
Expects accesskit_sdk_path command line argument or environment variable with the path to the pre-build AccessKit-C 0.14.0 folder.
Supersede https://github.com/godotengine/godot/pull/72886 Fixes https://github.com/godotengine/godot/issues/58074 Implements https://github.com/godotengine/godot-proposals/issues/983 (partial) Implements https://github.com/godotengine/godot-proposals/issues/1964
Would it be possible, as a developer, to customize the spoken text and thus override some of the default text? I consider that although automatic mechanisms can offset a lot of work in making a game's accessible, there are always cases that need to be manually tweaked in order to provide a good user experience.
I've come up with a few methods of doing that in a project of mine (detailed here). Of those, being able to specify a method that can override the default spoken text, and recursively test for this method existence on parent nodes, has been a very useful workflow:
extends Node
...
func tts_text(focused: Control) -> String:
if focused == special_node:
return "This is a special node!"
else:
# Returning an empty string makes it keep visiting parent nodes, and if none overrides this, use the default implementation
return ""
Would it be possible, as a developer, to customize the spoken text and thus override some of the default text?
Yes, for the simple custom text, you can change Nodes accessibility_name and accessibility_description properties. Or, if you need a more complex behavior, you can implement a custom NOTIFICATION_ACCESSIBILITY_UPDATE notification handler and use DisplayServer.accessibility_update_set_* methods to config it. And then call queue_accessibility_update() to inform screen reader Node is changed.
Would it be possible, as a developer, to customize the spoken text and thus override some of the default text?
Yes, for the simple custom text, you can change
Nodesaccessibility_nameandaccessibility_descriptionproperties. Or, if you need a more complex behavior, you can implement a customNOTIFICATION_ACCESSIBILITY_UPDATEnotification handler and useDisplayServer.accessibility_update_set_*methods to config it. And then callqueue_accessibility_update()to inform screen readerNodeis changed.
That's awesome, fantastic work!
But it still will have a usual "node type, status, description" structure which depends on specific screen reader and its config (so if control type is button it's gonna say "Button. Custom name" not just "Custom Name" anyway). I do not think it's possible to fully override the screen reader prompt to a completely custom one, since we are only providing an information about nodes to a screen reader. What and when to read is up to the screen reader to decide.
Hi there. is the main editor supposed to work with screen readers as of yet? or only games? Thanks a lot for all the effort.
Hi there. is the main editor supposed to work with screen readers as of yet? or only games? Thanks a lot for all the effort.
Standard controls used in the editor should work, but the editor have a lot of custom elements. For most of them (like 2D/3D canvas editor), it will be really hard (if possible) to implement accessibility.
Hi, thanks. How do I enable the accessibility? I managed to compile it from source. Based on the code it looks like the accessibility or screen reader should be detected automaticly... When I am in the editor and I use the tab and arrow keys, it doesn't speak anything.
Hello. Would be possible for the future make context menus (like the menu bar) readable for screen readers? currently it only announces menu bar and it reads nothing, and that was possible with the old godot 3.2 with nolan's plugin. If yes, that would be very great, as with this current version, almost all is readable, but to start to messing with this as I did before with nolan's plugins, we need that the context menus become accessible/readable. thanks much!
Hi, just wondering what the progress is like on this PR? Is there any way I could perhaps help contribute or help?
Hi, just wondering what the progress is like on this PR?
What's implemented:
- Support for all main GUI controls and for adding accessibility features to the custom nodes.
What's not implement:
- Accessibility for the Godot editor (some support for the project manager is implemented, but not for the rest of the editor). There's no specific plans for it, a lot of editor parts use custom controls, and it's not fully controllable by keyboard only. This definitely won't be done it this PR.
Everything need to be tested, but since 4.3 is close to beta feature freeze and this is a lot of changes, it will be done probably done for 4.4 as soon as 4.3 is released.
What's not implement:
* Accessibility for the Godot editor (some support for the project manager is implemented, but not for the rest of the editor). There's no specific plans for it, a lot of editor parts use custom controls, and it's not fully controllable by keyboard only. This definitely won't be done it this PR.
Okay well can you work around that by using vs code as your script editor? Again I'm wondering if there is any way I can help or contribute?
Hello! Thanks a lot for this work! Unfortunately I cannot build this PR from source at current time but I have listened to the recording in the first message and for me as a blind developer who wants to work with Godot this sounds promising.
I will write my thoughts about what I personally expect from the editor and maybe that could help.
First of all, most of blind developers write code in some already accessible IDEs or code editors like VS Code. So I guess there is no need to implement the full code writing support. But the ability to view build errors I think is steel should be accessible.
All graphic-related stuff, such 2D and 3D canvas and drawing is not needed for a blind person because we actually cannot draw anything and implementing some kind of audible drawing is a huge problem and since the first attempt in 2008 nobody achieved any valuable result in this.
What we really really need is a project manager accessibility and I guess creating and editing scenes and nodes, because doing so entirely from text files can be a tough task.
Also if some kind of plugin manager or other project settings window exists we also need an accessibility of it.
As for games, not for an editor, maybe sighted developers would need some easier accessibility features but I guess blind developers will still implement their own screen reading logic in audio games. We already used to it and it is relatively comfortable for us to implement such things in every game. We already have several speech output libraries in C which help our games to communicate with any installed screen reader, from NVDA and JAWS to SAPI voices on Windows, speech-dispatcher on Linux and VoiceOver or NSSpeechSynthesizer on MacOS and other apple systems.
Kudos to you for the amazing work you've done on this, and it genuinely seems like the holistic approach we need in tackling the whole engine and making both the editor and Game UI accessible to screen readers that I have been hoping for years would come to Godot.
The FocusMode enum expansion for "FOCUS_ACCESSIBILITY" is a good, the choice of using NOTIFICATION_ACCESSIBILITY_UPDATE in the _notifcation() seems like a great idea and aligns with the existing architecture.
The only thing so far that raised my eyebrows was the change in String:utf8, but this is still a Draft and I'm not even sure if this will stay in the final pr (I am am an amateur in C++, I know just enough to read it).
Please let me know if there's anything I can do to help move this forward. I run Windows 10 and Fedora 40 with Gnome + Wayland and could do some testing on those platforms.
