Bug 2614 - Frysk GUI does not make (all) accessibility information available
Summary: Frysk GUI does not make (all) accessibility information available
Status: NEW
Alias: None
Product: frysk
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
: P1 normal
Target Milestone: ---
Assignee: Unassigned
Depends on:
Blocks: 2004 2271
  Show dependency treegraph
Reported: 2006-04-27 20:59 UTC by Len DiMaggio
Modified: 2008-03-18 15:00 UTC (History)
3 users (show)

See Also:
Last reconfirmed:

Screen shot (84.21 KB, image/jpeg)
2006-04-27 21:03 UTC, Len DiMaggio
Screen shot (24.71 KB, image/jpeg)
2006-04-27 21:04 UTC, Len DiMaggio
Another illustration - the lack of AT info makes edit/delete tests impossible. (14.75 KB, image/jpeg)
2006-05-02 18:51 UTC, Len DiMaggio

Note You need to log in before you can comment on or make changes to this bug.
Description Len DiMaggio 2006-04-27 20:59:12 UTC
This will ultimately be a problem for users relying on accessibility information
- it's definitely a problem for building automated tests as dogtail uses
accessibility information to access GUI objects.

The easiest way to implement this in a way to support dogtail and automated GUI
tests may be to always supply a "description" for each GUI element - as
supported by: javax.accessibility.setAccessibleDescription(String description)
 	Sets the accessible description of this object.


I've attached an example of what this looks like - as displayed by the dogtail
"sniff" utility. If a unique description - unique at least within each Frame -
is available, the dogtail test scripts can access all GUI elements. Without this
information, multiple GUI elements such as the combo boxes in the attached
screenshots cannot be accessed as dogtail will always access the same combo box.
Comment 1 Len DiMaggio 2006-04-27 21:03:03 UTC
Created attachment 988 [details]
Screen shot

This screen shot shows the information available for the selected combo box.
Note that description is blank. The Name field cannot be reliably used as the
value displayed isn't the name of the field, but rather the value selected from
the combo-box. In the case of this Frame, all the combo boxes have the same
role name value ("combo box") so dogtail cannot specify which one to select in
a test script.
Comment 2 Len DiMaggio 2006-04-27 21:04:58 UTC
Created attachment 989 [details]
Screen shot

Here's another illustration - this field has a "description" value that is
unique in the Frame - so, dogtail can specify the field:

observerName = observerPanel.child(roleName='text', description='Enter a name
for the observer')
Comment 3 Len DiMaggio 2006-05-02 18:51:09 UTC
Created attachment 998 [details]
Another illustration - the lack of AT info makes edit/delete tests impossible.
Comment 4 Len DiMaggio 2006-05-02 19:01:03 UTC
Assigning to Phil - May 2, 2006
Comment 5 Phil Muldoon 2006-05-02 19:17:43 UTC
Added other gui hackers, so they might investigate thier own respective glade
Comment 6 Len DiMaggio 2006-05-05 20:07:31 UTC
Action item for ldimaggi - define the AT-related fields in the glade files.
Comment 7 Len DiMaggio 2006-05-05 20:15:13 UTC
Proposed standard for the AT name values for each Glade GUI widget = 

               the widget name + a useful/mnemonic suffix

(ex)  vbox45 becomes vbox45_processGroupComboBox

Comment 8 Phil Muldoon 2006-05-09 14:50:17 UTC
While doing it the way you indicate sound goods, this will actually lead to a
scenario where the widgets name and the AT name will differ. 

Also, as vboxes/hboxes/alignment and most labels are not handled in Java thier
names are just left as the glade default.

What you propose will take weeks of work in the monitor (there are 1000s of
hboxes/vboxes/alignments/labels). The actual "real" widgets are already properly
named. Could we, for the time being, just propogate the name to the AT name, and
work with the long term goal of applying your mneumonic to
Comment 9 Len DiMaggio 2006-05-09 15:02:49 UTC
In response to Phil's comment this morning (2006-05-09):

YES - definitely - that's just what I had in mind. 

The key is to get some unique information into the AT name property. 

In working with some prototype test scripts for the Druid, it quickly became a
headache dealing with vbox/hbox named fields (but it was still possible), but we
probably won't want to even try to give better names to ALL those fields. We'll
try an iterative approach on added better names. 
Comment 10 Phil Muldoon 2006-11-28 15:14:35 UTC
Len, I think all AT info was exposed at this time, and we are current with the
glade files? (ie because of the dogtail scripts working, I would assume so)