The radio buttons are not accessible using up arrow and down arrow keys as well and also not getting automatically selected on navigating through radio buttons.

[Blessymanna]

GitHubTags:#A11ySev4#A11yUsable;#A11yTCS;#DesktopApp;#Win11;#.NET Core[WPF]-Win32-June2022;#.NET Core;#Benchmark;#Keyboard;

Environment Details:

Application Name: Unified Service Desk
Windows Version: Win11
Application Version: 4.2

Repro Steps:

1. Open RadioButton Test file.
2. Open RadioButton Test.sln file.
3. Tab to "Start" button and hit enter.
4. Tab to the radio buttons
5. Observe whether the radio buttons are accessible using up and down arrow keys as well and also getting automatically selected on navigating through radio buttons or not.

Actual:

The radio buttons are not accessible using up and down arrow and also not getting selected automatically on navigating through left and right arrow keys, it is selected on pressing space bar.

Expected:

The radio buttons should be automatically selected on navigating and also those radio buttons should be accessible using up and down arrow keys.

User Impact:

Keyboard users may get confusion on navigating through radio buttons and screen reader users cannot get the information of the navigation clearly.

RaditoButtonTest.zip
Keyboard_Issue.zip

[singhashish-wpf]

The radio buttons are accessible using the tab key and can be selected by pressing the space key. @Blessymanna Could you please elaborate more on the documentation which asks for the specific behaviour of being accessible via arrow keys and default selection on focus as opposed to the current behaviour?

[Blessymanna]

@singhashish-wpf The expected behavior of any radio buttons that we check for sample, they can be accessible using tab key and all the arrow keys(left, right, up, down) and there is an issue with the same thing that Jaws is announcing use up/down arrow keys to navigate and that is the inbuilt behavior of jaws. So, this can be changed if those radio buttons are accessible using up/down arrow keys as well.

[singhashish-wpf]

Radio Buttons are aligned in the sample app in horizontal direction and that is why you are able to navigate through them using left and right arrow keys. You would need the radio buttons to be aligned vertically in order to be able to navigate through the up/down arrow keys.

I tried modifying the sample project to have the vertical orientation in the XAML and you could navigate them using up and down arrow keys. This confirms to the specification as per my understanding.

Regarding selecting the specific radio button when focus is received; Could you please share the spec/document where this is mentioned?
If the user specifically wants, then he can modify the sample app with below code and the radio button will get selected once it gets the focus.

<Window.Resources>
        <Style TargetType="RadioButton">
            <Style.Triggers>
                <Trigger Property="IsFocused" Value="True">
                    <Setter Property="IsChecked" Value="True" />
                </Trigger>
            </Style.Triggers>
        </Style>
    </Window.Resources>

Thanks !

[singhashish-wpf]

@Blessymanna
Could you please take a look at the comment and inform us in case of any deviations? Thanks
cc: @merriemcgaw

[merriemcgaw]

@singhashish-wpf this is the standard behavior of Win32 and WinForms. Arrow keys up/right move to the next radio button and down/left move to the previous radio button. Whether your current behavior rises to the level of a must-fix MAS violation we will probably have to take to the CAIAcc office hours. Personally I read this spec as needing to respond to both right arrow and down arrow to move to the next radio button control in the single-row layout.

@Blessymanna - what happens if there is one radio button already selected before you use your keyboard to move through the group of radio buttons? The spec clearly states that when none are selected shifting focus shouldn't automatically change the checked state of the control?

[rperez030]

@merriemcgaw you are right. As the specification that has been posted here states, when no radio button is selected tabbing to the group sets focus to the first radio button, but there is no change in state until the user presses any of the arrow keys which will cause the corresponding radio button to become focused and checked. A subsequent press of the Tab key must send focus to the next interactive control after the radio group.

[miloush]

I would like to point out that the directional navigation is a fundamental feature of WPF that has been there since the beginning. Changing that behaviour could be breaking to many applications that rely on it.

I am not sure how the documentation linked by @merriemcgaw should apply to WPF, it seems to be more of a description of how a set of controls in WinUI works rather than any kind of generic requirements.

[merriemcgaw]

@miloush that's a very good point to consider. We have to balance being accessible with not breaking existing applications.

Unless there is a way for the screen reader user to know which direction the radio buttons are laid out in, they must simply guess. That is not compliant with Accessibility standards in general. If this is something that will potentially break existing applications, we can certainly try to quirk the behavior. My preference would be to have the user opt out of the more accessible behavior if it turns out to break their application. I'm open to arguments for making it opt-in, however.

[rperez030]

The behavior described in https://docs.microsoft.com/en-us/windows/apps/design/controls/radio-button#navigation-within-single-column-or-single-row-layouts has been the behavior of radio groups since at least Windows 95, and it matches the behavior of the same control in other platforms, including browsers. it doesn't contradict the directional behavior of WPF, since the selection in horizontal radio buttons can be changed with left and right arrow keys as well as up and down arrow keys according to the guidance document. This change has the potential to fix many applications that users perceive as broken at the moment and will not affect users that rely on the directional navigation using the arrow keys. It would also make navigation with the Tab key more efficient by allowing the user to skip the radio group with a single keystroke, which is the standard behavior for Windows applications.

[miloush]

@merriemcgaw It probably depends on how you expect this to be implemented, whether it will only affect navigation initiated by accessibility API, whether you expect the requests for navigation from within the application in given direction to be affected, whether this is change of existing API or adding a new API etc.

Opting out means that existing applications that work would suddenly break. Plenty of software around is no longer maintained to be able to opt out. If this is beyond framework version barrier and would only affect applications compiled against new versions, I would be more open to changing the defaults with opt-out if justified.

@rperez030 WPF brought new concepts on how elements are being arranged and with that came new possibilities of navigation that were not limited to the decades of legacy before. It is a bit unfortunate but probably understandable if accessibility standards are based on 30 years old technology.

it doesn't contradict the directional behavior of WPF, since the selection in horizontal radio buttons can be changed with left and right arrow keys as well as up and down arrow keys according to the guidance document

That is not true, arrow keys by default navigate to controls in the respective direction. For example in the sample application, down arrow moves focus to the TextBox below radio buttons.

In WPF you can move focus using FocusNavigationDirection.Next. Accessibility API should be using that to move to the next logical item in a collection rather than FocusNavigationDirection.Down, otherwise why even have them as separate options.

It would also make navigation with the Tab key more efficient by allowing the user to skip the radio group with a single keystroke

You can do that easily by using KeyboardNavigation.TabNavigation="Once", for example on the StackPanel in the sample application.

WPF allows you to customize a lot of the behavior and I don't see why this possibility should be taken away. Perhaps as a compromise we could introduce a new value here, such as "Wrap" and allow KeyboardNavigation.DirectionalNavigation="Wrap" to do the behavior you are suggesting.

The documentation that is being cited seems to be contradicting itself, see https://docs.microsoft.com/en-us/windows/apps/design/input/keyboard-interactions under Use "inner navigation" with sets of related controls:

If items are displayed in a single column, Up/Down arrow key navigates items. If items are displayed in a single row, Right/Left arrow key navigates items. If items are multiple columns, all 4 arrow keys navigate.

or in the Multiple Column/Row Arrow Key Navigation section. How does the accessibility solve it in this case? It seems it needs to be aware of the layout already.

The guidelines also don't say anything about RTL. Maybe we should refer to actual standards that we are trying to comply with.

To not just throw theoretical compatibility threats around, this is an example of radio buttons layout in one of my apps:

I find it pretty essential that arrow keys move to the radio button in the direction of the arrow key and I am still impressed that WPF provides this functionality out of the box, regardless of the actual layout (which in my case is read at runtime from a hardware instrument and can theoretically be arbitrary). It is a reason to go for WPF rather than "other platforms, including browsers" and it would be sad to lose such an advantage.

[rperez030]

To be clear, accessibility standards require that functionality is available through keyboard, but do not define the expected behavior for controls. That is up to each platform and operating system. On Windows, that expectation has been set around Win32 because it is the best documented by Microsoft and the one that most of us are familiar with. When controls do not behave in a predictable way, it can lead to frustration and lack of productivity, and that applies to everyone. I'm not writing from a theoretical or philosophical point of view. I've been a screen reader / keyboard user all my life. I've also been an assistive technology trainer for a number of years, and I've observed the frustration of users trying to find the logic of why the same control behaves differently in different applications or websites. for me, using a keyboard has become muscle memory. In the same way a visual user probably doesn't stop to think of performing a double click to activate something that looks like an icon, I don't stop to think of which key I should press when I tab to a combobox, radio group or button. The JAWS for windows screen reader has a feature called tutor messages that provides keyboard hints to new users, and it does that based on established usage patterns for common control types. That was the reason why this bug was filed in the first place. If each Windows UI framework suddenly decided to take its own approach to the keyboard behavior of common controls, it would disrupt usage patterns and create a situation where users will have to learn how to interact with each application separately, and app developers that don't customize the keyboard behavior in their applications will start receiving bugs for trusting the frameworks to do the right thing by default.

arrow keys by default navigate to controls in the respective direction. For example in the sample application, down arrow moves focus to the TextBox below radio buttons. In WPF you can move focus using FocusNavigationDirection.Next. Accessibility API should be using that to move to the next logical item in a collection rather than FocusNavigationDirection.Down, otherwise why even have them as separate options.

@miloush thanks for clarifying that. assistive technology software such as screen readers generally do not rely on the accessibility API for navigation on desktop applications for reasons that are beyond this post. They just follow focus changes and provide contextual information as users drive the applications using regular keyboard navigation. Accessibility API based navigation is used mostly for screen review, which is usually a secondary method for users when regular keyboard navigation doesn't work, or to review non interactive content. For many of us, traditional keyboard navigation has the big advantage that it doesn't depend on app layout most of the time. I'm not saying that directional navigation is bad, but maybe it could have been introduced gradually as an option that developers could provide through an app setting or, even better, through a global setting at the operating system level. I think this is somewhat similar to a feature in Chromium based browsers called caret browsing which can be turned on or off at the browser level. It is helpful to keyboard users who are not screen reader users to interact with scrollable regions or select text.

If we go by the strict letter of the law, one could even argue that this bug should be downgraded to a sev4 (usable bug) because the radio buttons are keyboard operable. However, this wouldn't change the fact that some users may be confused when after pressing an arrow key keyboard focus goes to an unexpected place, or that they always need to tab multiple times to go through a radio group. If we could at least make the arrow keys wrap around the radio buttons and ensure that the tab key stops only once on the radio group by default, that will better align with the usage pattern people are more familiar with.

[merriemcgaw]

@rperez030 do we need to take this to Office Hours with your recommendation of downgrading to Sev4? I think that @miloush has a point that existing app users may get confused and potentially broken if this is changed out from under them. My recommendation to the team is to not fix it in .NET 7, but to address the keyboard navigation as an opt in experience in .NET 8.

[miloush]

@rperez030 Thank you for the clarification.

If each Windows UI framework suddenly decided to take its own approach

My point is challenging the "sudden" here. You are of course right that for 30 years the Win32 behaved in one way, but it is now almost 20 years for WPF to behave a different way. Obviously, you are raising good points, but they should have been raised when WPF was being designed (which they as well might have been, I wasn't there).

All I am saying is we need to be a bit careful with decisions here, for this is not a new UI framework that forgot to do something, but rather a framework with considerable legacy of its own. I am also not saying nothing should be done, there is infrastructure to support the behaviour you are looking for and it makes sense to at least add such option. If it affects only applications compiled against .NET 8 and newer, then even opt-out might be fine.

@rperez030 By the way, since in WPF a group of radio buttons is created by assigning them a group name rather than logically grouping them in a container, do you expect the down arrow navigation to jump around the window when cycling through a group? That might require some extra code rather than just tweaking directional and/or tab navigation.

[rperez030]

Hi team. I was able to manipulate the control properties and get to a keyboard behavior that is more align with the traditional radio group behavior.

• I added TabNavigation="Once" to ensure that navigation with the Tab key stops only one at the radio group.
• KeyboardNavigation.DirectionalNavigation="Cycle" so that navigation with the arrow keys wraps around while keyboard focus is inside the radio group.
• I added a GroupBox element and gave it an accessible name so that the radio groups are represented as a group in the accessibility tree and announced as a group by screen readers when the user tabs to it.
• Finally, I added AutomationProperties.HelpText to the group with a control description to advise screen reader users to use the left and right arrow keys to move between options and space bar to select.

This is a modified version of the sample app that was uploaded with the initial bug containing the changes. that together with @merriemcgaw's recommendation to change the default behavior in .NET 8 makes me feel confident about downgrading this. I also think it would be great if we could document this approach in a place such as the official example so that developers know how to manipulate these properties together to improve the usability / accessibility of the control. @miloush and @merriemcgaw , does it make sense to you? When considering future changes for the default behavior it may be a good idea to align with the Win UI's guidelinesfor radio buttons which are very much up to date.

[miloush]

Looks good @rperez030, glad that works for you. By the way, you don't need to use explicit TextBlocks, you can just use Content="RadioButton1" on the RadioButton and the GroupName is not necessary either since they are grouped by the parent panel. (Also TextWrapping is NoWrap by default.)

[merriemcgaw]

@rperez030 so glad you were able to come to a place of confidence about moving to a Sev4 issue. Is there anything we need to do in order to make that formal so that this issue can be appropriately closed on the product team side? Thanks again for looking into this!

[rperez030]

@Blessymanna can you please make sure this bug gets downgraded to a sev4 (usable bug)? The control is keyboard operable as required by MAS 2.1.1, and keyboard behavior can be further customized by developers for a more accessible experience.

[Blessymanna]

As per the above comment, downgrading the severity to sev4.

[merriemcgaw]

This can now be closed based on whether WPF team wants to do anything. It may be a feature to consider to make an option where the developer could opt for default behavior that matches what the rest of desktop apps tend to do.