RE: aria-current concerns from Apple

I see your point, and yes, aria-current will be used on unmanaged container elements, but there are use cases that involve interactive widgets though that may come into play as well.

For example, imagine an interactive grid construct that represents an event calendar, where the current role=gridcell is marked up with aria-current. If focusing directly to each role=gridcell node, then this information would be conveyed. However, if focus is set on role=grid and aria-activedescendant is used to point to the same role=gridcell, then this information will not be conveyed, even though both of these navigation methods are supported according to the spec.

Also imagine an ARIA Tree construct that represents the interactive index of an Ebook, where the user can arrow down the chapters of the book, expand the desired chapter, then arrow into desired subsections, and press Space or Enter to load that content into a viewer pane. In which case, the currently loaded section would include aria-current on the active role=treeitem node, which would be conveyed when setting focus to each role=treeitem node in the Tree. However, if setting focus to the role=tree container and pointing to the same role=treeitem node using aria-activedescendant, the same information would not be conveyed, causing the same problem to occur.

In both cases, using aria-selected for this purpose wouldn't be reliable, because aria-selected may be needed for different purposes within the same widget.








-----Original Message-----
From: James Craig [mailto:jcraig@apple.com] 
Sent: Friday, December 04, 2015 6:12 PM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Cc: Alexander Surkov <surkov.alexander@gmail.com>; public-aria@w3.org; White, Jason J <jjwhite@ets.org>; PF <public-pfwg@w3.org>
Subject: 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 Sunday, 6 December 2015 00:35:29 UTC