[Terminal> Command Palette]: Screen Reader is not announcing any info about '>'(more options) for 'New Tab' list item.

[ghost]

Windows Terminal version

1.12.3472.0

Windows build number

10.0.22504.1010

Other Software

Test Environment:
OS: Windows 11 Version Dev (OS Build 22504.1010)
App: Windows Terminal Preview
Screen Reader: Narrator
Tool: Accessibility Insights for Windows Version 1.1.1741.1

Steps to reproduce

Repro Steps:

1. Open Windows Terminal.
2. Open Command Palette using 'Ctrl + Shift + p'.
3. Open Narrator using 'Win + Ctrl + Enter' keys.
4. Navigate to 'New tab...' suggestion using down arrow keys and observe the issue.

User Experience:
Screen Reader users UX will not be good if Screen Reader doesn't know the full control properties.

Guideline Reference:
https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships

Attachments:
Screen Reader is not annoucing any info about ExpandCollapsed control for 'New Tab' list item..zip

Expected Behavior

Screen Reader should announce 'New Tab 48 of 107 Selected Activate for more options' for 'New Tab' list item.

Actual Behavior

Screen Reader is not announcing any info about '>'(more options) for 'New Tab' list item. Issue repro with all list item control where '>' (more options) control is present.
i.e. For 'New tab.. >' Screen reader is only announcing 'New Tab 48 of 107 Selected'

Observation: Issue repro with NVDA and JAWS Screen Reader.

[carlos-zamora]

Hmm... I'm gonna bet we need to add an AutoProp.HelpText to the NestedItemTemplate in CommandPalette.xaml. We can make it just say "Activate for more options" (and localize it, of course).

[carlos-zamora]

@v-rpundir, there is already help text that says "more options". We could change it to "Activate for more options", no problem.

However, I've noticed that NVDA reads help text by default, but Narrator does not unless you enable the "Read advanced details..." setting. So the change above would work better for NVDA because it would read the item exactly as you've desired ("New Tab 48 of 107 Selected Activate for more options").

That said, I'm unsure about next steps here. The "..." in the text is a standard for signifying that there are more options and we already have adequate help text. Should I change the AutoProp name to "New tab (activate for more options)"? That doesn't seem right either. Should this be an issue on Narrator to enable that setting by default? Or should this bug be closed entirely since the user should explicitly ask for the help text?

[carlos-zamora]

Notes on relevant code for anybody that comes along:

• set help text on list view item:

  terminal/src/cascadia/TerminalApp/CommandPalette.cpp

  Lines 1227 to 1231 in bb40efc

  	if (dataTemplate == _itemTemplateSelector.NestedItemTemplate())
  	{
  	const auto helpText = winrt::box_value(RS_(L"CommandPalette_MoreOptions/[using:Windows.UI.Xaml.Automation]AutomationProperties/HelpText"));
  	listViewItem.SetValue(Automation::AutomationProperties::HelpTextProperty(), helpText);
  	}

• localized resource:

  terminal/src/cascadia/TerminalApp/Resources/en-US/Resources.resw

  Lines 659 to 661 in bb40efc

  	<data name="CommandPalette_MoreOptions.[using:Windows.UI.Xaml.Automation]AutomationProperties.HelpText" xml:space="preserve">
  	<value>More options</value>
  	</data>

[ghost]

Hi @carlos-zamora Thanks for reaching out.

Actually, we are asking for an accessible name for the '>' icon which visually indicates that it will expand to show more options. It is fine if you have added help text for '...' but 'more options' is not that clear to convey these controls' structure.

To solve this problem from your side I suggest keep help text and but include 'Expand' property with the control (which is accessible name for '>') in code.

It will also solve future bugs when Voice Access (new Accessibility tool that allows users to control their computers by using voice commands) users use Expand command (by seeing this '>' icon) on this type of controls as shown in this video attachment Voice Acess Demo on Terminal.zip

We are also aware about the fact of different Screen Reader behavior with help text but in my experience, it is always better to find ideal solution from product side.

Let me know if it is not a feasible solution.

Thanks :):