Issue 204 and accessibility APIs

On Thu, Apr 12, 2012 at 12:35 PM, Laura Carlson
<laura.lee.carlson@gmail.com> wrote:
>> longdesc and issue 204
>
> I tried my hand at writing a change proposal for Issue 204 and sent it
> to text team members. It quotes much of John's CP, Rich's short email,
> and the PF. It removes the sentence that Janina mentioned at
> Tuesday's text meeting.  Leif has already given me input that I need
> to act on. Other input is welcome and appreciated.
>
> The draft is at:
> http://www.w3.org/html/wg/wiki/ChangeProposals/CorrectHidden

You should explain or retract the implications that:

1. Accessibility APIs are unable to represent structures that are not
rendered on screen.

2. Accessibility APIs cannot represent a relationship between two
nodes of the accessibility tree where one node is acts a description
for the other node.

As far as I can tell, there's no constraint that accessibility
hierarchies match view hierarchies:

    https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Accessibility/cocoaAXAccessEnabling/cocoaAXAccessEnabling.html#//apple_ref/doc/uid/20001059-BAJJIBFA

MSAA, IAccessible2 and ATK have specific semantics for indicating
off-screen status:

    http://blogs.msdn.com/b/vsaccessibility/archive/2004/09/20/232157.aspx

    http://live.gnome.org/Accessibility/Documentation/GNOME2/AtkGuide/MSAA

    http://asurkov.blogspot.co.uk/2012/02/firefox-12-for-at-developers.html

Some accessibility APIs have semantics for saying that the
relationship between objects in the accessibility hierarchy is a
describing relationship:

IAccessible2 (baked on top of MSAA):

    http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/group__grp_relations.html#g478e78069b9a5439a01943969d1423a7

UI Automation:

    http://msdn.microsoft.com/en-us/library/windows/apps/ee684017.aspx#uia_describedbypropertyid

Apple Accessibility API only allows you to specify that objects are related:
       http://developer.apple.com/library/mac/#documentation/UserExperience/Reference/Accessibility_RoleAttribute_Ref/Attributes.html#//apple_ref/doc/uid/TP40007870-Attributes-SW1

The ARIA implementation guide requires @aria-describedby populate a
string description field (accDescription) and this is in fact
implemented. As far as I can tell, that's the reason why
@aria-describedby is flattened, not underlying limitations of modern
accessibility APIs.

As an aside, representing generic document and application semantics
in ARIA markup required adding features to IAccessible2 and UI
Automation and then changing accessibility API clients to match. I
don't see any reason to treat implying additional features in
accessibility APIs as somehow out of scope for HTML markup that
likewise represents generic document and application semantics.

--
Benjamin Hawkes-Lewis

Received on Thursday, 19 April 2012 06:14:42 UTC