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