GNOME Bugzilla – Bug 111854
frame context info is very useful
Last modified: 2004-12-22 21:47:04 UTC
when tabbing to widgets within a frame, often their label can be misunderstood without the context provided by the frame label. a good example can be found in the nautilus preferences dialogue (albeit not through proper frames): Icon View Defaults default zoom level [ 100% ] <- combo box [x] use compact layout [ ] use manual layout List View Defaults default zoom level [ 100% ] <-- combo box now, if gnopernicus correctly read out the combo box labels, tabbing through these controls wouldd sound like: "default zoom level, 100 percent" "use compact layout" "use manual layout" "default zoom level, 50 percent" you can see that the lack of context makes it hard to figure out what's going on here. billh noted the difficult balance of verbosity and context -> i believe this leans heavily towards context.
If relations for the above objects were corectly implemented in nautilus than there should be NO problem in gnopernicus.So what are you reporting is a nautilus bug : lack of relations for those objects. We are doing this context reporting, which is based on Relations like LABEL_FOR and LABALED_BY (please see in gnopernicus : 2.Input/Output settings| 2. Braille settings| 1. Braille device | Braille Device that the port number is reported "Port 1". BUT in this case relations are well defined.)
This problem is discussed in bugs 72249 and 103456. The problem is that the combo box is specified as the mnemonic widget for the label but the combo box has no knowledge that it is a mnemonic widget for the label. Without the change proposed for gtk+ in bug 103456, the solution is add the relations in the nautilus code. I am transferring the bug from gnopernicus to nautilus
This is not an issue with the label and combo box, I've already lodged bugs about those elsewhere. Read the report again: "when tabbing to widgets within a frame, often their label can be misunderstood without the context provided by the frame label." This has *nothing* to do with label/combo box relations, it has to do with frame/widget group relations. (This is further complicated by the HIG-compliancy hacks that aren't real frames, but exactly the same problem exists in dialogues that use frames, such as the keyboard a11y dialogue.) Please read the report again, because this bug is not what you've read it to be. (reassigning to gnopernicus)
In my opinion this is an enhancement request, so I change priority to "enhancement".
After some discutions with other gnome developers, all were agree that there should be a "labeled by" relation between frame label and every object in that frame. But, also there should be ONLY one relation of this kind, so, there is an issue, because the combo box already has an label. Setting a relation between it and frame label makes that for this object 2 relations. What is the solution here? A ideea is to have a "labeled by" relation the label which has a "label for" relation with the combo. Any other ideeas?
This isn't a case of multiple label-for/labeled-by relations, but rather a situation of a member-of-group relation. The one combo-box and two check boxes shown at the top of this bug are members of the same logical group - the "Icon View Defaults" group. That is the correct relation to use here.
I'm agree with you Peter, but how can I obtain the group name ("Icon View Defaults" in our case) starting from combo object? Ther is no such relation in at-spi. Member-of-group relation helps me only to get all objects contained in a group, not the "parent" of group.
The problem with using member-of-group relation is, as Remus, points out we cannot use the group to determine the label. It looks like we also need a label-for/labelled-by relations to navigate between the group and the label. Would using controller-for and controlled-by relations be an alternative?
Controller for/by is inappropriate. Changing the thing that is the "controller for" doesn't automatically change the thing that is "controlled by". Think about a spreadsheet cell, where one cell (the "controlled by" cell) contains a formula referencing another cell (the "controller for" cell). Here changing one changes the other (but not vice-versa). I imagine that labeling the group is probably the right answer, but we need to look carefully at this idiom in the Java Accessibility API (and StarOffice/OpenOffice.org) before coming to a final decision.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
the trouble with the group relation is that it results in a geometric expansion of relationships, i.e. in a group of N elements, each element currently has (N-1) relations. Also there is as has already been pointed out, no concept of a "group object", GROUP is explicitly only a relationship and is non-hierarchical. I am not comfortable with trying to introduce a semi-hierarchical convention as was discussed elsewhere by Peter (i.e. a convention that the first element in a group relation list is the 'parent'). However, I think the whole GROUP business is a red herring here; I agree with Jeff that this really should be about how gnopernicus deals with objects inside frames! A possible solution would be for gnopernicus to announce the frame text whenever focus moves from one frame to another (and on initial focus within a new toplevel); thus in Jeff's example you would hear: "Icon View Defaults; default zoom level 100%" [TAB], "use compact layout" [TAB], "use manual layout" [TAB], "List View Defaults; default zoom level 100%" etc. in other words announce the frame when focus enters a new frame. This would in my opinion solve the most urgent problem most of the time without introducing lots of new verbosity. - Bill
*** Bug 126261 has been marked as a duplicate of this bug. ***
In this case I think that a new kind of relation is necessary. Perhaps GROUPED_BY and GROUP_FOR relations. Any other ideea?
*** Bug 133275 has been marked as a duplicate of this bug. ***
*** Bug 133196 has been marked as a duplicate of this bug. ***
I think we can greatly improve the user experience with a simple change. <billh> The heuristic is the simple one-sentence heuristic I stated a moment ago <billh> "Gnopernicus should speak the label of a frame when focus moves to an object inside a frame, from outside the frame." <billh> SPI_ROLE_FRAME, specifically. <billh> For 'frame-within-a-frame' we have two easy choices: either speak all frame labels, starting from the "outermost" one that's changed, <billh> or the second simple choice is to speak only the "nearest" frame and stop searching at the first containing frame.
*** Bug 148573 has been marked as a duplicate of this bug. ***
upgrading the AP value since we are getting AP2 dups.
note that my suggested fix for bug 128289 may address this problem also, in many cases.
Created attachment 30228 [details] [review] proposed patch This patch includes also patch for 128289.
Patch applied to CVS.
the patch may fail if objects are packed using other methods than those in cases described in this bug and closed bugs as duplicates of this one.
Remus - could you please give a concrete example? Can you describe the packing of objects in a dialog? Perhaps even include a glade file showing the pathological packing?
Patch goes up in the hierarchy (but no more than a specified number of levels, 5 for this patch) till an object with role FILLER or PANEL and VERTICAL state is found. Then checks if this object has 2 children, a LABEL and a PANEL, otherwise this is not the "context". As an aditional check, if object detected as "context" and current object are already conected via a label_for/labeled_by relation, then first object is not reported as "context" for the second.
OK, I understand what the patch is designed to do. Now could you explain a situation or two in which the patch will fail? Best is a glade file illustrating this (one in which the naming container is within the 5 levels, as we know about that limit).