RE: ACTION-1442 Default state of aria-current

Brian Garaventa wrote:
> “So, if undefined, the user agent sets no current flag either way.
> If false, the current flag is set to false,
> And if true, the current flag is set to true.
> 
> Then the screen reader for example can convey that, when a flag is 
> present, that an element is currently active or not currently active
> based on whether the flag is set, or convey nothing at all if the 
> flag is undefined.
> 
> Would this make sense?”

Léonie Watson <lwatson@PacielloGroup.com> wrote:
> Thanks Brian. I’m actually starting to wonder whether we’re over-
> complicating this attribute?
> 
> The original use case for aria-current was to identify the current 
> element within a collection, for example the current page as 
> represented by a link in a list. In that scenario, I’m not sure 
> there is a use case for informing the user that the other elements 
> in the collection are not the current one.

100% agree. Do not over complicate. We do not want screen readers to say 
"Not current" or "Not active". You only want to know which element is 
currently active.

> At the moment the proposed scope for aria-current is a navigation 
> container, but a navigation container isn’t a collection. The more I
> look at this, the more I wonder whether aria-attribute should be 
> scoped to a list, and for its default state to be false.

We need to be careful about the scope and not be too limiting. This could 
be useful both in static lists or collections or in widgets. Consider the 
following use cases:

1. A static list of wizard steps presented in an SL, OL, or UL where 
visual styling is used to indicate the current step. In this case, we want 
aria-current="true" on the LI that is the current step.

2. A tree widget that is used in a left nav for site navigation. In this 
case, we want aria-current="true" on the treeitem that represents the 
currently displayed page. Note that this is important because some 
navigation trees also support other operations that require selection so 
using aria-selected is not a good choice for indicating which is currently 
displayed. Listbox can be used for the same purpose.

3. Any collection of links in a list, set of lists, table, or grid used 
for navigation.

I think this covers the use cases I have encountered, but I am sure there 
are plenty more.

Two other widgets that may potentially make legitimate use are tablist and 
menu.

I question requiring this to be used in a navigation region. I would not 
classify a static wizard step indicator as a navigation region, but I 
would definitely want to be able to use it in that case.

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:     "'Bryan Garaventa'" <bryan.garaventa@ssbbartgroup.com>, "'W3C WAI 
Protocols & Formats'" <public-pfwg@w3.org>, 
Date:   06/09/2014 02:31 PM
Subject:        RE: ACTION-1442 Default state of aria-current



Brian Garaventa wrote:
“So, if undefined, the user agent sets no current flag either way.
If false, the current flag is set to false,
And if true, the current flag is set to true.
 
Then the screen reader for example can convey that, when a flag is 
present, that an element is currently active or not currently active based 
on whether the flag is set, or convey nothing at all if the flag is 
undefined.
 
Would this make sense?”
 
Thanks Brian. I’m actually starting to wonder whether we’re 
over-complicating this attribute?
 
The original use case for aria-current was to identify the current element 
within a collection, for example the current page as represented by a link 
in a list. In that scenario, I’m not sure there is a use case for 
informing the user that the other elements in the collection are not the 
current one.
 
At the moment the proposed scope for aria-current is a navigation 
container, but a navigation container isn’t a collection. The more I look 
at this, the more I wonder whether aria-attribute should be scoped to a 
list, and for its default state to be false.
 
Léonie.
 
 
 
 
-- 
Senior Accessibility Engineer, TPG
@LeonieWatson @PacielloGroup
 
From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] 
Sent: 09 June 2014 16:55
To: LWatson@PacielloGroup.com; 'W3C WAI Protocols & Formats'
Subject: RE: ACTION-1442 Default state of aria-current
 
If aria-current is included within an element node, but it’s value is null 
“” or includes a value other than “true” or “false”, shouldn’t this be 
treated the same as undefined?
 
Please correct me if I’m wrong, but this seems to make sense for a Boolean 
attribute.
 
So, if undefined, the user agent sets no current flag either way.
If false, the current flag is set to false,
And if true, the current flag is set to true.
 
Then the screen reader for example can convey that, when a flag is 
present, that an element is currently active or not currently active based 
on whether the flag is set, or convey nothing at all if the flag is 
undefined.
 
Would this make sense?
 
From: Léonie Watson [mailto:lwatson@paciellogroup.com] 
Sent: Saturday, June 07, 2014 1:57 PM
To: 'W3C WAI Protocols & Formats'
Subject: ACTION-1442 Default state of aria-current
 
TF,
 
What should the default state of aria-current be? In the draft spec text 
from brian, it has an undefined state, but I’m wondering whether its 
default state should be false?
 
Is there a use case for indicating which element(s) are not current, or 
just the one that is?
 
 
Léonie.
-- 
Senior Accessibility Engineer, TPG
@LeonieWatson @PacielloGroup