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

Yes, agree, must be distinctly different from selected.

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:   Alexander Surkov <surkov.alexander@gmail.com>
To:     Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>, 
Cc:     Matthew King/Fishkill/IBM@IBMUS, "LWatson@PacielloGroup.com" 
<LWatson@paciellogroup.com>, "public-pfwg@w3.org" <public-pfwg@w3.org>
Date:   11/19/2014 11:46 AM
Subject:        Re: ACTION-1442: Draft spec text for aria-current and 
aria-currentfor



In case of IA2 and ATK I think "current" object attribute should be used 
what is different from selectable stuff, moreover afaik ATK selectable 
interface is not so flexible unlike UIA, and it cannot be reused for 
aria-current implementation. Anyway ARIA markup should be driven rather by 
web authors needs than AT mapping, or in other words, if aria-current is 
semantically different from aria-selected then it's worth to have separate 
attribute, find proper mapping and make the AT to support it.

On Wed, Nov 19, 2014 at 2:16 PM, Bryan Garaventa <
bryan.garaventa@ssbbartgroup.com> wrote:
Matt and others,
So do you think there is a definitive need to have both aria-current and 
aria-selected remain separate in the Accessibility API?
 
The reason why I ask, is that IE is leaning towards  mapping both 
attributes to the same state (selected), which would make it impossible 
for ATs to detect the difference in the Accessibility Tree.
 
From: Matthew King [mailto:mattking@us.ibm.com] 
Sent: Wednesday, November 19, 2014 9:42 AM
To: LWatson@PacielloGroup.com
Cc: public-pfwg@w3.org

Subject: RE: ACTION-1442: Draft spec text for aria-current and 
aria-currentfor
 
Léonie, I have applications that have a problem right now because we do 
not have both current and selected available. 
We need to indicate which page in a wiki tree is displayed. 
At the same time, We can also explore the tree and select a page for move 
or delete for when creating a sibling or child. The selection refers to 
the pages that are chosen for action, but they may not be the displayed 
page. 
I think this could be a farily common use case for having both in the same 
widget. 

With more words, we could certainly make the example more clear. But, 
rather than more words in the spec, I thought it may be better to direct 
people to the APG where we can have functional examples.

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:        Matthew King/Fishkill/IBM@IBMUS, <public-pfwg@w3.org>, 
Date:        11/19/2014 09:34 AM 
Subject:        RE: ACTION-1442: Draft spec text for aria-current and 
aria-currentfor 




Matt King wrote: 
“Note: 
When applied to an element contained in a widget that supports selection, 
the meaning of aria-current is different from the meaning of 
[aria-selected]. Authors should not use aria-current in lieu of 
aria-selected and should avoid using aria-current in circumstances where 
the meaning of aria-current would be the same as aria-selected. For 
example, in a single-select [tablist] where the selected [tab] element 
corresponds to the displayed tabpanel, aria-current is unnecessary. 
However, if the selected state of a tab is used to indicate which tab is 
selected for an action, such as move, delete, or make current, then 
aria-current should be used to indicate which tab represents the currently 
displayed tabpanel.” 
  
This still feels a bit confusing. I’m tempted to suggest that aria-current 
and aria-selected should never be used simultaneously on the same element. 
The UX for someone hearing that an element was both selected and current 
would be very confusing. 
  
  
Léonie. 
  
  
-- 
Senior Accessibility Engineer, TPG 
@LeonieWatson @PacielloGroup 
  

Received on Wednesday, 19 November 2014 19:54:13 UTC