♿ Router: Focus element after URL hash scroll into view navigation

[MrGrigri]

♿ feature request

Add a flag for the Router Module to accept a flag to enable focusing of the element to which it is scrolled. In a previous issue (#6595) it was discussed that a feature request is needed to handle this issue.

This feature is required for Accessibility to work properly.

Relevant Package

@angular/router/ExtraOptions

Description

This feature is required for Accessibility to work properly. The anchorScrolling router option works...however, according to the HTML Standard Spec, Navigate to a Fragment, the last step is:

Move the sequential focus navigation starting point to [the] target.

Describe the solution you'd like

Add a parameter for ExtraOptions as anchorFocus with the boolean type attached and false as the default

export interface ExtraOptions {
  ...
  anchorScrolling?: 'disabled' | 'enabled',
  anchorFocus?: boolean,
  ...
})

This could be achieved by dynamically setting a tabindex of '0' on the targeted element, focusing on that element, then setting the tabindex to '-1'. If a tabindex is already set to '0', then just focus on the element.

[AlekNiebla]

Hey can I work this issue?

[AlekNiebla]

Hey can I work this issue?

hey im not gonna take on this issue

[danielnixon]

This is one of the issues I'm tackling in https://github.com/oaf-project/oaf-angular-router

[jasonaden]

Thanks for the issue. This would be a good one to get fixed. Thanks for taking a look @danielnixon .

[zelliott]

Quickly chiming in, I don't think the proposed solution (reproduced below) is what we want:

This could be achieved by dynamically setting a tabindex of '0' on the targeted element, focusing on that element, then setting the tabindex to '-1'. If a tabindex is already set to '0', then just focus on the element.

We don't want to set focus on the target element, we want to move the sequential focus navigation starting point to the target. There's likely some logic in Angular's router (I'm super unfamiliar with Angular's router) that's preventing the browser from correctly doing this.

[MrGrigri]

@zelliott, according to the spec, the element needs to be focused on for accessibility reasons.

[zelliott]

Sorry, I misread the spec, thanks.

However, after reading the spec, I still don't think the proposed solution is quite what we want. The target element should not be focused. Instead, it should have the focusing steps run on it. The difference is that if the target element is not focusable, it is not focused. Maybe a bit pedantic, but thought it'd be worth clarifying here.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}