If I create a Gtk.Entry and add an icon (for example, as GTK_ENTRY_ICON_SECONDARY), and set it as activatable, to show a popup with extra options, I can’t access it with the keyboard, using TAB navigation. I also tried the MENU key, but it shows the right-click menu, not the one in the activatable icon. How can I enable that, to make this kind of entries accessible?
Hi,
You have to define your own keyboard shortcut to activate the icon.
This topic may be interesting for the details: How do I add custom shortcuts to functions in gtk4
Mmm… But that would require that the user knows the keyboard shortcut, and that there is that activatable icon in that entry. The true problem here is that the icon isn’t being announced by Orca in any way, because only selectable elements are announced, so just adding a keyboard shortcut doesn’t fix the problem. (Yes, my question wasn’t very clear about what the problem was).
OK, understood. If you want a selectable icon, the best way would be to create your own button.
- either like a GtkComboBox, by packing both the entry and the button in a GtkBox with the
.linkedstyle - or by inserting a button directly inside the GtkEntry, look at the
gtk4-demo> Entry > Tagged Entry for an example how to do that.
If I understand it correctly, what the Tagged Entry does is just create a new widget with a GtkBox, and inside an Entry and a Button… isn’t it?
In the example, the tag itself is a GtkBox with a GtkLabel (“Blue”) and a “close” GtkButton.
But it’s added directly as child of the entry, without an extra box.
Here the widget hierarchy as shown by the inspector:
I get it, but my point is that this looks more like a Gtk bug, because it makes an element not accessible to blind people… Should I report it upstream, or is something that, by design, won’t be fixed?
I’m not sure it’s a bug.
Usually clickable entry icons will do an action that can also be performed with the keyboard in some way (clear the text, show emoji chooser, …), so blind people won’t need to focus/click on that icon.
What you want is something that fulfills the a11y “button” role. According to the docs, such widgets shall be individually activatable with an action, but entry icons don’t support that, they only emit icon-press signals, not actions.
My specific case is the libnma, used in the gnome control center, which uses them to choose things in password entries like “remember this password for all the users”, “remember this password only for this user” and “ask password every time”. And that means that a blind user can’t access those options (you can check that by going to the gnome control center → Network → open the interface options → Security → Security 802.1x, type something in the password entry and click on the icon.
Should I presume that the bug is, then, in libnma, which is the one that builds that interface, and send a patch there?
1 Like
Yes, I agree the interface should be changed.
1 Like
Thanks. I’ll do that.
1 Like
IMO it’s unfortunate that this isn’t available to a11y, but the docs make it explicit:
Note that functionality or information that is only available by clicking on an icon in an entry may not be accessible at all to users which are not able to use a mouse or other pointing device. It is therefore recommended that any such functionality should also be available by other means, e.g. via the context menu of the entry.
So currently, it’s probably indeed an app bug if some functionality isn’t available by other means.
But I’d still report it as a potential improvement, and see if there are meaningful reasons behind explicitly not exposing this to a11y, or if it’s merely a known limitation.
1 Like