- From: Alexander Surkov <surkov.alexander@gmail.com>
- Date: Wed, 26 Nov 2014 10:28:58 -0500
- To: Joseph Scheuhammer <clown@alum.mit.edu>
- Cc: "White, Jason J" <jjwhite@ets.org>, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>, "Gunderson, Jon R" <jongund@illinois.edu>, "LWatson@PacielloGroup.com" <LWatson@paciellogroup.com>, Matthew King <mattking@us.ibm.com>, "public-pfwg@w3.org" <public-pfwg@w3.org>
- Message-ID: <CA+epNsd5VJ65U=e0nOQ4MUAKmMrts0d4JLOQKxfoJR2MRx+quQ@mail.gmail.com>
Can you think of use case where aria-activedescendant and aria-current can be used for different elements of the same container? Otherwise why would not extend meaning of aria-activedescendant to fit aria-current needs like the attribute pointing to currently active element? There's some confusion with naming. Dominic suggest to rename it to aria-active what makes it sound close to aria-activedescendant. Joanie suggests to map it to ATK active state which is currently used for active windows only. IA2 has active state that can be used both for windows or current element within controls (i.e used for aria-activedescendant case). Obviously current and active in a container concepts are close and have a subtle difference (if they have). On Wed, Nov 26, 2014 at 10:10 AM, Joseph Scheuhammer <clown@alum.mit.edu> wrote: > On 2014-11-20 9:35 AM, White, Jason J wrote: > >> This discussion has been informative, but it motivates a call for >> clarification of the semantic differences between the proposed aria-current >> state, aria-selected and aria-activedescendant. As I understand the >> differences: >> >> aria-activedescendant implies that the element has the keyboard focus. >> >> aria-selected entails that the element will be acted upon by certain >> application commands, such as move, copy or delete operations, or that it >> is the chosen item in a list of options. >> > > FWIW: > > aria-activedescendant is a property of containers. Examples include grid, > radiogroup, and listbox roles. It is used as a way of designating the item > that has focus, and results in focus events in the accessibility API. > > aria-selected is a property of contained elements. Examples include > gridcell, radio button, and option roles. It is used to define a set of > selected items. If items are added or removed from the set, selection > events are emitted in the accessibility API. > > While in certain cases focus-follows-selection, such as a single selection > listbox, there is no general requirement that selection and focus > coincide. It's possible that some item is both selected and focused, but > it is also possible that the selected item(s) and the focused item are two > different elements. > >> aria-current (as proposed) appears to be a navigational concept: there >> are operations that will change what is "current", but this status entails >> nothing about any other application commands that operate upon the >> "current" item. As such, it's the weakest of the three concepts in the >> sense of having minimal implications regarding what will be affected by the >> user's subsequent actions. Both aria-selected and aria-activedescendant >> have fairly strong, though distinct, consequences in this regard. >> > > According to the current proposed spec text, aria-current can be applied > to any element. It's not limited any specific type of container. > > As a navigational concept, it has the semantic "you-are-here". The > aria-current item may or may not be focused, and it may or may not be > selected. > > An example of its potential use is shown here: > http://idrc.ocad.ca/index.php/research-and-development/ongoing-projects. > On the left is a site index, which is a hierarchical list of links. > Visually, one of the links is styled as blue text and has a blue arrow > pointing at it; in this specific case "Ongoing Projects". As a sighted > user, at a glance, I can tell by those visual cues where I am on the site. > And if I navigate to another page on the site, the blue-text-with-arrow > moves appropriately. Unfortunately, this "current" status is provided only > through visual styles. The proposed @aria-current is supposed to capture > that navigational information. > > Note that focus can be in numerous places on this page: on any one of the > table of contents links, including the current one, or any focusable > element elsewhere. Focus and aria-current are independent of one another; > in particular, aria-activedescendant may or may not coincide with > aria-current. > > As far as selection is concerned, nothing on this page is selectable. > > It seems to me that aria-current defines something separate from > aria-activedescendant and aria-selected. While it's possible that the same > element is simultaneously focused, selected, and current, there is no > requirement that all three coincide, and they don't in general. > > > -- > ;;;;joseph. > > 'Array(16).join("wat" - 1) + " Batman!"' > - G. Bernhardt - > > >
Received on Wednesday, 26 November 2014 15:29:26 UTC