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<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