Re: Wiki for atk best practices

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.

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
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

Let me hear your thoughts. We can discuss the idea further at the
Boston Summit if it proves interesting to more than me alone. :)

gnome-accessibility-list mailing list
gnome-accessibility-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]