After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 323586 - gtkdialog vs gtklabel focus issues
gtkdialog vs gtklabel focus issues
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
2.8.x
Other All
: Normal minor
: ---
Assigned To: gtk-bugs
gtk-bugs
AP3
: 328448 349715 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-12-08 20:29 UTC by Jason Grieves
Modified: 2016-05-24 11:36 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jason Grieves 2005-12-08 20:29:39 UTC
Distribution/Version: Ubuntu

1) open up 2 tabs
2) try to close gnome-terinal
3) use tab to navigate from Close All Tabs and Cancel
The cursor focus goes from "Close all tabs" to the top text and then to cancel.
 I do not know of applications that allow focus of text like this.  Difficult
for low vision or blind users who use tab key to navigate desktop with keyboard.
Comment 1 Olav Vitters 2005-12-18 13:48:04 UTC
Hmm.. allowing the text to be focussed is good according to HIG. Have to ask accessibility list about this one.
Comment 2 Jason Grieves 2005-12-19 19:42:30 UTC
OK.  Should be a good discussion.  I worked with a contractor who tested for 508 compliance.  Though this does meet 508 standards, he shared his thoughts on the difficulty of focus issues.  Might be a mute point for me, but I was hunting for the focus when I did not have access to the mouse and had a very small screen. I am low vision, so I finally had to stick my nose on the screen and notice the cursor was in the text.  
Comment 4 Alan Horkan 2005-12-19 20:35:48 UTC
In version 2.8 tab only switched between the buttons but tabbing didn't
select/focus the text so the change seems like it might have been intentional.  

I dont really have anything relevant to add but there is something else I
absolutely must say:

> Might be a mute point

"moot point"

mute is a person who cannot speak
moot is a hypothetical considered unimportant
http://dictionary.reference.com/search?q=moot

Sorry to be pedantic it is a mistake which particularly bothers me and I had to
point it out
(I know my own spelling and grammar sucks but I'm trying to correct it and I
don't mind if you point out my mistakes) 
Comment 5 bill.haneman 2005-12-19 20:43:59 UTC
Hi Alan:

Putting the text in the focus chain does seem a bit odd; usually what we do with such dialogs is use ATK_ROLE_ALERT to let screenreaders they should read the whole dialog when it posts.  As far as I know, text need not be focussable in order to be selectable, but perhaps I am wrong about that?

IMO the "real" problem may be that the text caret was too hard to find.  Jason, were you using one of the HighContrast and LargePrint themes?  We tried to make the text cursor very big and fat in those themes, and in a color that contrasts with everything else.
Comment 6 Alan Horkan 2005-12-19 20:52:47 UTC
> As far as I know, text need not be focussable
> in order to be selectable, but perhaps I am wrong about that?

the text was selectable in 2.8 despite not being included in the tab order


Comment 7 Jason Grieves 2005-12-19 23:50:03 UTC
>the text was selectable in 2.8 despite not being included in the tab order

This is what I expected to occur, in Windows the text is not even selectable, or in the tab order.  My understanding is that JAWS will read the informatioin, as well as allow hotkeys to produce reading of the text.

Bill, I did not have LargePrint on at the time, but that is a good suggestion.  That appears to provide a much better contrast of where focus is.  

As a mostly keyboard user, I am still curious what the end result should be?  It does meet HIG and 508, but I do not understand why this is in the tab order.  I like the solution of being selectable (for example to copy and paste the message).  Why was the functionality changed?
Comment 8 Calum Benson 2005-12-20 00:55:32 UTC
FWIW, the relevant "see alsos" here are bugs #59707 and #138085.  In particular, the latter bug was closed with the comment from Matthias:

"I have put selectable labels back in the regular tab chain now, and modified
GtkDialog to skip labels when looking for the right widget to focus initially.
This seems to work ok with message dialogs, and also with GnomeAbout."

I'm unclear how else people are proposing that the message text in an alert be selectable from the keyboard, if it's not in the keyboard focus chain?  I thought this was pretty much the standard behaviour for alerts these days, since Matthias' closure of that bug.

If that understanding is correct, one improvement on the visibility front might just be to automatically do a 'select all' on a selectable label whenever it's focused via the keyboard.  Pretty much the only reason for a label to be selectable is so you can copy and paste it anyway, so it would probably speed up that process in most cases too.
Comment 9 Alan Horkan 2005-12-20 11:44:34 UTC
> in Windows the text is not even selectable,

it may depend on the application but I think from windows 2000 onwards text in dialogs was always selectable using the mouse so you could easily copy it for a bug report (but I'm pretty sure it was not in the tab order).  
There was also a feature (possibly this was an improvement in Windows XP) where you could hit "Ctrl+C" on any dialog and copy the entire text of the whole dialog including button labels to the clipboard.  Perhaps Gnome/Gtk could do something like that which might solve the larger problem of generally getting at the text rather than the detail of selecting it.)
Comment 10 bill.haneman 2005-12-20 11:59:07 UTC
Jason: Given the fact that the text can only be keyboard-selected when focussed, what makes the inclusion of the text in the tab sequence awkward?  I understand that it adds a keystroke to traversal of the entire dialog, but it allows screenreader users to read the text at leisure, which otherwise would require "flat review" mode.  On balance it may be better to allow the text to be focussed... especially if the "hard to see the text caret" problem is solved by use of a higher-contrast theme.

BTW Jason, depending on your vision you might try one of the HighContrast theme variants instead of ordinary 'Large Print', for instance HighContrastLargePrint which should be available from the "Theme Details" tab of the Theme dialog, if you installed the "accessibility" themes package (not sure how Ubuntu is packaging these themes at the moment, they may be optional packages).
Comment 11 Matthias Clasen 2005-12-20 13:50:06 UTC
I think I agree with Calum that selectable labels should probably behave like
entries and select on focus in. We should probably respect the same
setting that entries have for this behaviour (gtk-entry-select-on-focus).

I think we should also harmonize the keybindings between selectable labels and
entries some more, maybe. Currently, there are some discrepancies:

             label         entry
Ctrl-A       go to start   select all
Ctrl-\                     unselect all
Shift-Ctrl-A               unselect all
Home         go to start   go to start
End          go to end     go to end
Ctrl-E       go to end     

Calum, what do you think about changing the bindings of selectable
labels to be the same as for entries ?
Comment 12 Jason Grieves 2005-12-20 17:01:43 UTC
Bill: Your suggestions are all valid.  I come from a Windows background where the text is not in the tab order, or even selectable for that matter.  You are correct, this will only take some time to remember that it is part of the tab sequence.  Now  that I have a better understanding of this feature, it is obvious of the benefits.  There were many times in Windows when attempting to copy an error dialogue and not being able to select the text.  

Thanks for all of the valuable input.  I have a much better understanding of this now.  Matthias, your idea seems logical and beneficial to me.
Comment 13 Matthias Clasen 2005-12-26 07:14:35 UTC
The GtkLabel changes outlined in #11 are in GTK+ head now.
Comment 14 Calum Benson 2006-01-12 18:13:27 UTC
(In reply to comment #11)

> Calum, what do you think about changing the bindings of selectable
> labels to be the same as for entries ?\

Yes, this sounds like a good idea. 

Comment 15 Behdad Esfahbod 2006-01-24 17:17:47 UTC
*** Bug 328448 has been marked as a duplicate of this bug. ***
Comment 16 Behdad Esfahbod 2006-01-24 17:20:37 UTC
What about making it a configuration that labels are in the tab order, and make it default off?  They should be selectable by mouse still.  Most of the users don't want labels in tab order I guess.

Mozilla browsers have this thing called Caret Browsing, toggled by F7, that puts a caret in the HTML page.  It's something similar...
Comment 17 Olav Vitters 2006-01-24 17:36:39 UTC
--> gtk+
Comment 18 Matthias Clasen 2006-03-10 06:10:50 UTC
Behdad, when I proposed making the inclusion of labels a preference in an
earlier bug about this issue, it was generally frowned upon as a modal interface...
Comment 19 bill.haneman 2006-03-10 09:34:37 UTC
It occurs to me that the only users who are likely to be bothered by the "text in tab sequence" are keyboard navigation users; by definition, those are the same users who need this feature in order to select text without the mouse.  So I don't see much benefit to the modal/configurable behavior, unless there is some significant population of "need keynav but don't need cut'n'paste" users.
Comment 20 Calum Benson 2006-04-26 17:11:53 UTC
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Comment 21 Calum Benson 2006-04-26 17:27:23 UTC
Apologies for spam... marking as AP3 to reflect accessibility impact.
Comment 22 Olav Vitters 2006-08-05 10:20:19 UTC
*** Bug 349715 has been marked as a duplicate of this bug. ***
Comment 23 Matthias Clasen 2016-05-24 11:36:11 UTC
We've recently introduced a gtk-keynav-use-caret setting that controls (among other things) whether labels in dialogs are made selectable.