107
edits
Mac:Accessibility/UniversalAccess: Difference between revisions
add info about older APIs that ATs need to use (hidden in an apple release note)
(more info about notifications in cocoa) |
(add info about older APIs that ATs need to use (hidden in an apple release note)) |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 10: | Line 10: | ||
Developers used to MSAA or ATK will find that UA is very easy to use. Everything is basically done just by querying elements for attributes, and setting them. | Developers used to MSAA or ATK will find that UA is very easy to use. Everything is basically done just by querying elements for attributes, and setting them. | ||
In this way, one could think of UA kind of like a hash table. You ask for an attribute | In this way, one could think of UA kind of like a hash table. You ask for an attribute and get an array, a string, a number, or any other value describing the data you asked for. | ||
Users of the UA APIs can easily extend UA just by supporting a new attribute. Whenever someone asks for the value of it. | Users of the UA APIs can easily extend UA just by supporting a new attribute. Whenever someone asks for the value of it. | ||
The first thing an AT typically does | The first thing an AT typically does is to ask the [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/doc/uid/20000945-BCIIHIGG query widgets about the attributes they support]. It can then go on to see which of those that are "settable", i.e. changable by the user. For example, the value attribute of a textfield is settable. | ||
=== Roles === | === Roles === | ||
| Line 20: | Line 20: | ||
=== Actions === | === Actions === | ||
An action is a way for the user to interact with the interface, e.g. through a screen reader. For example clicking a button, deleting, or incrementing a value. To know [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/doc/uid/20000945-DontLinkElementID_20 which actions] a widget supports | An action is a way for the user to interact with the interface, e.g. through a screen reader. For example clicking a button, deleting, or incrementing a value. To know [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/doc/uid/20000945-DontLinkElementID_20 which actions] a widget supports is as easy as [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/index.html asking for an array of them]. | ||
=== Notifications === | === Notifications === | ||
[http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/doc/uid/20000945-DontLinkElementID_21 Notifications] are sent out to the ATs when something significant in the UI has changed | [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/doc/uid/20000945-DontLinkElementID_21 Notifications] are sent out to the ATs when something significant in the UI has changed (for example, a new window was opened or new rows were added to a table). | ||
A notification in Cocoa is an object with: | A notification in Cocoa is an object with: | ||
| Line 30: | Line 30: | ||
* a userInfo dictionary (hash table). | * a userInfo dictionary (hash table). | ||
The dictionary (hash table) can be filled with any custom | The dictionary (hash table) can be filled with any custom information that the poster of the event wants all receivers to have. [http://developer.apple.com/documentation/Cocoa/Conceptual/Notifications/index.html Go here for more information about notifications in Cocoa]. | ||
== AT APIs, and client APIs == | |||
Client applications that want to be made accessible, can do this simply by implementing the NSAccessibility protocol, all in Objective C. | |||
ATs will typically need to use some C APIs in conjunction with those defined in NSAccessibility. The C APIs let the AT get the root accessibility objet from a given pid, among other things. [http://developer.apple.com/releasenotes/Accessibility/AssistiveAPI.html See this older release note for more information.] | |||
== What UA is Missing == | == What UA is Missing == | ||
Universal Access is great in a lot of ways, but for a web browser | Universal Access is great in a lot of ways, but for a web browser there are still things missing. | ||
The | * The major thing missing for us is a way to notify a user of dynamically updated content (think AJAX and DHTML). VoiceOver isn't currently verbose enough to account for those things, and no such notifications can be found. | ||
* We have found that trees/listboxes don't seem to provide enough info about changes to their contents. No details yet. | |||
== WebKit additions == | == WebKit additions == | ||
Because UA is easily extendable with new attributes, roles and notifications, WebKit has implemented some custom extensions to UA to make it work better in a web context. We've gathered them here as well. | Because UA is easily extendable with new attributes, roles, and notifications, WebKit has implemented some custom extensions to UA to make it work better in a web context. We've gathered them here as well. | ||
[[Mac:Accessibility/UniversalAccess:Webkit|WebKit UA extensions]] | [[Mac:Accessibility/UniversalAccess:Webkit|WebKit UA extensions]] | ||
| Line 45: | Line 51: | ||
Feel free to add and improve this introduction, or even copy it to another wiki. | Feel free to add and improve this introduction, or even copy it to another wiki. | ||
--[[User:Hwaara|HakanW]] | --[[User:Hwaara|HakanW]] | ||