-
Notifications
You must be signed in to change notification settings - Fork 350
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
Question: Modal Dialog - Mouse click overlay close #1615
Comments
@LaurenceRLewis |
Yes. And it works for the datepicker example, but not for the other dialog examples (dialog, alertdialog). Typical for modal dialog is a close button in the upper right corner. This allows the modal dialog to be closed quickly without scrolling the page, as is sometimes the case here. It is true that modal dialogs can often be closed by clicking outside the dialog. But this is not always the case. I wonder if this is a good practice. Maybe someone clicks accidentally and the dialog is closed, although this was not intended. I tend to think that it is better that the dialog cannot be closed in this way because it encourages operating errors. So I would be in favor of implementing a close button in the upper right corner, but not the possibility to close the dialog by clicking outside |
@mcking65 yes Clicking on the inert background outside of the modal. |
@JAWS-test a close button contained inside the modal dialog bounds is a given. The default behaviour on iOS for popups is they close when the user taps the surrounding background. I advocate that the same mouse click/tap behaviour works the same for modal dialog, where a click or tap on the inert background closes the modal. |
Discussion in TF meeting:
|
The ARIA Authoring Practices (APG) Task Force just discussed The full IRC log of that discussion<MarkMccarthy> TOPIC: Modal dialog questions<MarkMccarthy> mck: we have a couple issues out there, but there are 2 that are pressing <Jemma> https://github.com//issues/1615 <Jemma> dialog issue <MarkMccarthy> Matt_King: issue 1615 - saying our dialogs don't close when you click outside of them... not sure if this was itentional or an oversight <MarkMccarthy> Matt_King: seems like we should just make it part of the implementation <MarkMccarthy> sarah_higley: i also noticed these don't have close buttons...so lets add both. there's a cancel button but not a close button <MarkMccarthy> Matt_King: seriously?! <MarkMccarthy> sarah_higley: i know! <MarkMccarthy> Matt_King: well last time we checked on these, it was more about technical issues related to iphones, so that's fair I guess. good catch Sarah! <carmacleod> https://w3c.github.io/aria-practices/#dialog_modal <MarkMccarthy> Matt_King: so we'll add close button AND that. <MarkMccarthy> ZoeBijl: well i have some conflicts about it. if you click outside of the modal, is the data you already put in saved? or deleted? <MarkMccarthy> sarah_higley: it should be saved <MarkMccarthy> ZoeBijl: yes, but is that what people will do? not sure this is the place to do that <MarkMccarthy> Matt_King: so then in that case, is "cancel" different than "close"? <MarkMccarthy> ZoeBijl: doesn't WCAG say... <MarkMccarthy> Matt_King: right, easy undo would cover that <MarkMccarthy> ZoeBijl: what i find (elsewhere) is that i'd click outside it accidentally and it wouldn't save the data - it's frustrating! <MarkMccarthy> Matt_King: so there's a couple choices - have the X icon for mouse users, and have that exactly duplicate the cancel button. OR distinct functionality where "close" doesn't remove the data but "cancel" does <MarkMccarthy> Jemma: yep, and they each have their own tab stops <MarkMccarthy> Matt_King: right <MarkMccarthy> MarkMccarthy: +1 <MarkMccarthy> sarah_higley: another possibility is to get rid of cancel entirely and just change it to a close button <MarkMccarthy> Matt_King: i like that too! <MarkMccarthy> Jemma: yeah! <MarkMccarthy> Matt_King: maybe we'll have to look at the project to make sure we're covering all bases, but that make sense <MarkMccarthy> MarkMccarthy: i think that's a better UX <MarkMccarthy> Matt_King: yeah, less complexity <ZoeBijl> For the minutes, this is the WCAG criteria that Matt and I were discussing: https://www.w3.org/TR/WCAG21/#error-prevention-legal-financial-data <MarkMccarthy> thank you zoe! <MarkMccarthy> Matt_King: so then, any objections to removing the cancel button and replacing with a close icon/button in the upper right? <MarkMccarthy> Jemma: and saving the data? <MarkMccarthy> s/thank you zoe!/thank you Zoe! <MarkMccarthy> [no objections] <MarkMccarthy> Matt_King: [committing the actions to an issue] <MarkMccarthy> Matt_King: our actions are in a comment in issue 1615! <MarkMccarthy> github: https://github.com//issues/1615 |
If both clicking outside the dialog and clicking the x button retain the field values, then there's no way for the user to cancel if they want to? So maybe add x button, but keep cancel button? In case it's useful, here's an article with some design thoughts about close/cancel in dialogs: https://www.nngroup.com/articles/cancel-vs-close/ |
Is there any HTML/ARIA guidance around a clickable background overlay div? Should the overlay have a |
I've been looking as well for the answer and here are my findings:
|
Closing a modal dialog by clicking (or tap) on the modal overlay is a common function.
What was the reason behind the APG modal dialog not including this behaviour.
Thank you.
The text was updated successfully, but these errors were encountered: