GNOME Bugzilla – Bug 127891
zoom control does not have focus indication
Last modified: 2008-01-29 18:13:10 UTC
using nautilus from CVS HEAD 25 Nov 2003 -launch gnopernicus -launch nautilus -keynav to the 'View as X' combobox, located beside the 'zoom in' button -<shift><tab> to the 'zoom in' button - note the correct feedback, "zoom in, pushbutton available" -<shift><tab> again .notice how focus disappears and gnopernicus reports "panel". .<shift><tab> again focuses the 'zoom out' button, as would be expected after tabbing from the 'zoom in' button. It appears there is focus being given between the two zoom buttons, which actually focuses the content pane below.
Updating status whiteboard to reflect a11y team's assessment of priority.
As far as I can see the focus is being given to the event box between the zoom out and zoom in buttons. However there is no focus indication drawn. If focus is to be given to this object then in addition to drawing the focus indication an accessible name should be set so that a blind user will know where the focus is.
Created attachment 25963 [details] [review] Proposed patch Since the event box contains a label (the zoom percentage - 100%), in my opinion, focus needn't be given to it. However, atkrelation (between label and the zoom buttons) needs to be set so that the label is read when the zoom buttons are focussed. Attaching a patch for the same.
Could someone please review this patch.
the zoom control takes focus because you can pop up a menu with all the zoom levels (although we're considering changing this). Padraig, Calum, does using the zoom level for the zoom button relations make sense?
If you don't remove focusability, you have to display onscreen focus indication (and of course respect the gtkstyle focus line settings for line thickness and dash pattern). thanks
Changing summary to more clearly describe the problem. I am not sure that setting the label relations is correct. Currently the buttons have accessible names "zoom out" and "zoom in". If the labels are added then gnopernicus will report the name of the buttons as the zoom level so a blind user could not distinguish between them. There remains the question of how the blind user can know the zoom level. One might argue that a blind user does not care. Perhaps controller-for controlled-by relations would be better. If bug 129895 is not implemented and the object remains focusable then, as Bill, points out, focus indication needs to be drawn.
*** Bug 149397 has been marked as a duplicate of this bug. ***
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
In the new zoom control (since bonobo-slay branch), the + and - buttons do take focus, but the label still not. So you can move from focus (+) to no focus (label) to focus (-).
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Created attachment 103974 [details] Orca debug output whilst testing this problem. A lot of things have changed since this was originally filed back in 2003. The default screen reader with the GNOME desktop is now Orca rather than gnopernicus, so i tried to reproduce the problem with that. Using the Left and Right arrow keys I was able to move between the zoom in, current value label and zoom out controls and get the correct speech and braille. See the attached Orca debug output log for more details.
Closing as FIXED.