After recently upgrading to Django 4, we’ve had users report issues related to the changes made in #34040. The users perform quite a lot of these searches, and an extra click to focus the search box annoys them. I wonder if it would be possible to restore the autofocus functionality when in popup? In the popup context, I think it makes sense to autofocus the search box since usability greatly improves.
Would this solution also be acceptable from an accessibility standpoint? Maybe @thibaudcolas ?
My opinion here is that it may be better to retain autofocus here than on a regular page but it’s still not ideal for a few reasons:
First, screen readers will skip the “Select account” text and the “Add account button”, so users won’t be able to know what type of object they’re selecting. In most cases they know where they come from, so maybe not too bad, but the worse problem is that they have no way to know if they can add a new account or not without tabbing back. And the button is not always there depending on the permissions setup.
Second, I didn’t check but I would assume this uses the same template as the regular list page, so there would be some added maintenance burden to special case popups.
And finally, these days, for most people, popups just open in a new tab. They’re not that distinguishable from a new tab other than not having navigation. I am wondering if we should find a better solution here overall, it is a bit of a relic of the past.
If you want this in your own project, I would suggest overriding search_form.html and adding the autofocus back.
My sole focus with this forum topic is to enhance Django (we’ve already implemented the template overriding you suggested).
On the first point: While I concur that skipping the “Add object button” is not ideal for screen reader users, I am inclined to argue that usability should take precedence over accessibility in this instance.
For the second and third points: The increase in maintenance we have is minimal. Prior to discovering this forum, I had already submitted a PR.
I still don’t think the juice is worth the squeeze here.
One way forward might be with something else I’ve started looking into: keyboard shortcuts. So you might hit a particular key to jump to the search box for example. Would this be “enough” for your users to not be annoyed, do you think? Then we can have not just the best of both worlds, but an improvement for everyone.
Indeed, we have only a small number of users at the moment, which allows us to easily guide them on how to use shortcuts. However, from the perspective of a typical Django user, it raises the question of how would a user become aware of the availability of keyboard shortcuts.
Perhaps a more holistic solution would involve leveraging the Aria dialog role to notify screen readers about the content and purpose of the dialog. This method may necessitate a departure from the current popup implementation, but it’s worth noting - as you mentioned earlier - that the existing approach is somewhat antiquated.
However, from the perspective of a typical Django user, it raises the question of how would a user become aware of the availability of keyboard shortcuts.
The same as GMail or GitHub - you press ? on your keyboard to view the shortcut list - we could also display a little button somewhere visible to make it more obvious. This is something I’m actively thinking about.
Perhaps a more holistic solution would involve leveraging the Aria dialog role to notify screen readers about the content and purpose of the dialog.
Do you have an idea in mind? I have one below but don’t know if it solves the issue in the way you would want.
This method may necessitate a departure from the current popup implementation
Something I’ve been thinking about, is moving these popups to using the <dialog> element in combination with the popover API to have modals without (much? any?) JS and use these rather then the current, somewhat broken implementation. I think this would be an amazing change, but it’s also a lot of work. I am not 100% sure what would happen with the focus in this case, if it would focus on the <dialog> itself or on the first form element - in this case I probably wouldn’t be against a tiny bit of JS to pop autofocus to whatever the first field is, but we may still have the same issue (the dialog would probably have a header, and moving the focus without user interaction will cause the same problem here).
