-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Not able to set a heading level when using WPF textblock control. #1825
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Its the first I'm hearing of "heading levels" for text, is this a new concept? How does it map in other UI frameworks like WinForms and WinUI, does it work out of the box there? In particular you'll want to coordinate with WinUI since its also XAML based and there is desire to keep concepts aligned instead of drifting apart further. |
Check out https://docs.microsoft.com/en-us/windows/uwp/design/accessibility/landmarks-and-headings. This shows how one can indicate heading levels and landmarks on text in UWP. |
Is this issue got fixed and by when can we expect this release available to developer community... We are also facing this issue and need a fix as it is causing problem to Accessibility challenged users for the apps developed using WPF XAML. Thanks, |
@adarshrema @vedeevi Changes are there in the latest release, hence marking it as closed. |
.net core version 4.7.2
Description: Accessibility Insights for Windows uses the WPF textblock control in various parts of the application. As heading level cannot be associated to textblock control and exposed to Assistive Technologies, a user using screen reader is unable to understand the logical structure of the screen.
Application: Accessibility Insights for Windows, download from:
https://github.com/microsoft/accessibility-insights-windows/releases/download/v1.1.0933.01/AccessibilityInsights.msi
Environment details:
Application Name: Accessibility Insights for Windows, Version: 1.1.933.1
Windows Version: Windows10
Screen Reader: Narrator, NVDA (Version: 2019.1.1)
Repro steps:
Actual behavior:
When screen reader users navigate to the “Settings” text it is not announced as header to them. Similarly, for the texts such as “shortcuts”, “Selection type”, “Other Options”, “Telemetry”.
This issue is observed in both the screen readers i.e. NVDA and Narrator.
Similar issue is observed in the below scenarios:
Open Accessibility insight for Windows application. -> 'Inspect Home' screen will appear. -> Go to left hand side navigation bar and select "Setting" Tab. -> Navigate to What's New tab item and hit enter. -> 'What's New' screen will appear. -> Verify all the elements of 'What's New' screen are accessible and MAS Compliant.
Open Accessibility insight for Windows application. -> 'Inspect Home' screen will appear. -> Go to left hand side navigation bar and select "Setting" Tab. -> Navigate to 'About' tab item and hit enter. -> 'About' screen will appear. -> Verify all the elements of 'About' screen are accessible and MAS Compliant.
Open Accessibility insight for Windows application. -> 'Inspect Home' screen will appear. -> Go to left hand side navigation bar and select "Setting" Tab. -> Navigate to 'Connection' tab item and hit enter. -> Select Azure Boards radio button. -> 'Connection Azure Boards' screen will appear. -> Verify all the elements of 'Connection Azure Boards' screen are accessible and MAS Compliant.
Expected behavior:
The " Settings” text should be announced as a header to the screen reader users.
User Impact:
If a certain text which appears as a header is not announced to the screen reader users as a header then the screen reader users might not understand the structure of the content.
MAS reference: MAS 2.4.6
The text was updated successfully, but these errors were encountered: