GNOME Bugzilla – Bug 128289
poor screenreader behavior for panel applet sub-components
Last modified: 2004-12-22 21:47:04 UTC
. cd payer added to the panel. on pressing tab, focus moves on to the cd player applet. screen reader reads as " play & pause ". This applet has other widgets like " stop, eject, previous track, next track". These widgets can be selected by using arrow keys. Expected: a. When focussed moved on to this applet, it should send accessible description as " cd-player". b. cd-player buttons are accessied through arrow keys, tool tip or accessible description should be given.
Updating status whiteboard to reflect a11y team's assessment of priority.
While traversing the cd player applet using the keyboard, the focus indicator moves from one button to the next until it jumps over to the next applet. While the focus is on any button, it reads the corresponding description, which is reasonable. Still considering the reported problem, I propose that we could modify the accessible names of the button widgets by prepending 'CD Player' to each of them. i.e. "Previous Track" would now read as "CD Player Previous Track" This could help in improving the clarity of the messages to a blind user.
I would not recommend appending "CD Player" to these names, as this will just result in excess speech output, and redundancy if the screen reader chooses to report (applet name, button) when focus first moves to an applet. On re-reading this bug report I believe this is a gnopernicus bug, not a bug in the applet. Please reassign, thanks!
Bill, is not so simple to report something different _only_ in this case. This can be done only ussing application specific code, but I'm not really sure if this is the way.
suggest adding a ROLE for embedded things (ROLE_EMBEDDED_PANEL? ROLE_PANEL_APPLET?) and using that for the heuristics, for gnome 2.8.
*** Bug 144345 has been marked as a duplicate of this bug. ***
This is also similar to the "frame context is very useful" bug/rfe... basically a user needs context-switching information in situations where the "parent" or "container" context has changed. Something like the frame-context behavior would also provide more information in the above case. See 128289 also, which could provide a useful heuristic for gnopernicus. (application-specific special casing would not be required).
I meant "see 144415" above.
DECISION: will not fix GNOME 2.8. Existing work around is to use the DescribeMySurroundings command. Will add an additional work-around: override the SpeakTitlebar command to give the name of the applet in this case. [algorythm is to walk up the hierarchy to find a title bar, if that fails, walk back down trying to find a container with an AccessibleName and speak that].
In case of an applet added to gnome-panel, if I walk up the hierarchy to find the title bar, the algorythm doesn't fail. There is a title bar reported for an applet, the same for all applets: "Bottom Expanded Edge Panel". Basically, this (the gnome-panel main frame) is the "main window" for all of these applets. In this case, I'm not sure how can I implement Peter's algorythm in order to report the "real" title bar for an applet. How can I take the decision : "this is not the correct title bar..." ? Any suggestion ?
I don't believe Peter's suggestion in comment #8 is what we actually agreed on (for this very reason). We either need ROLE_EMBEDDED here, in order to signal that we're at the top of the embedded component, or we should just take the accessible name of the first non-anonymous container of the focussed object. However I don't believe this second algorithm will really work reliably either, since sometimes the focussed object itself will be the right one to report. I believe we must use ROLE_EMBEDDED in order to solve this problem.
I agree with you Bill, the best choice will be to have this ROLE_EMBEDED. About your second suggestion, maybe it will be useful to introduce a new command on a layer to "report the name of the first non-anonymous container" (I can implement this, but we are in the UI and string freeze...)
Created attachment 30147 [details] [review] proposed patch This patch needs also presentation entries in presentation files.
Created attachment 30173 [details] [review] reworked patch
Patch applied to CVS.
I thought we agreed yesterday NOT to apply this patch until it was re-worked to address bug #111854 as well. What went wrong?
I remembered only to not speak "switch to window". My mistake. For bug #111854 the patch can be also produced from this point, the difference is the detection of context switching. In this case is to go up to and check if role EMBEDDED is present. I will try to create a new patch for 111854.
This bug depends on #bug 149149.
149149 has been fixed for several weeks; you just need to update libgail-gnome. thanks
We updated gnome-panel because we were expecting that this role is added there. We will try with libgail-gnome. Thanks.
The patch applied to CVS HEAD was reverted
Patch reapplied to CVS.