That creates a rather significant problem. Rich
Rich Schwerdtfeger From: Pete Brunet <[email protected]> To: Richard Schwerdtfeger/Austin/IBM@IBMUS, Cc: IA2 List <[email protected]>, [email protected], Alexander Surkov <[email protected]> Date: 02/04/2013 09:15 PM Subject: Re: [Accessibility-ia2] IA2 1.3 ready for review On 2/4/13 9:03 PM, Richard Schwerdtfeger wrote: Pete, Is there a plan to update AccProbe for the new interfaces? Hi Rich, AccProbe should be updated but there is no resource to do it. Alex: I am concerned about FF implementing this stuff in the middle of Candidate Recommendation phase. That would set everything back and there are already more bugs than I would like to see in FF 21 which need to be addressed. It would be best if this were synched with ARIA 1.1. Rich Rich Schwerdtfeger Inactive hide details for Pete Brunet ---02/04/2013 08:47:01 PM---On 2/4/13 8:16 PM, Alexander Surkov wrote: > Hi, Pete. Thank Pete Brunet ---02/04/2013 08:47:01 PM---On 2/4/13 8:16 PM, Alexander Surkov wrote: > Hi, Pete. Thank you for getting back on this. Answering From: Pete Brunet <[email protected]> To: Alexander Surkov <[email protected]>, Cc: IA2 List <[email protected]> Date: 02/04/2013 08:47 PM Subject: Re: [Accessibility-ia2] IA2 1.3 ready for review Sent by: [email protected] 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 -- 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
<<inline: graycol.gif>>
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
