RE: Response to your comments on Accessible Rich Internet Applications (WAI-ARIA) 1.0

Re. Comment 324: Popups - aria-owns and aria-controls

Thanks for this detailed explanation and the link to the example. I accept this response. tt

-----Original Message-----
From: Janina Sajka [mailto:janina@a11y.org] 
Sent: Thursday, June 17, 2010 11:29 AM
To: Terrill Thompson
Cc: PFWG Public Comments
Subject: Response to your comments on Accessible Rich Internet Applications (WAI-ARIA) 1.0


Comment 324: Popups - aria-owns and aria-controls
Date: 2010-03-23
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010JanMar/0045.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-owns (property) <http://www.w3.org/TR/2009/WD-wai-aria-20091215/#aria-owns>
Status: Accepted proposal

-------------
Your comment:
-------------
I've been struggling recently with how best to apply ARIA to the use case
of a hidden informational popup that is made visible by user action.
Netflix..com provides a good example of this type of behavior (hovering
over a movie results in a popup being displayed), as does my own test
page:
http://terrillthompson.com/ncaa/test.html

When a user triggers the pop-up, the desired effect is for screen readers
to automatically alert the user that the popup has appeared, and
temporarily move their focus to that popup. When they close the popup,
their focus should return to the originating trigger element.

It seems to me that one of these properties may be applicable to the popup
use case described above. However, I'm not clear how the two properties
differ from one another. Both reference the other, but no explanation is
given as to their relationship. Aria-controls includes examples. Perhaps if
aria-owns also included examples, the difference between these properties
would be more clear. Another alternative would be to include text that
specifically describes the differences, similar to text that currently
explains the difference between aria-describedby and aria-labelledby.

--------------------------------
Response from the Working Group:
--------------------------------
The owned element is not a DOM child of the referencing element.
Conceptually, the owned element is a child of the owner, but this isn't
expressed by the DOM parent/child relationship. 

The main difference between aria-owns and aria-controls is the nature of
the relationship they describe. Aria-owns describes a parent-child 
relationship. Aria-controls describes a controlling relationship. Given
that your target object is not visible at the time you activate the link
you really are not controlling any concrete object that the user can
reference. 

The correct way to address this problem is to provide an aria-expanded
property on the link to indicated if the content it is controlling is
expanded or collapsed. By setting the aria-expanded property to "false" the
assistive technology knows that the item is collapsed and expandable. When
the author expands the link the aria-expanded property should be set to
"true" and the aria-owns property assigned to the link with a value of the
container for the message you have rendered. 

Since this is a link, the user's focus should move, therefore you must
then set focus to an element in the revealed region and provide keyboard
functionality to close the message and move focus back to the link when the
aria-controls property should be removed. Authors should expect user agents
to provide a controlled-by property feature in the accessibility API which
will allow the assistive technology to reference the element that generated
the newly expanded region. We will address this use case in the WAI-ARIA
Authoring Practices.

When focus moves back to the link the aria-expanded property should be set
to false. The assistive technology should announce changes in the expanded
property throughout the process. 

You can see an example of this at
http://test.cita.illinois.edu/aria/hideshow/hideshow2.php.

Received on Friday, 23 July 2010 18:52:21 UTC