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".
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 _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
