Allow keyboard focus on credits and license text in generic about dialog (PR #27050)

4 views
Skip to first unread message

Quin Gillespie

unread,
Sep 21, 2026, 5:39:43 PM (2 days ago) Sep 21
to wx-...@googlegroups.com, Subscribed

In the generic about dialog, the text shown in the collapsible panes (license, developers, documentation writers, artists and translators) is a wxStaticText, which can't get focus. Keyboard and screen reader users could open a pane but could not Tab to its contents, so they could not read them.

This makes the text in these panes accept focus, so Tab moves to it and screen readers read it. Other wxStaticText controls are not changed.

There is no visible focus indicator on the text. Before this change focus went to the empty pane panel instead, which had no indicator either, so this is not worse for sighted keyboard users.

I kept this small on purpose. For the license, a read-only multiline wxTextCtrl would work better: screen reader users could read a long license line by line, and it would show focus. It would change how the dialog looks, though. Would you be open to that as a follow up?

Tested with NVDA on Windows 11, together with #27048 and #27049.


You can view, comment on, or merge this pull request online at:

  https://github.com/wxWidgets/wxWidgets/pull/27050

Commit Summary

  • 1397c1e Add keyboard focus to credits and license text in generic about dialog

File Changes

(1 file)

Patch Links:


Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.Message ID: <wxWidgets/wxWidgets/pull/27050@github.com>

VZ

unread,
Sep 21, 2026, 7:37:58 PM (2 days ago) Sep 21
to wx-...@googlegroups.com, Subscribed
vadz left a comment (wxWidgets/wxWidgets#27050)

Sorry, I don't understand: is there really no way to read the text of any static texts at all with a screen reader? It looks like we should perhaps make all of them focusable in order to allow reading them then, possibly if we can detect that a screen reader is running (can we?).


Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <wxWidgets/wxWidgets/pull/27050/c5769068213@github.com>

Quin Gillespie

unread,
Sep 21, 2026, 7:56:30 PM (2 days ago) Sep 21
to wx-...@googlegroups.com, Subscribed
trypsynth left a comment (wxWidgets/wxWidgets#27050)

Sorry, I wasn't clear. Screen readers can read static text: NVDA reads the static text of a dialog when it opens, and a label is read as the name of the control after it. So there's no need to make all static texts focusable, and having every label as a Tab stop would be worse for everybody, as native Windows dialogs don't work like this either. (Detecting a screen reader is possible with SPI_GETSCREENREADER, but I wouldn't rely on it for this.)

The problem here is the text in the collapsible panes: it isn't shown when the dialog opens, so it's never read automatically, and it's not the label of anything. Without this PR, users have to switch to NVDA's review cursor or object navigation to read it. With it, they can Tab to it, but NVDA then reads the whole text at once. That's fine for a short list of names, but a lot for a long license like the GPL.

So for the license I'd really prefer a read-only multiline wxTextCtrl: it can be read line by line with the normal arrow keys, and it shows focus. Would you be OK with changing this PR to use it for the license, while keeping the focusable static text for the credits? It would change how the license looks, so I wanted to ask first.


Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <wxWidgets/wxWidgets/pull/27050/c5769256183@github.com>

VZ

unread,
Sep 21, 2026, 7:58:22 PM (2 days ago) Sep 21
to wx-...@googlegroups.com, Subscribed

Closed #27050.


Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <wxWidgets/wxWidgets/pull/27050/issue_event/31566547677@github.com>

VZ

unread,
Sep 21, 2026, 7:58:24 PM (2 days ago) Sep 21
to wx-...@googlegroups.com, Subscribed
vadz left a comment (wxWidgets/wxWidgets#27050)

After thinking more about this: no, making wxStaticText focusable is really wrong.

I actually prefer your idea of using readonly wxTextCtrl instead, it's definitely better for the long text like what is shown in these controls. Please redo this PR using this approach, TIA!

P.S. While searching for more information about this, I found mentions of "announcement API" which is something that could be very useful for wxStaticText controls used for error/warning display and maybe wxInfoBar. Something like wxWindow::Announce(const wxString& message) should even be implementable on all platforms and not just wxMSW, if you'd be interested in doing this.


Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <wxWidgets/wxWidgets/pull/27050/c5769270913@github.com>

Quin Gillespie

unread,
Sep 21, 2026, 8:03:22 PM (2 days ago) Sep 21
to wx-...@googlegroups.com, Subscribed
trypsynth left a comment (wxWidgets/wxWidgets#27050)

Thanks, I'll redo this with a read-only wxTextCtrl in a new PR.

About the announcement API: I'd be very interested in doing it. I've already implemented this for wxDragon (Rust bindings for wxWidgets) in https://github.com/trypsynth/live-region, which works under all 3 platforms: UI Automation notification events under MSW, announcement notifications under macOS, and the ATK notification signal (falling back to announcement for ATK < 2.50) under GTK. It also supports priorities, e.g. whether the message should interrupt the current speech or not.

One non-obvious thing I found under MSW: raising the notification on the provider returned by UiaHostProviderFromHwnd() succeeds but doesn't reach any screen reader, so the window needs to return its own provider from WM_GETOBJECT.

So something like wxWindow::Announce(const wxString& message, wxAnnouncePriority priority) should be quite doable. I can test it under MSW and macOS.


Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <wxWidgets/wxWidgets/pull/27050/c5769309947@github.com>

Reply all
Reply to author
Forward
0 new messages