microsoft / axe-windows Goto Github PK

The ControlSupportsTextPattern rule was changed to require all edit controls to support the text pattern. This is in-line with a recent change to the UIA documentation. However, there are legacy situations which the rule now reports as errors and which are unlikely to be resolved. These are perceived as false positives by users.

The first reproduceable instance given to us was the find edit field in Notepad. This edit field is built with the Win32 framework. Axe.Windows should not be reporting this error for Win32 because it is unlikely to be fixed and Win32 edit fields don’t seem to present a barrier to ATs, probably because they can be accessed using Windows messages.

The second reproduceable instance given to us was Windows Explorer, where there are many edit fields which generate this error on every page. These don't actually appear to be editable content. But the framework, DirectUI, has designated them as such. We believe it is safe to exempt edit fields which are not focusable in the DirectUI framework from the ControlShouldSupportTextPattern rule because these do not appear to be truly editable.

ControlShouldSupportTextPattern should be updated with the exemptions described above.

Test issue to validate query. I'll close it once the test is over

AutomationId is unavailable.

HierarchyNodeViewModel.cs Line No:- 277

this.Children = (from c in ce.Children
                                 select new HierarchyNodeViewModel(c, showUncertain, isLiveMode)).ToList();

Why is automationId unavailable at this point. I tried it for those elements which do have automationId. Is it on purpose?. If yes, Can you let you know at which point AutomationIds get set for the elemnet. I am trying to get AutomationElement equivalent of A11yElement.

Describe the bug

AI-Win fails to report patterns for certain elements for which Inspect shows patterns. The problem probably resides in axe-windows, not AI-Win.

To Reproduce
Steps to reproduce the behavior:

1. Open "Edit local users and groups"
2. Invoke the "Users" row in the center list
3. Point AI-Win (run it as admin) at any of the cells in the "Name" row
4. Observe that there are no available patterns in AI-Win

Expected behavior

If you point Inspect at the same cell, you can see GridItemPattern, LegacyIAccessiblePattern, TableItemPattern are supported and their properties are displayed.

Actual behavior

AI-Win displays no patterns.

Screenshots or .GIF

Desktop (please complete the following information):

• OS: Windows 10 1909
• Accessibility Insights for Windows Version: 1.1.1107.1 (and others)
• Target Application: MMC

We need to add authenticode signing to the assemblies provided in the NuGet package. The requirement is that we use a certificate compatible with the open source nature of the package.

Describe the bug
The rule Focusable sibling elements must not have the same Name and LocalizedControlType fails when there are two adjacent Hyperlink elements. Hyperlinks should be excluded from this rule and moved into a warning based on the rationale given here (Best practice is that links with the same destination would have the same descriptions, but links with different purposes and destinations would have different descriptions).

Describe the bug

After the projects in axe-windows were converted to .Net Core, we had to disable some unit tests which were failing intermittently, and some that were failing because dependent assemblies couldn't be loaded.

The intermittent failure is in Axe.Windows.AutomationTests.AutomationIntegrationTests.Scan_Integration_Win32ControlSampler.

The tests failing due to missing dependency assemblies are in Axe.Windows.OldFileVersionCompatibilityTests.LoadOldFileVersions.

Migrated from ai-win, see full detail there

The UIA spec (https://docs.microsoft.com/en-us/windows/desktop/winauto/uiauto-supporteditcontroltype) requires every edit control to support at least the Text control pattern. The Value pattern is supplemental. This rule should return an error.

As I understand it, the rule fires when an edit control supports the value pattern but does not support the text pattern. The documentation says ITextProvider is required, while IValueProvider depends. The only thing wrong with the rule is how the outcome is reported. I believe failure instances should be shown as errors instead of uncertain.

This issue tracks adding more actionable guidance for the DataGridCell issue in microsoft/accessibility-insights-windows#931.

It was fixed by directing the user to either update to .NET 4.7.1 or to use accessibility switches. This DataGridCell issue (alongside some other updates) was explicitly called out in the .NET 'What's new in accessibility' documentation here.

If axe-windows detects this error, we should suggest updating/accessibility switches in the tool itself.

Details:

• create a new failing rule that targets DataGrids with this issue (can look for custom control type/localized control type, wpf framework, and class name)
• include how-to-fix information that mentions the suggested fix from above & how-to-fix information from LocalizedControlTypeIsNotCustom
• update the behavior of LocalizedControlTypeIsNotCustom:

  axe-windows/src/Rules/Library/LocalizedControlTypeIsNotCustom.cs

  Line 16 in 95b5fe9

  class LocalizedControlTypeIsNotCustom : Rule

  to exclude testing elements that are tested by the new rule

An alternative approach would require updating our how-to-fix mappings to be chosen dynamically from within a rule, rather than a 1:1 mapping from a rule to HowToFix entities. When discussing with Rob, the new-rule approach seemed more aligned with the existing codebase.

We should also check whether this rule has an associated how-to-fix link. Based on that, it might make sense to add or update the doc with a note about this issue.

In older style native Win32 application wizards there is a hidden tab control near the top. This hidden tab control, which is purely an implementation detail, is being picked up by the Insights tool and failures reported against the tab positions and labels.

Here is an example of the failures reported by Insights:

And here is the overlay window showing where the failures are detected:

These screenshots are not taken from the real application which I am working on because that is private, and so I've found a publicly available example instead. The application above is a free application called Source Monitor which I know uses older style wizards and is still actively maintained. The wizard displayed above is the "New Project" wizard which contains 7 pages.

Please can you explain why the tool is reporting failures with this hidden control, as it is not obvious how it affects accessibility as the user will never interact with it.

Are SARIF outputs still supported?

I'd like to know if there is away to generate SARIF files on failure along with a11ytest files. The entry is present in scan result output, but doesn't look like it gets populated.

If not, do you know a way to craft SARIF files from a11yTest ones?

I'd like to leverage a devops task that uploads SARIF files directly to the Accessibility tab for a better view of failures.

Thanks!

Issue

Possible false-negative result for the rule "Children of off-screen element's must also be off-screen"

Accessibility Insights show the error mentioned above for a WPF app which has a list box with complex elements and some of the elements are scrolled to outside the visible area. It happens because the ListBox/ListView control marks top-level elements IsOffscreen = true, but don't do it for all sub-elements. In other words, it happens that the element outside the visible area has IsOffscreen = true, but all its children have IsOffscreen = false.

With the default scrolling behavior, it is not possible to select an element without making it visible (that immediately makes the element IsOffscreen = false). So, I don't see any wrong behavior in WPF.

To Reproduce

Steps to reproduce the behavior:

<Window x:Class="ChildrenOffscreenIssue.MainWindow" 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:collections="clr-namespace:System.Collections;assembly=mscorlib"
        xmlns:system="clr-namespace:System;assembly=mscorlib" mc:Ignorable="d" Title="MainWindow" Height="450"
        Width="400">
    <ListBox>
        <ListBox.ItemsSource>
            <collections:ArrayList>
                <system:String>item 01</system:String>
                <system:String>item 02</system:String>
                <system:String>item 03</system:String>
                <system:String>item 04</system:String>
                <system:String>item 05</system:String>
                <system:String>item 06</system:String>
                <system:String>item 07</system:String>
                <system:String>item 08</system:String>
                <system:String>item 09</system:String>
                <system:String>item 10</system:String>
                <system:String>item 11</system:String>
                <system:String>item 12</system:String>
                <system:String>item 13</system:String>
                <system:String>item 14</system:String>
                <system:String>item 15</system:String>
            </collections:ArrayList>
        </ListBox.ItemsSource>
        <ListBox.ItemTemplate>
            <DataTemplate>
                <StackPanel>
                    <TextBlock Text="{Binding}" />
                    <Button Content="{Binding}" />
                </StackPanel>
            </DataTemplate>
        </ListBox.ItemTemplate>
    </ListBox>
</Window>

Expected behavior

Accessibility Insight tool mustn't report the error for elements that have a parent with IsOffscreen = false.

Actual behavior

Accessibility Insight tool reports the error for elements that have a parent with IsOffscreen = false.

Screenshots

Desktop

• OS: Windows 10 1909
• Accessibility Insights for Windows Version: 1.1.1198.01
• Target Application: WPF / .NET 4.6.1

Is your feature request related to a problem? Please describe.
A user trying to consume axe-windows in Visual Studio has the potential to specify an unsupported version of Newtonsoft.Json. We use version 10.0.3, so versions before 10.X should be blocked via the nuspec file

Sample
This is an excerpt from a NuGet package that provides similar protection:

    <dependencies>
      <group targetFramework=".NETFramework4.5.1">
        <dependency id="Newtonsoft.Json" version="10.0.1" exclude="Build,Analyzers" />
      </group>
    </dependencies>

Is your feature request related to a problem? Please describe.

We are looking at using axe-windows for our extension inside of Visual Studio. We'd like to run it as part of our CI pipeline so that we can pre-emptive catch any accessibility issues or at least reduce the chances of shipping something with accessibility issues. The problem is we would like to only run the check on our extension and not all of Visual Studio.

Describe the solution you'd like

I'm not sure of the best way to approach this. Currently the scanner just finds the root element of a given process id. It'd be ideal to give it some kind of identifier or input such that the scanner chooses a different "root" element to start at such as a specific pane?

Describe alternatives you've considered

Right now I'm look at manually narrowing down the scan results and walking the tree of each element that has errors to see if it has a specific "root" element. The idea is that anything that has the "root" element as a parent at some level is an error I need to follow up on.

Additional context

Description

For the rule “An element's BoundingRectangle must not obscure its container," we should make an exception for element's with the type of "Pane" and with the "IsDialog" property set to true.

The rule already contains an exemption for elements of type "Window" because windows may obscure their container elements. The same reasoning applies to dialog boxes because they too may obscure their containers.

element.”

Describe the bug

For the rule NameIsReasonableLength, we have received a false positive report where text elements had names longer than 512 characters. It seems reasonable that text elements, by virtue of their type and purpose, may have names in excess of the 512 character limit. Therefore, we shall remove the character count limit for text elements.

This was reported against AIWin, but the root cause is in Axe.Windows

Please check whether the bug has already been filed.

Describe the bug
UIA StyleId properties are not reported in the most helpful way to AIWin users.

To Reproduce
Steps to reproduce the behavior:

1. Go to a Microsoft web page with semantic headings. For example, Office.com.
2. Point the AIWin tool to a heading on the page. For example, at Office.com, "Welcome to Office".
3. Use the AIWin tool to access the TextRange for the UI, via the TextChild patterm.
4. Check the reported UIA StyleId property data, "Unknown(70001)".

Expected behavior
As listed at https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-style-identifiers, a StyleId property value of 70001 is "A first level heading". As such, AIWin should say something like "Heading level 1, (70001)".

Actual behavior
By saying "Unknown(70001)", it's less likely that the AIWin user will learn the heading level of the UI of interest.

Screenshots or .GIF

Desktop (please complete the following information):

• OS: Windows 10 1909, OS Build 18363.535
• Accessibility Insights for Windows Version: 1.1.1072.1
• Target Application: Settings app in Windows.

Additional context

Describe the bug

In the rule ProgressBarRangeValue, the current expected value for minimum is 0 and the current expected value for maximum is 100.

This rule is based on the documentation provided here.

Originally, the docs said to have min = 0 and max = 100. But after some conversations about the allowable values of frameworks like WPF, the documents are being changed to specify only that max > min.

The rule should be changed to match the new documentation.

Facing memory leak issue when capturing data using test mode
Code used:
CaptureAction.SetTestModeDataContext(ecId.Value, DataContextMode.Test, TreeViewMode.Control, true);

When above code is used to capture data for large web pages memory gets piled up and not released even when Release Data Context is called.

One point machine gets hanged up.

From the unicode spec: https://www.unicode.org/versions/Unicode12.0.0/ch23.pdf
Section 23.5
"The primary Private Use Area consists of code points in the range U+E000 to U+F8FF"

Such codepoints cannot be rendered by speech synthesizers or Braille displays because the meaning of any codepoint in the range is private.

Rules should be created to detect such characters in the UIA Name, HelpText, and LocalizedControlType properties; and any other properties where a speech synthesizer or Braille display might be used to convey content to a user.

Please check whether the bug has already been filed.

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Actual behavior
What actually happened.

Screenshots or .GIF
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. Windows 10 1809] (Get the version by running winver from the command line)
• Accessibility Insights for Windows Version:
• Target Application: [e.g. Chrome, Wildlife Manager]
• Target Application Version: [e.g. 22]

Additional context
Priority requested -
Add any other context about the problem here.

Please check whether the bug has already been filed.

Describe the bug
Tests from SystemAbstractionsTests.dll are not running in the build loop.

To Reproduce
Steps to reproduce the behavior:

1. Open the results of a build loop (I tried both PR builds and official builds)
2. Open the test results
3. Search for any of the following unit tests
   • RegistryGetValue_Matches
   • CreateDirectory_CreatesDirectory
   • CurrentDirectory_Matches
   • DateTime_Matches
   • DirectoryExists_ReturnsExpected

Expected behavior
Unit tests should be executing

Actual behavior
Unit tests do not execute. There is, however, the following message in the logs:
[MSTest][Discovery][d:\a\1\s\src\SystemAbstractionsTests\bin\Release\netcoreapp2.1\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.dll] Unable to load types from the test source 'd:\a\1\s\src\SystemAbstractionsTests\bin\Release\netcoreapp2.1\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.dll'. Some or all of the tests in this source may not be discovered.
[MSTest][Discovery][d:\a\1\s\src\SystemAbstractionsTests\bin\Release\netcoreapp2.1\SystemAbstractionsTests.dll] Unable to load types from the test source 'd:\a\1\s\src\SystemAbstractionsTests\bin\Release\netcoreapp2.1\SystemAbstractionsTests.dll'. Some or all of the tests in this source may not be discovered.
[MSTest][Discovery][d:\a\1\s\src\packages\MSTest.TestAdapter.1.4.0\build\netcoreapp1.0\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.dll] Unable to load types from the test source 'd:\a\1\s\src\packages\MSTest.TestAdapter.1.4.0\build\netcoreapp1.0\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.dll'. Some or all of the tests in this source may not be discovered.
[MSTest][Discovery][d:\a\1\s\src\packages\MSTest.TestAdapter.1.4.0\build\uap10.0\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.dll] Unable to load types from the test source 'd:\a\1\s\src\packages\MSTest.TestAdapter.1.4.0\build\uap10.0\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.dll'. Some or all of the tests in this source may not be discovered.

Additional context
These unit tests work as expected (meaning they are discovered and run successfully) when run locally

Is your feature request related to a problem? Please describe.

Not really a feature, but writing test results does take some time. Usually it doesn't really make a difference, but if there are hundreds of test runs, this might make a difference.

Describe the solution you'd like

This is where it becomes a bit difficult. Currently an empty path is being replaced with a default path, setting the FileFormat to "None" still creates files (I think). The scanner factory could expose a function that skips the creation of the file helper entirely, something like "BuildNoFileLogging". However having the configuration object still have the filepath and fileformat property might look a bit weird.

Describe alternatives you've considered

None yet as this isn't a big issue. It would be nice to have.

Additional context

Please check whether the bug has already been filed.

Describe the bug
Axe.Windows will throw an exception if it tries to open an A11yTest file with an unknown RuleId. This most typically happens when opening an A11yTest file generated by a newer version of Axe-Windows.

To Reproduce
Steps to reproduce the behavior:

1. Scan an app using AIWin version 1.1.911.1 (https://github.com/microsoft/accessibility-insights-windows/releases/tag/v1.1.0911.01/AccessibilityInsights.msi). This uses Axe.Windows 0.2.0, and includes a new rule.
2. Save the A11yTest file
3. Open the A11yTest file in AIWin version 1.1.883.1 (https://github.com/microsoft/accessibility-insights-windows/releases/tag/v1.1.0883.01/AccessibilityInsights.msi). This uses Axe.Windows 0.1.0.
4. The file refuses to load. If you run in the debugger, it's throwing an exception from the rule that was added in Axe.Windows 0.2.0 (but does not exist in Axe.Windows 0.1.0)

Expected behavior
The file should open and display the results.

Desktop (please complete the following information):

• OS: Windows 10 1903

Additional context
Having the RuleId in the A11yTest file is no longer needed. Now that the RuleResult includes all of the details about the rule, we should be able to simply remove the RuleId from the A11yTest file. I've confirmed that Production versions of AIWin (using Axe.Windows 0.1.0) can properly handle A11yTest files that omit the RuleId from the file.

The NumericUpDown control in WinForm does not support TextPattern (tracking issue). It consists of a spinner up/down control alongside an edit control showing the selected number.

This issue is to track whether this is a false positive on our end - e.g. should the NumericUpDown control be excluded from the ControlShouldSupportTextPattern check? Typing is not allowed in the control - the only way to edit the numbers is through the up/down arrow keys. (It's allowed for numbers, I had tried letters earlier). The value change is announced in NVDA, for example.

Example application:
WindowsFormsApp2.zip

Password input control in Old/ Classic Microsoft Edge (framework id: MicrosoftEdge) hosted in a Windows Universal App fails “The Name must not include the same text as the LocalizedControlType” rule.

Actual behavior

When the password input control from Old Edge is hosted in a Windows Universal App, the word 'password' is repeated in Name and LocalizedControlType resulting in violation of “The Name must not include the same text as the LocalizedControlType” rule. When the same HTML is hosted on Web, this rule is not violated as the LocalizedControlType is generated as 'edit'. This is a limitation of old Edge and this behavior will continue as long as the framework is use and the bug cannot be fixed.

Expected behavior

Update the rule so users do not encounter this as an error when password input control from Old Edge is hosted in a Windows Universal App.

Fix

If the framework is “MicrosoftEdge”, if the control type is Edit, and if IsPassword is true, the rule that tests to make sure that the Name and LocalizedControlType to be different will not be checked.

Describe the bug

The LandmarkOneMain rule checks if a page has a single main landmark (no more, no less). This maps to best-practice / moderate user impact in a similar rule in axe-core. The intent is that websites shown in browsers or WebViews should have a main landmark to ease navigation. Our rule can pick up a case where a WebView is used in a larger XAML application to show a small portion of a webpage, even if the app has a XAML main landmark of its own. Determining whether a main landmark is appropriate in these different cases should be done manually and is more of an assessment-type of test. The LandmarkOneMain rule should be changed to 'warning' to reflect this.

axe-windows version 0.3.4

We have received a report of a false positive for the BoundingRectangleNotNull rule in the case where a non-focusable button is the child of a slider. This is similar to a previous issue/exemption for the same rule, regarding WPF scroll bars. (See AI-Win issue #205.)

We should change the rule so that non-focusable buttons which are the children of sliders are exempt from the rule.

Are UWP apps supported?

I'd love to test my UWP app, where I have Selenium UITests running on the build pipeline.
When I try to integrate the package, I get this error:
NU1202: Package Axe.Windows 0.3.5-prerelease is not compatible with uap10.0.17763 (UAP,Version=v10.0.17763). Package Axe.Windows 0.3.5-prerelease supports: net471 (.NETFramework,Version=v4.7.1)

Description

We want to implement a scrollable list in our app, which has complex items (e.g. a group containing a list).
When one of the complex items is scrolled out of visible part of the app, and the Accessibility Insights tool test is being run, the inner component of the complex list item is falsely considered as having the property "IsOffScreen" set to true, although its parent does have the correct value for this property (false).
Note: This scenario was also seen when running the Accessibility Insights tool on the Windows BT devices settings page.

Similar issues:
#357
#352

To Reproduce
Precondition: Have a non-empty list in the "Other Devices" section on the Windows BT settings page.

1. Go to Windows -> Settings
2. Click on Devices -> Bluetooth & other devices
3. Scroll all the way to the top, and make sure the "Other Devices" section is scrolled out of the app.
4. Run Accessibility Insights test on the Settings window.

Expected behavior

All tests should pass

Actual behavior

The "Other Devices" group, which is scrolled off screen, has the IsOffScreen property is set to true, while one of its children (a list which is also offscreen) has the IsOfScreen property set to false.
This causes the test to fail with the error: "An onscreen element must not have a null BoundingRectangle property."

Screenshots

Desktop

• OS: Windows 10 1909
• Accessibility Insights for Windows Version: 1.1.1248.1
• Target Application: UWP

Describe the bug

Now that we've converted axe-windows to .Net Standard, the unit test projects have all been converted to .Net Core. However, we should be able to build the test projects as .Net Core and .Net Framework simultaneously. This task is a reminder to investigate and, if possible, do that.

new rule

Based on https://docs.microsoft.com/en-us/dotnet/api/system.windows.automation.automationelement.automationelementinformation.isoffscreen?view=netframework-4.8:

“If the element has a clickable point that can cause it to be focused, it is considered to be onscreen even when a portion of the element is off screen.”

Based on this, there should be two rules:

1. When an element's clickable point is on screen, its IsOffscreen property should be set to false.
2. When an element's clickable point is off screen, its IsOffscreen property should be set to true.

Please check whether the bug has already been filed.

Describe the bug

When saving to A11yElement.PlatformProperties, the Window Style and Window Extended Style are added as uints, because that's the return type declared in the P/Invoke wrapper of GetWindowLong. When fetching the values via A11yElement.GetPlatformPropertyValue, we have a mismatch between int and uint and throw an Exception, which later gets caught, but we've interrupted what we were trying to retrieve. Looking through the code, some calls to A11yElement.GetPlatformPropertyValue specify int, while others specify uint. After talking with @RobGallo, we'll standardize on int to not impact any publicly exposed interfaces.

Migrated from ai-win, see original post there

The structure rules have the following gaps:

• they run on elements regardless of whether IsControlElement or IsContentElement is true.
• unit test coverage is light on these rules
• in some cases, additional pattern guidance has been added in Microsoft documentation (example here). Our rules do not use the pattern when selecting elements to test

Because these are best-practice rules (evaluated as either Pass or Note), the user impact is not too high if the rules are unnecessarily run or scoped too loosely. However, we should be as close to the docs as possible.

We should consider making a full pass through the documentation to:

• ensure content rules and control rules only test elements if IsControlElement or IsContentElement is true
• add unit tests for each class
• where appropriate, ensure rules only test elements if the appropriate pattern exists

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Create a new Win32 window app from the regular template in VS.
2. Replace the About dlg with the following:

#include "commctrl.h"

IDD_ABOUTBOX DIALOGEX 0, 0, 170, 100
STYLE DS_SETFONT | DS_3DLOOK | DS_FIXEDSYS | WS_POPUP
FONT 8, "MS Shell Dlg"
BEGIN
    LTEXT       "Test", 2000, 10, 10, 50, 12,
    EDITTEXT    2001, 10, 30, 30, 12, WS_GROUP | WS_TABSTOP | ES_READONLY
    CONTROL     "", 2002, UPDOWN_CLASS, UDS_AUTOBUDDY | UDS_SETBUDDYINT | UDS_ARROWKEYS, 40, 30, 11, 14
END

3. Run the app and move keyboard focus to the edit area where the current updown value is shown.
4. Use AI-Win to inspect the updown control
5. Observe: AI-Win does not include the Text pattern under the "Patterns" area

Expected behavior
AI-Win report Text pattern for the updown control from Win32
This is based on: by using Inspect on the same control, the UIA IsTextPatternAvailable and IsTextPattern2Available properties are both true

Actual behavior
AI-Win does not report the Text pattern as available for the updown control from Win32

Please check whether the bug has already been filed.

Describe the bug

Starting with commit 17c1319, we're getting the following warning during PR builds and signed builds

warning : NU5128: Some target frameworks declared in the dependencies group of the nuspec and the lib/ref folder do not have exact matches in the other location. Consult the list of actions below: [d:\a\1\s\src\CI\CI.csproj]

• Add a dependency group for .NETStandard2.0 to the nuspec

According to the documentation, this is a warning that didn't exist in previous versions of NuGet and seems to be related to using the new tools. The docs also offer a couple of options to remove this warning. We should figure out how to address this warning so that our builds are as clean as possible.

This was transferred from AIWin, but the root cause is in Axe.Windows

Please check whether the bug has already been filed.

Describe the bug
UIA HeadingLevel properties are not reported in the most helpful way to AIWin users.

To Reproduce
Steps to reproduce the behavior:

1. Go to the Windows Settings app System Sound page.
2. Point the AIWin tool at the "Output" heading on the page.
3. Check the reported UIA HeadingLevel property data, "Unknown(80052)".

Expected behavior
As listed at https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-heading-level-identifiers, a HeadingLevel property value of 80052 is "Heading level 2". As such, AIWin should say something like "Heading level 2, (80052)".

Actual behavior
By saying "Unknown(80052)", it's less likely that the AIWin user will learn the heading level of the UI of interest.

Screenshots or .GIF

Desktop (please complete the following information):

• OS: Windows 10 1909, OS Build 18363.535
• Accessibility Insights for Windows Version: 1.1.1072.1
• Target Application: Settings app in Windows.

Additional context

Describe the bug

A product shows a short vertical separator, and AIWin reports its bounding rectangle as being too small.

To Reproduce

1. Create a new WPF app targeting .NET Framework 4.8.
2. Add a very short short separator.
3. Run AIWin FastPass against the app.

Expected behavior

AIWin reports that there are no failures in the programmatic representation of the separator.

Actual behavior

AIWin reports that the BoundingRectangle property of the separator must represent an area of at least 25 pixels.

Desktop (please complete the following information):

• OS: Windows 10 2004.
• Accessibility Insights for Windows Version: 1.1.1248.1

Additional context

The separator in the product provide visual assistance to some customers that two text strings are distinct, but it's not essential. As such AIWin should not be calling this a failure. Given that BoundingRectangleSizeReasonable() already seems to not report this failure for text elements, perhaps that could be extended to not report it for separators too?

Are there plans to support individual element testing?

When designing and writing new controls, would greatly benefit from an easier accessibility testing. However from what I can tell, axe-windows only supports scanning complete processes. But when writing unit tests, it would be great to be able to scan an individual control using axe-windows instead of having to embed it into an app and scan the process. So are there plans to support this?

An app creator contacted us with an AI-Web scan of an application which included web-based content displayed in Edge (original, not based on Chromium). Seemingly normal div tags are converted by Edge into UIA elements with the control type of group. But these elements have bounding rectangles which are null.
Since this is not resolvable by the end user, and not likely to be resolved in the older version of Edge, we should not show this error in the case where the bounding rectangle is null for a group inside Edge.

Is your feature request related to a problem? Please describe.

In UI tests that generate multiple a11ytest files, it is desirable to distinguish them in the resulting output. The current Config.Builder allows the user to specify a directory, but the name of the resulting .a11ytest file is determined by Axe.Windows. It would be helpful if the user could supply a file name provider to the Builder or a file name to Scan(). Currently the user needs to rename the resulting files, as we do here:

https://github.com/microsoft/accessibility-insights-windows/blob/9ea46a709b30d8d7684998fe8bba9951d38bd180/src/UITests/UILibrary/AIWinDriver.cs#L54

Describe the solution you'd like
Alongside the existing output directory method here, the config could provide a WithOutputFileName((Func<string> nameProvider) method as well.

Describe alternatives you've considered
The user can rename the returned file themselves. If the library can do this for them, it would be a bit easier.

Create a new WPF app using .NET Framework 4.8, and add a DataGrid to it. Give the column headers unique names, and populate the cells with some text which is duplicated between cells. Or just grab the demo app I built at https://account79.visualstudio.com/WPFDataGridDuplicateCellNames.

Run the app and point AIWin to the DataGrid.

Result: AIWin reports a failure relating to cells having duplicate Name and LocalizedControlTypes.

Expected: No failure should be reported given that the cells support the UIA GridItem and TableItem patterns, as as such, screen readers can announce the row and column information associated with the cells. This means customers can learn the unique meaning of each cell, even when multiple cells contain the same text.

• OS: Windows 10 1909
• Accessibility Insights for Windows Version: 1.1.1248.1
• Target Application: Test WPF app targeting .NET Framework 4.8, containing a DataGrid.

Describe the bug
When I first assembled the automation package, I included all of the dependencies (Sarif, Netwonsoft, and some System.* assemblies) directly into the package. I did it largely out of ignorance, because it seemed logical to have the files all together in one place. That also helped the PowerShell cmdlet story to flow easily. As it turns out, the recommended way to manage dependencies is simply to include them as dependencies, and allow the resolution to be handled by the app. Now that PowerShell cmdlets are going away, maybe it’s time to align with the recommended dependency handling. Here are a couple of links discussing this issue:
https://stackoverflow.com/questions/28229892/nuget-package-dependencies
https://docs.microsoft.com/en-us/nuget/consume-packages/dependency-resolution

This probably wouldn’t be part of the API spec, but it seems like we ought to have a clear story here before we get to the 1.0 release.

To Reproduce

Expected behavior

Actual behavior

Screenshots or .GIF
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. Windows 10 1809] (Get the version by running winver from the command line)
• Accessibility Insights for Windows Version:
• Target Application: [e.g. Chrome, Wildlife Manager]
• Target Application Version: [e.g. 22]

Additional context
Priority requested -
Add any other context about the problem here.

new rule

Based on https://docs.microsoft.com/en-us/dotnet/api/system.windows.automation.automationelement.automationelementinformation.isoffscreen?view=netframework-4.8:

“When the value is true for a container, it is also true for the container element's descendants.”

We should add a rule which validates this policy.

Please check whether the bug has already been filed.

Describe the bug

In this repo, there isnt a place where the rules and the WCAG/Section 508 mapping are documented

Expected behavior

A table that says the rule name, description, standard and if its a warning or a failure

Issue

False-negative result for the rule "An element's IsOffScreen property must be false when its clickable point is on screen."

Using WPF .NET 4.6.1 all hidden controls have false-negative results regarding IsOffscreen==True and ClickablePoint. It happens because, in spite of the fact that WPF returns IsOffScreen==True, it also returns some value for ClickablePoint.

According to MSDN:

If the element has a clickable point that can cause it to be focused, it is considered to be onscreen even when a portion of the element is off screen.

The main thing in the statement above is "that can cause it to be focused". But there is no way how an element can be focused if it is hidden. So, I see an incorrect implementation of this rule.

To Reproduce

<Window x:Class="IsOffscreenIssue.MainWindow" 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" mc:Ignorable="d" Title="MainWindow"
        Height="450" Width="800">
    <StackPanel>
        <Button Content="btn 1" />
        <Button Content="btn 2" Visibility="Collapsed" />
    </StackPanel>
</Window>

Expected behavior

Accessibility Insight tool mustn't report that error for hidden elements.

Actual behavior

Accessibility Insight tool reports that error for hidden elements.

Screenshots or .GIF

Desktop

• OS: Windows 10 1303
• Accessibility Insights for Windows Version: 1.1.1152.1

Additional context

Related issue: #162

Test Axe.Windows scanning against a UWP app and if so how?

Continuing conversation from #460

There are few different ways how that could be achieved. The key issue is that a UWP app needs installation. The possibilities are:

• Sideload app and try to clean up after tests
  • If something goes wrong, the machine can be left in a bad state
• Have the test run be optional, if it finds the app it runs, otherwise tests are skipped
• Similiar to the point above: Only run those tests locally
  • Issue is that in that case tests might not be run and all

Since the main thing to check is whether it is working with a UWP UI, not the UWP app, another option would be to use XAML Islands. That way, we can run an exe file that in turn starts a UWP UI that we can scan against. That way, we would be able to test against UWP UIs (and as such UWP apps) without having to deal with installation and clean up of a UWP app.

However setting up XAML islands isn't the easiest after all and the root window of the app still reports itsself as WPF framework, only the content does report itsself as using "XAML" (UWP):

So at the end of the day, this mostly boils down to what are the costs of getting it to work, and what is there to gain to test against a UWP app or UWP UIs.

Issue

There are instances where the rule which detects control type strings within Name property strings may incorrectly return an error. For example, on a site for a taylor making a suit jacket, there could be and "add a button" button. In this case, the occurrence of the word "button" in the name is correct because it is not referring to the control type.

Current state

We are keeping this bug open so users can report any other instances when they find a false-positive in this rule so we can understand better how to address it.
We welcome feedback for improving the heuristic that detects control type strings in the Name property.

Suggested improvements

• Only look for control type strings at the end of the name.
  This would avoid double speaking. However, there were real-world instances we encountered where this wasn't always the case, e.g., "'table of definitions' table".

• Only check for control type strings at the beginning and end of the name. However, this will not catch other cases like "this is an image of a flower"

• Check for commonly used phrases and the control type for example: "this is a " or " this shows a "

We will continue to refine our approach so that this rule does not produce false positives.

In the mean time, if you should encounter this error, please let us know in this bug.

The purpose of the rule is to avoid double rendering of the control type in accessible technologies such as screen readers. If the Name property contains a word or phrase which is a homonym of a control type string and which does not refer to the control's type, that may be an acceptable exemption to this rule.

Describe the bug

We exclude certain menubars/items from the BoundingRectangleNotNull check here.

In a non-English application, the automation name is localized so the 'System' string check doesn't work. We should consider solely relying on the automation id so that the automation names don't have to be identical.

Your question here

How does A11yAutomation.GetUIAutomationObject().PollForPotentialSupportedPatterns() and A11yAutomation.GetUIAutomationObject().PollForPotentialSupportedProperties() poll internally?

My use case is to inspect elements from an electron app. Using Accessibility insight for window tool, I can see the props in real-time but I want to understand that when an electron app internally loads a webpage, how does Windows get access to the dom structure?