Proposed Accessibility implementation change in Carbon
Proposed Accessibility implementation change in Carbon
- Subject: Proposed Accessibility implementation change in Carbon
- From: Guy Fullerton <email@hidden>
- Date: Fri, 24 Oct 2003 18:19:35 -0700
We're considering making a change to Carbon's accessibility implementation
for the sake of correctness, and it could cause problems with existing code
in either regular or assistive applications. Please read the following and
respond if this change will be a problem for you.
(This will only be relevant to assistive application developers or
developers that have done work to make their Carbon applications accessible.
Most of you will know whether you fall into these categories. For those that
are unsure, you can search your code for references to
kEventClassAccessibility and various APIs that begin with AXUIElement.)
On Panther GM and earlier, the base kEventAccessibleGetAllAttributeNames
Carbon Event handler (which is installed by the base HIObject class)
automatically adds AXChildrenAttribute and AXParentAttribute to the array of
supported attributes.
Though this was convenient for many accessible objects, we found several
places where it causes problems. If the given object doesn't have or support
children, reporting the attribute name is silly. The same thing goes for the
parent attribute. The reporting of the attribute names made it difficult for
an object to communicate the fact that it didn't support a parent or
children. In addition, it makes it almost impossible for the system to
return appropriate error codes from the AX APIs for these kinds of objects.
Therefore, we are considering removing this functionality from the base
event handler. We would add code to system-supplied HIObject subclasses
(like HIView) such that they add those attributes when appropriate. For
example, the HIView handling for that event will add AXChildrenAttribute
when the view has at least one child, and it will add the AXParentAttribute
when the view has a super view. In addition, the default HIView handling for
kEventAccessibleGetNamedAttribute + AXChildrenAttribute would only create an
array and add it to the event if the view has at least one child view.
If made, this change could potentially show up in a Panther software update.
This has four implications:
1) If you are making your Carbon app accessible by creating HIObject
subclasses, your subclass would be responsible for adding those attribute
names when appropriate ... but only when it is running on this theoretical
future OS release. If you want to make your app equally accessible on
current and future OS releases, you would have to conditionalize your code
to make sure you don't add redundant attribute names when it is running on
an OS release where the system adds them for you.
2) If you are adding your Carbon app accessible by creating HIView
subclasses or adding kEventClassAccessibility handlers to existing HIViews,
and your view's handlers add accessible children that are not represented by
true HIView subviews, you would also have to do the same thing mentioned in
#1. (Phew!)
To see whether your application falls into #1 or #2, see if you have a
kEventAccessibleGetNamedAttribute handler that looks for the
AXChildrenAttribute and responds by building an array of children. If you do
not also have a corresponding kEventAccessibleGetAllAttributeNames that adds
the AXChildrenAttribute to the array of supported attributes, you probably
fall into the scenarios described in #1 or #2.
3) If your Carbon app has a kEventAccessibleGetNamedAttribute handler
(probably on an HIView), you could no longer expect that the default
handling of the event (as executed by CallNextEventHandler) will always add
a CFMutableArrayRef parameter to the event. In this situation, if the
default handling did not add an array to the event and if your app needs the
array to exist, your app would be responsible for creating the array and
adding it to the event.
4) If you are writing an assistive application, you might want to be
tolerant of the fact that a given UIElementRef may still support the
AXChildrenAttribute or AXParentAttribute even though neither of the
attributes are reported via AXUIElementCopyAttributeNames. This would allow
your assistive application to properly handle any apps who ran into #1 or
#2, but who haven't had a chance to fix it yet.
Though the implications deal with edge cases, we know there are a few
developers who have made or are in the process of making their applications
accessible. Therefore, we want to get the feedback from these developers
before making such a change.
Please respond to this message if you have concerns about such a change.
_______________________________________________
accessibility-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/accessibility-dev
Do not post admin requests to the list. They will be ignored.