GNOME Bugzilla – Bug 118247
Want AccessibleNames on calculator buttons, radio buttons & check boxes
Last modified: 2004-12-22 21:47:04 UTC
By default the AccessibleName of a GTK+ button is its text. The text-to-speech engine that a blind user gets speech from may not clearly pronounce things like "Frac" and "Abs". If they had more expansive AccessibleNames (like "Fraction" and "Absolute Value") it would be a significant help. Also things like "1/x" and "x^2" would benefit from such names. Also, in the Scientific mode, many of the radio buttons and check boxes are abbreviations that likewise should have more expansive AccessibleNames.
Agreed. I've cc:'ed Breda on this one. Could you give me a set of names you'd like me to use please? Or should I just use the tooltip phrases?
I don't think we want to use the tooltip (especially for something like "Bsp" which as "Remove rightmost character from displayed value" as its tooltip). I think simply spelling out the word that is being abbreviated is the right answer in most cases (e.g "backspace" for "Bsp"), with the mathematical symbols (e.g. 1/x) replaced by the appropriate name of the operation (e.g. "inverse"). As you are the author of the calculator, I'd just as soon leave the choosing of names to you... :-)
Fair comment on long tooltips. Breda is the person who did the online help for gcalctool. There is more than one author here. I will pass a list of suggested accessiblenames by her before committing.
Well, I lied, I went ahead and committed the following changes without talking to Breda first. Breda (or Peter), if you have any suggested changes (see my comments below), just reopen the bug and comment accordingly. -- My concern with having new AccessibleName strings for all 80 buttons is: - the amount of extra memory that would take up. - the pain that all the translators would have to go through - the repetition because a lot of the actual tooltip strings would be fine. So, taking this into consideration, I plan to use the tooltip string where possible and just provide new AccessibleName strings (the astr member of the button struct) for: Button | Label | AccessibleName ---------+---------------------------------------------- Bsp "Backspace" CE "Clear Entry" Clr "Clear" Int "Integer portion" Sto "Store to register" Frac "Fractional portion" Rcl "Retrieve from register" Exch "Exchange with register" < "Shift left" > "Shift right" &16 "16 bit unsigned integer" &32 "32 bit unsigned integer" ( "Left bracket" ) "Right bracket" Acc "Accuracy" Exp "Exponential" e^x "E to the x" 10^x "Ten to the x" y^x "Y to the x" x! "Factorial" Rand "Random" If you think that there are others that should have specific AccessibleNames or you don't like the wording of the ones I've choosen, just reopen the bug and comment accordingly. Checked into CVS HEAD. Fixed in v4.2.101.
Hi Rich, a few comments :) &16 "16 bit unsigned integer" &32 "32 bit unsigned integer" Strictly speaking, these should be "16-bit" and "32-bit" respectively, but perhaps the hyphen would confuse the text-to-speech engine? If so, you can continue to omit the hyphen. e^x "E to the x" 10^x "Ten to the x" y^x "Y to the x" Insert "power of" before "x" in each case: e^x "e to the power of x" 10^x "Ten to the power of x" y^x "y to the power of x" I also changed the case of the first letter of two of the above, because I'm not sure whether the text-to-speech engine calls out capital letters in a different way? Might not be necessary... Rand "Random" I'd change "Random" to "Random Number", for clarity. [Btw, I don't have the necessary privilege to reopen this bug.]
> &16 "16 bit unsigned integer" > &32 "32 bit unsigned integer" > > Strictly speaking, these should be "16-bit" and "32-bit" > respectively, but perhaps the hyphen would confuse the > text-to-speech engine? If so,you can continue to omit the > hyphen. FreeTTS, Eloquence/Viavoice and Festival get it right (when it's "16-bit"). DECtalk says "16 dash bit". Cepstral get's the "16-bit" right, but does an abyssmal pronuciation of "integer". Overall, I'll leave it as "16 bit" and "32 bit". It'll then speak right for all of them. > Insert "power of" before "x" in each case: > e^x "e to the power of x" > 10^x "Ten to the power of x" > y^x "y to the power of x" Done. > I also changed the case of the first letter of two of the above, > because I'm not sure whether the text-to-speech engine calls out > capital letters in a different way? Might not be necessary... It isn't. I left them as initialially capitalised. > Rand "Random" > I'd change "Random" to "Random Number", for clarity. Done. Changes in v4.2.102. > [Btw, I don't have the necessary privilege to reopen this bug.] Wow. As the original submitter of the bug, I'm surprised. No biggie in this case though. Thanks.
That's all fine with me -- thanks, Rich :) (Btw, it was Peter who opened this bug originally -- you were kind enough to think of copying me.) Peter may have other comments...
More text than "e^x" is important, but I'm concerned about replacing it with "e to the power of x" (and likewise long strings). The user will hear this text primarily when they tab through the dialog. 6 words is a lot to listen through. A calculator user would hopefully know what "e to the x" means. But I think the best thing here is to get some feedback from a Gnopernicus user or three.
I agree that the best thing is to get feedback from the users. I must admit that I don't think that "e to the x" is a common contraction in this part of the world, but perhaps I'm wrong. You're probably right that those who use a scientific calculator would be able to work out what it means. Peter is the accessibility expert here, so I defer to his judgement on this one :)
Well "<whatever> to the <whatever else>" was what I had originally, so by a democratic vote, I hereby reinstate that wording for those three button. Re-re-fixed in v4.2.103. I agree, lets fine tune this when we've had feedback from real users.