AccessibleName default values for WinForms Controls

.NET Core Version:

.NET Core SDK (reflecting any global.json): Version: 5.0.100-alpha.1.20073.10 Commit: 29f4d693a9

Runtime Environment: OS Name: Windows OS Version: 10.0.18363 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\5.0.100-alpha1-05536\

Have you experienced this same bug with .NET Framework?: Yes

Problem description:

At this moment there is a number of issues with Accessible name:

• missing AccessibleName for some controls (for instance ComboBox or TextBox, which have null AccessibleName by default)

• term duplication in the default AccessibleName and accessible control type (UI Automation control type) localized name for other controls (like announcement “Spinner spinner” for NumericUpDown control which has “Spinner” accessible name and “spinner” en-us control type localized name)

• indistinguishability of controls to visually impaired users when announced by Narrator if there are multiple controls of same type on the form (for instance two PropertyGrid controls have same “PropertyGrid” accessible name)

Considerations The question comes with the #2818 and #2820. The issues does not fit into a requirement or an improvement. This is because the app developer is not blocked by the lack of accessible name. The standard way to associate an accessible name with a control is as follows:

• is to place a label (a control with Text property) in front of this control in the tab order. Then AccessibleObject.Name will read it;
• the next option for app developer is to actually set `myControl1.AccessibleName = “descriptive name”'. As suggested in #2820, ‘AccessibleName’ is a synonym of ‘ControlType’. ‘ControlType = Slider’; ‘AccessibleName = TrackBar’. This is not helpful, as the name should not contain ‘ControlType’. We are providing names for controls that are not exposed to the developer, ‘TrackBar’ does not fit this case.

On the opposite side, app developer may forget to set ‘AccessibleName’ or place a Label in front of a control. Anyway, an app developer can set some accessible name as an empty string if it is necessary for him. The explanation can be found in #2382.

But there are several issues with default accessible names that are synonymous to control types.

1. It does not produce accessible applications by default. Consider the following UI: Looking at the image above, do you know what value to enter into this control? What will it be used for? It seems that an AT user will not know what to do with control of type ‘Spinner’ that is named ‘“Numeric”’ because this name does not explain what value the number in the control represents. Such a name does not solve the problem that Accessible Name property is designed to solve, it does not explain business logic behind this control. This solution will not improve applications of accessibility of WinForms controls.

2. An application developer has a smaller chance to fix the above mentioned accessibility issue in this application because we suppressed Accessibility Insights (AI) error report. The suggestion here is that this is an application developer responsibility to provide meaningful ‘AccessibleName’ and responsibility of AI tool to teach the developer how to write accessible applications. Role of the WinForms developer is to provide public API that allows app developer to set a meaningful accessible name. We provide hard-coded accessible names only for UI elements that don’t expose public APIs to the app developers. Application developers should to make applications accessible. We are not enforcing keyboard shortcuts or taborder either, because these depend on the business logic.

Taking into account above considerations, we have two points here:

• AccesibleName is for application specific naming which will provide the information about the business purpose of the control.
• AccessibleDescription is also is application specific description and is not related to the control implementation.
• AccessibleControlType is for providing WinForms control type.

Like in the following example: ‘Age NumericUpDown’ where

• ‘Age’ is an ‘AccessibleName’ which should be provided by application developer and is not WinForms developer responsibility (it seems that by default an empty accessible name should be provided for both ‘Numeric’ and ‘Domain’ ‘UpDown’ controls)
• ‘NumericUpDown’ is the localized control type that is the WinForms developer responsibility as they provide the set of control types and thereby should provide localized accessible control types for each available control.

So it seems that we need to start the work here to ensure that WinForms controls API does not provide accessible names as these should be application-related business-specific accessible names and should not copy the control type name or its part to accessible name (keep it blank). And on the other hand WinForms developers need to provide meaningful localized control types for all controls.

And the result of this work should be like follows (application developers will implement accessible names in their application):

Before the fix	Control types and default empty accessible names	Controls in the custom application
“” TextBox (altready OK)	“” TextBox	“First name” TextBox (example)
“” CombBox (altready OK)	“” CombBox	“Occupation” ComboBox (example)
“Numeric” Spinner (issue)	“” Numeric UpDown	“Age” Numeric UpDown (example)
“Domain” Spinner (issue)	“” Domain UpDown	“Rating” Domain UpDown (example)
“Property Grid” pane (issue)	“” Property Grid	“Skills” Property Grid (example)

Proposed changes and expected behavior:

• Need to show error by AI if application developer does not provide business specific accessible name. So we need to make Accessible names empty for the controls exposed to developers.
• Accessible names of the controls which are not public should not be empty.

Minimal repro:

• Create the app with WinForms controls and ensure that by default Accessible names are empty and localized control types show the control type specific names.
• Accessible names can be set via control API (AccessibleName property) or by adding the label before the control.
• Control child elements should not have default accessible names or accessible names which contain control type names.

[Tanya-Solyanik]

If we remove AccessibleName default values we are further from being accessible by default than if we have an AccessibleName property that contains the localized control type.

I don’t think we are improving framework by providing default accessible names on public controls. First, we are not in a position to provide useful accessible names because we don’t know business logic behind these controls. And second, by providing a default name we disable accessibility insights warnings that would otherwise explain developer how to provide a good accessible name.

[SergeySmirnov-Akvelon]

This is fixed in scope #3676 issue.