Skip to content
This repository has been archived by the owner on Sep 5, 2024. It is now read-only.

mdDialog: user should not be able to interact outside of dialog #1340

Closed
marcysutton opened this issue Jan 29, 2015 · 11 comments
Closed

mdDialog: user should not be able to interact outside of dialog #1340

marcysutton opened this issue Jan 29, 2015 · 11 comments
Assignees
Labels
a11y This issue is related to accessibility type: bug
Milestone

Comments

@marcysutton
Copy link
Contributor

So that keyboard and screen reader users cannot get lost while a dialog is open, focus should be limited to controls within the dialog (Cancel button, Accept button, etc.). Modal dialogs should not allow the user to interact with the page behind it.

Related: clicking on the background behind an alert or confirmation dialog should not do anything.

@marcysutton marcysutton added type: bug a11y This issue is related to accessibility labels Jan 29, 2015
@marcysutton marcysutton changed the title mdDialog: user should not be able to tab outside of dialog mdDialog: user should not be able to interact outside of dialog Jan 29, 2015
@marcysutton marcysutton self-assigned this Jan 30, 2015
@marcysutton marcysutton added this to the 0.8.0 milestone Jan 30, 2015
marcysutton pushed a commit that referenced this issue Jan 30, 2015
marcysutton pushed a commit that referenced this issue Feb 5, 2015
@marcysutton
Copy link
Contributor Author

This also might require us to remove the parent option for alert/confirm dialogs. Custom dialogs could still use it.

@ThomasBurleson
Copy link
Contributor

@marcysutton - the dialog mask currently traps the outside-dialog clicks right ?

@marcysutton
Copy link
Contributor Author

@ThomasBurleson by default, yes...clicking the background is the same action as clicking the "cancel" button. But any other links on the page shouldn't be accessible.

I found the parent option is indeed necessary so that people can provide a different wrapper as a dialog target (such as a div with a CSS class on it). I'm doing two things to fix our docs:

  1. Pass parent: document.body to our demos to deal with multiple ng-apps and make modals cover the entire screen.
  2. Write docs indicating that parent should only be used on nodes that cover the entire screen.

For accessibility, I still have to disable every node that isn't the dialog so it won't be accessible from a screen reader using aria-hidden. I have focus handled already in #1350.

@marcysutton marcysutton modified the milestones: 0.9.0, 0.8.0-rc1 Feb 6, 2015
marcysutton pushed a commit that referenced this issue Feb 10, 2015
@yarl
Copy link
Contributor

yarl commented Mar 5, 2015

One more thing to add here: there should be no possibility to focus element behind dialog window using [tab] key. So basically, tab focus order should be looped inside dialog.

@marcysutton
Copy link
Contributor Author

Exactly–that's what I meant by interaction.

marcysutton pushed a commit that referenced this issue Mar 11, 2015
marcysutton pushed a commit that referenced this issue Mar 12, 2015
marcysutton pushed a commit that referenced this issue Mar 12, 2015
marcysutton pushed a commit that referenced this issue Mar 16, 2015
@kburson
Copy link

kburson commented Apr 27, 2015

Hmmm, Now the default behavior is that nothing outside the dialog is clickable. It used to be that clicking outside the dialog would 'hide' (close) the dialog, but that is no longer the case. This was functionality I was depending on. Was it a mistake to remove it?

I understand wanting to keep the focus inside the dialog, but it is also nice to close the dialog by clicking on the mask outside... now I do not have that anymore.

Can you please put this back?

Also, are you planning on a separate popover service where I can open a dialog and keep it open while I interact with the backend? This is now a requirement from the designers on my project. The 'modeless' dialog would display a list of data that would be referenced for data entry somewhere on the main page. I thought about using 'toastr' or 'mdToast', and even simply rolling my own hidden/floating div. Seems like a sort of functionality that should be included in the base framework doesn't it?

Also, since upgrading to md 0.9.0 my md-raised buttons no longer have a hover effect that 'raises' them off the page. the Demo page also is missing this. Was this a design decision? I liked that effect.

@marcysutton
Copy link
Contributor Author

Hi, I am only going to answer your dialog question–other questions need to be isolated into separate issues or asked in the Angular Material forum.

Modal dialogs are supposed to restrict user interaction to inside of the dialog–either confirm or cancel. The click outside to close functionality still exists, you just have to enable it. Look at clickOutsideToClose in the dialog service API.

@kburson
Copy link

kburson commented Apr 27, 2015

Ah, thanks, missed that.

@du6
Copy link
Contributor

du6 commented Sep 14, 2015

Hi, I still have focus problem when opening an mddialog. In the jsfiddle example (http://jsfiddle.net/4s46h476/), when you click the 'OPEN A DIALOG!' button and then click 'TAB' key, it is focused on the 'input' element behind the mddialog. Shouldn't the focus be trapped inside the mddialog only? Thanks.

@marcysutton
Copy link
Contributor Author

Yes, this is being tracked as a bug in #4105.

@du6
Copy link
Contributor

du6 commented Sep 14, 2015

Thanks for the instant response!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
a11y This issue is related to accessibility type: bug
Projects
None yet
Development

No branches or pull requests

5 participants