List options under 'Type filter' button are not accessible by keyboard: A11y_.NetAspireDashboard_Resource_Filter_Keyboard.

[PoojaNamde]

"Check out Accessibility Insights! - Identify accessibility bugs before check-in and make bug fixing faster and easier."

Please do not close this bug. This bug should only be closed by Trusted Tester after verification.

Tags:

A11yTCS; #A11yMAS; #A11ySev2; #Win11; #ChromiumEdge; #FTP; #DesktopWeb; #.NET Core; #SH_.Net Aspire Dashboard_Web_Mar2024; #WCAG2.1.1; #Keyboard;

Environment Details:

Application Name: .Net Aspire Dashboard URL: https://localhost:19888/ Chrome Version 122.0.2365.80 (Official build) (64-bit) Window Version: Win 11 OS Build: 22621.3085

Repro Steps:

1. Hit the URL: http://localhost:15888/
2. TAB to "Resources" tab item and hit select the tab by pressing Enter key.
3. Tab through the page and check if 'Filter' edit box is accessible by keyboard.

Actual Results:

List options under 'Type filter' button are not accessible by keyboard.

Expected Results:

List options under 'Type filter' button should be accessible using keyboard TAB/ arrow keys.

User Impact:

Keyboard users will not be able to interact with the control and will miss the information regarding it.

Attachment:

https://github.com/dotnet/aspire/assets/90901519/00f7c525-4684-4207-9170-e5614ae70ee1

[adamint]

This is very hard to workaround. @vnbaaij am I correct that this is a bug on FluentPopover?

[adamint]

Waiting on 4.6.1 release of fluentui-blazor: https://github.com/microsoft/fluentui-blazor/pull/1800

[adamint]

@kvenkatrajan the testers ask that they close issues, not us. @PoojaNamde

[adamint]

@PoojaNamde could you please re-test? Thank you.

[adamint]

@PoojaNamde

[SwatiJo]

@adamint It should be navigable using up and down arrow keys

[adamint]

Yes @SwatiJo could you re-test and close this bug? We updated a package that should have fixed this issue.

[SwatiJo]

@adamint Can you please share link to the package where this issue is fixed?

[adamint]

It is fluentui-blazor, but you can re-test with the main branch here. @SwatiJo

[SwatiJo]

@adamint Retested this issue on main branch. Options under dropdown are navigable with left arrow key but that is not correct navigation, when dropdown opens, focus should move to dropdown and then options inside dropdown should be navigable using up and down arrow keys.

[dotnet-policy-service[bot]]

This submission has been automatically marked as stale because it has been marked as requiring author action but has not had any activity for 14 days. It will be closed if no further activity occurs within 7 days of this comment.

[kvenkatrajan]

I have removed the "needs-author-action" from the a11y bugs since this is moved to stale and closed automatically with no author action.

[adamint]

@kvenkatrajan this isn't a resolved issue

[adamint]

@dvoituron @vnbaaij do you know why your popover navigation PR isn't working for us?

[vnbaaij]

As @tlmii already mentioned in the merged PR:

The keyboard keys needed are a little awkward - once you open the popover by hitting space you need to hit the left arrow to move back through the checkboxes. But it does work.

This is how it works in the web component. We can't change that on the Blazor side.

Although I agree the solution is not hte greatet /most optimal, I don't believe there is anything in the a11y standards that actually describes with what keys things are exactly supposed to work with.

[adamint]

We were just told by @SwatiJo that this still constitutes a sev2 accessibility issue as the new behavior is not discoverable or correct. @SwatiJo how do we route this to the web components team?

@vnbaaij

[kvenkatrajan]

@kvenkatrajan this isn't a resolved issue

This had a Needs-author-action tag. If its marked with this tag, it would be auto closed with inactivity (which is what we want to avoid hence moved it to a11y-resolved status instead). Please go ahead and review all a11y-resolved items and remove tag if not resolved and requires additional remediation. thanks!

[vnbaaij]

We were just told by @SwatiJo that this still constitutes a sev2 accessibility issue as the new behavior is not discoverable or correct. @SwatiJo how do we route this to the web components team?

@vnbaaij

An issue needs to be created in the microsoft/fluetui repo. It needs to be made clear that this targest the web-components-v2 branch (https://github.com/microsoft/fluentui/tree/web-components-v2/packages/web-components).

[SwatiJo]

@vnbaaij @adamint @PoojaNamde

1. Mark the bug resolved/done with justification on why the bug is external.
2. Assigns to tester with notes where to route the bug, and who to file it for

Here is the external bug process - https://microsoft.sharepoint.com/teams/cea11y/SitePages/External-Bug-Process.aspx

[adamint]

We were just told by @SwatiJo that this still constitutes a sev2 accessibility issue as the new behavior is not discoverable or correct. @SwatiJo how do we route this to the web components team? @vnbaaij

An issue needs to be created in the microsoft/fluetui repo. It needs to be made clear that this targest the web-components-v2 branch (https://github.com/microsoft/fluentui/tree/web-components-v2/packages/web-components).

@PoojaNamde please follow these instructions, noting that this affects the Popover comment. We will need to add this to conformance documentation.

[dvoituron]

@vnbaaij @adamint @SwatiJo Sorry, I was off yesterday. I think that we worked on this "feature" a few weeks ago, to find a workaround in the FluentUI-Blazor lib (PR 1800).

After checking, your problem seems to be due to using this FluentPopover in a FluentToolbar (which seems to take precedence over the JS parts added in this PR 1800). A small workaround for your case could be to replace the "toolbar" with a "stack" and add a style to have the same visual.

<style>
    .toolbar {
        padding: var(--layout-toolbar-padding);
        grid-area: toolbar;
    }
</style>

<FluentStack role="toolbar" Class="toolbar"> ... 

Example using only keys to navigate.

[dvoituron]

After some further research, it seems that the web component fluent-toolbar changes all sub-elements with tabindex="-1", except the one it's on. And that it overloads the passage from one element to another via the arrows.

So, moving the FluentPopover should resolve that. See the PR #4243.

[SwatiJo]

@adamint @kvenkatrajan Tested on Version: 8.1.0-dev , issue has been fixed. @PoojaNamde please close this bug. NoRepro_TypeFilterButton.webm

[PoojaNamde]

Closed; Issue is fixed as per above comment.