Re: Issue 204 and accessibility APIs

Hi Benjamin,

Thank you very much for your input. If you have specific verbiage that
you would like to propose to be included that would enable you to
support the details section of the CP please do elaborate.

Best Regards,
Laura

On Thu, Apr 19, 2012 at 1:13 AM, Benjamin Hawkes-Lewis
<bhawkeslewis@googlemail.com> wrote:
> 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



-- 
Laura L. Carlson

Received on Thursday, 19 April 2012 11:25:24 UTC