As soon the "Create movies" page open, keyboard focus starts from outside of the page which is incorrect: A11y_ASP.NET_Movies_Create Movies_Keyboard

[PoojaNamde]

GitHub Tags:

A11yMAS; #A11yTCS; #A11ySev2; #BM_ASP.NET_Web_Jun2024; #.NETCore; #WCAG2.4.3; #DesktopWeb; #Win11; #FTP; #Keyboard; #ChromiumEdge;

Environment Details:

App name: ASP.NET Window Version: Win 11 OS Build: 22621.3085

Repro Steps:

1. Download the "BlazorWebApp" zip file and run .exe file.
2. Command prompt will open, TAB to "http://localhost:5000/" link and press CTRL + ENTER key.
3. TAB to "Movies" tab and hit ENTER key. TAB to "Create New" button and hit ENTER key.
4. Navigate using TAB key and observe the issue.

Actual Result:

As soon the "Create movies" page open, keyboard focus starts from outside of the page which is incorrect.

Similar issue is observed in throughout the "BlazorWebApp" and "BlazorWebAppUnchanged" template when we open any link.

Expected Result:

As soon the "Create movies" page open, keyboard focus should not start from outside of the page. When page opens keyboard focus should starts from first interactive control present in the page.

User Impact:

Keyboard users will face difficulty while navigating using keyboard keys, they will have to navigate using multiple TAB keys to reach out to the control.

Attachment

https://github.com/dotnet/aspnetcore/assets/90901519/f6703757-73ae-43b9-bc4c-6be456222e13

[siyandand1]

The keyboard focus issue on the "Create movies" page in BlazorWebApp is critical for accessibility. It should start correctly at the first interactive element upon page load to ensure smooth navigation for keyboard users. I'm currently looking into this issue to address it promptly.

[Yash14j]

GithubTags:#Rev:yaja;

[MackinnonBuck]

One potential solution might be to add support for <FocusOnNavigate> (see https://github.com/dotnet/aspnetcore/issues/52412) when using static routing. However, this would by default bring focus to the <h1> element (in this case, the "Create" header) instead of the first interactive input.

@PoojaNamde, how critical is it that the first input receives initial focus? Is it acceptable from an accessibility standpoint to focus the header instead?

[PoojaNamde]

@MackinnonBuck "Create new" button should be receiving the focus.

[MackinnonBuck]

@PoojaNamde, your suggestion in the issue was to make the first interactive control in the "Create" page receive focus after clicking the "Create new" button. That element is the "Title" input text box. My proposal is to instead bring focus to the "Create" heading at the top of the page. The user will then have to press TAB only once to reach the "Title" input box.

One problem with bringing focus directly to the "Title" input text box is that the screen reader will not read the "Create" heading. This concern is mentioned in the "Accessibility concerns" section of this document, although I'm not sure if there's an analogous section of the WCAG.

Would this issue be resolved if, instead of focusing on the "Title" input text box, focus was moved to the "Create" heading?

[PoojaNamde]

@MackinnonBuck sorry for confusion. Yes it will be great if focus starts from "Title".

[PoojaNamde]

Closed; #Regressed:09-20-24;

Verified the bug in environment http://localhost:5000/Account/[Register](http://localhost:5000/Account/Register) Bug is fixed and does not repro. Hence closing the bug. Please find the closing attachment

56287_Closed.zip