Realistically, do ATs ever call localizedRelationType? I was thinking that it was a bit excessive to require every application to localize the same constant set of strings. It would seem "closer to the user" to just leave it up to the AT whether those strings need to be localized or not.
Carolyn From: Alexander Surkov <[email protected]> To: Pete Brunet <[email protected]> Cc: IA2 List <[email protected]> Date: 26/10/2009 06:25 AM Subject: Re: [Accessibility-ia2] Relations Sent by: [email protected] Hello. If AT needs IAccessibleRelation::localizedRelationType (however it's not implemented in Firefox for example and no idea what AT expects actually) then we can't drop IAccessibleRelation and introduce "relationTargets ([in] type, [out] array of IUnknowns)", but instead it should be "relationTargets ([in] type, [out] array of IAccessibleRelation)". Concerning to IAccessibleRelation::getNextTarget, it's worth to introduce if there are cases when AT wants to get only one relation even if several ones are available. For example, if AT wants to speak the first relations and speak next relations on user demand only. Thank you. Alex. On Fri, Oct 23, 2009 at 11:48 PM, Pete Brunet <[email protected]> wrote: > Here is a summary of yesterday's discussions regarding relations > > Pete > - replace IA2 with IA2_2 > - remove: nRelations, relations, relation > - add: relation ([in] type, [out] IARelation) > > Carolyn > - keep IAccessible2, deprecating nRelations, relations, relation > - add IARelationships with 2 methods, relations and relationsForType > > Jamie > - Regarding new IARelationships > - It's not clear if Jamie wants to keep the first method Carolyn suggests, > i.e. relations > - For relationsForType he prefers either > - relation ([in] type, [out] IARelation) /* my suggestion */ OR > - relation ([in] type, [out] array of IUnknowns), deprecating IARelation > - Since we are considering adding support for attributes, this gives weight > to IA2_2 > - Consider extending IA2_2 via inheriting from IA2 > > Alex > - prefers to not have relations method in the new IARelationships > - add getNextTarget > > My comments... > > There are actually three reasons to change IAccessible2 > 1) fix relations > 2) fix attributes > 3) remove the unneeded inheritance from IAccessilbe > > If IA2_2 was defined to not inherit from IA2 (and thus not from IA) would > the rework on either the client side, server side, or both be too much to > warrant the effort? > > I propose IA2_2 (possibly not inheriting from IA2), > - deprecating: nRelations, relations, relation and IARelations > - add: relationTargets ([in] type, [out] array of IUnknowns) > - note: I didn't list nextTarget (from Alex) but if others feel this is a > good method we can discuss it > > Also, there is no support in this for a localizedRelationType. Is a method > needed, i.e. localizedRelation ([in] type, [out] relation)? > > Pete > --- > Alexander Surkov wrote: > > Hi. > > Thinking from performance point of view and assuming AT don't need all > relations always I like more original proposal because it allows to > calculate relations lazily. However it could require to extend > IAccessibleRelation by method "boolean GetNextTarget(IAccessible > **aTarget)" or similarly. So server won't calculate all targets for > the given relation type until AT request it. > > I have not strong opinion if interface should be deprecated or > methods. However if we have a practice to deprecate interface entirely > (I mean IAccessibleTable interface) then we should follow it. > > I like IAccessible2_2, that's probably the best. Though I'd happy to > hear better one :) It's more evident than IAccessible22. However we > append '2' in the end of interface name like in the case of > IAccessibleTable2. Therefore IAccessible22 should be more logically > correct but it may confuse. On the another hand our successors could > really invent IAccessible22 specification in 1000 years :). As well > IAccessible2_2 it's more correct than IAccessible3 because > IAccessible2 has additional meanings of set of interfaces or > specification. > > Thank you. > Alex. > > > On Fri, Oct 23, 2009 at 7:00 AM, James Teh <[email protected]> wrote: > > > On 23/10/2009 1:03 AM, Carolyn MacLeod wrote: > > > I think deprecating IAccessible2 would be really confusing to everyone, > no matter what the new interface's name is. > > > Agreed, although there may be sufficient justification; ee below. > > > > Perhaps something like this might be a bit less wild? > - deprecate IAccessible2::nRelations, relation, relations > - add IAccessibleRelationships > > > I think this makes sense if this is the only reason we are deprecating > IAccessible2. > > > (although I guess then AT's would have to QI or QS to get an object's > > relations, which is more work for a pretty common thing...) > QI isn't so bad. Certainly, I think QS would be a bad thing. > > > > which has only 2 methods: relations and > relationsForType > > > I'm more for Pete's original suggestion; i.e. > > > HRESULT relation ([in] BSTR *relationType, [out, retval] IAccessibleRelation > **relation) > > > Remember that IAccessibleRelation accounts for multiple targets. > > Another idea is to deprecate IAccessibleRelation altogether and just > have the relation() method return an array of targets for the specified > type, similar to IAccessibleTableCell::columnHeaderCells. The question > is: when retrieving relations, is it fair to assume that an AT wants all > targets in the majority of cases? If this is an incorrect assumption, > then this would be less efficient. > > With regard to deprecating IAccessible2: > If it was just relations, I would think a new interface (as proposed > here) is fine. However, if we want a new interface for attributes as > well (see Pete's previous email), that's two new "add-on" interfaces > replacing deprecated functionality. In that case, perhaps it is time to > consider deprecating IAccessible2. However, I agree that this would be a > total pain for everyone involved. > > The Microsoft approach is generally to subclass the old interface and > just add the new methods to the subclassed interface, rather than > replacing it altogether. See MSHTML for example. > > 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 > > _______________________________________________ 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
