Introduction to Universal Access

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 definition of the NSAccessibility protocol for a good quick reference.

In the following sections, we will use a few commonly used acronyms for convenience:

• AT, means Assistive Technology, or simply a 3rd party application, e.g., a Screen Reader.
• 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 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 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 which actions a widget supports is as easy as asking for an array of them.

Notifications

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. 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. 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

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.

WebKit UA extensions

Comments, suggestions, etc

Feel free to add and improve this introduction, or even copy it to another wiki.

--HakanW