It's a (focus) Trap

    People who write standards are very cleverly settled. It is enough for them to write how everything should work well, and then their problems are no longer.

    This is exactly what happened with the “how dialogs should work”, or rather, the “correct” modal dialogs from the point of view of a11y.

    In the description of the dialog role on MDN, everything is written very simply:

    • The dialog must be properly labeled
    • Keyboard focus must be managed correctly

    The problem is that MDN forgot one more important point, and all the others forgot about one of the above - that the modal should not let the trick out of its hands. The active element must be locked. Do not let him escape from our trap.

    Modal dialog

    The story began just recently - in the Web Standards Newsletter I got a link to the “correct” WAI-ARIA Dialog . And away we go.

    The component is actually good:

    • it hangs aria-hidden on the page to hide the content from screen-readers (only works in the first example).
    • it obscures the content and cuts down the scroll of the page.
    • controls focus, so that from the modal it is impossible to snag.
    • after closing the dialog, it returns focus to the starting position.
    • and adds different aria-specific tags, of course.

    He does everything that he asks for MDN and even more, since without the first item “exit” from the dialogue with the activated screen reader is not difficult.

    In general - must have!


    But the implementation of " focus-management " was a little disappointing - the guys really intercept keyboard events (and not only) and emulate the tab button themselves.

    It’s so incomprehensible that I decided to dig a little how “this” should work in general. The word "dig" means to check how various sites and frameworks deal with tabs.

    Let's start with the sites (a bit biased selection):

    • Google Gmail | G + - perfect. ️
    • Classmates - with the departure of the tab, they close the modal, to which the focus never comes
    • FB - depends on the page. In the group / on the personal page - there is nothing at the time of writing messages. Never press Tab (in safari) on the main - the roof blows.
    • VK - page "randomly" ignores tab ️
    • Yandex.Maps - the page completely ignores the tab ️
    • Yandex.Music - the page completely ignores the tab ️
    • YAN - no focus management.
    • LiveJournal - no focus management.
    • My own sites - no focus management.
    • Habrahabr - no focus management, modals
    • Jira / Confluence - perfect. ️

    The conclusion is simple - the “normal” sites have a little lack of brains, and Yandex tear off their hands.

    With frameworks (a slightly biased selection) is much more interesting:

    With frameworks, it is also quite bad. And absolutely no one hangs aria-hidden on the rest of the content to make the modal actually accessible to people who are forced to use screen readers.


    In fact, I also didn’t bother with all this garbage before, but here, as an evil, my dear wife decided to learn HTML HTML page layout where pepelsbey with a big, big company made her and me think about how tabable my site is.

    I had to learn new science and solve the problem with focus.

    PS: Vadim recommends scoring all this aria-hidden with focus-management and using the inert html attribute , which simply “turns off” (I’m completely lying) everything except the modal and there will be no problems with screen / reader or with focus.

    Although I’m not sure about the second one, and it still doesn’t work very well, and the polyphiles are simply terrifying .....

    Focus lock

    In general, as they said on Leo Tolstoy Street ... - and what are your suggestions .

    In fact, the problem is very simple - despite the fact that millions of modules have been written for JS, there are practically no modules for focus management.

    • focus-manager is a simple focus-manager with a simple and vanilla API and a great example . There are a couple of cons
    • ToleFocus is some kind of monster that you want to run away from.
    • react-focus-trap is so simple that it returns focus only to the beginning.
    • Focus manager from AUI, but who has heard of AUI before ?
    • focus-trap , it is also focus-trap-react which was used in the WAI-ARIA demo at the beginning of the article. And which by default is turned off by Esc and generally does not use the DOM-API very correctly

    In general, 7 troubles = +1 new bike . Or rather, a real train from focus-lock , dom-focus-lock , react-focus-lock and vue-focus-lock - for all occasions.

    From the side of the wrapper (react, vue, dom), everything is very simple - get the DOM node and close the focus in it. All salt is in focus-lock.

    There are several reasons for creating a new library:

    • Unfortunately, all solutions (except for focus-trap / lock) completely ignore tabIndex and become completely inoperative if one smart programmer breaks the tabbing order.
      The case, of course, is a little synthetic, but quite real. To my great regret.
    • Of all the solutions (except focus-trap / lock and react-focus-trap), you can easily tab up in safari (JFYI: safari distinguishes Tab and Opt + Tab). And if the focus once leaves the trap - no one will return it back.
    • focus-trap, which works so well everywhere, does this because it intercepts and emulates the Tab, they completely ignore the settings of the same Safari paragraph above.
    • All solutions (except focus-lock and BluePrint.js) select the first element at the input, not the autofocus element.
      PS: focus-trap is looking for an element with the initialFocus attribute. Why?

    So I had to make another bike, which temporarily meets a slightly larger list of whistles than its closest competitors. Or specifically everyone.

    Just wrap the modals (and not only the modals) in FocusLock - and half of the problems will be solved by the
    React-focus-lock demo - ( find the difference ).
    Vue-focus-lock demo -

         any data

    But only half, since aria-hidden (or inert) will have to be hung up by someone else and somewhere else. But that's another story.


    Total do not forget% username% that modals are not only a gray lightbox that does not click with the mouse, but also the wonderful world of keyboard exercises.

    But most importantly - do not forget that you do not need to interfere with the user’s operation of the site not only with the mouse.

    PS: Better yet, turn on VoiceOver or another ScreenReader and try your sites for strength. You will be surprised.
    Many things, for example, “manual keyboard navigation” in Yandex.Mail, do not actually change the active element. Yandex definitely lost
    one programmer from Finland as a user.

    PPS: Gmail, however, is not that much better.

    In general - don't fall for it -

    Also popular now: