In older Windows and app releases, dialogs were not recognized as such. To get around this, Windows App Essentials defined a list of dialog classes for elements that should be recognized as a dialog. Starting in Windows 10 1809 (October 2018 Update), UIA6 (specifically, IUIAutomationElement9) includes a boolean to specify if a window is a dialog, allowing NVDA and other screen readers to read dialog content automatically.
When first introduced, not many apps took advantage of the boolean property. In recent years, more apps (and Windows itslef) are taking advantage of this property, making NVDA read more dialogs. Therefore the list of dialog classes has shrunk to a point where there is none as of August 2021. Therefore deprecate and remove additional diaog classes check from the global plugin portion.
The implementation will be divided into two parts:
Deprecate (nickel 1): comment out dialog check code (at the cost of tagging Dialog import with Flake8 F401 NOQA flag for now).
In case additional dialog classes must be added again, it should be done from apps themselves, or if it spans multiple apps (same class name is used), overlay class chooser is preferred. This assumes future diaog classes are not listed in classes defined in UIA handler module.
Hi,
In older Windows and app releases, dialogs were not recognized as such. To get around this, Windows App Essentials defined a list of dialog classes for elements that should be recognized as a dialog. Starting in Windows 10 1809 (October 2018 Update), UIA6 (specifically, IUIAutomationElement9) includes a boolean to specify if a window is a dialog, allowing NVDA and other screen readers to read dialog content automatically.
When first introduced, not many apps took advantage of the boolean property. In recent years, more apps (and Windows itslef) are taking advantage of this property, making NVDA read more dialogs. Therefore the list of dialog classes has shrunk to a point where there is none as of August 2021. Therefore deprecate and remove additional diaog classes check from the global plugin portion.
The implementation will be divided into two parts:
In case additional dialog classes must be added again, it should be done from apps themselves, or if it spans multiple apps (same class name is used), overlay class chooser is preferred. This assumes future diaog classes are not listed in classes defined in UIA handler module.
Thanks.