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

>*  aria-current indicates that the element with aria-current is the element that corresponds to what is currently displayed.

Just to clarify one point, “corresponds to what is currently displayed” should mean the element that is visually styled to appear as current, not to reference only content that is visually displayed.

E.G An image that is styled to be current amongst a list of images, etc.


From: Matthew King [mailto:mattking@us.ibm.com]
Sent: Friday, November 07, 2014 5:26 PM
To: Cynthia Shelly
Cc: LWatson@PacielloGroup.com; 'W3C WAI Protocols & Formats'; 'Alexander Surkov'
Subject: RE: ACTION-1442: Draft spec text for aria-current and aria-currentfor

Cynthia wrote:
> I’m thinking about how to map this to UIA.  Do you think that the
> below code is 3 selectable buttons with one button selected?

That is a workable option for that specific use case.

> In UIA we can add the selection pattern to arbitrary controls.  We
> don’t need to make a new state.

We could extend the use of aria-selected to more elements, as issue 587 suggests, but I do not think that approach adequately addresses the use cases for aria-current.

> Would it work for the graphics scenario, for example one step in a
> flow chart being highlighted?

Only if we extended aria-selected to be nearly global so it can be used on essentially any static element.

> What is the semantic difference between this state and selection?
> In the sample below, could button 1 be selected while button 2 is
> current? What would that mean?

*  aria-current indicates that the element with aria-current is the element that corresponds to what is currently displayed.

* aria-selected indicates that a focusable element is chosen for some type of action or operation.

There is at least one use case where aria-current and aria-selected could effectively be synonomous: the button set described earlier in this thread and referenced at the beginning of this note. A similar use case is the selected tab in a single-select tablist that represents the currently displayed tabpanel content. However, even this one can be problematic. This is because many screen readers do not announce the selected state when navigating in a single-select widget such as a listbox, tree, or tablist. This is due to the assumption, which is true most of the time, that selection follows focus in a single select widget. Because that is generally true, I think most screen readers do not announce selected every time the focus moves. Such excess verbosity is quite annoying.

Now imagine a single-select wiki navigation tree where selection does not follow focus but the selected state is instead used to represent the currently displayed page. The user presses enter to change the displayed content and move the selected state to the corresponding treeitem. There would be two problems with this tree:

1. The screen reader will not likely announce which item is selected when exploring the tree because of the typical screen reader assumption that selection follows focus in a single-select. This could change, but I think we will find very strong resistence to such a change.

2. If the tree supports other operations for the currently selected item, such as move, copy, or delete, the user would have to load the content before performing such operations. Since I have already encountered this use case, I know from first-hand experience that this is not a limitation that designers find acceptable -- and I agree with them.

In this case, having a separate state for aria-current would be very beneficial. It would also be useful in a multi-select navigation tree that supports performing other non-navigation operations for multiple pages.

> Would we want platform APIs to add current in addition to selected?

Yes.

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com<mailto:mattking@us.ibm.com>



From:        Cynthia Shelly <cyns@microsoft.com<mailto:cyns@microsoft.com>>
To:        Matthew King/Fishkill/IBM@IBMUS, "LWatson@PacielloGroup.com<mailto:LWatson@PacielloGroup.com>" <LWatson@PacielloGroup.com<mailto:LWatson@PacielloGroup.com>>,
Cc:        "'W3C WAI Protocols & Formats'" <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>, "'Alexander Surkov'" <surkov.alexander@gmail.com<mailto:surkov.alexander@gmail.com>>
Date:        11/07/2014 01:55 PM
Subject:        RE: ACTION-1442: Draft spec text for aria-current and aria-currentfor
________________________________



I’m thinking about how to map this to UIA.  Do you think that the below code is 3 selectable buttons with one button selected?  In UIA we can add the selection pattern to arbitrary controls.  We don’t need to make a new state.  Can that be done in the other APIs?  Would it work for the graphics scenario, for example one step in a flow chart being highlighted?  What is the semantic difference between this state and selection?  In the sample below, could button 1 be selected while button 2 is current?  What would that mean?  Would we want platform APIs to add current in addition to selected?

I know I was in favor of this idea a few months ago, and I am not sure I’m changing my mind, I’m just thinking more about it from an API layer perspective.

From: Matthew King [mailto:mattking@us.ibm.com]
Sent: Thursday, November 6, 2014 1:49 PM
To: LWatson@PacielloGroup.com<mailto:LWatson@PacielloGroup.com>
Cc: 'W3C WAI Protocols & Formats'; 'Alexander Surkov'
Subject: RE: ACTION-1442: Draft spec text for aria-current and aria-currentfor

I was assuming we need only:

<div id="nav">
 <button>1</button>
 <button aria-current="true">2</button>
 <button>3</button>
</div>

I do not understand what currentfor would do for end users. In the above example, "2" is the button representing the currently displayed content. Pressing it again, if it is not also disabled, would refresh that content.

My expectation is that this would be used when there is a visual difference associated with button 2 that communicates the same message (this is the currently shown content).

Screen readers may choose to translate the state into strings like "Currently Displayed" or "Now showing" or something to that effect.

A completely different approach would be to allow authors to include a string like:
aria-current="Current Step" or aria-current="Displayed Page".
While more flexible, and while it gives authors more control over what is communicated, it comes with risks.

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com<mailto:mattking@us.ibm.com>



From:        Léonie Watson <LWatson@PacielloGroup.com<mailto:LWatson@PacielloGroup.com>>
To:        "'Alexander Surkov'" <surkov.alexander@gmail.com<mailto:surkov.alexander@gmail.com>>,
Cc:        "'W3C WAI Protocols & Formats'" <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>
Date:        11/06/2014 01:30 PM
Subject:        RE: ACTION-1442: Draft spec text for aria-current and aria-currentfor
________________________________




Alexander Surkov wrote:
“Do I understand that typical scenario of this attribute looks the following way:
<div id="nav">
 <button aria-current="false" aria-currentfor="nav">1</button>
<button aria-current="true" aria-currentfor="nav">2</button>
<button aria-current="undefined">3</button>
</div>
If so then aria-current="undefined" dupes aria-currentfor, or do you consider the scenario when UA fixes missed aria-currentfor?”

Good question. My understanding is that aria-currentfor would only be needed on the element with aria-current – to setup the scope for the currently indicated item.

So in your example buttons 1 and 3 would not have their state indicated, but button 2 would be identified as the current item within the scoping container/div.


Léonie.


--
Senior Accessibility Engineer, TPG
@LeonieWatson @PacielloGroup