Blazor Desktop tenets: Accessibility

[Eilon]

• Check compatibility with screen readers
• Check keyboard navigation such as tab key into and out of the WebView
• Check automation metadata, e.g. AutomationAttribute in WPF
• Need to review guidance from docs of each native WebView component for any best practices

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[MackinnonBuck]

@Eilon @mkArtakMSFT I've investigated each of the items above and documented my findings below.

Check compatibility with screen readers

The BlazorWebView control in MAUI, WPF, and Windows Forms respects accessibility attributes like aria-label (the screen reader reads the label value).

Check keyboard navigation

Following is the behavior exhibited by each platform:

• The BlazorWebView WPF control respects TabIndex and IsTabStop as of BlazorWebView WPF tab navigation improvements #7742.
• The BlazorWebView Windows Forms control also respects TabIndex and IsTabStop. However, when shift+tabbing backwards out of the WebView, focus loops back around to the last element in the WebView. I spent a few minutes investigating this, and there doesn't seem to be an obvious reason why it happens, so further investigation is necessary. Tabbing forward out of the view works as expected.
• The BlazorWebView MAUI control does not support TabIndex and IsTabStop because those properties have been removed from MAUI: [Spec] Remove TabIndex and IsTabStop properties #1646. However, the WebView contents do respect the HTML tabindex attribute and tab navigation works as expected.

Check automation metadata

Using Accessibility Insights for Windows, we see automation properties appear to be correctly populated for elements in the BlazorWebView. I've verified this in MAUI, WPF, and Windows Forms. Here's a screenshot of the automation properties for a button in a WPF BlazorWebView:

The same automation properties are discovered on the other platforms.

Review WebView2 component guidance

The WebView2 developer guide contains general usage guidance that I've reviewed and assessed. However, after evaluating each of the items mentioned in that article, I realized that none of them had significant accessibility implications. It may still be useful to review these findings offline, but I've left them out of this comment to not distract from the purpose of this issue.

Next steps

• Determine if the Windows Forms BlazorWebView backwards tab navigation behavior is a bug that deserves its own tracking issue. Update: Issue created here
• Review findings relating to WebView2 usage that don't have direct accessibility implications.

[MackinnonBuck]

Closing this issue, as follow-up items relating to the original issue comment have been addressed.