Add heading levels to Extensions page

[lauren-ciha]

Summary of the pull request

I enabled the narrator in scan mode to read the heading levels of the "Installed" and "Available in the Microsoft Store" headings on the Dev Home Extensions page by adding Automation.HeadingLevel properties to each text block.

References and relevant issues

https://task.ms/52443515

Detailed description of the pull request / Additional comments

Before:

03e67077-a961-4d1f-b8ca-aafefea96bd9.mp4

After changes:

heading_level_scan.mp4

Validation steps performed

PR checklist

• Closes #xxx
• Tests added/passed
• Documentation updated

[guimafelipe]

I am not sure about the IsTabStop variable. It is one more button the user needs to press to navigate the UI. And it does not affect the narration of the internal controls.

[lauren-ciha]

Thanks for letting me know!

As of the most recent commit, I removed the TabStops from both headers. The "Installed" group is now read by the narrator, but the "Available in the Microsoft Store" header is not. I think this is because there is an interactable element (GetUpdatesButton) in the InstalledItemsStackPanel, so the group is automatically read with when the focus is on the button. The AvailableFromStoreStackPanel, on the other hand, has an ItemsRepeater with interactable subelements. Each of these is read as its own group. When I add an AutomationsProperties.Name to the ItemsRepeater, the heading isn't read. Do we need a CustomRepeaterAutomationPeer on the ItemsRepeater to read the heading or is there a better approach?

[dhoehna]

Asking every user of DevHome to "Please change verbosity" is not the correct fix. We should either

1. Find a work around to this issue, or
2. Close the task as external and make a bug on the narrator.

[dhoehna]

I want to make sure I understand the second issue correctly.

The issue is the narrator is not announcing the headers in the extension list.

This is happening because the first interactable element isn't a top element. This results in narrator correctly announcing the tabbed-to element, but not the header. Does that sound right?

[lauren-ciha]

Good to know that switching settings is not a fix. Let's find a resolution.

I think we're on the same page:

• The second issue is that the groups were not being announced. The group names are the same as the heading titles. I apologize for confusing those earlier.
• As of the last commit, the "Installed" group is announced at the default verbosity level because the "Get Updates" button is a child of the "Installed" group. Now, only the "Available in the Microsoft Store" group is not announced.
• The first interactable element in the "Available in the Microsoft Store" group (the "Get" button on the first extension in the list) is within an extension item group. My understanding is that since the "Get" button has a parent group, by design the narrator announces only the parent group ("Microsoft Game Dev Extension" group) and not the grandparent group ("Available in the Microsoft Store"). Is top element another word for child element?

Here's the current narrator behavior (default verbosity, scan off):

current_narrator.mp4

One workaround we considered was changing the extensions from a SettingsCard (which is its own group) to a button so that both the "Available in the Microsoft Store" group and the extension name were announced. We decided to not take this approach because we wanted to mimic the UI design of the Microsoft Store. Although the Microsoft Store has a similar two-group layout, the groups on its LibraryPage are announced because each group has buttons and/or navigation elements as children:

Another team ran into a similar issue where a grandparent group was not read: https://task.ms/32064580. They had concluded that the narrator behavior was by design and didn't make any further changes. Therefore, I think best approach would be a workaround.

I'm not sure where to start:

• Can we customize the narration behavior for this page?
• Can we move or add an interactable element to the "Available at the Microsoft Store" group that would benefit all users? (The MS Store library has a sort button)

[lauren-ciha]

I've updated the current PR to address just the heading level fix. If I can find a workaround for the "Available in the Microsoft Store" group narration, I will make a separate PR for it. Otherwise, I will close that bug as external.

[krschau]

Do these actually get read or is it the TextBlocks inside?

[lauren-ciha]

The InstalledItemsStackPanel.[using:Microsoft.UI.Xaml.Automation]AutomationProperties.Name gets read as the group name (e.g. "Installed group"). If scan mode is on, it would read "Installed group; [and if you navigate to the heading] Heading level 2: Installed" (the TextBlock). If the narrator read the "AvailableFromStore" group, it would read its StackPanel's AutomationProperties.Name. If you navigate to the "Available in the Microsoft Store" heading in scan mode, it reads "Heading level 2: "Available in the Microsoft Store" (the TextBlock).

I think the narrator reads the StackPanel Automation Properties.Name as the group name because the item groups underneath them are ItemsRepeaters, not Lists or another control with a designated header.