GNOME Bugzilla – Bug 607042
Orca does not always present sufficient context in Where Am I
Last modified: 2010-08-01 23:09:37 UTC
Steps to reproduce: 1. Move focus to the 'enabled' checkbox in the 'Progress Bar Updates' panel of the Speech page of the Preferences dialog. 2.Do a basic whereAmI Expected results: Orca would announce the label of the panel ('Progress Bar Updates') just as it does when presenting whereAmI information for a group of radio buttons. Actual results: Orca does not announce the label of the panel; just the label of the focused checkbox ('enabled') We should fix this.
Created attachment 151450 [details] This debug.out file representing Joanie reported problem. Possible this debug.out file help found why happen this problem. Attila
Created attachment 151508 [details] [review] take 1 Attila, this patch causes Orca to speak the first containing panel with a name if the user does a basic where am I on a checkbox. By doing this, we pick up the label you want spoken. Please test this and indicate whether or not it meets your needs. Thanks.
Joanmarie, the patch is working right if I do basic where am I command with all progressbar controls now. Need extend this patch fix with detailed where am I command. If you not have enough time to fix this, I look your patch and try solving this problem. Now, your fix resulting enough apply shorter hungarian translation with first progress bar update control (Enabled check box). I have one question: Possible do similar fix with normal navigation method? Attila
Created attachment 151527 [details] [review] Second patch I modifyed little your patch with src/orca/formatting.py. When the checkboxes is unfocused, and have a group label, Orca spokening this information. This modification is solving all prewious wroted problem with new progress bar update checkbox with prewious wroted another bugreport. This modification not look the verbosity setting now. A more elegant method possible need handling this problem: if the verbosity setting is set to detailed, good spokening this form the check box informations if the control is unfocused. If the verbosity setted up brief, possible enough old formatting value, and if the user want more information hearing, press where am I command. What can result this modification now? When I tabbed now the frequenci (secs) progress bar control and press Shift+tab key combination, I now hear right default the group label and the enabled checkbox checked message. This is good now. If don't need add detailed where am I with basic where am I formatting schema, because not often do users detailed where am I operations with checkboxes, please commit this modifyed patch, and this bug is full fixed. Or if you want, need handling this formatting setting with look the verbosity setting with my suggestion. Bot two method is good I think. Your openion? Attila
Comment on attachment 151508 [details] [review] take 1 This version has been committed to master because it fixes the problem (as confirmed by Attila) and does so without introducing additional chattiness which other users might find excessive and undesirable.
(In reply to comment #3) > Joanmarie, the patch is working right if I do basic where am I command with all > progressbar controls now. > Need extend this patch fix with detailed where am I command. If you not have > enough time to fix this, I look your patch and try solving this problem. It's not so much that I don't have enough time. Detailed whereAmI does not exist for all objects. It only exists in cases where the object is complex enough that two forms of whereAmI are necessary. Checkboxes are not complex enough to require two forms of whereAmI. Therefore, we do not have a Detailed whereAmI for checkboxes. Therefore, there is nothing to extend this functionality to. > I have one question: > Possible do similar fix with normal navigation method? Yes and no. Is it possible? Sure. Do the majority of users want that? I don't think so. I'll comment more on your proposed patch.
Review of attachment 151527 [details] [review]: Thank you for submitting this alternative version. I'm afraid I am rejecting it because it introduces "chattiness" in the form of repeating a label which -- for most users -- will be unwanted. Additional thoughts follow. ::: src/orca/formatting.py @@ +112,3 @@ pyatspi.ROLE_CHECK_BOX: { 'focused': 'checkedState', + 'unfocused': 'namedContainingPanel + labelAndName + roleName + checkedState + required + availability + ' + MNEMONIC + ' + accelerator', As a result of this change, users will hear "Progress Bar Updates Panel Progress Bar Updates enabled checkbox checked" when they initially give focus to the widget. The rest of the time, it will say "Progress Bar Updates enabled checkbox checked" each and every time focus is given to that checkbox from within the Progress Bar Updates panel. I realize that this is what you are proposing we should do. However, keep in mind that this is three additional words (in English anyway) that a user has to wait to be spoken before hearing the object with focus and its state (i.e. 'enabled checkbox checked'). Most users are able to easily figure out -- or, perhaps more accurately, most users already know and do not have to figure out -- that if they in the Progress Bar Updates Panel, what the 'enabled' checkbox enables is progress bar updates. As such, having this information spoken twice is unnecessary. Users who want to be efficient, rather than spend extra time listening to unnecessary (and in this case, redundant) labels, will complain (and file bugs) stating that we should not be repeating the panel label here because it was just spoken and that having to listen to it be spoken a second time slows them down and makes them less efficient. Being efficient is especially important for users who need Orca for work-related tasks. If you think that some users will benefit from having this label repeated all of the time, please open a new bug -- make that a new enhancement request. The change will need to be a setting, one that is *not* enabled by default.
It seems that when bugzilla indicates that a review is a 'draft' which has not yet been 'published', it is lying. <sighs> Sorry for the duplicate comment. Anyhoo, because I have committed the patch which fixes this problem, and because the other issues raised in this bug are not this bug but potential enhancement requests, I am closing this bug as FIXED. It should remain closed unless the patch I have committed breaks something. If new features (e.g. a chattier level of verbosity, the implementation of detailed Where Am I for checkboxes), new enhancement request(s) should be opened -- one request per enhancement.
Joanmarie, thank you your useful comments, I absolute agree. I open new enhancement request with bug 607206. Attila