GNOME Bugzilla – Bug 135242
Gnopernicus should special-case the app-switch window
Last modified: 2005-02-17 12:13:03 UTC
Pressing (and holding) Alt-Tab brings up a window listing all of the running apps, allowing a user to switch to a new one. Gnopernicus says "Creat Window", "Status Bar", and then reads the contents of the text at the obttom of the window. The 3-letter role abbreviation show in Braille is "STA". Pressing Tab repeatedly (while holding the ALT key) leads to Gnopernicus speaking "Status Bar" and then the updated contents of the text. This window is a very special case in the desktop user interface, and Gnopernicus should handle in specially and differently. When the window appears, Gnopernicus should say "Switching to" and then the text displayed in the status bar, and repeated pressing of Tab should just read the new text. The 3-letter role abbreviation in Braille should be different than STA for status bar (perhaps "ASW" for app-switch?). This will break string freeze, and so should probably not happen until after GNOME 2.6 is put to bed (unless there is broad agreement on the value of this change).
Sorry, this is a "window switch" thing, not an "app switch" thing. So the suggested role abbreviation would be "WSW" rather than "ASW". Also, for blind users familiar with JAWS under Windows, the text might be "Switch to window" instead of "Switching to" above.
Peter: I don't see offhand how this can be special-cased without adversely affecting performance of the rest of gnopernicus. Is the current behavior really such a problem? After all, the window-switch window has been invoked as a result of user activity, so the user doesn't need to be told "WSW" as opposed to "STA". We can't IMO special case things like this without either ugly (and inefficient, fragile) hacks, or scripting.
Fundamentally the speech for this dialog is too verbose. It is something the user does all the time, and being told that static text is being read is cumbersome for the user. It is a very special situation (this dialog), and deserves special handling. Now, how we do that special handling (and in which release of GNOME) is another question. One option I think is very valid to consider is introducing a new and special ROLE for this dialog. Another may be scripting based.
I take it that the verbosity is mostly a speech issue (the braille output seems OK to me) So at the moment, gnopernicus says: "create window, status bar, terminal" if I press Alt-tab and 'terminal' is focussed? I see that for some windows, with names much longer than 'Terminal', this could be a major annoyance, but on the other hand, we'd want to actually read the window name/title in either case. So the excess verbosity is, in effect, "create window, status bar" (I think). We should use ROLE_WINDOW for the focus-switching window (rather than ROLE_FRAME); why not avoid "create window" when ROLE_WINDOW is created? ROLE_WINDOW is not a normal toplevel window, according to the ATK docs. If the window switcher's toplevel has role FRAME instead of WINDOW, that's a window-switcher bug which we should file. So, this would reduce the verbage to: "status bar, Terminal". Aside from the special-casing opportunities here (i.e. check the parent of the status bar before saying "status bar", etc.), we would just say something more concise for ALL status bars (or say nothing but their contents!). This might be worth testing to see what (if any) negative impact the omission of the role name might have for other status bars. I imagine that hearing "status bar" over and over might become annoying in more cases than this one.
typo: please replace "we would just say something more concise" with "we _could_ just say something more concise..." in the above remarks.
Yes. I think the desired speech from our users will be somthing very close to "Switch to window terminal". Note also that the "status bar" statement will get *very* annoying if the user is still holding down the ALT key with successive presses of TAB. To get to the third application in the list you hear "Create Window; Status bar; <app1>; Status Bar; <app2>; Status Bar; <app3>", vs. the desired "Switch to Window; <app1>; <app2>; <app3>". Perhaps another way to address some of this is with logic in Gnopernicus to not repeatedly say "Status bar" when reading status bar role object updates if nothing else is spoken in between speakings of the status bar contents.
I think that saying something use-case-specific like "Switch to window" requires scripting. It would otherwise require fully application-specific special-casing (or introducing a role which ONLY exists in this application), which we have had a policy against doing up until now. A reasonably generic solution in the meantime might be: "Status: Terminal, gedit, ..." etc. as you suggest, which could be achieved without special casing, by: * omitting "create window" for ROLE_WINDOW objects; * speaking "Status" for status bars, only when they initially become the focussed object (as you suggest above).
As long as user is holding down the ALT key and has heard the initial 'Status bar/Switch to window' event, I don't see any need for additional information besides the name of the next window. A user knows the context of his/her actions as long as he/she is still holding the ALT key so minimal output would be sufficient to speed up the process. Bill, your above solution with of removing 'create window' and reporting 'Status bar' once would be ideal IMO.
Where else is ROLE_WINDOW used in the desktop? Will omitting "Create window" text for ROLE_WINDOW cause other unintended side effects?
I am not aware of any objects currently with role ROLE_WINDOW. I think that setting the role can be done in gail. If the window type is GTK_WINDOW_POPUP then it role should be ATK_ROLE_WINDOW otherwise the role will be ATK_ROLE_FRAME unless it has a more specific role like ATK_ROLE_DIALOG or ATK_ROLE_TOOL_TIP. Should this change be made to gail?
yes. According to the ATK docs, ROLE_FRAME should be reserved for decorated GtkWindows.
gail changes committed.
recent gail fix may regress gok, will need to check.
Created attachment 26202 [details] [review] proposed patch This patch will not report events for an object with role WINDOW and also will not report role name of current object when user has pressed ALT+TAB.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Created attachment 36010 [details] [review] a new proposed patch
Remus - how does this patch fit into the much larger XEvIE-based keyboard reworking you've proposed? The code in this patch (above) seems fairly innocuous, and will make a very visible (err..) change in users' experiences. But timing-wise, I'm not sure when something like this would be good to put in.
This patch no connection with the changes for keyboard. The intention of the new patch is to present a message ("switch to") when user presses ALT+TAB first time, then the name of the current selection. When the selection changes, only the name of the new selection is spoken. I agree this is "very visible change in users' experiences". A decision how this bug will be fixed should be taken here.
Thanks for the clarification. This looks good to me. Bill - any comments?
Comment on attachment 36010 [details] [review] a new proposed patch Patch committed on cvs head.
This broke string freeze.
Christian - which do you prefer, retroactively requesting freeze breakage approval, or un-tagging the new string (appears to be "switch to")?
Yes, the "switch to" is a new string indeed.