Thanks Rob and Alex (and those who commented on this back in October).
Here is a proposal...
1) Relations
- Keep IAccessible2 and IARelation, but deprecate them.
- Add IAccessible2_2, with no inheritance to IAccessible or IAccessible2
- remove: nRelations, relations, relation
- add the following:
- nRelationTargets // if only the first one is needed don't call
this so the server doesn't have to calculate it
- relationTarget([in] index, [out] IUnknown) // if the index is bad
(or index==0 and there are no targets), out parameter is NULL
- relationTargets ([in] type, [out] array of IUnknowns) // don't use
this if only the first one is needed.
Alex, I added the first two methods due to your comment that ATs might
only need the first target and this would result in a noticeable
performance gain. If this is not a valid scenario I'd prefer to remove
those two methods.
To the AT devs, would you like the option of iterating via
relationTarget rather than iterating through the array returned by
relationTargets?
I don't think we need a method like
localizedRelationType([in] type, [out] localizedType)
to convert a relation type to a localized relation type, assuming it's
OK to let the ATs localize the 16 relation types, but let me know if you
disagree.
2) Attributes (see the email archives from Oct 22 - 26, 2009)
- Keep IAccessibleText but deprecate it.
- Add IAccessibleText_2.
- remove: attributes
- add:
- HRESULT attributeValue ([in] BSTR name, [out, retval] BSTR *value)
- IA2Attribute, a struct containing two BSTRs, one for the name, one
for the value
- HRESULT attributeList ([out, size_is(,*nAttributes)] IA2Attribute
**attributes, [out, retval] long *nAttributes)
- Make the same changes to IAccessible2_2, i.e.
- remove attributes
- add attributeValue, attributeList
3) Extended States
There had been talk about removing extendedStates and
localizedExtendedStates. From the spec, the definition of "extended
state" is:
An extended state is a state which is dynamically generated by the
application. It is not predefined by the IAccessible2 specification.
Does anyone see a need for these?
Pete
---
Rob Gallo wrote:
> I'll say a couple of things straight away:
>
> IA2_2 should not inherit from IA2. That way we're not tied down by having to
> implement stubs for legacy functions; the interface will be cleaner; and we
> don't waste good function names (we can simply change the signatures).
>
> And Firefox should not stop supporting IA2. Firefox can support both
> interfaces, but it can't stop supporting IA2 because of users with older
> versions of Jaws.
>
>
>
>
> Thanks,
> RG
>
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> Alexander Surkov
> Sent: Wednesday, February 17, 2010 4:53 AM
> To: Pete Brunet
> Cc: IA2 List
> Subject: Re: [Accessibility-ia2] Relations
>
> Hi. Pete.
>
> I think I'm fine with your suggestion.
>
> 1) replace IAccessible2 by new interface
> 2) change the relation methods
> 3) change attribute methods
>
> However we could return an accessible relation object if we want to save
> localizing stuffs and an ability for lazy calculation of relation targets
> (for instance if the client needs the first target only and do not get
> target count then we could not calculate other targets). In this case we
> don't need to introduce stuffs like getNextTarget (getNextTarget approach is
> a bit more evident though).
>
> However it would be really nice to get opinion from James and Rob.
>
> 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
