Settings - General Page - Accessibility Issues

[alekhyareddy28]

📝 Provide detailed reproduction steps (if any)

Run Windows Accessibility Insights on PowerToys Settings General Page.

✔️ Expected result

• PT Settings must be accessible

❌ Actual result

Code/Property Related tests

Two of the automated check fail.

Link to Accessibility insights file - https://microsoft.sharepoint.com/:u:/t/Notes145/EfgNE--B2_pKlPmBuNFlvk8B-55nQZm6CKxy77I1QhW7Dw?e=dzPtdJ.

Tabbing tests

On comparing and contrasting this with the windows tabbing setting, the following issues are identified -

1. The individual powertoys tabs, such as color picker, fancyzones etc are not accessible by the keyboard. Ideally we would want to tab into one of the elements on the left panel and then use the arrow keys for navigating across the different powerToys.
2. We have three radio buttons for the various themes, but we can tab into only the first radio button and not navigate to the other items using arrow keys which is not expected behavior.

The following gif shows how windows handles tabbing.

Screen Reader

• When we use the screen reader with a set of radio buttons under a heading, then it is expected to read the heading as well as the content of the button. (This can be easily tested with any windows settings page). However, with PT settings, only the selected item is read such as in the Settings theme, when we have the Dark radio button on focus, the Settings theme text is not read which makes it difficult to understand the complete functionality of the radio button.
• The same holds good even with version, it just reads v0.20.1 but does not say the word version.
• When we have the focus on , we would also want it to read the warning above it, otherwise a visually impaired user would not be aware that there is some setting which has been turned off because we are not running as admin. (Edit: It is read out when we press Insert+B and other than the image all enabled text is read as expected).
• This information is read out on pressing Insert+B. However, the we must provide some information about the image as just the word graphic is being read out now.
  

Contrast issues

These items do not meet the contrast threshold standard while testing using Accessibility insights -

[alekhyareddy28]

@niels9001, I've been looking into the tab related accessibility issue for the settings page. The expected behavior for a group of radio buttons is to tab into the selected item and then use the arrow keys for up and down navigation as shown in the gif below.

However, with the powerToys settings page, I'm able to tab into the group of radio buttons but not navigate using arrow keys as shown above.

The arrow navigation is built in by default into the radiobuttons control. Do you have any idea as to why this might be happening?

I tried setting TabNavigation properties as well as XYFocusKeyboardNavigation but that did not seem to work.

Adding @laviusmotileng-ms.

[alekhyareddy28]

update: The two failures that we see with the code/property related checks regarding the on screen property must not have a null bounding property is due to xaml islands. The two pane elements are throwing that error and there is nothing that can be done from our side as they are components which do not have a bounding property. We would no longer face this issue once we switch to winui 3.0.

[niels9001]

@alekhyareddy28 Hmm, no idea - is that a XAML Island bug as well?

What we could do, is simply replace the theme selection radiobutton group with a ComboBox. It would save us some space as well.

[alekhyareddy28]

update: @niels9001, it seems like a xaml island bug. I created a simple xaml island project with just a radiobuttons control with three radio button controls and the keyboard navigation does not work as expected. However, the following code works in a standalone uwp app.

<UserControl
    x:Class="Microsoft.PowerToys.Settings.UI.Views.ShellPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:behaviors="using:Microsoft.PowerToys.Settings.UI.Behaviors"
    xmlns:winui="using:Microsoft.UI.Xaml.Controls"
    xmlns:helpers="using:Microsoft.PowerToys.Settings.UI.Helpers"
    xmlns:views="using:Microsoft.PowerToys.Settings.UI.Views"
    xmlns:ic="using:Microsoft.Xaml.Interactions.Core"
    xmlns:i="using:Microsoft.Xaml.Interactivity"
    xmlns:muxc="using:Microsoft.UI.Xaml.Controls"
    mc:Ignorable="d">


    <Grid>
        <muxc:RadioButtons>
            <RadioButton>Item 1</RadioButton>
            <RadioButton>Item 2</RadioButton>
            <RadioButton>Item 3</RadioButton>
        </muxc:RadioButtons>
    </Grid>
</UserControl>

@crutkas suggested to create a new issue for xaml island related bugs instead of modifying the ui as they would be fixed in a few months time once we transition to winui 3.

[crutkas]

We should file a bug against the WinUI repository and link to this bug.

Lets create a new issue for us for WinUI 3 upgrade for settings as well and reference this as well

[alekhyareddy28]

Update: When i was trying to fix one of the screen reader issues when the title of the radio buttons was not being read (ie. the screen reader was only reading 'Dark' and not Settings theme, i came across this microsoft accessibility insights article which suggested we use stack panel and group the items. I tried to do a similar thing with the radio buttons control and it did not work. There is no user facing change as well.
Before:

After: Key navigation works as expected and even the heading Settings theme is being read by the narrator.

[alekhyareddy28]

Created an issue in the winui repo: RadioButtons control does not support keyboard navigation in XAML islands microsoft/microsoft-ui-xaml#3156

#6032 is the tracking issue for accessibility issues related to xaml islands.

[alekhyareddy28]

update: The contrast related issues are off the threshold by a very small value 0.002. We are using the system brushes so there is little for us to do there. The rest of the issues are fixed in the above PR.