Accessibility focus mode breaks behavior of `grab_focus`

[hhyyrylainen]

Tested versions

• Reproducible in: 4.5.stable.mono.official.876b29033 and I personally didn't test but I got a report that 4.5.1 does not fix this
• Not reproducible in: 4.4.1

System information

Godot v4.5.stable.mono - Fedora Linux 42 (Workstation Edition) on Wayland - X11 display driver, Multi-window, 3 monitors - Vulkan (Forward+) - dedicated AMD Radeon RX 7900 XTX (RADV NAVI31) - AMD Ryzen 9 9950X3D 16-Core Processor (32 threads) - 123.4 GiB memory

Issue description

The new "Accessibility" focus mode is triggering and causing white outlines around a few random GUI elements in the game I'm working on. AFAIK I do not have a screen reader on / enabled on my computer but I still get the white outlines. And a player who originally noticed the problem and reported it to me likely is not using a screen reader. Plus another programmer from our team tested 4.5.1 and I don't recall that they would have talked about using a screen reader.

So to me it seems like the new 4.5 screen reader support is triggering when a screen reader is not being used, and thus causing visual problems with existing games using Godot that upgraded to Godot 4.5.

Edit: I got a confirmation from the player who reported the issue originally to me that they do not use a screen reader (and barely even know what that is)

Steps to reproduce

• Start a game with a non-focusable GUI element (likely needs to be in a modal window)
• The GUI element should incorrectly become focused and get the white outline even though there is no screen reader being used
• Setting the Control focus node to totally none fixes the problem

Minimal reproduction project (MRP)

AFAIK there's nothing in my project that would override Godot's normal screen reader detection so any project should be able to show the engine incorrectly detecting a screen reader being used

[AThousandShips]

I can't replicate this in a general project, can you replicate this in a completely new project yourself?

[hhyyrylainen]

I can try, but is there like no easy bool variable somewhere in the engine to check the screen reader detection status? If I'm understanding what's going wrong correctly, then a blank project with nothing in it could also be used to check if the engine internally thinks there is a screen reader or not.

I can try to replicate the triggering condition in a new project, though it will take until next week as I'm making a new release of the game I'm working on for tomorrow so I can't spare any development time for this before that is out.

[AThousandShips]

Since with these instructions alone I can't replicate the issue, so a minimal project or more specific instructions would be needed unfortunately, can't replicate unwanted focus in my own projects

[hhyyrylainen]

According to the documentation on Control focus_mode property, the value of "Accessibility" which is the default now says:

The online documentation doesn't seem to have this text: https://docs.godotengine.org/en/4.5/classes/class_control.html#class-control-property-focus-mode

But that in-engine text very heavily implies that if a screen reader isn't detected, the node should be totally unable to grab focus. However it does, and I've confirmed that the few problematic instances so far I've noticed go away if I swap the mode to None. So based on the documentation the engine should be incorrectly thinking that there is an active screen reader.

Thus I think that there is a bug in whatever code in the engine determines if a screen reader is active or not. To test that I think it would be sufficient to go into the Godot source code and just call something like std::exit if a screen reader is detected as active. That would make it very clear when Godot accidentally detects a screen reader.

[AThousandShips]

Accessibility is not the default in general, did you set it manually? Or on what node are you seeing that focus mode? The default is 0, or "None" for Control, and is 2, or "All" for some other nodes like buttons

[hhyyrylainen]

I did not set it manually, it seems to be the default for rich text labels which are so far the only GUI elements I've noticed the problem on. So it is possible the problem is only visible there.

But a detection of a screen reader being present when there isn't one can cause GUI problems for players in general in games that implement screen reader support as the changed visuals wouldn't correctly turn off when there is no screen reader.

[AThousandShips]

Ah yes that one does have that as the default mode indeed, most don't, but I can't replicate this with a RichTextLabel on my end either with a minimal setup, so this might be specific to specific OS versions or something

So if you can create a minimal project for this showing the issue I can test it, but with just this I can't replicate it on my end

[hhyyrylainen]

I'll get back to this next week once I have time to investigate. I'll likely start digging into the engine source code to see what the screen reader detection code looks like and if I can compile a custom engine variant that just crashes when it thinks there's a screen reader for easy testing.

[AThousandShips]

Would be best to get an MRP first but any investigation of the code as well would be great!

Would have to be done to avoid creating false negatives though, that'd be more important than preventing false positives

[bruvzg]

Some Linux configs falsely reporting screen-reader status is a known issue, so far we were not able to determine exact cause, since it is never reproducible on the clean installs of the same distros. So it's not clear what might be causing it (most likely some software is abusing accessibility APIs). Currently used checks are already excessively strict.

[hhyyrylainen]

I'd personally prefer a conservative approach (with an explicit way to force it on), as I do not want to receive a bunch of confusing bug reports from players with strange white squares over their screen after the Godot 4.5 upgrade, which didn't warn about this (or I skimmed that part of the release notes, if so, sorry):

(screenshots from the original bug report that alerted me to this)

Now that I know about the problem I can easily enough identify what's going on, but first time seeing that bug report it was extremely confusing how a part of the game that hadn't been touched at all could just suddenly break and at a first glance draw random white boxes on the player's screen.