Re: aria-selected is not generally necessary on single selection containers

Hi Bryan,

Maybe I'm not understanding something. Screen readers can see that the
listbox contents have changed. But it seems you're solving the problem that
they don't do anything with that info, and want to force them into
outputting something about the list?

In any case, I wasn't saying aria-selected in the single selection case is
illegal, but that it's not generally necessary, and in the examples we have
we should look into cleaning up redundant markup. It makes the examples
harder to understand. If I'm a newbie, and I'm looking at the examples, I'm
wondering why do I need to use 2 different ARIA attributes to indicate the
same thing.

Aaron

On Thu, May 24, 2018 at 2:00 AM Bryan Garaventa <
bryan.garaventa@levelaccess.com> wrote:

> There is one scenario that supports the use of aria-selected that was
> proposed but never followed up on.
>
>
>
> Historically the combobox design pattern does not support the announcement
> of newly rendered content, which typically makes comboboxes like these go
> undiscovered when non-sighted screen reader users encounter them. E.G when
> using a touch screen to type into a combobox field using VoiceOver where a
> dynamic list is displayed yet nothing is announced to convey that this has
> occurred, so this might as well not exist for non-sighted users who are
> unaware of this functionality or what it contains.
>
>
>
> So the proposal was, to use aria-selected to cause a selection change
> event to occur so that ATs could recognize that the first option was
> selected after such a list is rendered, and then this option could be
> announced much like the auto suggest functionality does within the Windows
> address bar or within the To field in Outlook.
>
>
>
> As I said though, this was never followed up on back then, but it would be
> helpful.
>
>
>
> As it currently stands without this support though, the common design
> pattern for auto-suggest combobox controls is fundementally flawed as is
> because of this problem, because nothing exists within the mappings to
> convey discoverability when rendered.
>
>
>
>
>
>
>
>
>
> Bryan Garaventa
>
> Accessibility Fellow
>
> Level Access, Inc.
>
> Bryan.Garaventa@LevelAccess.com
>
> 415.624.2709 <(415)%20624-2709> (o)
>
> www.LevelAccess.com
>
>
>
> *From:* Aaron Leventhal <aleventhal@google.com>
> *Sent:* Wednesday, May 23, 2018 5:33 PM
> *To:* public-aria-practices@w3.org
> *Subject:* aria-selected is not generally necessary on single selection
> containers
>
>
>
> I was looking at the ARIA 1.1 combobox example, and here is some feedback
> a markup simplification that aligns with the specs:
>
> Using aria-selected at all is generally redundant in a list of options, or
> any single selection container. Using either focus or aria-activedescendant
> is enough.
>
>
>
> See here in the ARIA spec:
>
> https://www.w3.org/TR/wai-aria-1.1/#aria-selected
>
> "Single-selection containers where the currently focused item is not
> selected. The selection normally follows the focus, and is managed by the
> user agent."
>
> And in CORE-AAM: "In the single selection case, selection follows focus".
>
>
>
> There are rare cases in single selection containers where the author wants
> nothing to be selected, even though something is focused. In this case the
> author should use aria-selected="false" on the focused item.
>
>
>
> Firefox has always gotten this right, but Chrome had it wrong. I just
> fixed this for tomorrow's Canary build. See
> https://bugs.chromium.org/p/chromium/issues/detail?id=846089 ("NVDA
> reading "not selected" in combobox list boxes").
>
>
>
> Bottom line, I believe the lines setting aria-selected should be removed
> from the combo box examples. I haven't checked other places in the ARIA
> practices. And I haven't checked what happens with every browser + screen
> reader combination. (It's generally up to the browser to do the right
> thing.)
>
>
>
> Aaron
>