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 >[email protected] >http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > > _______________________________________________ gnome-accessibility-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
