RE: Using aria-selected on focusable elements

BTW, I strongly support what Léonie is suggesting and have an endless 
supply of need for this.

Today in IBM, in order to support the requirement that we programaticly 
reveal the visual indicator of the active page or element in a navigation 
widget we have cobbled together a set of less than ideal design patterns. 
One such pattern, for example,  is to putt all the links in a toolbar and 
make them toggle buttons. We make the active one pressed. In this way we 
support arrow key navigation and also indicate the active page.

I wonder if a property called aria-active wouldn't be more intuitive than 
aria-current?

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 <tink@tink.co.uk>
To:     "'Alexander Surkov'" <surkov.alexander@gmail.com>, 
Cc:     "'W3C WAI Protocols & Formats'" <public-pfwg@w3.org>
Date:   10/18/2013 11:01 AM
Subject:        RE: Using aria-selected on focusable elements



Alexander Surkov wrote:
" are there other use cases than HTML:a element? Should it be really 
applied
to any focusable element?"

Good question. On reflection, probably not. All the use cases I can think 
of
relate to links.

Thinking further, perhaps such an attribute could have different possible
values beyond true/false?

For example aria-current="page" when used on links in navigation lists or
breadcrumb trails, or aria-current="step" when used on a progress bar. 
These
would translate into "Current page" and "Current step" when recognised by
screen readers.

Léonie.