Trap Focus Plugin improved

[alexcsandru]

I'm struggling to modify the plugin to actually trap focus.
Right now focus is not completely trapped, it's bleeding outside in the URL bar, and it's not the correct way based on what w3.org says : W3.org-ARIA Practices Dialog modal trap focus

I do not fully understand how the plugin works, and hope someone will help me to improve or to add some parameter x-trap.strict to fully comply with w3.org ARIA.

Thanks!

[SimoTod]

The current x-trap mimics the inert specs, I think: https://html.spec.whatwg.org/multipage/interaction.html#inert
To achieve what you want, you need to add listeners for the tab key event and, if the focus was on the current focusable item, move the focus on the first one after the nextTick. YOu also need to remember to remove those listeners when x-trap evaluates to false.
Alternative, you can find a library that already does it for you and then you write your own directive. I believe someone on discord did it already.

[alexcsandru]

Thank you SimoTod, but I wanted to improve the actual focus plugin for Alpine, not to build something to work.
And yes there is a library that does exactly that: https://github.com/focus-trap/focus-trap, but I wanted to improve Alpine.
I will try to work on Alpine Plugin myself, It will take longer :) but I will do it.

Thanks again! 👍

[philwolstenholme]

Here's a browser-friendly version of the directive that @SimoTod mentioned. It's made by @
MuzafferDede who posted a link to it on Discord and relies on https://github.com/focus-trap/focus-trap#installation:

I updated it to allow outside clicks so things like @keyup.escape.window="open = false" @click.outside="open = false" work as a way of removing the focus trap.

Alpine.directive(
    "focus-trap",
    (el, { expression }, { effect, evaluateLater }) => {
      let evaluator = evaluateLater(expression);

      let oldValue = false;

      let trap = focusTrap.createFocusTrap(el, {
        escapeDeactivates: false,
        allowOutsideClick: true
      });

      effect(() =>
        evaluator((value) => {
          if (oldValue === value) return;

          // Start trapping.
          if (value && !oldValue) {
            setTimeout(() => {
              trap.activate();
            });
          }

          // Stop trapping.
          if (!value && oldValue) {
            trap.deactivate();
          }

          oldValue = !!value;
        })
      );
    }
  );

Here's the original: https://github.com/MuzafferDede/alpine/blob/e8416300f8826b16bbb91cb171766866c3d662b0/packages/trap/src/index.js

[MuzafferDede]

Yeah, I was curious that "Should focus move to the address bar after the last element?". As i know, it shouldn't move to the address bar. I asked Caleb about this if it was intentional and he said;

yes, that's intentional and usually desireable

I still created a version of it which i think is an alternative to the current approach. If we can confirm that the current approach is against to accessibility, i can rise a PR for it.

[alexcsandru]

Thanks, @philwolstenholme for the code and original source link.
Hello, @MuzafferDede, Thanks a lot for your code (refactored x-trap) it works exactly how should work.
And about the current version, yes it is against what should be, I can confirm that with W3.org

• Modal example on W3, (press on Add Delivery Address)
• Date picker on W3 example (press on the calendar)

All the websites (google.com on Google Apps, twitter.com on more, nytimes.com on the menu, bbc.com/future on more, buzzfeed.com on the menu, washingtonpost.com on the menu), and official guide W3.org ARIA practices (first two examples).

IMPORTANT: it's mandatory to create an exit of focus trap through the ESC key (@keyup.escape.window="menu = false") conform W3.org

I'm not against "exotic features" but when comes to ARIA, I want to make the greatest experience I can give for a lot of people.

[philwolstenholme]

I can see why Caleb went with the https://github.com/WICG/inert approach as it feels like a more browser native approach, but it's trying to solve a slightly different (more simple) problem than true focus trapping is. I think https://github.com/focus-trap/focus-trap is a better option.

Only 3.2kb minified and gzipped too, which isn't too bad: https://bundlephobia.com/package/[email protected]

[philwolstenholme]

@MuzafferDede I just updated my copy/paste of your work to add the allowOutsideClick option so people can use @click.outside="open = false" without focus-trap preventing Alpine from reacting to the click event.

[alexcsandru]

It uses https://www.npmjs.com/package/focus-trap

I've created this file, and then I replaced the directive 'focus-trap' with 'trap', and I'm importing it as a plugin like the official trap plugin.
If Alpine supports the new x-trap improvement, I have to change only the plugin, and everything should work the same.

// File: app.js
import Alpine from 'alpinejs'

// Original import of trap plugin : 
// import trap from '@alpinejs/trap'  
import trap from './trap' // the new and improved by @philwolstenholme 

// File: trap.js by @philwolstenholme 
import * as focusTrap from 'focus-trap'

export default function (Alpine) {
  Alpine.directive('trap', (el, {expression}, {effect, evaluateLater}) => {
    let evaluator = evaluateLater(expression)

    let oldValue = false

    let trap = focusTrap.createFocusTrap(el, {
      escapeDeactivates: false,
      allowOutsideClick: true,
    })

    effect(() =>
      evaluator((value) => {
        if (oldValue === value) return

        // Start trapping.
        if (value && !oldValue) {
          setTimeout(() => {
            trap.activate()
          })
        }

        // Stop trapping.
        if (!value && oldValue) {
          trap.deactivate()
        }

        oldValue = !!value
      })
    )
  })
}

Thank you so much @philwolstenholme !!

[calebporzio]

Can subscribe summarize exactly what changes should be made to x-trap?

[SimoTod]

Maybe a .strict modifier as initially suggested would make everyone happy.

[alexcsandru]

Default to be the version that follows the standard and a modifier to make the other effect (with URL focus). Yes, that will be also great.

[calebporzio]

Yeah I'm open to that @SimoTod

I understand all your points about abiding by standards and respect that.

I still would love an answer to my question though: What is a practical example of where the standard-abiding behavior is better? I can only think of the current behavior being better lol: If I'm not able to tab to the URL bar on a web page, it feels like the page is being overly greedy about my focus. I will say though, most of the time I just hit CMD+L and that would still work so I get it.

Anyhow, just trying to ground us in practical advantage - hopefully both that and the spec will line up

[alexcsandru]

What is a practical example of where the standard-abiding behavior is better?

No one says that standard behavior is better or not, but it's a standard and we should respect that because people who use this kind of navigation are used to this behavior.
I do not use keyboard navigation but I'm trying to apply the standard as it is, otherwise it's not standard.

I believe that most of the people who use keyboard navigation know about CMD/CTRL+L, and maybe that's why the standard is not to jump in URL in a trap state because they have a short command to jump in URL if they want.

If you want to change a standard behavior I think it's better to go to the source (W3) and change it there.
But to change it against a standard way, it's like someone believes that in America it's a better way to drive on the left side of the road, and he goes on the left side with his car.

This is a good way of thinking and acting??

[calebporzio]

Haha, again, I understand the standards point. However, if an American thought it was better to drive on the left side of the road, they would die - that's a pretty practical reason for driving on the right side of the road - not just abiding to standards lol.

Either way, moving forward with this.

I'm using inert because it was recommended in "Inclusive Components", a great resource on accessibility:

(https://inclusive-components.design/)

After writing a whole paragraph defending the current implementation, I think the new one is better anyways. I'll merge that PR now.

Thanks for helping me think through this! And thanks @MuzafferDede for the PR!

[MuzafferDede]

Caleb, i have a PR ready to push that contains all the changes. I am cleaning up the code.

[MuzafferDede]

@calebporzio #2072 ready to be reviewed.

[philwolstenholme]

One small thing, the WAI-ARIA Authoring Practices examples aren't actually a standard (compared to say, the HTML5 standard, or WCAG 2.1), they're just examples of pretty good technical implementations. They're a bit out of date now (e.g. lacking notes on mobile/touch behaviour) but they still mostly stand up as examples of minimum/baseline behaviour that authors can then improve on. I think the vast majority of the focus trap implementations in standalone projects like focus-trap, but also in libraries/frameworks constrain tabbing to within the document, so the address bar and other browser UI (e.g. back/forward buttons and any items in a bookmark bar) are out of bounds. I think we should match this precedent. Would it be helpful if I went through a bunch of different frameworks/libraries and noted down which allow tabbing out of the focus trap to the address bar, and which ones don't? An important thing with accessibility is to try and be as predictable as possible and match what people are used to from other sites, rather than guess at how keyboard-only users (for example) might think and have your site/app behave in an unpredictable/different way. I think us guessing that they might want to exit the focus trapped modal/menu and access the address bar via the Tab key (rather than use a keyboard shortcut) is an example of the sort of thinking that it'd be safer to avoid.

…

On Mon, 20 Sep 2021, 9:04 am Stratienco Alexandru, ***@***.***> wrote: *What is a practical example of where the standard-abiding behavior is better?* No one says that standard behavior is better or not, but it's a standard and we should respect that because people who use this kind of navigation are used to this behavior. I do not use keyboard navigation but I'm trying to apply the standard as it is, otherwise it's not standard. I believe that most of the people who use keyboard navigation know about CMD/CTRL+L, and maybe that's why the standard is not to jump in URL in a trap state because they have a short command to jump in URL if they want. If you want to change a standard behavior I think it's better to go to the source (W3) and change it there. But to change it against a standard way, *it's like someone believes that in America it's a better way to drive on the left side of the road, and he goes on the left side with his car.* This is a good way of thinking and acting?? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2057 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQL2DPLWPRDC5X2KE74ADTUC3TKPANCNFSM5D5FBECA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[alexcsandru]

Yeah, understand that and in general, I'm looking at some big websites (Google, Twitter, Facebook), and I'm looking at the implementation and the w3 examples. And I'm trying to make the same implementation. And I'm not guessing what they might want in general because I hope the big websites make a good decision with implementation.
Thanks. :)

[philwolstenholme]

Oh sorry if I wasn't clear enough, but I was agreeing with you @alexcsandru, not disagreeing 😄👍

[MuzafferDede]

I have worked as accessibility consultant for some of the airlines and i have worked with a university named Deque University in USA for years on those projects. We followed their code reports to build up accessible websites. Focus trap was the one of the major thing that i have struggle for months because there was no any solid solution at the time i was working on a modal. According to their report, focus must stay within its container, and they specially pointed that focus should not jump to the address bar. Because they have their own shortcut to focus on address bar and we should strictly follow the focus order. So my initial tweet was based on this.

And my own thought on general accessibility is that, people with disabilities uses certain tools, widgets, softwares, hardwares to access applications and its content. They build up guidelines for both users and creators to follow up and generate a culture for everyone to meet accessibility needs. Probably they didn't make greatest decisions at the beginning or their decision won't make any sense today, but the accessibility culture already has been build up on this guidelines and it's not easy to change today. All we can do for now is understand that there are things we don't know and we might not understand well but we can help them to get our applications the way they want, instead of thinking better ways for them until we really understand the need.

We still need @calebporzio kind of people to question these decisions to make things better for sure. In the end of the day, we are all in the same team, no one is agains accessibility anyways. I guess everyone is happy now so.. Thanks everyone!

[alexcsandru]

I'm not against anyone and understand very well people that question everything, and most of the time it's a great way of thinking, and the Project X was born probably in the same way, and it's brilliant!

I just wanted to improve things, I'm trying to take part in the open source world and this was my first Discussion on github. Yes I know, shame to me because until now I did not participate, just benefit from open source projects, but I'm on the right way :)

Thanks again Caleb :)

[philwolstenholme]

Oops, I replied before I saw Caleb's response! :)

…

On Mon, 20 Sep 2021, 2:55 pm Caleb Porzio, ***@***.***> wrote: Haha, again, I understand the standards point. However, if an American thought it was better to drive on the left side of the road, they would die - that's a pretty practical reason for driving on the right side of the road - not just abiding to standards lol. Either way, moving forward with this. I'm using inert because it was recommended in "Inclusive Components", a great resource on accessibility: [image: image] <https://user-images.githubusercontent.com/3670578/134012317-0a8a78f7-42dd-4cf5-955c-d1d965cd114f.png> (https://inclusive-components.design/) After writing a whole paragraph defending the current implementation, I think the new one is better anyways. I'll merge that PR now. Thanks for helping me think through this! And thanks @MuzafferDede <https://github.com/MuzafferDede> for the PR! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2057 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQL2DNCW5MAFAXL2MQSH4DUC44MHANCNFSM5D5FBECA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.