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

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.

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.

I don't think this is as clear as it should be; these are subtle distinctions and I can foresee disagreement as to which state should be applied in different scenarios. I don't have specific scenarios in mind; the point is simply that the distinctions are fine enough to create plenty of scope for ambiguous and disputable cases. Do we really need a three-way distinction?



________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________

Received on Thursday, 20 November 2014 14:35:43 UTC