Focusing on first focus-able element by default is a major accessibility issue about focus-trap HOT 8 CLOSED

Thanks for the suggestion, @Dan503.

I don't think I'm convinced yet that this is the best default behavior for focus-trap. I believe you already can accomplish it — focusing a container element — but in many cases it may not be desirable.

For example, in the WAI-ARIA Authoring Practices modal dialog description, they recommend first focusing an interactive element or title when a modal opens, not the modal's container element.

You're right that in your example the verbosity seems helpful; but I'm not sure whether that's reflective of a realistic encounter a screen-reader user would have with a well-designed component.

So, considering that this behavior should be possible now and those ARIA recommendations don't prescribe it in the most common focus-trapping situation (a modal), I'm inclined to think the current defaults are fine. Still open to more information, though.

from focus-trap.

Demo 1 is the most common focus-trapping situation (a modal). It just isn't styled up to be a modal.

We are talking default behaviour here so we are generally talking about implementation by devs who just want it to work and aren't thinking that much about accessibility. They probably haven't added tabindex="-1" to the heading and even then, tabbable doesn't target things with tabindex="-1" on them so it wouldn't focus on the heading anyway in that situation. adding tabindex="0" to the heading is bad for usability because adding keyboard focus to non-interactive elements is super confusing for keyboard users.

Which of these two behaviours makes sense as the default behaviour? What is the behavior that focus-trap wishes to actively endorse as the best possible accessibility for modal dialogues considering this is essentially an accessibility plugin?

1. Modal opens and a screen reader reads out a link somewhere buried deep in the middle of the modal dialogue text with no other context to help the user understand what this random link that they were just read out is.
2. They open the dialogue and the screen reader reads out all of the text in the dialogue. The user understand all the context, they know where all the links are and they are able to then navigate to the links quickly with the [tab] key.

So out of option 1 (current implementation) and option 2 (my pull request) what do you think makes for the best user experience for screen reader users? What user experience would focus-trap like to actively endorse as the best default usability for the vast majority of websites to use?

Plus there is also the added benefit of the plugin not throwing an error if the user triggers a focus-trap on an element that has no tabbables inside of it.

I altered demo 7 in my pull request to present a very likely scenario people might have that covers similar ideas to the original demo 7. I made demo 7 act like a loading screen. You activate the focus trap (which in an element with no tabbables in it) and it counts down for 5 seconds (to simulate a loading screen). The user is not able to interact with the site until the count down ends and the deactivate button appears (unless the user presses the [esc] key).

Have I convinced you that this is the right thing to do yet?

from focus-trap.

If a user want's to make it less verbose then they can set a heading as the initial focus point. Since focus-trap doesn't analyse the focus-trap element markup for how good the accessibility of the markup is, it should just read out the the whole thing by default unless the user changes the behaviour in the options.

from focus-trap.

but in many cases it may not be desirable.

Can you give an example?

from focus-trap.

the best possible accessibility for modal dialogues

Unless I see more information to the contrary, I feel like I should trust the WAI-ARIA Authoring Practices to tell me what's accessible behavior for a modal dialog. And you haven't addressed your divergence from their recommendations.

I believe there is some authoritative work in support of your suggestion, e.g. https://developer.paciellogroup.com/blog/2018/06/the-current-state-of-modal-dialog-accessibility/. However, I find more suggestions in line with the WAI-ARIA Authoring Practices. If you can find more authoritative info, I'd be very interested. But maybe not for this library so much as for modal components ...

We are talking default behaviour here so we are generally talking about implementation by devs who just want it to work and aren't thinking that much about accessibility.

That is not the concern of this library. It can be used in a universally accessible way (and ideally would be). But it doesn't have to be: for example, it could be used in a way that targets sighted keyboard users. focus-trap is not endorsing anything: it is a low-level utility library that other things can be built on top of. This isn't a modal component — it's mean to be used by modal components.

If you'd like to make a modal library that uses focus-trap in the way that you think is best, you should! Happy to link to it in the readme.

Plus there is also the added benefit of the plugin not throwing an error if the user triggers a focus-trap on an element that has no tabbables inside of it.

I still don't think this is a benefit: that situation is a user error.

So: I think that if you'd like to propose an option to include the container in the focus trap, I'd be open to that. I'm not sure we need a significant, breaking change, though, to address concerns that may be more appropriately addressed in higher-order libraries.

from focus-trap.

I've had a thought on how this can be implemented without causing a major breaking change to the plugin.

What if by default on activation, focus-trap also takes tabindex="-1" elements and it's container into consideration on where it sends it's initial focus to?

So if the user adds tabindex="-1" to the focus-trap container, then the container will receive focus by default. If a heading inside the container has tabindex="-1" then the heading will receive focus.

It should only take tabindex="-1" elements into consideration on initial focus. They should not be taken into consideration after inital focus.

To make this easier in this plugin, it would be good if there was an includeNegatives option in the Tabbable plugin.

This means that people can get the container focus functionality by default as long as they manually add the negative tabindex property to the focus-trap element themselves.

I don't think it is likely to break current implementations since it requires the user to explicitly add a negative tabindex in the HTML for it to change the functionality.

I'd prefer container focus to be the general default functionality but I don't see that happening. Would you be open to this as a solution?

from focus-trap.

This is already possible, exemplified in the demo, and now mentioned in the docs, so I don't think changes are necessary. But thanks for the discussion.

from focus-trap.

I don't see any warnings in the documentation about the potential accessibility issues that come from sending focus to the first focusable element.

There should at least be a warning somewhere to notify users of the potential issue.

from focus-trap.