Re: ACTION-1442: Draft spec text for aria-current and aria-currentfor

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:10:58 UTC