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



From:   Cynthia Shelly <cyns@microsoft.com>
To:     Matthew King/Fishkill/IBM@IBMUS, "LWatson@PacielloGroup.com" 
<LWatson@PacielloGroup.com>, 
Cc:     "'W3C WAI Protocols & Formats'" <public-pfwg@w3.org>, "'Alexander 
Surkov'" <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
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 



From:        Léonie Watson <LWatson@PacielloGroup.com> 
To:        "'Alexander Surkov'" <surkov.alexander@gmail.com>, 
Cc:        "'W3C WAI Protocols & Formats'" <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