GNOME Bugzilla – Bug 436661
flat-review speaks SwingSet2 toolbar image paths instead of item names
Last modified: 2008-07-22 19:27:39 UTC
Using KP_6 to move through the SwingSet toolbar items causes Orca to speak the full path to the image icons for the toolbar items. Orca should speak the toolbar item names, for example, "InternalFrame demo." 1. Start SwingSet2 2. Hit tab to move to the next toolbar item. Orca correctly speaks the toolbar item name. 3. Hit KP_6 to move flat-review to the next toolbar item. Orca incorrectly speaks the path to the jpg image for the toolbar item, instead of the item name.
The problem is that for Swing images, the image description is typically the path to the image file. It would be better to speak the accessible description, which is typically the tooltip text. Here's the accessible information for the first JToggleButton in the SwingSet2 toolbar. The tooltip displayed is 'JInternalFrame Demo'. flat_review.getZonesFromAccessible (name= role=toggle button) text='', label='None', description='JInternalFrame demo', image.imageDescription='jar:file:/home/monsanto/jdk1.6.0/demo/jfc/SwingSet2/SwingSet2.jar!/resources/images/toolbar/JDesktop.gif' What's the best thing to do here where there is a tooltip? There's related problem in the Java Control Panel where an image is displayed, but there no tooltip. The only information available is the image description, which is another file path. I think it would be better to simply speak 'image' rather than speak the long image path, which sounds like nonsense.
I'm not quite sure where all the text is coming from. What does the accessible hierarchy look like for this object?
frame root pane layered pane panel panel panel panel tool bar toggle button
Well...darn. It looks like some work might need to be done in flat_review.py:getZonesFromAccessible. Right now, it assumes that if the thing has an image with a description, the developer actually used a human consumable string for the description. Looks like Swing, on the other hand, has a strong desire to put *something* in there, so it chooses the pathname. I wonder if getZonesFromAccessible should pursue the name and description of the object and the description of the image in a different logical order: 1) Check for accessible.name, if it exists and has len > 0, use it 2) Otherwise, do the same for accessible.description 3) Otherwise, do the same for accessible.image.description This may be achievable by moving the block (and refactoring it to set 'string' instead of creating a zone directly) starting at line 783: # We really want the accessible text information. But, if we have # an image, and it has a description, we can fall back on it. # if (len(zones) == 0) \ ... to an elif clause starting at line 837 (e.g., after we've already checked name and description). If this makes sense, can you please give it a shot? My fear is that reorganizing this logic is going to expose problems where the accessible name and/or description contain nonsense while the image.description contains the good stuff. I'll guess we'll find out. If that does become true, will need to create a heuristic for deciding which of the three to use.
Created attachment 89131 [details] [review] possible patch Will, I didn't follow the reasoning for moving the image-handling code from the block starting at line 783 to the block starting at 837. It seems like it would be better to leave the specialized image-handling logic (getImagePosition, getImageSize) in the existing block, even if it duplicates some tests. The attached patch works for SwingSet2. It needs to be tested on some non-Java applications. Any suggestions? I didn't seen anything in gtk-demo, except for 'icon view basics'.
> I didn't follow the reasoning for moving the image-handling code from the block > starting at line 783 to the block starting at 837. It seems like it would be > better to leave the specialized image-handling logic (getImagePosition, > getImageSize) in the existing block, even if it duplicates some tests. This patch looks good. I like it and it seems like the right thing to do. I'm marking this as "accepted-commit-now" with the assumption you'll test this a bit more. Thanks! > The attached patch works for SwingSet2. It needs to be tested on some non-Java > applications. Any suggestions? I didn't seen anything in gtk-demo, except for > 'icon view basics'. I'm not sure...in gtk-demo, there's a "Stock Icon and Item Browser" demo. In the table, the icons don't have any names. The icon in the right hand panel, however, seems to get a name. Right now, Orca reads the name in flat review, so you might to make sure it still reads the name with your patch. The same thing goes for the images in the dialogs you can bring up in gtk-demo's "Dialog and Message Boxes" demo.
I tested with gtk-demo and found no regressions; changing bug status to fixed.