On 2/4/13 8:52 PM, Alexander Surkov wrote:
> Hi, Pete. It looks good. Perhaps I'd change "In some cases an
> application's accessible tree is such that an object can have a
> logical parent which is not its parent in the tree of accessibles." to
> "... such that objects can be in a logical parent-child relationship
> which is different from hierarchy in the accessible tree".
Thanks Alex, I changed the text.
>
> Thank you.
> Alex.
>
>
> On Tue, Feb 5, 2013 at 11:46 AM, Pete Brunet <[email protected]> wrote:
>> On 2/4/13 8:16 PM, Alexander Surkov wrote:
>>
>> Hi, Pete. Thank you for getting back on this. Answering inline.
>>
>> 1) It makes sense to allow IAccessible2_2::attribute to take sequence
>> of attribute names like "margin-left;margin-right;" to get these
>> attribute values for a single call.
>>
>> Is this important enough to add additional development effort for server
>> side implementers?
>>
>> Let's leave it out of IA2 1.3. Otherwise I afraid we never get it
>> done. If the feature is needed by AT then it can be prototyped in the
>> browser before we put it into spec since it doesn't require the
>> interface changes.
>>
>> 3) Any specific reason to use long for nTargets in
>> relationTargetsOfType since it seems it never takes negative values?
>>
>> It's a good point, but since an unsigned long wasn't used anywhere else it
>> seems like at least for the sake of consistency to leave it as is.
>>
>> I don't mind.
>>
>> 6) IAccessibleHypertext2::hyperlinks. Just to make sure: we decided to
>> go with array instead EnumVariant? Do AT want to get all items at once
>> even if the document is big and has many links?
>>
>> Back on 14 Aug 2012 you agreed that the array would be preferred in order to
>> keep it consistent with the array returned by
>> IAccessible2_2::relationTargetsOfType.
>>
>> If I agreed then ok :) It seems our discussion is many years long. I
>> can hardly remember where we started from. I think my point was that
>> obtaining all hyperlinks can be slow. If it is an issue then we can
>> address it the next round if necessary.
>>
>> 8) IA2_RELATION_NODE_PARENT_OF "This object is a parent of a target
>> object." It's not clear as well since it doesn't answer why
>> get_accParent doesn't work. Maybe you should say it's a logical parent
>> and the relation is reverse to RELATION_NODE_CHILD_OF. It is used, for
>> example, for flat structured trees.
>>
>> I could remove it. Noone else showed interest in it other than for symmetry
>> with IA2_RELATION_NODE_CHILD_OF. The comment about get_accParent is a good
>> one. You asked for this new relation back on 9 Nov 09 because you added it
>> for ATK and wanted to enhance the symmetry between the ATK and IA2
>> interfaces. Or I could just add another sentence, "This relation is the
>> reciprocal of IA2_RELATION_NODE_CHILD_OF." I didn't understand the comment
>> about flat structured trees but if you want to keep this relation please
>> provide an additional sentence.
>>
>> We shouldn't remove it. It's needed for sync with ATK. Also this
>> constant was settled down in ARIA spec implementation guide already :)
>>
>> If you use "logical parent" instead "parent" (i.e. not a parent in the
>> accessible tree) then it should be fine. It can sound "This object is
>> a logical parent of a target object. This relation is the reciprocal
>> of IA2_RELATION_NODE_CHILD_OF."
>>
>> About flat trees. The accessible tree may look like:
>>
>> <div role="tree">
>> <div role="treeitem" level="1">item</div>
>> <div role="treeitem" level="2">sub item</div>
>> </div>
>>
>> in this case parent for 'item' and 'subitem' is 'tree' but logical
>> parent of 'subitem' is 'item'.
>>
>> I updated the comments as follows. Please review.
>>
>> /** This object is a logical child of a target object. This relation is the
>> reciprocal
>> of the IA2_RELATION_NODE_PARENT_OF relation. In some cases an application's
>> accessible
>> tree is such that an object can have a logical parent which is not its
>> parent in the
>> tree of accessibles. */
>> const WCHAR *const IA2_RELATION_NODE_CHILD_OF = L"nodeChildOf";
>>
>> /** This object is a logical parent of a target object. This relation is the
>> reciprocal
>> of the IA2_RELATION_NODE_CHILD_OF relation. In some cases an application's
>> accessible
>> tree is such that an object can have a logical parent which is not its
>> parent in the
>> tree of accessibles. */
>> const WCHAR *const IA2_RELATION_NODE_PARENT_OF = L"nodeParentOf";
>>
>>
>> Thank you.
>> Alex.
>>
>>
>> On Tue, Feb 5, 2013 at 8:13 AM, Pete Brunet <[email protected]> wrote:
>>
>> Hi Alex, I am going to try to get some momentum going on this again...
>>
>>
>> On 9/23/12 11:52 PM, Alexander Surkov wrote:
>>
>> Hi, Pete. Here's my two cents.
>>
>> 1) It makes sense to allow IAccessible2_2::attribute to take sequence
>> of attribute names like "margin-left;margin-right;" to get these
>> attribute values for a single call.
>>
>> Is this important enough to add additional development effort for server
>> side implementers?
>>
>> 2) It'd be nice to add a reference to relation constants for
>> relationTargetsOfType method description, see "[in] type The requested
>> relation type."
>>
>> Done.
>>
>> 3) Any specific reason to use long for nTargets in
>> relationTargetsOfType since it seems it never takes negative values?
>>
>> It's a good point, but since an unsigned long wasn't used anywhere else it
>> seems like at least for the sake of consistency to leave it as is.
>>
>> 4) Should we keep IAccessibleDocument restricted to HTML documents?
>> After all HTML sounds like an implementation detail. The idea it
>> serves to is when the loaded document shouldn't be read from the
>> beginning.
>>
>> I changed it to:
>> /** @brief Returns the most recently used anchor target within a document.
>>
>> A document's most recently targeted in-page anchor is returned. A
>> typical use
>> of this method is to fetch the anchor target within an HTML document.
>> In this
>> case anchor targets are those which has been defined with the <a> tag.
>>
>> 5) "Document that copyText, cutText, and pasteText are deprecated."
>> Can you please refresh me on it? The reason specified is "This
>> function is available via the application's GUI." but it seems it can
>> be applied to the whole IAccessibleEditableText interface.
>>
>> This was a long discussion involving several people back in June 2011 from
>> the 7th to the 29th and this is what we ended up with. It was determined
>> that the three deprecated methods are clipboard operations and there are too
>> many differences and ambiguities in how applications implement their
>> clipboard functionality. Also copy/cut/paste methods are not in use while
>> the other ones are so we can't deprecate the entire interface. We also
>> talked about adding, if needed at some later date, five new actions for cut,
>> copy, pasteDefault, pasteFormatted, pasteUnformatted.
>>
>> 6) IAccessibleHypertext2::hyperlinks. Just to make sure: we decided to
>> go with array instead EnumVariant? Do AT want to get all items at once
>> even if the document is big and has many links?
>>
>> Back on 14 Aug 2012 you agreed that the array would be preferred in order to
>> keep it consistent with the array returned by
>> IAccessible2_2::relationTargetsOfType.
>>
>> 7) IA2_RELATION_GROUPING_OBJECT_FOR: "This object is a grouping object
>> for the target object." - it'd be nice to give a hint for
>> implementers. After a time I don't really remember what is it about :)
>>
>> Actually this got into this draft of the spec by mistake. We agreed it was
>> not needed back on 1 March 12. Ditto with
>> IA2_RELATION_POPUP_INITIATOR_FOR. I removed them both.
>>
>> 8) IA2_RELATION_NODE_PARENT_OF "This object is a parent of a target
>> object." It's not clear as well since it doesn't answer why
>> get_accParent doesn't work. Maybe you should say it's a logical parent
>> and the relation is reverse to RELATION_NODE_CHILD_OF. It is used, for
>> example, for flat structured trees.
>>
>> I could remove it. Noone else showed interest in it other than for symmetry
>> with IA2_RELATION_NODE_CHILD_OF. The comment about get_accParent is a good
>> one. You asked for this new relation back on 9 Nov 09 because you added it
>> for ATK and wanted to enhance the symmetry between the ATK and IA2
>> interfaces. Or I could just add another sentence, "This relation is the
>> reciprocal of IA2_RELATION_NODE_CHILD_OF." I didn't understand the comment
>> about flat structured trees but if you want to keep this relation please
>> provide an additional sentence.
>>
>> 9) Description for IA2_RELATION_POPUP_INITIATOR_FOR doesn't make
>> things really clear for implementers too. Btw, the used string is
>> "popInitiatorFor", I'm not sure if this is on demand, should it be
>> "popupInitiatorFor" instead?
>>
>> Removed. See #7.
>>
>> 10) Both IAccessibleHypertext and IAccessibleText are marked as
>> deprecated (see http://a11ysoft.com/ia2/docs/html/), however
>> IAccessibleHypertext2 and IAccessibleText2 are inherited from them.
>> What does deprecation mean here?
>>
>> Thanks for noticing that Alex. Does anyone see any issues if I remove the
>> inheritance?
>>
>> Thank you.
>> Alex.
>>
>>
>> On Fri, Sep 21, 2012 at 11:22 AM, Pete Brunet <[email protected]> wrote:
>>
>> I finished up the IA2 1.3 work over the weekend but due to some changes on
>> the LF web site am unable to post it there. I've provided it at
>> a11ysoft.com. Please review it. I won't get to the object attributes until
>> later (to add explicit-name).
>>
>> documentation: http://a11ysoft.com/ia2/docs/html
>> zip file: http://a11ysoft.com/ia2.zip
>>
>> The one bug I see so far is that I don't have a link for the IAccessible2
>> interface on the main page. That is at:
>> http://www.a11ysoft.com/ia2/docs/html/interface_i_accessible2.html
>>
>> The zip file contains everything I'll eventually post on the LF site, among
>> other things, changelog.txt and the merged IDL file, ia2_api_all.idl.
>>
>> Pete
>> --
>> Pete Brunet
>>
>> a11ysoft - Accessibility Architecture and Development
>> (512) 467-4706 (work), (512) 689-4155 (cell)
>> Skype: pete.brunet
>> IM: ptbrunet (AOL, Google), [email protected] (MSN)
>> http://www.a11ysoft.com/about/
>> Ionosphere: WS4G
>>
>> _______________________________________________
>> Accessibility-ia2 mailing list
>> [email protected]
>> https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
>>
>>
>> --
>> Pete Brunet
>>
>> a11ysoft - Accessibility Architecture and Development
>> (512) 467-4706 (work), (512) 689-4155 (cell)
>> Skype: pete.brunet
>> IM: ptbrunet (AOL, Google), [email protected] (MSN)
>> http://www.a11ysoft.com/about/
>> Ionosphere: WS4G
>>
>>
>> --
>> Pete Brunet
>>
>> a11ysoft - Accessibility Architecture and Development
>> (512) 467-4706 (work), (512) 689-4155 (cell)
>> Skype: pete.brunet
>> IM: ptbrunet (AOL, Google), [email protected] (MSN)
>> http://www.a11ysoft.com/about/
>> Ionosphere: WS4G
--
*Pete Brunet*
a11ysoft - Accessibility Architecture and Development
(512) 467-4706 (work), (512) 689-4155 (cell)
Skype: pete.brunet
IM: ptbrunet (AOL, Google), [email protected] (MSN)
http://www.a11ysoft.com/about/
Ionosphere: WS4G
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
