search

microsoft / accessibility-insights-windows

Accessibility Insights for Windows
https://accessibilityinsights.io
Other
430 stars 102 forks source link

[General Question] pass an AI4Win test of a win32 dialog using an ip address control #1838

Closed skuskusku closed 2 months ago

skuskusku commented 5 months ago

How to provide unique names for sibling controls in a win32 ip address control I don't know if this is a bug or behaviour I have to live with, but anyway, here it goes: I have a native win32 application that uses the ip address control from comctl32. If i run a test with AI4Win the ip address control gets the name shown in AI4Win from its preceding static text label and its control type is shown as "pane". AI4Win shows 4 subitems of type "edit" as children of this pane, each of which stands for one octet of the IP address shown in the ip address control and all 4 subitems have as their name the name of their parent element of type "pane", which itself got its name from the preceding static text label. Now AI4Win flags all 4 of those edit controls with an error, namely: "Focusable sibling elements must not have the same Name and LocalizedControlType" and as a suggestion for a fix: "Provide unique names for sibling controls that have the same ControlType property.". Those four octets are sibling edit elements all with the same name. I already tried to override get_accName for the ip address control, having the idea that I could return different strings for different lVal values of the variant type sent to get_accName, such as "highest octet value of the ip address", "second highest octet value of the ip address" and so on. But unfortunately, the lVal value of the variant type sent to get_accName is always 0 (CHILDID_SELF).

So my question is: What should I do to pass an AI4Win test of a win32 dialog using an ip address control? Is it possible at all? Is this maybe a false positive in AI4Win?

Any help appreciated,

-- Stefan

skuskusku commented 5 months ago

my apologies for not being able to give this question a meaningful subject title, I found no way to edit this.

codeofdusk commented 3 months ago

Thanks for reporting this issue! We're actively working toward a solution, but in the meantime, you can safely ignore this failure on IP address controls.

codeofdusk commented 2 months ago

Firstly, our sincerest apologies for the delay in getting this sorted.

Secondly, the latest production release (v1.1.2829.01) has downgraded this rule to "uncertain" on Win32 controls due to the high number of false positives reported.