Re: extension of Glade DTD to support accessibility

[Colm Smyth <Colm Smyth sun COM>]

Hi Bill,

I suggest that Sun's Accessibility team are probably the only people
in the GNOME project with the background knowledge and experience needed
to design this critical feature for GNOME.

If the team could propose a workable extension of the Glade DTD that
provides additional attributes to libglade, we could simply drive
that with the community and the glade maintaners.

BTW, while we're talking about areas where Sun needs to evangelize
projects for the community to implement, what is our strategy for
evangelizing the creation of AtkObject implementations for "non-core" 
Gtk+ widgets (e-table is just one  interesting example) ? (would 
supporting these have any implications for the libglade DTD?)

Colm.

>From: Bill Haneman <Bill Haneman sun COM>
>Subject: extension of Glade DTD to support accessibility
>To: gnome-accessibility-list gnome org
>Cc: james daa com au, John Heard sun COM, gnome-devel ireland sun com
>MIME-Version: 1.0
>Content-MD5: WMI+Dz/oCAQ3lDFnoEXblQ==
>
>Hi folks:
>
>For awhile now one of the ideas in the background of Gnome accessibility 
>has been how Glade can help us enhance accessibility for applications.  
>Now that we have defined a set of accessibility interfaces and 
>properties, it seems appropriate to consider how to support those 
>properties in Glade/libglade.
>
>As has been pointed out before, in many cases applications may need to 
>provide accessibility hints in addition to or instead of those provided 
>"automatically" by the ATK implementation for stock GTK widgets.  For 
>example, an unlabelled button may wish to set an accessibility "name" 
>without actually containing a label:
>
>  AtkObject atkObject = gtk_widget_get_accessible (aButton);
>
>  atk_object_set_name (atkObject, "Quit");
>
>I believe that a libglade application can do this by querying libglade 
>for a pointer to the appropriate widget, via the widget's unique 
>identifier.  However it would be nicer if some ATK properties (at least) 
>were settable via attributes in the Glade XML.
>
>This presumably suggests three steps:
>
>extension of Glade's XML DTD to include these (optional) attributes;
>extension of libglade to parse these attributes and call the appropriate 
>atk methods (as above);
>(eventually) extension of Glade to expose these attributes when a 
>developer is setting widget properties in the Glade UI builder.
>
>I believe that the ATK attributes of most interest are those ordinarily 
>set by the following ATK methods:
>
>atk_image_set_image_description (AtkImage *image, gchar *desc);
>atk_object_set_name (AtkObject *accessible, gchar * name);
>atk_object_set_description (AtkObject *accessible, gchar *desc);
>atk_object_set_parent (AtkObject *accessible, AtkObject *parent);
>atk_object_set_role (AtkObject *accessible, AtkRole role);
> (ROLES are readily specified via a string)
>atk_table_set_caption  (AtkTable *table, gchar *caption);
>atk_table_set_column_description (AtkTable *table, gchar *desc);
>atk_table_set_row_description  (AtkTable *table, gchar *desc);
>
>also (very important!) need to have multiple attributes of type 
>"atk_relation" settable on a widget.  The atk_relation consists of a 
>relation type flag (such as LABEL_FOR) and a reference to some other 
>widget (implementable using an "id" attribute if glade XML supports such 
>attributes on the XML elements). AtkObject's set_parent method likewise 
>takes a reference to an "AtkObject" object.  The other methods are 
>readily implemented using character strings as attribute values.
>
>Comments, suggestions (and volunteers :-) welcome...
>
>-Bill
>
>------
>Bill Haneman x19279
>Gnome Accessibility / Batik SVG Toolkit
>Sun Microsystems Ireland 
>