- From: James Craig <jcraig@apple.com>
- Date: Fri, 4 Dec 2015 02:32:25 -0800
- To: Alexander Surkov <surkov.alexander@gmail.com>, public-aria@w3.org
- Cc: "White, Jason J" <jjwhite@ets.org>, PF <public-pfwg@w3.org>
Some follow-up since the aria-current concerns expressed earlier were not addressed. In the nightly builds, WebKit does not consider the awareness of the current item for the container node. In other words, a screen reader would be able to speak "current" on the current nav link, but would not be able to indicate which link was "current" when focus is on the container nav. As Alex mentioned previously, it is possible for the browser to implement the feature as specified, but due to the performance cost of potential deep traversal in WebKit, we do not intent to implement the container's relationship to the current element. > Because: 1> deep traversal is expensive, 2> although we can cache the current element and optimize the performance, aria-current can be used on any kind of elements, sometimes it’s difficult to determine how many levels the current element should traverse up to find its parent container node (Or can we always assume that the parent node of the current element is the container we want?). > > Therefore, I think eventually we still want to pursue for the IDREF pointer for a better mapping. If the pattern were changed to match that of other ARIA IDREF features (aria-controls, aria-describedby, aria-labelledby, etc.) we will reconsider implementation on the container node, too. Thanks, James
Received on Friday, 4 December 2015 10:32:54 UTC