They do pick up the "title" attribute sometimes and apply it as a label. But it's not really the same as being able to keyboard navigate to the browser-generated tooltip.
Ex-Apple. Ex-Google. Creative technologist with extensive experience building for the web platform. Focused on crafting accessible, user-friendly digital products and tools.
> For instance, the Esc key does not close non-modal dialogs by default
Modal dialogs are the ones that pop up on the screen and take over the main experience. Those come with escape key. I think you have to program the click-away with JavaScript however.
Non-modal dialogs are uncommon, but basically they are more like menu pop-ups that can be ignored when open, so no need for escape key.
I was recently refactoring the dialogs at work where I inherited a codebase with a few different custom implementations of equally many dialogs. Some of those had the click outside handler closing the dialog, others didn’t. So I went outside to the world wide web to see how other apps do this to pick one consistent experience.
What I saw is there is no consensus on whether clicking outside should close a modal dialog or not. A menu dialog, sure, but a modal dialog was all over the place.
I went with not closing on outside press. My reasoning is that perhaps the user had filled up some form or done some other stateful interaction with the dialog’s content, and then clicked outside on accident (perhaps missed the submit button because their mouse was jerked around, or they are on a very small touch-screen) that would be annoying to have to reopen the dialog and re-enter those values.
I would ask to save the state locally (while the tab/window is still open) but allow clicking outside to close the dialog. finding the hidden x or cancel is sometimes hard, but it's easy to click/tap outside the window.
While this is certainly an option, quite often users expect to start with a clean slate when they open a new dialog. In this case you can only pick one. Give the user an extra convenient way to dismiss the dialog, but doing so, risk surprising them when they open the dialog the second time.
Me, I opt for the no surprise and make sure the top x-mark is nice and clickable, as well as a cancel button after a submit button, and make sure the escape key also works for users with easy access to physical keyboards.
<font> provides no structural or accessibility information. It was only there for styling purposes.
<dialog> provides structural and accessibility information plus interactivity that previously required JavaScript. It comes with default styles but that's not the primary reason to use it.
