[BUG] Improve Message: "A split button must not support both the Invoke and Toggle patterns" about axe-windows HOT 18 CLOSED

@chingucoding, please feel free to take a stab at rewording the text. You'll also need to take a look at the HowToFix description. These are intentionally short because there's a cap on the maximum length of a bug sent to ADO. Please try to keep this in mind when wordsmithing.

from axe-windows.

Thanks, @lihas! We'll take a look. Just to make sure that we're looking at the same thing you are, can you please attach one or both of the following:

1. A simple app that we can build on our end that shows the problem.
2. An a11ytest file showing the error.

Thanks again!

from axe-windows.

This issue has been marked as ready for team triage; we will triage it in our weekly review and update the issue. Thank you for contributing to Accessibility Insights!

from axe-windows.

Hello again, @lihas! I've looked at the UIA documentation and the history of this rule, and I can't find any scenario where the docs would justify having neither TogglePattern nor InvokePattern. I tried adding a simple SplitButton into a Win32 app, and wasn't able to reproduce the failure that you're describing. I'm afraid that we'll need to ask you for a small sample project that demonstrates the behavior. Knowing the Windows version that you're running on would also be very helpful, since there's also a chance that this represents a Windows bug. Thanks!

from axe-windows.

The team requires additional author feedback; please review their replies and update this issue accordingly. Thank you for contributing to Accessibility Insights!

from axe-windows.

I've looked at the UIA documentation and the history of this rule, and I can't find any scenario where the docs would justify having neither TogglePattern nor InvokePattern

if the split button should support at least one of the two, then the error message should be modified.
"A split button must not support both the Invoke and Toggle patterns"
This is the current error message. This implies that a split button should not have both these patterns together (so having neither is also okay).
A better message would be something like this.
A split button must not support both the Invoke and Toggle patterns, but must support at least one.

In my first message I have mentioned that either the test is returning false positive, or the message string is wrong (ambiguous). Apologies for not highlighting the latter as much. I believed that the former is the real issue.

Meanwhile I am working on a sample MFC (win32) app. My split button doesn't support either of the two patterns as of now - invoke, and toggle. It only supports Expand Collapse pattern.

from axe-windows.

sample app - https://github.com/windows-development/SplitButtonAccessibility
The sample app is a native MFC/win32 app.
In the following image "Split btn" is a split button which implements IExpandCollapseProvider, but neither of IToggleProvider, and IInvokeProvider.

A native win32 split button by default supports IInvokeProvider, and IExpandCollapseProvider, however when a split button is child of a toolbar control, then these interfaces are not implemented by default.

Accessibility insights initially highlights that IExpandCollapseProvider is missing, on implementing this, it starts giving the following error.

A split button must not support both the Invoke and Toggle patterns.

This seems to imply that a split button should not implement both these interfaces at once, but it is perfectly fine if neither are implemented.

This leads to two cases.

1. The error is a false positive, and therefore it is perfectly fine to implement just IExpandCollapseProvider, and neither of IInvokeProvider, and IToggleProvider.
2. A split button must always implement at least one of IToggleProvider, and IInvokeProvider. If this is the case then the error message should be modified to call this out, eg. - "A split button must not support both the Invoke and Toggle patterns, but must support at least one of them"

from axe-windows.

This issue has been marked as ready for team triage; we will triage it in our weekly review and update the issue. Thank you for contributing to Accessibility Insights!

from axe-windows.

Thanks, @lihas! I'll take a look at this on Monday. One more question--what OS were you running when you ran the scan? We've had reports of odd problems with pattern detection on Windows 11, so it would definitely be interesting to know if you encountered this on Windows 11.

from axe-windows.

Thanks, @lihas! I have a repro of this using your sample code and Win10. We'll need to investigate it from our side, but at first glance this appears to be a bug in the MFC framework. They're synthesizing a SplitButton from a Button, and completely ignoring the UIA pattern requirements that are documented at https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-controlpatternmapping. Marking as ready for triage.

from axe-windows.

Dave, the bug is neither in MFC, nor in the detection of patterns.
I debugged axe, and accessibility insights (after locally building them both).
The patterns supported by my split button are getting detected correctly.
Also, although an MFC app, MFC has no role to play here since I am implementing the provider from scratch.
I can create a sample in pure win32 (without use of MFC) if required.
After reading the link shared by you, I think the best way forward would be to modify the error message displayed.

from axe-windows.

@DaveTryon Please let me know if you need more information.

from axe-windows.

We triaged this today. The consensus is to change the primary message to "A split button must support exactly one of the Invoke or Toggle patterns"

We will create separate issues that deal with false positives triggered by generic SplitButton items supported in Win32, UWP, and (potentially) MFC.

from axe-windows.

@DaveTryon Mind if I work on this issue?

from axe-windows.

The bug text has been fixed in Axe.Windows 1.1.2. I'll update this bug once the Canary version of AIWin picks up the fix

from axe-windows.

Hello, @lihas! This change is now live in our release at https://github.com/microsoft/accessibility-insights-windows/releases/tag/v1.1.1836.01. You can easily use this build just by switching to the Canary release channel. Please take a look, then close the bug after you've regressed it. Thanks!

from axe-windows.

The team requires additional author feedback; please review their replies and update this issue accordingly. Thank you for contributing to Accessibility Insights!

from axe-windows.

Installed Canary Release: v1.1.1836.01 from the link given above.
I am able to see the updated message.
Bug is fixed.
Closing this issue.

from axe-windows.