Re: aria-current concerns from Apple

+1

On 12/7/2015 9:45 AM, Birkir Gunnarsson wrote:
> 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
>>
>>
>>
>>

-- 
Regards, James

Oracle <http://www.oracle.com>
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1 415 987 
1918 <tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com 
<sip:james.nurthen@oracle.com>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment