GNOME Bugzilla – Bug 357545
Orca does not speak all buttons in openoffice database table creation wizzard
Last modified: 2008-10-25 17:57:42 UTC
Create a new database in openoffice base. While going through the wizzard, choose the selection to run the table wizzard. In this wizzard there are two buttons with no labels when the user is adding categories. They are just before the back, next and cancel buttons.
Sorry, Mike I need most specific instructions to try to repeat what you are doing here. You are presumably running sbase. What selection(s) did you choose before you got to the table wizard? Did you have an existing database? Also, as you know, no work has been done so far in Orca on improving the startup wizard for sbase. But from the sound of it, this is a different problem, and it's a case of certain OOo components not having proper LABELED_FOR or LABELLED_BY relationships.
I've filed issue #69889 at openoffice.org against this: http://www.openoffice.org/issues/show_bug.cgi?id=69889 Adjusting the summary of this one to indicate that it's currently blocked.
Add accessibility keyword. Apologies for spam.
Removing target milestone from [blocked] bugs. We have little control over them, so we're better off letting priority and severity be our guide for poking the related components.
The blocking bug has been marked as fixed. Looking at OOo 3.0, I see both accessible names and accessible descriptions present for these buttons. We're still grabbing the accessible text (> >> and so on), though. So I'm unblocking this one and assigning to myself.
Created attachment 121312 [details] [review] proposed patch Pylinted and regression tested with OOo Writer and gtk-demo (I'll do FF next, but I don't anticipate any breakage). Will, please review. Thanks!
(In reply to comment #6) > Created an attachment (id=121312) [edit] > proposed patch > > Pylinted and regression tested with OOo Writer and gtk-demo (I'll do FF next, > but I don't anticipate any breakage). I believe I've seen programmatic names exposed via the accessible name, so I'm nervous about making this change in default.py. But, I'd feel OK about it in the OOo speech_generator, kind of like we did with gcalctool. Thanks!
Created attachment 121322 [details] [review] revision 2 > I believe I've seen programmatic names exposed via the accessible name, so I'm > nervous about making this change in default.py. Fair enough. > But, I'd feel OK about it in > the OOo speech_generator, kind of like we did with gcalctool. Thought about that, but.... If we do that, then whereAmI and the braillegenerator will speak and display the punctuation signs. Is that what we want? Unlike gcalctool, where what's on the buttons is generally an abbreviation of the function name, these OOo buttons are using mathematical symbols because they just so happen to visually resemble arrows which spatially point to/from other objects that (assuming no magnification) are simultaneously visible. I think that resemblance (and the intent behind it) may be less obvious in braille. I could, however, make an argument for preserving the symbols for the whereAmI functionality -- and if you can as well, I'll have revision 3 coming right up. :-) But if I'm on a button and not sure where I am and do a whereAmI, I think I'd find the name of more value than the punctuation. So.... This version makes a getDisplayedText for the soffice script which causes us to do (what I think is) the right thing in speech, braille, and whereAmI. But if you've already thought about all of the above and indeed want what we did for gcalctool, I'm happy to do that as well.
(In reply to comment #8) > Created an attachment (id=121322) [edit] > revision 2 Looks perfect. Please commit if it tests/pylints well. Thanks!
> Looks perfect. Please commit if it tests/pylints well. Thanks! Thanks! Committed to trunk and the gnome-2-24 branch. Closing as FIXED.