- From: Birkir Gunnarsson <birkir.gunnarsson@deque.com>
- Date: Mon, 7 Dec 2015 12:45:50 -0500
- To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
- Cc: Matt King <a11ythinker@gmail.com>, James Craig <jcraig@apple.com>, Alexander Surkov <surkov.alexander@gmail.com>, "public-aria@w3.org" <public-aria@w3.org>, "White, Jason J" <jjwhite@ets.org>, PF <public-pfwg@w3.org>
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