Re: aria-current concerns from Apple

> On Dec 4, 2015, at 5:47 PM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com> wrote:
> 
> 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 think combining both aria-current and aria-activedescendant seems problematic. 

We're requesting something equivalent to activedescendant.

> I would think this would not be expensive

You're right that the activedescendant model would not be expensive. I'm just worried that there would there be side effects. Activedescendant is used exclusively on focus-managed widgets, but aria-current will likely only be on unmanaged container elements. 

James

> 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 02:12:57 UTC