MozillaWiki

Accessibility/Comparisons:ATK To UA: Difference between revisions

Page Discussion

Accessibility/Comparisons:ATK To UA (view source)

Revision as of 14:26, 13 June 2006

4,422 bytes added ,  13 June 2006
no edit summary
No edit summary
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
= ATK to UA, interfaces =
= Discussion with comparison of ATK interfaces to UA =
This page provides an overview how to do some common operations in UA, when a developer is used to ATK. I highgly recommend to [[Mac:Accessibility/UniversalAccess|read the introduction to UA]] before reading this document.
This page attempts to provide an overview of UA, comparing some major interfaces in ATK to UA functionality. I highly recommend to [[Mac:Accessibility/UniversalAccess|read the introduction to UA]] before reading this document.


Any developer serious in implementing UA support should always read [http://developer.apple.com/documentation/Cocoa/Conceptual/Accessibility/index.html#//apple_ref/doc/uid/10000118i Apple's official accessibility documentation]; this is by no means an end-all be-all document, but can give you an idea about how things work. Feel free to add and edit entries.
Any developer serious in implementing UA support should always read [http://developer.apple.com/documentation/Cocoa/Conceptual/Accessibility/index.html#//apple_ref/doc/uid/10000118i Apple's official accessibility documentation]; this is by no means an end-all be-all document, but can give you an idea about how things work. Feel free to add and edit entries.
Note that this page only is interesting if you're implementing UA support in your application, AT developers use [[Mac:Accessibility/UniversalAccess#AT_APIs.2C_and_client_APIs|other APIs]].


= Interfaces =
= Interfaces =
Line 10: Line 12:
; accessibilityActionDescription : returns a human-readable (localized) description of a specified action.
; accessibilityActionDescription : returns a human-readable (localized) description of a specified action.
; accessibilityPerformAction : performs a specified action.
; accessibilityPerformAction : performs a specified action.
There are [[Mac:Accessibility/UniversalAccess#AT_APIs.2C_and_client_APIs|AT APIs]] for getting a localized name for an action (e.g., what the "AXPress" action would be in human-readable english).


== Making a view/widget accessible (AtkComponent) ==
== Making a view/widget accessible (AtkComponent) ==
In UA, every widget has to implement a few methods to be made accessible. Those views that are invisible, and uninteresting to the user should implement the [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/occ/instm/NSObject/accessibilityIsIgnored accessibilityIsIgnored] method to return NO (false).
=== Ignored nodes ===
In UA, every widget has to implement a few methods to be made accessible. Those views that are invisible, and uninteresting to the user should implement the [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/occ/instm/NSObject/accessibilityIsIgnored accessibilityIsIgnored] method to return NO (false).  


The position and size of a widget is not accessible-specific, so you call the necessary NSView methods to get that information.
The ignored objects in the hierarchy are skipped, and the AT will only "see" children, siblings, or parents that are not marked as ignored.


Hit-testing (getting the accessible object at a given point on the screen) can be done using the [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/occ/instm/NSObject/accessibilityHitTest: accessibilityHitTest:] method on any view.
=== Hit testing ===
You return the position/size of your widget when the AT asks for the [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/doc/c_ref/NSAccessibilitySizeAttribute AXSize] or [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/doc/c_ref/NSAccessibilityPositionAttribute AXPosition] attributes.


To get the currently focused widget's accessibility object, [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/occ/instm/NSObject/accessibilityFocusedUIElement accessibilityFocusedUIElement] is used, which will return the deepest accessible descendant.
Hit-testing (getting the accessible object at a given point on the screen) is done using the [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/occ/instm/NSObject/accessibilityHitTest: accessibilityHitTest:] method, where you want to return the bottom-most widget in your internal hierarchy.
 
=== Focus ===
To get the currently focused widget's accessibility object, [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/occ/instm/NSObject/accessibilityFocusedUIElement accessibilityFocusedUIElement] is used, where you need to return the element that is focused.


To set focus, there is the AXFocused attribute that is often settable. To see if a specified attribute is settable, use the [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/occ/instm/NSObject/accessibilityIsAttributeSettable: accessibilityIsAttributeSettable:] and then [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/occ/instm/NSObject/accessibilitySetValue:forAttribute: accessibilitySetValue:forAttribute:] to set it.
To set focus, there is the AXFocused attribute that is often settable. To see if a specified attribute is settable, use the [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/occ/instm/NSObject/accessibilityIsAttributeSettable: accessibilityIsAttributeSettable:] and then [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/occ/instm/NSObject/accessibilitySetValue:forAttribute: accessibilitySetValue:forAttribute:] to set it.


To "manually" traverse and inspect the accessibility hierarchy of a view/widget, you get the value of these attributes:
=== Traversing the hierarchy ===
When the AT traverses your hierarchy, it requests the following attributes, that you need to implement in all accessible objects:
; AXChildrenAttribute : will return an array of all accessible children of the widget, skipping any ignored widgets on the way.
; AXChildrenAttribute : will return an array of all accessible children of the widget, skipping any ignored widgets on the way.
; AXParentAttribute : will return the accessible parent of this widget, skipping any ignored widgets on the way.
; AXParentAttribute : will return the accessible parent of this widget, skipping any ignored widgets on the way.


== Traversing the DOM (AtkDocument) ==
If an object wants to know its order relative to its siblings, it can ask the parent for the AXChildrenAttribute.
This does not currently exist in UA, like with many things that are web-specific.  
 
=== Values in a widget ===
To get the value of most widgets (barring textviews, and other widgets with very rich content) you simply get the [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/doc/c_ref/NSAccessibilityValueAttribute AXValue] attribute.
 
Minimum and maximum values (for e.g., sliders and progressbars) can be returned from the [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/doc/c_ref/NSAccessibilityMaxValueAttribute AXMinValue] and [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/doc/c_ref/NSAccessibilityMinValueAttribute AXMaxValue] attributes.
 
=== Relations ===
There are also [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/doc/uid/20000945-DontLinkElementID_16 attributes for linking a label to its widget, the widget to its label, and the AXLinkedUIElement attribute] that can be used to linked elements together than in the interface only are linked visually.
 
== Traversing the DOM (AtkDocument, AtkHypertext) ==
'''AtkDocument''' is ATK's way to expose the DOM to client applications. To my knowledge, this does not (yet) exist in UA, as with many advanced features (particularly those web-specific).
 
Here are two examples of how WebKit's web view exposes web page content:
 
; <p>text<img/>some text</p>
This is exposed as text, image, text -- all sibling nodes.
 
; <a href="foo.html">bar<img/></a>
The link is exposed as an AXLink, parent of the text and image nodes.
 
This is one of the areas where it's showing that UA was designed for desktop applications, and not for rich web browsers. Hopefully features features in the future UA will address this kind of gap.


== Text editing (AtkEditableText) ==
== Text editing (AtkEditableText) ==
Line 43: Line 73:
* Get the range for a line, or an index, or all visible characters
* Get the range for a line, or an index, or all visible characters
In other words, contrary to ATK, text runs themselves do not contain accessible objects.
In other words, contrary to ATK, text runs themselves do not contain accessible objects.
Textviews can thus be considered to be "opaque". Their contents can't be traversed like in ATK; instead they are queried for specific ranges or points. This makes it harder to make accessible rich-text editing.


== Links (AtkHyperlink) ==
== Links (AtkHyperlink) ==
Line 52: Line 84:


Links usually sport the [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/doc/c_ref/NSAccessibilityPressAction AXPressAction] (just like buttons).
Links usually sport the [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/doc/c_ref/NSAccessibilityPressAction AXPressAction] (just like buttons).
== Images (AtkImage) ==
In UA, images are supposed to have the [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/doc/c_ref/NSAccessibilityImageRole AXImage role]. The position, size, and other data of the actual image is retrievable via the actual NSView in the view hierarchy.
== Tables (AtkTable) ==
The tables in UA are in reality adapted to tables in the user interface. Thus they lack many advanced features. The [http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/doc/uid/20000945-DontLinkElementID_8 attributes on the AXTableRole are defined here].
The attributes let an AT traverse a table by:
* All rows, or all columns
* Currently visible row(s) or column(s)
* Currently selected row(s) or column(s)
All of these attributes return arrays of children elements. In the row case, you get an array of all the objects on that row.
To get at a specific cell, it may be possible to just get at the right row, then choose the element depending on which column you want.
Hwaara
107

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/26889...27733"