107
edits
Mac:Accessibility/UniversalAccess: Difference between revisions
add info about older APIs that ATs need to use (hidden in an apple release note)
No edit summary |
(add info about older APIs that ATs need to use (hidden in an apple release note)) |
||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
= | = Introduction to Universal Access = | ||
This | This page previously hosted a quick reference to Apple's accessibility framework. Since then, Apple has updated it to be much more useful. See Apple's [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/index.html definition of the NSAccessibility protocol] for a good quick reference. | ||
In the following sections, we will use a few commonly used acronyms for convenience: | In the following sections, we will use a few commonly used acronyms for convenience: | ||
| Line 7: | Line 7: | ||
* '''UA''' refers to ''Universal Access'' - Apple's name for all of their accessibility APIs. | * '''UA''' refers to ''Universal Access'' - Apple's name for all of their accessibility APIs. | ||
== | == Everything is an Attribute == | ||
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 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. | |||
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 === | |||
An AT can know the "role" of a widget just by asking for the value of the [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/doc/c_ref/NSAccessibilityRoleAttribute role attribute]. The role tells the AT a lot about the widget behaves (button? listbox? etc.) | |||
== | === 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 is as easy as [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/index.html asking for an array of them]. | |||
=== 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 (for example, a new window was opened or new rows were added to a table). | |||
A notification in Cocoa is an object with: | |||
* a name (of the event fired), | |||
* an object (usually the "emitter" of the event, for example a widget), | |||
* a userInfo dictionary (hash table). | |||
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 == | |||
Universal Access is great in a lot of ways, but for a web browser there are still things missing. | |||
* 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 == | ||
WebKit has | 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]] | ||
= Comments, suggestions, etc = | = Comments, suggestions, etc = | ||
Feel free to add and improve this introduction, or even copy it to another wiki. | |||
--[[User:Hwaara|HakanW]] | |||
--[[User:Hwaara|HakanW]] | |||