GNOME Bugzilla – Bug 118246
Accessibility problems with focus
Last modified: 2004-12-22 21:47:04 UTC
There are several problems relating to focus that impact accessibility, especially when used with Gnopernicus. 1. Focus doesn't wrap in a loop. The "7" button is one endpoint and the text field the other end (only tested in "basic" mode). 2. It doesn't appear that focus ever really can get to the text field; certainly Gnopernicus doesn't speak when tabbing into that field (there is also no visual indication that the field has focus, a violation of Section 508 1194.21(c) (see: http://www.access-board.gov/sec508/guide/1194.21.htm#(c). It also doesn't seem possible to select part of the text from the keyboard (as can be done with the mouse).
On the first part, is this the same as bug #118246? If so, then this is because of Gtk+ bug #60690, which was fixed back in April. Is it possible you are using an older version of the Gtk+ library? If this isn't the behaviour you are seeing, could you describe in more detail a set of action to recreate it please? I'll investigate the other parts further? Also, what version of gcalctool are you using? Thanks.
Uh... You wrote "On the first part, is this the same as bug #118246?", but *this* bug *is* #118246... I don't think this is the same as Gtk_ bug #60690, as it occurs with the TAB key and not the arrows. I'm using gcalctool version 4.2.98 (from an internal Sun build from 18July03). Steps to reproduce: 1. Launch gcalctool (comes up in Basic mode) 2. Use the mouse to press a button (e.g. Bsp). It now has keyboard focus 3. Press Shift-Tab repeatedly. Keyboard focus moves backward from the button you pressed until reaching the 7 button at the top left of the set of buttons. At this point, further pressings of Shift-Tab will not move the focus beyond the 7. 4. Press Tab repeatedly. Keyboard focus moves forward until reaching Exch at the bottom right of the window. One more press and focus disappears (presumably its on the text field, but there is no visual indication of that, nor does Gnopernicus read you that text or otherrwise indicate via speech or Braille that you are on the text field). Further pressings of Tab will not bring the focus "out of hiding". Pressing Shift-Tab will bring it back to Exch.
That should have been gcalctool bug #106627.
Hi Rich, Well, the text field is not focusable, but it can be fixed easily with the following patch. Also, I noticed better tab behaivor after making this change. Index: gtk.c =================================================================== RCS file: /cvs/gnome/gcalctool/gcalctool/gtk.c,v retrieving revision 1.95 diff -u -p -r1.95 gtk.c --- gtk.c 25 Jul 2003 21:33:32 -0000 1.95 +++ gtk.c 1 Aug 2003 23:50:56 -0000 @@ -842,7 +842,7 @@ create_kframe() gtk_text_view_set_cursor_visible(GTK_TEXT_VIEW(X->display_item), FALSE); gtk_text_view_set_editable(GTK_TEXT_VIEW(X->display_item), FALSE); - GTK_WIDGET_UNSET_FLAGS(X->display_item, GTK_CAN_FOCUS); + GTK_WIDGET_SET_FLAGS(X->display_item, GTK_CAN_FOCUS); gtk_text_view_set_pixels_above_lines(GTK_TEXT_VIEW(X->display_item), 12); gtk_text_view_set_pixels_below_lines(GTK_TEXT_VIEW(X->display_item), 12);
If we want to show the focus, one solution would be to make the cursor visible for the text field. I don't really like the look of it, but it might improve accessibility? Index: gtk.c =================================================================== RCS file: /cvs/gnome/gcalctool/gcalctool/gtk.c,v retrieving revision 1.95 diff -u -p -r1.95 gtk.c --- gtk.c 25 Jul 2003 21:33:32 -0000 1.95 +++ gtk.c 1 Aug 2003 23:53:25 -0000 @@ -840,7 +840,7 @@ create_kframe() gtk_text_buffer_create_tag(buffer, "x-large", "scale", PANGO_SCALE_X_LARGE, NULL); - gtk_text_view_set_cursor_visible(GTK_TEXT_VIEW(X->display_item), FALSE); + gtk_text_view_set_cursor_visible(GTK_TEXT_VIEW(X->display_item), TRUE); gtk_text_view_set_editable(GTK_TEXT_VIEW(X->display_item), FALSE);
And one last idea. Sorry for this mess, Rich. Showing the cursor on focus of the text field isn't too bad (IMHO) if some other widget has the default focus when the gcalctool is first displayed. Here is the patch for that suggestion... Index: gtk.c =================================================================== RCS file: /cvs/gnome/gcalctool/gcalctool/gtk.c,v retrieving revision 1.95 diff -u -p -r1.95 gtk.c --- gtk.c 25 Jul 2003 21:33:32 -0000 1.95 +++ gtk.c 2 Aug 2003 00:05:36 -0000 @@ -874,6 +874,7 @@ create_kframe() gtk_window_add_accel_group(GTK_WINDOW(X->kframe), X->kbd_accel); grey_buttons(v->base); gtk_window_set_icon(GTK_WINDOW(X->kframe), X->icon); + gtk_window_set_focus(GTK_WINDOW(X->kframe), GTK_WIDGET(BUT_CLR));
Thanks Dennis! I'll try these out on Monday. Peter if you beat me too it, can you try them and comment on them please?
I won't get to it before you will I'm sure. The gnome-calculator that this replaces does show the caret in the text field in certain circumstances - so there is that precedent. I would think, however, that initial focus is best in the text field, though I guess you could set things up to send text to that field even if focus isn't there. There is also a convention started by Mozilla to optionally show the caret (press F7 to make that happen).
Fix from Dennis checked into CVS HEAD. Fixed in v4.2.104. I also chatted with Nils (bank holiday in Ireland so Calum wasn't online), which widget should have initial focus and he agrees on Clr.