RE: aria-current concerns from Apple

Personally I don't see this as being a problem, since the element that is marked as being current will be conveyed as current when interacted with such as by focus.

How about this case, if a container element, such as a widget with supported child nodes has focus and aria-activedescendant points to the selected child role which also includes aria-current, will this be conveyed?

I would think this would not be expensive because it is the same process that is used for checking aria-selected for example on role=listbox or ari-checked from role=radiogroup or for aria-haspopup from role=menu, etc.





-----Original Message-----
From: James Craig [mailto:jcraig@apple.com] 
Sent: Friday, December 04, 2015 2:32 AM
To: Alexander Surkov <surkov.alexander@gmail.com>; public-aria@w3.org
Cc: White, Jason J <jjwhite@ets.org>; PF <public-pfwg@w3.org>
Subject: Re: aria-current concerns from Apple

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 Saturday, 5 December 2015 01:47:33 UTC