Here is a summary of the prior discussion on clipboard functionality: Malte 6/27/11 - IAEditableText2 - re start/end offsets see thread from Oct 2010 starting at https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2010-October/001223.html - re mime types 1) apps will choose which format they prefer when multiple formats are available. I couldn't find any suggested solution for this AT shouldn't guess what format would be best spec should allow the string to be empty, which means that it's up to the app to choose the preferred format. 2) when AT provides a mime type, but app doesn't support it, what should happen? Should the app choose format, or ignore the call? If the later, how does AT know? 3) It's not always text If in OOo Writer, and clipboard has OOo Calc stuff. A default paste will not paste an HTML table, but an OLE object. But the method is called pasteText, not pasteSpecial. app will not always choose some text format. prefer pasteSpecial over pasteText 4) What about simply using a bool parameter? - not convinced that AT want's to deal with mime types user normally simply wants to do paste-without-format vs. paste-with-format If he really is interested in selecting a certain format, he can use a dialog - I guess most AT will only use 2 different strings: Empty string (assuming that means formatted+default), and "plain/text". With a bool, you don't have the issue described in 2) TRUE simply means to prefer formatted text if available/possible, otherwise fall back to unformatted text.
Carolyn 6/27 - IAEditableText2::pasteText 1) we need a mapping from mime type to platform-specific clipboard format 2) we need to allow all mime types but the name pasteText is wrong 3) What if mime type is empty string or NULL? What if mime type is unsupported? return E_INVALIDARG and paste nothing? 4) In MS Word clipboard commands operate on all selections, but insert (typing) only operates on the selection that contains the caret. Perhaps pasteText should simply be specified to always operate on the selection And if that is the case, remove the parameters from copyText and cutText Carolyn 6/27 - IAEditableText2 - Why not just use dialog? - Why have offsets (other than for copy for case of no selection)? Notes: cut/copy - no parms, just use selection paste - no parms, if there is a selection use it, otherwise use caret Malte 6/28 - IAEditableText - clipboard API is incomplete; no API for copy/paste on a drawing document or a bitmap editor. Pete 6/28 - IAEditableText - Do any ATs use it? Notes (responses to this query): - JAWS and NVDA do not - Arnstein uses insertText, deleteText, and replaceText - GOK uses AccessibleAction and AccessibleRelation (and also the setter in AccessibleValue). - Why not use GUI? Same question for IAAction. Assume it's for mobility impaired Jamie 6/28 (off list) - IAEditableText, vs GUI, vs IAAction - Use case: Sometimes, a user needs to access a control which isn't keyboard focusable e.g. a control on a toolbar that isn't normally used by keyboard users In these cases, the user will use the screen reader's review functionality to get to that object but then might want to perform actions on that object. - copy, cut, paste, etc. should actually be implemented on the object using IAAction, rather than having a separate IAccessibleEditableText. This would use the current selection within the object as is normally the case. - introduce a way to activate predefined action constants, rather than having to iterate through all actions and check their names. Carolyn 6/29 - IAEditableText vs IAAction and IAEditableText - could be useful for speech recognition systems. - clipboard operations don't belong on IAccessibleEditableText. Having them on IAccessibleAction makes more sense clipboard operations are not just for text objects. - these actions do merit some kind of quick access mechanism either they can have their own method names or predefined action constants. - They can operate on the current selection, removing the need for offset parameters, and allowing multi-selection-capable apps to define their own semantics for clipboard "actions". - paste and pasteSpecial are boolean in nature, so they can be 2 actions. The clipboard format for pasteSpecial can (I think?) be handled on the app side, i.e. ask the user whether they want to paste html or rtf or plain text, etc Thread "clipboard operations" starting 7/22/11 http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2011-July/001495.html Decision 2/9/12 - deprecate IAEditableText::cut/copy/pasteText add note that these functions are available via the app's GUI - don't yet add 5 new actions for cut, copy, pasteDefault, pasteFormatted, pasteUnformatted these can be added in the future if needed - No negative responses received Note that the decision to not add the new actions at this time is because I received no response to this query, "will there ever be a case where there is no keyboard accessible GUI for cut/copy/paste?" See this post for more: http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2011-July/001504.html An important aspect of the decision is reducing the work load for server side developers. Pete _______________________________________________ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
