Re: Wiki for atk best practices

[Bill Haneman <Bill Haneman Sun COM>]

Peter Parente wrote:

> Hi folks,
>
> I'd like to propose the creation of a wiki to support the discussion
> and documentation of "best practices" for applications which expose
> information through atk/at-spi. The idea is to have a place for
> existing atk developers to document how they make their standard
> widgets accessible and, more importantly, to provide a reference for
> new developers just starting to enable their applications. The goal is
> to avoid a proliferation of different uses of atk across applications
> and toolkits such that at-spi ATs only have to deal with one design
> per widget, or, at worst, a few with minor discrepancies.
>
> For instance, it would be nice to avoid different event orderings,
> detail1/detail2 field usage, and layouts of the accessible hierarchy
> in Firefox, OpenOffice, gtk, Qt, etc. tree widgets. As far as I can
> tell nothing in the atk/at-spi spec suggests, for tree table widgets,
> which interfaces should be implemented (though this may be obvious),
>  
Perhaps not, but examples of how the theoretical guidelines in the Atk 
and at-spi docs are applied seem useful.

> when events should be fired, in what order they should be fired, 
The above may not be feasible to specify.  We avoid specifying it 
because we really cannot guarantee what an implementation may/will do; 
our experience has been that we are mostly at the mercy of the toolkit's 
implementation details here.

> what
> data they should carry, 
That should go in the main API docs as part of the spec IMO...

> how the accessible objects should be arranged
> in the hierarchy, 
Again, possibly not something we can specify.  Our experience has been 
that this can and does change from release to release of a toolkit, and 
so little can or should be guaranteed.  Thus little should be assumed by 
the client about the ordering of children (unless a specific order has 
been requested, in the Collection API future).

> what roles non-trivial tree table cells should have
> (e.g. check boxes in cells), what object attributes an AT might expect
> to find, and so on. The wiki could give recommendations for all of
> these cases based on community consensus. Hopefully, making such
> information easily accessible would encourage developers to avoid
> making completely arbitrary decisions when they encounter a weakly
> specified use of the API.
>  
Generally seems OK with the above caveats.

> I know that Sun has published some initial documentation on gnome.org
> concerning atk in GNOME applications. A wiki could turn those pages
> into living documents and allow them to grow over time to encompass
> more widgets, more toolkits, changing uses of atk, and new atk/at-spi
> features. Of course, the wiki would probably start with pages about
> the basic gtk widgets and how gail makes them accessible today as a
> baseline. Even this basic information might help the KDE folks get
> started down a similar path for Qt. Over time, it could probably grow
> to encompass more complex topics like the new-atk implementation for
> documents in Firefox.
>
> Obviously, the wiki would have to have some organization for
> documenting widget classes, implementations, and attributes, but those
> details could be gradually decided upon over time. For now, I'd just
> like to hear what the community thinks about the idea. Would anyone
> contribute to such a wiki? Does anyone see a downside to encouraging
> the community at large to discuss atk best practices? Do people think
> this would improve the quality of application accessibility or hinder
> it?
>
> Let me hear your thoughts. We can discuss the idea further at the
> Boston Summit if it proves interesting to more than me alone. :)
>
> Thanks,
> Pete
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>