W3C home > Mailing lists > Public > public-html-a11y@w3.org > April 2012

Issue 204 and accessibility APIs

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Thu, 19 Apr 2012 07:13:49 +0100
Message-ID: <CAEhSh3drxTf924zhn5_FciSipttK_+6CQt_8xzRx9yd02LYUWw@mail.gmail.com>
To: Laura Carlson <laura.lee.carlson@gmail.com>
Cc: "Michael[tm] Smith" <mike@w3.org>, public-html-a11y@w3.org
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:


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




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):


UI Automation:


Apple Accessibility API only allows you to specify that objects are related:

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:28 UTC