Don't have any accessibility mode specific behavior of quickpick

[TylerLeonhardt]

Right now, we depend on different behavior of the quick pick when using a screen reader so that the quick pick is accessible. However, the change we made last iteration to make it accessible, also made it less usable.

Lots of good info in this thread:
#166920 (comment)

The overarching problem is that a quick pick cannot have a placeholder and set active items at the same time because the placeholder must be read out by a screenreader to be accessible.

We should try out using aria-live instead of aria-activedecendant to make this work.

[TylerLeonhardt]

To @joanmarie and @LeonarddeR, @isidorn gave me your names to ask about ARIA. Here's the craziness I am trying to accomplish. I have:

<div id="a" aria-live="polite"></div>

and then under that (as child), I add in "randomly":

<div id="b" aria-labelledby="list_item_0"></div>

This causes the aria-label on list_item_0 to be read, which is great! This alternative also reads the aria-label... I have my same outer div:

<div id="a" aria-live="polite"></div>

and then adding aria-owns="list_item_0" to this div with an id of a also causes the live region to trigger and reads the aria-label of list_item_0

My question is... it seems like the role on the list_item_0 element is ignored. I was hoping that I could set the role to link or option or something else that might make sense and then the screen reader will read out the fact that that element is a link or whatever. Do you know why this is? Is this a limitation of live regions? A limitation of NVDA?

NOTE: At no time, do these elements that I have mentioned have dom focus. Dom focus is entirely in a different part of the UI and doesn't change when this does happen. This is what I want. I don't want dom focus to leave where it is.

[rperez030]

I think you are expecting aria-live to work for something which is beyond its purpose. The role of the element with id ="list_item_0" is not announced because the purpose of aria-live regions is simply to announce changes in text content. In fact, for the fix you are trying to implement, there is no need for the role of the object to be announced. You are not trying to simulate a focus event. Think of it as announcing search suggestions instead. If the role was announced, screen reader users may be led to believe that keyboard focus is where it isn't.
I would suggest you try with something simpler than that.

<div id="a" aria-live="polite"> text to be read by the screen reader </div>

Avoid nested divs with additional aria attributes which can lead to unexpected behavior. I'm actually surprised that your child div gets read at all. I suppose since it is an empty div that Chrome is calculating the accessible name based on aria-labelledby. You may want to apply an sr-only class to that div so that it is not visible.

• to

[TylerLeonhardt]

@rperez030 your suggestion also works and is something I tried. My concern with all these options is that the role of the selected item in the quick pick is lost. If I want to mark that an item in the quick pick acts as a link instead of just a regular option, then there is no way for me to do that in a way that a screen reader picks it up.

• I can't give the input box aria-activedescendant because then no details about the input box are read out.
• I can't have an aria-live label announce that the active list item has changed because it doesn't include info about the role

I can't figure out the right way to have these requirements:

• dom focus in the input
• placeholders & text operations (selection, deletion, etc) in the input read out
• fake focus in the list which will read out the label of the current active item
• fake focus in the list which will read out the role of the current active item

Please let me know if you have any ideas how to do this, otherwise I'll get almost there and use your simpler suggestion which gets us all of those bullets except for the last one.

[rperez030]

hi @TylerLeonhardt. I will comment on some of your points and suggest a simpler approach in the end.

• the role of the active item had never been announced because the active element is inside of a list, and NVDA treats each element inside of a list as having the role LISTITEM.
• The 2 roles you mention, link and option, have the same keyboard behavior, so announcing them in this context is irrelevant. If someone can come up with something that requires a different keyboard behavior inside of that list, we will likely have bigger problems.
• An aria live region is good to announce elements as we type, but when arrow keys are used to navigate, it is necessary that focus is managed inside the list either by aria-activedescendant or true keyboard focus, otherwise the specific screen reader commands related to the element with focus will not work.

Simpler approach:

As @scottaohara mentioned to me in a side conversation we are having, all of this can be avoided simply by replacing the current accessible name of the widget "Quick Input" with the placeholder text. I don't remember if there was a reason not to do that in the first place. This will resolve the problem that started the entire thread, allow us to continue using aria-activedescendant and eliminate the need to have a screen reader optimized widget. The name "Quick Input" is not helpful anyway. The only inconvenient of this method is that we cannot track the activity in the edit field using a screen reader, but we couldn't do that with the previous behavior either. It is perhaps a smaller price to pay. We still could allow something like that if we can remove aria-activedescendant when shift +Tab is pressed, for example, and add it back if the user presses down arrow key or the Tab key.

Does it make sense?

[TylerLeonhardt]

Yes that makes sense. #179217 this PR will set the aria-label of the list to the placeholder which from my testing works nicely.

I haven't implemented that shift +Tab behavior you suggest... but it's something we should do... tracked here #101183

[TylerLeonhardt]

Fixed in #179217

[isidorn]

I just tried out the Quick Pick behaviour on Windows with NVDA and what you did feels good to me.
So the first element gets nicely focused. And we read the placeholder via alert. This feels intuitive and good to me -> verified

[starball5]

Related on Stack Overflow: Why isn't VS Code auto-focusing the first entry in the Quick Open list?

[rperez030]

This is due to changes in the previous iteration for the component. I'm surprised this was promoted to production.