bug(sidenav/drawer/focustrap): over/push mode results in Serious a11y issue

[drc-nloftsgard]

The previous version in which this bug was not present was

No response

Description

When using mat-sidenav or mat-drawer with mode over or push (and might need backdrop=true) there is a div element: <div class="cdk-visually-hidden cdk-focus-trap-anchor" aria-hidden="true"></div> which gets tabindex="0" added to it when the sidenav/drawer is opened. This causes an a11y finding (see below) because aria-hidden="true" elements should not be focusable.

Reproduction

StackBlitz link: https://stackblitz.com/edit/e4bsuu?file=package.json StackBlitz was forked from the second example here: SideNav Examples Steps to reproduce:

1. Select Sidenav mode: Over, Has backdrop
2. Click Toggle drawer button
3. Via axe DevTools run a new scan of the page

Expected Behavior

No a11y isssues

Actual Behavior

2 instances of a 'Serious' issue found via Axe: 'ARIA hidden element must not be focusable or contain focusable elements'

Related to the focus trap elements(s): <div class="cdk-visually-hidden cdk-focus-trap-anchor" aria-hidden="true" tabindex="0"></div>

Reference doc: Axe 4.7 aria-hidden-focus contains examples and possible solutions.

Environment

• Angular: 16.1.1
• CDK/Material: 16.2.0
• Browser(s): Chrome
• Operating System (e.g. Windows, macOS, Ubuntu): MacOS

[crisbeto]

In practice this isn't a problem for users, because as soon as the element receives focus, it forwards it to the first focusable element inside the sidenav.

[drc-nloftsgard]

In practice this isn't a problem for users, because as soon as the element receives focus, it forwards it to the first focusable element inside the sidenav.

Is there any alternative solution that would be compliant with WCAG standards?

• Does tabindex have to be 0? Could it be -1?
• Could hidden, display or visibility be used instead of aria-hidden?
• Any other ideas?

[zarend]

Hello,

We generally consider issues that are a problem for end users.

Angular Material does not have a hard requirement that we cleanly pass AXE accessibility checks, and we have made no commitment to pass accessibility checks. We prioritize accessibility issues that have a reason why they are not meeting accessibility criteria, such WCAG. We also consider issues that are a problem for end users.

Actual Behavior 2 instances of a 'Serious' issue found via Axe: 'ARIA hidden element must not be focusable or contain focusable elements'

Closing as working-as-intended, since there is no requirement to pass Axe checks. I believe this axe failure is a false positive, and sometimes we add work-arounds for specific AT that causes Axe checks to fail.

If there is a problem affects users, please file a new issue report to describe it and how it affects users.

Is there any alternative solution that would be compliant with WCAG standards?

I believe we're compliant, but if there is a WCAG criteria that we are failing, please file and issue report and list that criteria.

Best regards,

Zach

[zarend]

@drc-nloftsgard I believe the Drawer/Sidenav component still uses the deprecated FocusTrapFactory. As an alternative, you can inject ConfigurableFocusTrapFactory, which is newer and has tested for accessibility. IIRC ConfigurableFocusTrapFactory will still give an axe violation, but I don't remember which violation.

I've filed #27629 for MAtDrawer using deprecated FocusTrap

[angular-automatic-lock-bot[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.}