Re: aria-current concerns from Apple

I think requiring an id ref on container and creating and updating an
ID on the current elemtn is something developers are not going to be
happy about.
The way that I saw aria-current was a quick and easy semantic
equivalent of using CSS to indicate or highlight an item in a list of
items.

I thought we had other indicators (aria-selected and
aria-activedescendant) to take care of complex widgets. I have yet to
think of a likely use case where we cannot use these ARIA attributes
to communicate the necessary info to end users.

I have no problem not knowing the current element in a set of elements
until I move focus to (or virtual focus on) that element.
I don't have to know when I reach the common container.


I have had common complaints from the developers I work with on a
daily basis that they require to create a lot of additional ID
attributes, ensure their uniqueness and then build relationships via
aria, this is particularly common concern for instructions or error
messages (aria-describedby).
I am worried that dumping more ID-related requirements on their plates
is not going to encourage them to add this information if they can get
away with not doing so.


On 12/7/15, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com> wrote:
> That would negate all of the tokens for automatic API language
> localization.
>
>
>
>
> -----Original Message-----
> From: Matt King [mailto:a11ythinker@gmail.com]
> Sent: Monday, December 07, 2015 12:38 AM
> To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; 'James Craig'
> <jcraig@apple.com>; '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
>
> So, is there a problem with redefining aria-current to be an attribute that
> has an idref value and is applied to a container? Seems like a better
> approach.
>
>
> -----Original Message-----
> From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
> Sent: Friday, December 4, 2015 5:47 PM
> To: James Craig <jcraig@apple.com>; 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
>
> 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 Monday, 7 December 2015 17:46:20 UTC