This is a known issue: on Linux/X11, the WebView in Wails apps does not automatically receive focus when the window is activated, which affects both keyboard navigation and accessibility for screen readers like Orca. Manual clicking triggers additional focus or accessibility events that are not fired by window focus alone. There is an open pull request that aims to improve focus behavior at startup, which may help with this problem by moving keyboard focus into the web content when the app window becomes active, potentially improving accessibility for screen readers as well (details).

Currently, Wails does not provide a built-in API to programmatically trigger accessibility events or focus for screen readers on Linux/X11. Any workaround would need to be implemented in your frontend code. For example, you can try programmatically focusing a key element (like a container or the first interactive element) in your JavaScript when the window is focused, though this does not guarantee accessibility activation for all screen readers. Make sure your frontend follows web accessibility best practices (proper ARIA roles, labels, and focus management), as Wails relies on the underlying WebKitGTK and the frontend's accessibility markup for integration with AT-SPI and Orca.

Keep an eye on the progress of the focus-related PR, and consider experimenting with frontend focus strategies to see if they help trigger screen reader activation in your environment.

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}