In color_picker.cpp _add_preset_button method, set_accessibility_name method using v_format with incomplete string "Color: #%" instead of "Color: #%s" which results in an error for every preset color.

Quick suggestion if it hasn't been considered already - a short document on best practices for using, configuring and organizing nodes, and support for features like calling strings directly or additional navigation. Something that explains to developers what to expect when they organize their nodes a certain way and how to test on various platforms. This would really improve accessibility implementation by ensuring people put nodes in a useful order, optimized for screenreader support etc.

A tutorial of a simple UI or game would be an excellent idea too. I could write the document but I'd need to be instructed on best practices and pull a demo together.

Thanks for the hard work everyone.

This is great and I have been waiting so long to be able to use a game engine! I'm wondering whether it is actually now possible for me (as a blind dev) to now actually make a game using Godot.
I'm trying to follow the step by step guide from the docs but don't really understand what to do since the editor isn't accessible yet. Can I just use VS Code and manually code the nodes myself?
I would also love to see a guide or page just telling people like me who use screen readers how to get started with Godot.

This is great and I have been waiting so long to be able to use a game engine! I'm wondering whether it is actually now possible for me (as a blind dev) to now actually make a game using Godot. I'm trying to follow the step by step guide from the docs but don't really understand what to do since the editor isn't accessible yet. Can I just use VS Code and manually code the nodes myself? I would also love to see a guide or page just telling people like me who use screen readers how to get started with Godot.

@paulGeoghegan
Hi! I'm unrelated to the devs of this awesome project, but I'm a sighted dev who makes accessible games.

I worked with some blind community members and made this website as a starting point, it has some addons that adds some additional features, and a "start here" tutorial. It's nothing crazy, just 1 tutorial atm, but I'm working on more and editing it a lot based on feedback and issues.

https://unseen-godot.alwaysdata.net/

@paulGeoghegan We have yet to write documentation on how to make use of the new accessibility features, both for using the editor and for authoring accessible games. For now the focus has been on implementing the features, and there's still more work needed to polish them, notably the editor accessibility, so we don't expect the experience to be satisfactory just yet for blind developers. But we'll get there!

On the other hand, you can indeed use Godot without the editor by writing GDScript or C# directly in your editor of choice.
You can create nodes from scripts, and even PackedScenes (to save reusable components as files).

This would warrant dedicated documentation to know how to get started without following the editor-heavy getting started guide. But here's a quick starter project I just made with a Godot project (project.godot file, which includes configuration settings, and where I enabled text-to-speech), a main scene (main_scene.tscn) with an attached GDScript (main_scene.gd), which enumerates available TTS voices for English and speaks "Hello world" with the first one.

godot-starter-template.zip

You may also be interested in the audio/text_to_speech demo in https://github.com/godotengine/godot-demo-projects:

https://github.com/godotengine/godot-demo-projects/tree/master/audio/text_to_speech

It's also heavy on the graphical interface side (showing an interface to list all TTS voices for different languages and play with them), but reading the code can give you a hint on how to use the TTS API in the DisplayServer singleton.

All this is available in Godot 4.4.1 which is the current stable release (so no screen reader support, only TTS output).

Can you currently in 4.5 prevent screen readers from reading a Control Node?

I tried testing the new screen reader support in 4.5 but found that the built in Windows 11 narrator was reading our cursor's Control Node out loud and nothing else. Our cursor is set up as a custom TextureRect that follows the mouse in our game to allow us to show different cursor textures so I would like to hide it from the screen reader. I realise I may be completely misunderstanding how screen readers function.

I know this was only integrated very recently but any pointers would be great thank you.

I tried testing the new screen reader support in 4.5 but found that the built in Windows 11 narrator was reading our cursor's Control Node out loud and nothing else.

Normally screen reader is reading Control node which currently has keyboard focus, if node should not interact with screen reader, it should not be focusable.

For other types of nodes you can manually control what's considered as focused - see https://github.com/godotengine/godot-demo-projects/tree/master/gui/accessibility demo for example.

@bruvzg Hello, sorry for reaching out on this old PR, I just couldn't find an answer and didn't see a better way to reach out. I'm just working on my addon for Godot to expand its screen reader accessibility. I recently ran into "The %s is not accessible at this time." message set by DisplayServer::accessibility_update_set_value on something my addon makes accessible, but I can't seem to find anyway to overwrite/disable that message being sent to screen reader via add on. Is there any way to do that via addons, or will I need to do a PR/branch?

A couple of people who use my addon with Godot want to participate in a Jam starting at the end of the month so just trying to get a few wish list items done if possible for them!

I recently ran into "The %s is not accessible at this time." message set by DisplayServer::accessibility_update_set_value on something my addon makes accessible, but I can't seem to find anyway to overwrite/disable that message being sent to screen reader via add on. Is there any way to do that via addons, or will I need to do a PR/branch?

These messages are placeholders in the internal editor components that have no accessibility support, I do not think add-on would be able to remove/override them, so it should be done in the main repo. If you are implementing support for some of these editor parts, it would be better to do it as PR instead of add-on in any case.

A big issue is that many developers would rather build custom elements and role assignment is not very easy or clear.

Custom elements can be implemented by adding NOTIFICATION_ACCESSIBILITY_UPDATE notification handler to any node, see https://github.com/godotengine/godot-demo-projects/tree/master/gui/accessibility demo for example.

These messages are placeholders in the internal editor components that have no accessibility support

I think they should just be removed entirely and we just make sure the inaccessible areas have a role, even if full accessibility isn't there. Then we can add accessibility over time, but the default assumption if someone probably can't use something is that it's inaccessible so it probably doesn't need to be stated explicitly.

If this is generally supported then I can PR it.

I recently ran into "The %s is not accessible at this time." message set by DisplayServer::accessibility_update_set_value on something my addon makes accessible, but I can't seem to find anyway to overwrite/disable that message being sent to screen reader via add on. Is there any way to do that via addons, or will I need to do a PR/branch?

These messages are placeholders in the internal editor components that have no accessibility support, I do not think add-on would be able to remove/override them, so it should be done in the main repo. If you are implementing support for some of these editor parts, it would be better to do it as PR instead of add-on in any case.

That is very true, the thought is addons for testing to help people better make PRs because they can be quickly implemented and make sure the planned end result actually works and makes the software more usable. I know some folks have made some PRs/issues as as a result, and I am hoping that with several of the gang planning on doing a jam next month we get some good data on what is most important.

But figuring out what is/isn't good and working together as a group to get PRs made is probably something we are overdue for. Like one adding a bunch of hotkeys to jump to like every tab. The one I was hoping to add that prompted this was just making the audio bus menu accessible.

But making it so I can touch that would also fix a minor annoyance people have of the 2D editor auto opening and always telling them it's not accessible.

I can see that; what I am suggesting is as a future development to create
an interface similar to role assignment in web development because the
current implementation is highly technical and unfriendly to inexperienced
users (such as those in a game jam).

Something like this is in my plans for 4.7.