Modal: explore a way to not show the close button tooltip on initial focus

[afercia]

When the Modal component opens, by default if moves focus on the first focusable element within the modal. This is required for accessibility.

In most of the cases, the first focusable element will be the default "X" close button on the top right. Since it's an IconButton component, it will display its tooltip (required for accessibility):

However, the tooltip suddenly appearing when the modal opens could be confusing for users. In a custom modal in development for a well known plugin, we've had a few users thinking that it was a "bug".

I wouldn't be opposed to explore a way to not display the tooltip on initial focus, e.g.:

• when the initial focus is set on the default close button, the tooltip prop should be false (however the button should keep its aria-label)
• after initial focus, when users hover or focus the button the tooltip should appear normally (the tooltip prop should be restored to the label value)

[karmatosed]

Design wise I would be very up for the tooltip not showing on first load - it is distracting and would be great to not have.

[jasmussen]

A "well known plugin" you say? :D I wonder what that one is! However it's good to have data to back up our gut feelings. Great ticket.

Why is it that we can't set focus on the modal itself as the first thing? There's precedence for this in the Document Outline panel:

The Block Library has similar behavior, where tabbing from the search field sets focus on the scrollable region below.

The primary reason for setting focus on the modal on open is that the first focus on the close button is not just confusing and jarring, it's arguably a usability issue. Although hiding the tooltip would be a bandaid, spacebar is used to scroll windows as well, which means a user might open the modal, and press space to start scrolling only to then close the window.

[afercia]

Why is it that we can't set focus on the modal itself as the first thing?

That's not the expected interaction with a modal dialog. Was also discussed at length during the modal component development. For reference, see the ARIA Authoring Practices:

https://www.w3.org/TR/wai-aria-practices/#dialog_modal

NOTE

• When a dialog opens, focus placement depends on the nature and size of the content.
  • In all circumstances, focus moves to an element contained in the dialog.
  • Unless a condition where doing otherwise is advisable, focus is initially set on the first focusable element.

exceptions:

• If content is large enough that focusing the first interactive element could cause the beginning of content to scroll out of view, it is advisable to add tabindex=-1 to a static element at the top of the dialog, such as the dialog title or first paragraph, and initially focus that element.
• If a dialog contains the final step in a process that is not easily reversible, such as deleting data or completing a financial transaction, it may be advisable to set focus on the least destructive action, especially if undoing the action is difficult or impossible. The Alert Dialog Pattern is often employed in such circumstances.
• If a dialog is limited to interactions that either provide additional information or continue processing, it may be advisable to set focus to the element that is likely to be most frequently used, such as an OK or Continue button.

[afercia]

About the examples in the GIF:

• the Document Outline panel doesn't have focusable elements when there's no headings hierarchy tree to show so initial focus is set on the content (".table-of-contents__counts")
• the Block Library sets focus on the scrollable region below when tabbing, that's not related to initial focus

[jasmussen]

So if the first focusable element is the scrollable area — I know it isn't the case now — that would surely not only be an element inside the modal, but an interactable one too, right?

[afercia]

Well we should also give it a role and an aria-label then. Yes, it would be "interactable" (actually only when the content is long enough to trigger scrolling) thus there would also be the need to communicate what it is (role) and label it (aria-label).
However, we can't "skip" elements. Currently, the modal has a fixed top bar with the close button. Setting initial focus on the scrollable content would "skip" the close button.

first focus on the close button is not just confusing and jarring, it's arguably a usability issue.

Well, I guess this is highly subjective. For example, as a user I'd like to have the ability to immediately close the modal if its content is not relevant for me. Regardless, I'd consider this a design issue. When it's not desirable an element is the first focusable element, the best option is to not place it as first element 😉

The "X" close button in the top right is a pretty consolidated pattern though. Also, almost all the modals in core work this way and they set initial focus on the close button.

Although hiding the tooltip would be a bandaid, spacebar is used to scroll windows as well, which means a user might open the modal, and press space to start scrolling only to then close the window.

Hm well keyboard users do know spacebar activates buttons. That's also why a clear indication of focus is important.

[jasmussen]

However, we can't "skip" elements. Currently, the modal has a fixed top bar with the close button. Setting initial focus on the scrollable content would "skip" the close button.

I would want to try and explore this in a pull request, it seems like there should be a way to make the scrollable content be first, and the Close button 2nd, both visually and in tab order. A heading with position sticky comes to mind. Would you object to me exploring such a PR?

For example, as a user I'd like to have the ability to immediately close the modal if its content is not relevant for me.

Would Escape or Tab then space not be sufficient here?

[afercia]

Not opposed to explorations. I'm not fully sure to understand why Gutenberg should deviate from core established patterns though. In core, initial focus is on the close button and I guess users expect that.

it seems like there should be a way to make the scrollable content be first, and the Close button 2nd, both visually and in tab order.

the only way would be moving the close button to the modal "footer", no? Them, what happens when the modal content has lot of focusable elements? Users would be forced to tab through all the content to get to the close button.

Escape yes of course it's an expected behavior.

Sticky header: position sticky doesn't work on IE 11. However, a while ago I was exploring something for #8561 where I think the best option would be making the modal height determined by the content. I've tried that and the current fixed header + scrolling is a bit annoying for an implicit height calculation. The only way I found was to make the header sticky... a bit unrelated but thought it was worth mentioning.

[jasmussen]

I'm not fully sure to understand why Gutenberg should deviate from core established patterns though.

Deviation from these standards would be temporary only until such a time as we would be able to roll out these enhancements to the rest of core, and in the mean time provide a better user experience including solving the issue at hand.

the only way would be moving the close button to the modal "footer", no?

Reading from top left to bottom right, surely the following would still be correct tab hierarchy and order, right?

[afercia]

Deviation from these standards would be temporary only until such a time as we would be able to roll out these enhancements to the rest of core

What I'm arguing here is if they're enhancements 🙂I'm not sure what the added value is. I'd tend to think established patterns and expectations shouldn't be changed, unless there's a really, really, good reasons to do that.

Reading from top left to bottom right, surely the following would still be correct tab hierarchy and order, right?

Not sure I fully understand what is 1 and 2 🙂To my understanding, in 1 the heading and X close button are placed within the scrollable area so they would disappear when scrolling. I think this shouldn't happen. 2 seems to me the current modal layout.

[tofumatt]

Fixed in #9900.