I agree with both Jamie and Alex on the Relations issue. I think that IAccessible2::relation (the singular version, which returns one relation given an index) is a problem because if the application adds or removes a relation, then the index is no longer valid. Would you consider deprecating this method?
Yes, it makes a lot more sense for a client to ask for relations based on type, rather than index. But that would mean you need IAccessible3... <grin> Carolyn From: Alexander Surkov <[email protected]> To: [email protected] Cc: [email protected] Date: 21/10/2009 12:18 AM Subject: Re: [Accessibility-ia2] IA2 and ATK Sent by: [email protected] Hi, Pete. James said almost everything I could say. Few notions. > Why were IATable2 and IATableCell requested and why wasn't IATable a > suitable solution? Technically everything coming from IATable2 and IATableCell is syntax sugar excepting IATableCell's row and column header cells getting. Because the way IATableCell expose heading information is more complete and graphic than IATable does. IATable allows either to not expose trick table information :) or expose it in very trick manner by virtual table usage like Jamie noticed. It would be implementation pain and the first option might be chosen by server I guess :). I can provide couple of examples if it's needed. > Does ATK need similar changes? ATK based AT might find useful and nice all this sugar additions. IATableCell provides direct access to table accessible like Jamie said and it provides an access to couple of table cell properties (like row/column extent) which should be more comfortable than existing approach in IATable. > Are there areas that need improvement in either IA2 or ATK (or both)? I didn't catch Jamie about hyperlink and action, partially I didn't understand why hyperlink can have only one action if it's inherited from hyperlink. I think I felt out of context. Jamie, please give additional details. I agree with Jamie on second item (relations issue). It's both IA2 and ATK problem. Additionally I would like to say about third problem which also concerns to IA2 and ATK both. It should be nice to have a new method to deal with object attributes and text attributes, i.e a method to get attribute value by its name. It should help both client and server sides to deal with attributes (it's not needed to calculate attributes all together and then parse them from string) and improve performance as well. If AT wants to get attributes all together but they don't want to parse a string then we could introduce attributes collection object like we have for relations in IA2. I think we should start separate topics for every mentioned improvement request. > What has changed in IA2 between the initial release of IA2 and now that should be considered for incorporation back into ATK? I'll join here to Jamie. AFAIK table related changes is the first time when we change IA2 interface. That was the first time when we updated IA2 interfaces in Firefox after IA2 interfaces initial release iirc. Thank you. Alex. On Wed, Oct 21, 2009 at 5:29 AM, James Teh <[email protected]> wrote: > Hi Pete, > > I can answer some of these to at least some extent. > > On 21/10/2009 2:16 AM, Pete Brunet wrote: >> 1) Why were IATable2 and IATableCell requested and why wasn't IATable a >> suitable solution? > * IATable provided a somewhat obscure mechanism for retrieving table > headers, returning an IATable object for the headers. If multiple column > headers were to be returned, this would probably require a "virtual" > table to be created by the app. It was felt that a simpler, more direct > way was needed to retrieve row and column headers. > * Many IATable methods took a table cell index as a parameter. It was > felt that it would be much easier to just pass in the object for the > required cell, since most of the time, a client already has the cell > object anyway when querying for further information. > * IATableCell provides a simple, direct way to retrieve the table from > its cells. Previously, a client had to crawl up the object hierarchy to > find the table, which is somewhat obscure and tedious at best. > >> Does ATK need similar changes? > If ATK's table interface is virtually equivalent to IATable, then yes, I > would argue that it does. NNote that I'm not familiar with ATK's table > interface, so this one's for Alex. :) > >> 2) When IA2 started a goal was to make it as close as possible to ATK so >> when IA2 was released it was as close to ATK as could be accomplished. >> What has changed in IA2 between the initial release of IA2 and now that >> should be considered for incorporation back into ATK? > I don't think any new interfaces have been added to IA2 since its > initial release, so it follows that no new methods have been added. For > the most part, it has been documentation clarifications. > >> 3) Are there areas that need improvement in either IA2 or ATK (or both)? > I can't speak for ATK, but for IA2: > * IAHyperlink: A discussion was started regarding the derivation of > IAHyperlink from IAAction. In short, I feel that this derivation infers > that a hyperlink can only have one action. However, we never came to a > conclusion on what should be done there. > * Relations: I think the current mechanism for relations is rather > suboptimal at best. A client cannot retrieve a relation by its type, > which is I think the most common request. For example, a client can't > ask specifically for the "controlledBy" relation. Instead, the client > must request all relations in one shot or crawl through the individual > relations until it finds the one it requires. This is also inefficient > on the server side, because the server then has to create relation > objects which will probably never even be used. For this reason, NVDA > never uses the current IA2 relation mechanism and instead uses Gecko's > special relation constants for IAccessible::accNavigate. > > Jamie > > -- > James Teh > Email/MSN Messenger/Jabber: [email protected] > Web site: http://www.jantrid.net/ > _______________________________________________ > Accessibility-ia2 mailing list > [email protected] > https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2 > _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
