Even if you can't specify something, saying what the best practices are, or explaining where there is more/less flexibility helps everyone.
- Aaron Peter Parente wrote: > Thanks for the quick response, Bill. More comments below. > > >>> 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. >> > > Agreed. > > >>> 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. >> > > True. Still, documenting a preferred approach and paths to other less > desirable, but still respectable, solutions might be helpful. The idea > is to minimize discrepancy when we can't completely eliminate it. When > a developer must deviate from the norm, the wiki is there to catalog > the difference for others to note. > > >>> what >>> data they should carry, >>> >>> >> That should go in the main API docs as part of the spec IMO... >> > > I agree that some of this information should make it back into the API > spec. Perhaps the wiki could be a proving ground. Consensus on the > wiki might suggest promotion to the spec. > > >>> 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). >> > > I was vague here. I was more specifically talking about the use of > relations to specify tree parent/child relationships in an otherwise > flat accessible hierarchy for tree tables. Again, it would be nice to > at least document solutions such as this one to minimize discrepancies > across apps and toolkits. > > 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
