On Oct 7, 2010, at 10:44 AM, Scott Kovatch wrote: On Oct 7, 2010, at 7:39 AM, James Dempsey wrote: That said, I think an AX client can be built to do the sorts of functionality you mention using the existing API. For an AXTextArea you can get the range of a particular line, get and set the current selection range and get and set the selected text, which can be used to insert and delete text. From actions like these, you can insert and delete text as you wish from an accessibility client. Any of these activities the move the selection would be visible, and at the end you would restore the selection.
For 'copy characters 3 through 10 to the clipboard, and don't move the selection', you could ask for the parameterized attribute AXRTFForRange, and then put the result onto the clipboard yourself as rich text.
In summary, the focus is to expose the interface elements of an application to assistive applications, to enable alternate means of using the application to be developed, so you can certainly make an application copy and paste through the AX APIs, but doing so through the mechanisms that are in place in the app.
I agree that a AT client could certainly accomplish the same thing with the existing accessibility APIs, but I'm not writing a client. That said, I need to make sure the corresponding accessibility attributes for the selection and selected text are settable. We already support getting the selected text, including attributes.
That is great - which hopefully means VoiceOver users, for instance, will be able to interact with your text areas. After re-reading the interface, I think one way a client could do this is to set the selected text range via AXSelectedTextRange and then send an action for Copy, Cut, Paste, etc., which we would expose for objects with an AXTextAreaRole.
If you have a particular client in mind, then this would work. For any general client, since no Copy/Cut/Paste actions are defined in the AX API, the client would not necessarily be expecting to find these actions, or have facilities for using them.
I need to find out what the user should expect to see. If it's entirely a model-based operation, then yes, I will need to look at scripting. If the user will see the selection changing, then I should be able to accomplish this with property-setting and actions.
I would also echo the comments of Travis, who mentions scripting.
While AX enables interaction with an application at the view layer (including making changes visible, so sighted users can collaborate with those using assistive technologies), scripting enables interaction with an app at the model layer – and there is a fairly rich scripting dictionary defined for text (including delimiting words/characters/paragraphs, etc). With the various scripting bridges on Mac OS X, you can control scriptable apps in languages other than AppleScript, (Obj-C, python, ruby).
Does implementing scriptability imply that your application will be bundled? The last time I looked into supporting scripting I think I read about adding entries in the Info.plist and having a separate scripting terminology file. That's not going to work for us, as many Java applications just have a jar file.
I'm not familiar with whether there is a way to make an app scriptable without a bundle. The email@hidden would probably have better answers on that topic.
Thanks,
James
Thanks, Scott K.
------------------ Scott Kovatch
IBM Eclipse Platform Team Pleasanton, CA
-------------------------------------------------- James Dempsey AppKit Engineering Apple
|