How do I actually go about testing accessibility features? What is each property for?

Godot Version

4.5.1 Stable

Question

Hey folks. This is a bit of a loaded question so I’ll try to break it apart into what troubles me the most. I’m trying to add accessibility features into my game but I am struggling to do so.

To start, I think one major point of pain is that the documentation texts provided with existing Control::accessibility_* properties are not useful in their current state. Does anyone have a better description of what each property does? The current descriptions are the self-explanatory kind that doesn’t actually detail the precise purpose or usage of the property. This makes it hard to know what each is used for and when I should use it. For instance, what is accessibility_name? If it is read to the user when they focus an element, should it be avoided on things like Button and Label? If the accessibility_name property is used for the text of what an element is, is accessibility_description for a lengthy explanation, like a tooltip? Should I just use an actual tooltip and read its contents instead? Or are these properties not for user-facing data in any way whatsoever? These questions could all have been answered in the documentation.

Despite the previous problem, I attempted to just kind of wing it in a test environment, adding buttons and labels to a blank scene with properties set to what I thought they should do. This brings me to the original question, which is how do I actually test this? I tried opening the Windows Narrator to see if maybe it would read the buttons and labels in the game since I had accessibility properties set, but I had no luck. The Narrator cannot focus any elements in the game window. Thinking maybe I needed a development tool for debugging, I installed Access Insights for Windows, which allows viewing the hierarchy of a window to see its various accessibility features, but this saw nothing within the Godot game window.

My understanding of the feature is that it should work out of the box, I give each node something to say, set its focus mode appropriately, and then the engine handles the part where it tells accessibility software what to do or speak. Accessibility is a very important feature, so I am a bit bothered by just how difficult this has been.

Thank you for your time.

1 Like

As noted in the release, these features are still in the experimental phase. That’s probably partly why the docs are scarce.

That being said, it works fine for me on Linux with the Orca Screen Reader. I’ve set up a simple scene with two buttons:

It doesn’t matter what you name the buttons in the scene tree. That will not affect anything.

If I turn on the screen reader and press tab, it will grab focus of the first button and read out the button text followed by “button”. If I modify the description under accessibility, it will read that afterwards. If I modify the name, it will read the name instead of the button text, followed by “colon” and then the button text followed by “button” (and then the description, if available). Press tab again, and the same thing goes for the second button.

Do note that it is not easy to implement accessibility features. You don’t want to just go with “what feels right to you”. There are some expectations that you are most likely not familiar with, and it will take quite some time to actually do things right.

1 Like

Interesting. I’m not sure why the tools I have available are not working, so I’ll have to keep searching for one that does work in the mean time. As you mentioned accessibility is very specific and has a technique to it, which is part of why I was so concerned with my ability to test it. I’m not about to try to add accessibility and then just leave it entirely untested :stuck_out_tongue:

Anyway, thank you for your input. I’ll make notes on the behavior of name and description for myself. I should be able to fill in the rest of the blanks once I get functioning software on my end.

1 Like

If you can’t get it to work, you might also consider opening up a git issue. Also, after rereading my reply, I realize it might’ve come across as discouraging, which wasn’t my intention. I’m glad every time devs think of accessibility and try to implement any feature that makes playing the game easier for people, no matter how small. Thank you for taking the time to learn how to do this.

2 Likes

I took your advice, and decided to really dig in and test things so I could file a good bug report. I did, but it was not a “bug” so much as it was an “I didn’t know I had to do something”.

Just in case anyone else comes along this post with a similar problem of tools not working, I’ve noticed that this only occurs with a custom build of the engine. It is caused by a missing library, see Issue #112671

1 Like