Re: [Accessibility-ia2] IA2 1.3 ready for review
Hi all, Sorry for taking so long. Here is my feedback: Accessible2.idl: IAccessible2 has been removed from the Interfaces section. It should still be included. (I see Pete has already acknowledged this.) I'm not sure it makes sense to say the older interfaces (except IAccessibleTable, which has essentially been completely replaced) are deprecated, as the newer ones subclass them. The IAccessible2 interface still contains the modifications relevant to IAccessible2_2. Specifically, the max parameters for extendedStates and localizedExtendedStates have been removed and the new methods attribute, accessibleWithCaret and relationTargetsOfType have been added. I assume this was unintentional in this latest version. This critical, as it will breka binary compatibility. AccessibleDocument.idl: Regarding IAccessibleDocument::anchorTarget, I wonder whether a relation fits here, which would eliminate the need for this interface. I think this was discussed before, but I can't remember why this idea was dropped. After all, it just returns an accessible. AccessibleHypertext2.idl: The comments for the IAccessibleHypertext2 interface say: The %IAccessibleHypertext interface is the main interface to expose hyperlinks in a document, typically a text document... This is a bit confusing, as this documentation is for IAccessibleHypertext2, not IAccessibleHypertext. It should probably just mention that this extends IAccessibleHypertext. The same goes for IAccessibleText2. I'll reply to Alex's feedback separately. Thanks, Jamie On 21/09/2012 12:22 PM, Pete Brunet 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), ptbru...@live.com (MSN) http://www.a11ysoft.com/about/ Ionosphere: WS4G ___ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2 -- James Teh Director, NV Access Limited Email: ja...@nvaccess.org Web site: http://www.nvaccess.org/ Phone: +61 7 5667 8372 ___ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
Re: [Accessibility-ia2] IA2 1.3 ready for review
Hi, Jamie. Answering inline. 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. I believe there was some talk a while ago about making these all actions which can be triggered using the standard action mechanism. This would require a way to perform an action given a constant. It is why the idea of using negative action indices came up. It seems it doesn't answer why we can't turn out the whole IAccessibleEditableText interface into actions. Btw, I would prefer doAction taking a BSTR rather than negative constant. Otherwise we should standardize all possible actions and we don't leave a room for the server to introduce non-standard actions. 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? It seems we didn't go with EnumVariant at all but we added maxCount 'in' argument. Should we have it here as well? 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 :) I guess a grouping object/container would expose this relation referring to all objects it contains. Is this really useful? It'd be nice to have examples. Does it applicable to HTML fieldset and HTML form? Should it include the element connected by node_child_of relation if the element is not a descendant? Thank you. Alex. On Wed, Oct 10, 2012 at 3:39 PM, James Teh ja...@nvaccess.org wrote: On 24/09/2012 2:52 PM, Alexander Surkov wrote: 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. I believe there was some talk a while ago about making these all actions which can be triggered using the standard action mechanism. This would require a way to perform an action given a constant. It is why the idea of using negative action indices came up. 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? Isn't that the whole point of this method? Otherwise, wouldn't IAccessibleHypertext::hyperlink be enough? Maybe I'm missing something... 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 :) I guess a grouping object/container would expose this relation referring to all objects it contains. Is this really useful? 9) Description for IA2_RELATION_POPUP_INITIATOR_FOR doesn't make things really clear for implementers too. Yeah; I have no idea what this is for. :) Btw, the used string is popInitiatorFor, Looks like a typo to me. Thanks, Jamie -- James Teh Director, NV Access Limited Email: ja...@nvaccess.org Web site: http://www.nvaccess.org/ Phone: +61 7 5667 8372 ___ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2 ___ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
Re: [Accessibility-ia2] IA2 1.3 ready for review
On 10/10/2012 5:07 PM, Alexander Surkov wrote: It seems [introducing actions for editable text operations] doesn't answer why we can't turn out the whole IAccessibleEditableText interface into actions. I agree and tend to think this is the way forward. Btw, I would prefer doAction taking a BSTR rather than negative constant. Otherwise we should standardize all possible actions and we don't leave a room for the server to introduce non-standard actions. This requires a new method (and thus a new interface), which was the main reason for avoiding it. However, I'm not really against this. Using strings is a touch more expensive, but it's negligible and more extensible. 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? It seems we didn't go with EnumVariant at all but we added maxCount 'in' argument. Should we have it here as well? We could do that. The question is whether an AT is ever going to want to retrieve anything other than one or all hyperlinks. I can only come up with use cases for one or all. Jamie -- James Teh Director, NV Access Limited Email: ja...@nvaccess.org Web site: http://www.nvaccess.org/ Phone: +61 7 5667 8372 ___ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
Re: [Accessibility-ia2] IA2 1.3 ready for review
Btw, I would prefer doAction taking a BSTR rather than negative constant. Otherwise we should standardize all possible actions and we don't leave a room for the server to introduce non-standard actions. This requires a new method (and thus a new interface), which was the main reason for avoiding it. However, I'm not really against this. I see. Using strings is a touch more expensive, but it's negligible and more extensible. we can go with VARIANT as we did for object attributes. Alex. On Wed, Oct 10, 2012 at 4:24 PM, James Teh ja...@nvaccess.org wrote: On 10/10/2012 5:07 PM, Alexander Surkov wrote: It seems [introducing actions for editable text operations] doesn't answer why we can't turn out the whole IAccessibleEditableText interface into actions. I agree and tend to think this is the way forward. Btw, I would prefer doAction taking a BSTR rather than negative constant. Otherwise we should standardize all possible actions and we don't leave a room for the server to introduce non-standard actions. This requires a new method (and thus a new interface), which was the main reason for avoiding it. However, I'm not really against this. Using strings is a touch more expensive, but it's negligible and more extensible. 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? It seems we didn't go with EnumVariant at all but we added maxCount 'in' argument. Should we have it here as well? We could do that. The question is whether an AT is ever going to want to retrieve anything other than one or all hyperlinks. I can only come up with use cases for one or all. Jamie -- James Teh Director, NV Access Limited Email: ja...@nvaccess.org Web site: http://www.nvaccess.org/ Phone: +61 7 5667 8372 ___ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2 ___ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
Re: [Accessibility-ia2] IA2 1.3 ready for review
On 10/10/2012 5:31 PM, Alexander Surkov wrote: Using strings [for IAccessibleAction] is a touch more expensive, but it's negligible and more extensible. we can go with VARIANT as we did for object attributes. I'm not sure this makes sense. Do you mean standard constants would be numeric and custom ones would be strings? Jamie -- James Teh Director, NV Access Limited Email: ja...@nvaccess.org Web site: http://www.nvaccess.org/ Phone: +61 7 5667 8372 ___ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
Re: [Accessibility-ia2] IA2 1.3 ready for review
we can go with VARIANT as we did for object attributes. I'm not sure this makes sense. Do you mean standard constants would be numeric and custom ones would be strings? yes On Wed, Oct 10, 2012 at 4:41 PM, James Teh ja...@nvaccess.org wrote: On 10/10/2012 5:31 PM, Alexander Surkov wrote: Using strings [for IAccessibleAction] is a touch more expensive, but it's negligible and more extensible. we can go with VARIANT as we did for object attributes. I'm not sure this makes sense. Do you mean standard constants would be numeric and custom ones would be strings? Jamie -- James Teh Director, NV Access Limited Email: ja...@nvaccess.org Web site: http://www.nvaccess.org/ Phone: +61 7 5667 8372 ___ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2 ___ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
