Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

At the opening of the modal the focus should be initially set on the first focusable element. #103

Open
ldzintegratore opened this issue Apr 27, 2018 · 2 comments

Comments

@ldzintegratore
Copy link

ldzintegratore commented Apr 27, 2018

The focus should be on a link, or on a form element or on the Close button. The ability to set this would be nice.
Thanks

@danhumaan
Copy link
Collaborator

Thanks for raising this ticket, and apologies about the delayed reply. If you have information to reinforce why you believe it should be X or Y, we're open to reading more and making an informed decision to improve Modaal.

For now, we'll mark this as an enhancement and gauge public interest in whether this is a desired feature or not before investing too much time developing something that will not be often used.

@dotherightthing
Copy link

dotherightthing commented Jan 13, 2021

The W3C's WAI-ARIA Authoring Practices 1.1 provide a set of criteria for building various common UX patterns.

The Dialog (Modal) pattern has these notes attached to it:

  1. 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.
    • 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.

and

  1. It is strongly recommended that the tab sequence of all dialogs include a visible element with role button that closes the dialog, such as a close icon or cancel button.

Currently Modaal contains .modaal-focus with a tabindex of 0. That puts the modal wrapper in the tab order. The spec suggests that any top level element should only be programmatically focussable via tabindex="-1", rather than present as a tab stop for keyboard users.

Scenario 1

Their Date Picker demo launches a modal containing a grid of dates. On launch of the modal, the focus is put on the current day's date:

Screen Shot 2021-01-13 at 12 50 13 PM

Scenario 2

In my use case today, I have a faux video 'play' button which launches an Ajax Modaal via click/tap/ENTER/SPACE. If ENTER/SPACE was used, I'd like an additional press of ENTER/SPACE to play the video, without the user having to locate the button first.

Workaround

I have implemented this pattern in the past, focussing a search field on before_open of a Modaal of type .modaal-inline. However this same approach doesn't appear to be working with the Ajax variant.

before_open: function () {
    var id = this.scope.id;

    setTimeout(function () {
        var $modal = $('#' + id);
        var $autofocus = $modal.find('[data-js-autofocus-modal]');

        if ($autofocus.length) {
            $autofocus.eq(0).focus();
        }
    }, 500);
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants