I recently read this article<\/a> by Keith Grant which introduced the newly arrived Disclaimer: The First, a quote from the W3C documentation<\/a> regarding what should happen following a keypress inside a dialog:<\/p>\n\n\n\n Tab:<\/p> Shift + Tab<\/p> To summarize, when inside a dialog, pressing This makes sense because when a dialog is open, a user is interacting only inside it and allowing the focus to escape outside the dialog would essentially be mixing contexts and possibly create a state where the user doesn\u2019t know which element is in focus.<\/p>\n\n\n\n So, going back to the idea of a modal, our expectation would be that tabbing inside of the modal would only focus on elements inside of the modal. Anything outside of the context of the modal would be out of scope because the tab is only concerned with what is inside of it. This is what we mean by focus trapping<\/strong>.<\/p>\n\n\n If we were to implement focus trapping inside a 1. Grab all the focusable\/tappable elements inside the dialog. This way, we create a loop on focus as the user presses Back to my experiment with the new If you have not heard about that before, it represents an element that has received focus or contains an element that has received focus. So, for example, you have a <dialog><\/code><\/a><\/a>. Excited by this new UI element, I immediately sat down to experiment with it to see how it can be used effectively as a modal\u200a\u2014\u200athe most common use of it. While experimenting, I discovered a neat CSS trick on how to trap focus within the element, a common accessibility requirement for modals, and a notoriously difficult one.<\/p>\n\n\n\n<dialog><\/code> demos in this article are tested on Chrome and Firefox browsers only. Safari has some weird issue where not all elements are focused while doing normal keyboard navigation with Tab key!<\/p>\n\n\n\n\n\n\nWhat is focus trapping?<\/h3>\n\n\n
\n
\n
Tab<\/code> or Shift+Tab<\/code> should cycle the focus within the dialog only\u2014amongst the focusable elements inside the dialog.<\/p>\n\n\n\nAn implementation with JavaScript<\/h3>\n\n\n
<dialog><\/code>, the most common approach would be to do the following when the dialog opens:<\/p>\n\n\n\n
2. Listen for Tab<\/code> and Shift+Tab<\/code> keypresses and manually focus the next or previous element, respectively.
3. If the keypress happens on the first focusable element, then focus the last focusable element in the chain and vice versa.<\/p>\n\n\n\nTab<\/code> or Shift+Tab<\/code>. See this W3C code snippet<\/a> as an example of how this might be approached with JavaScript. You\u2019ll see it\u2019s quite a bit<\/em> of JavaScript.<\/p>\n\n\nEnter
:focus-within<\/code><\/h3>\n\n\n<dialog><\/code> element. When thinking about focus trapping, a CSS pseudo-class (also very recent in browsers) immediately came to my mind\u200a: :focus-within<\/a><\/code>.<\/p>\n\n\n\n<div><\/code> and inside of it is an input<\/code> element. If you want to style that <div><\/code> when the contained\u00a0input<\/code>\u00a0has focus, you can do it like so:<\/p>\n\n\n\ndiv:focus-within {\n border: 2px solid red;\n}<\/code><\/pre>\n\n\n\n