Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Accessibility] MatDialog is trapping tab key but not headings navigation shortcuts #7787

Closed
opozo opened this issue Oct 13, 2017 · 2 comments · Fixed by #9016
Closed

[Accessibility] MatDialog is trapping tab key but not headings navigation shortcuts #7787

opozo opened this issue Oct 13, 2017 · 2 comments · Fixed by #9016
Assignees
Labels
Accessibility This issue is related to accessibility (a11y) G This is is related to a Google internal issue P2 The issue is important to a large percentage of users, with a workaround

Comments

@opozo
Copy link
Contributor

opozo commented Oct 13, 2017

Bug, feature request, or proposal:

MatDialog is trapping tab key but not headings navigation shortcuts, this is actually working well on AngularJS Material [1] [2]

[1] https://material.angularjs.org/latest/demo/dialog
[2] https://github.com/angular/material/blob/master/src/components/dialog/dialog.js#L1134

What is the expected behavior?

Screen reader should trap tab key as well as headings navigation shortcuts when modal dialog is opened.

What is the current behavior?

Screen reader is not trapping headings navigation shortcuts when modal dialog is opened.

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

"@angular/material": "2.0.0-beta.12"

@crisbeto crisbeto added Accessibility This issue is related to accessibility (a11y) P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent labels Nov 28, 2017
@jelbourn jelbourn added G This is is related to a Google internal issue P2 The issue is important to a large percentage of users, with a workaround and removed P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent labels Dec 14, 2017
@jelbourn
Copy link
Member

@crisbeto escalating this since it came up from a team in Google. AFAIK the only way to do this would be to add aria-hidden to all of the non-dialog content while its open. I think we should be able to mark all of the siblings to the overlay container as aria-hidden (except for our own aria-live element and anything already aria-hidden), keeping track so we can restore them upon close.

We might also want to deal with stacked dialogs, but that's not as much as a priority.

crisbeto added a commit to crisbeto/material2 that referenced this issue Dec 16, 2017
Hides all non-overlay content from assistive technology by applying `aria-hidden` to it. This prevents users from being able to move focus out of the dialog using the screen reader navigational shortcuts.

Fixes angular#7787.
crisbeto added a commit to crisbeto/material2 that referenced this issue Dec 18, 2017
Hides all non-overlay content from assistive technology by applying `aria-hidden` to it. This prevents users from being able to move focus out of the dialog using the screen reader navigational shortcuts.

Fixes angular#7787.
crisbeto added a commit to crisbeto/material2 that referenced this issue Dec 18, 2017
Hides all non-overlay content from assistive technology by applying `aria-hidden` to it. This prevents users from being able to move focus out of the dialog using the screen reader navigational shortcuts.

Fixes angular#7787.
crisbeto added a commit to crisbeto/material2 that referenced this issue Dec 21, 2017
Hides all non-overlay content from assistive technology by applying `aria-hidden` to it. This prevents users from being able to move focus out of the dialog using the screen reader navigational shortcuts.

Fixes angular#7787.
jelbourn pushed a commit that referenced this issue Jan 4, 2018
…9016)

Hides all non-overlay content from assistive technology by applying `aria-hidden` to it. This prevents users from being able to move focus out of the dialog using the screen reader navigational shortcuts.

Fixes #7787.
jelbourn pushed a commit to jelbourn/components that referenced this issue Jan 8, 2018
…ngular#9016)

Hides all non-overlay content from assistive technology by applying `aria-hidden` to it. This prevents users from being able to move focus out of the dialog using the screen reader navigational shortcuts.

Fixes angular#7787.
jelbourn pushed a commit to jelbourn/components that referenced this issue Jan 9, 2018
…ngular#9016)

Hides all non-overlay content from assistive technology by applying `aria-hidden` to it. This prevents users from being able to move focus out of the dialog using the screen reader navigational shortcuts.

Fixes angular#7787.
jelbourn pushed a commit that referenced this issue Jan 9, 2018
…9016)

Hides all non-overlay content from assistive technology by applying `aria-hidden` to it. This prevents users from being able to move focus out of the dialog using the screen reader navigational shortcuts.

Fixes #7787.
tinayuangao pushed a commit that referenced this issue Jan 10, 2018
…9016)

Hides all non-overlay content from assistive technology by applying `aria-hidden` to it. This prevents users from being able to move focus out of the dialog using the screen reader navigational shortcuts.

Fixes #7787.
@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 8, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Accessibility This issue is related to accessibility (a11y) G This is is related to a Google internal issue P2 The issue is important to a large percentage of users, with a workaround
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants