# Request for Vote: Admin Keyboard Shortcuts and Command Palette **URL:** \ **Category:** Django Internals\ **Created:** [May 22, 2025, 7:21am UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037 "2025-05-22T07:21:57Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![khanxmetu](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/khanxmetu/32/28600_2.png) [@khanxmetu](https://forum.djangoproject.com/u/khanxmetu)\ **Post date:** [May 22, 2025, 7:21am UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037/1 "2025-05-22T07:21:57Z")
Hi folks, The proposal to add keyboard shortcuts and command palette in the admin had been accepted as part of GSoC. I need your input to move it forward. Here’s a summary of previous efforts. [Ticket#16521](https://code.djangoproject.com/ticket/16521) about keyboard shortcuts was marked as accepted in 2012. A simple patch followed 11 years later, but the author was directed to [forum](https://forum.djangoproject.com/t/django-admin-save-shortcuts/27016) for community discussion. Apparently, there had been slight interest shown and no one opposed the idea. @tom developed an experimental package: [`django-admin-keyboard-shortcuts`](https://github.com/knyghty/django-admin-keyboard-shortcuts) with plans to merge into core. The idea was again presented at different occasions: [DjangoCon Talk](https://m.youtube.com/watch?v=JUCo9I08tgc) and recently [GSoC](https://code.djangoproject.com/wiki/SummerOfCode2025). At this stage I believe there is a general consensus in favor, but the community has yet to decide which shortcuts should be set as default. [`django-admin-keyboard-shortcuts`](http://github.com/knyghty/django-admin-keyboard-shortcuts/blob/main/README.rst#supported-shortcuts) has a list of supported shortcuts. I’d encourage you to propose new shortcuts and/or share feedback about existing ones regarding their usability. We believe one of the main goals is to quickly search model instances from anywhere across admin. If enough community interest is shown, the search could be extended into a full-fledged command palette similar to [kbar](https://kbar.vercel.app/). I’d also want to check with [@steering\_council](https://forum.djangoproject.com/groups/steering_council) whether we require DEP for keyboard shortcuts or command palette. Additionally, we want a combobox widget (supporting pagination and remote data source) for the search. The [`select2`](https://select2.org/) library being used by existing autocomplete widget in admin meets those requirements, however it is tightly coupled with jQuery. At this stage we wonder if it would be a good idea to continue writing select2+jQuery code, propose a no-jQuery select2 replacement or use vanilla JS. If you could help decide such dependencies early, we could continue working on instance search and begin migrating core (if required) while waiting for additional feedback. Thanks ---
**Author:** ![carltongibson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/carltongibson/32/267_2.png) [@carltongibson](https://forum.djangoproject.com/u/carltongibson)\ **Post date:** [May 22, 2025, 7:49am UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037/2 "2025-05-22T07:49:30Z")
Hi @khanxmetu, thanks for raising this. My only real concern here is whether the command palette is sufficiently stable to get tied to Django’s long-release cycle and stability guarantees? That is, are we confident that we’re not going to need to make numerous/rapid adjustments to it once we get people using it? The answer might be Yes there, but how battle tested is this? (I don’t know, hence asking.) If we’re not confident then one approach would be to promote the package but still keep it separate, in order to allow continued iteration. One idea there would be pip extras. This would be new for us, but I think we’ll likely need to do something similar for the db-tasks backend, which faces the same challenge. What goes for one could go for all. In general, it would be nice to have _some_ story here, even if pip extras isn’t it. > Additionally, we want a combobox widget … Can I point to this: [Usage Guide - django-tomselect documentation](https://django-tomselect.readthedocs.io/en/latest/usage.html) by @jacklinke > … yet to decide which shortcuts should be set as default … I’m imagining some config file? 🤔 (TOML or something?) I’d offer a **small** set of defaults and a how-to on adding your own. The jump to model example is probably the most obvious. But those points are secondary to the stability question. ---
**Author:** ![CodenameTim](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/codenametim/32/31507_2.png) [@CodenameTim](https://forum.djangoproject.com/u/CodenameTim)\ **Post date:** [May 22, 2025, 10:41am UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037/3 "2025-05-22T10:41:36Z")
> [@carltongibson](#): > > That is, are we confident that we’re not going to need to make numerous/rapid adjustments to it once we get people using it? Could we approach this more as, do we think this base set is complete where it won’t need to change and that any additions will be easily customizable per project? I don’t see this doing well as a separate package and would need to be adopted to help shift community opinion. Regarding pip extras. If we had pip extras, it would more likely be a part of the admin extra. Not on its own. Maybe the inclusion of this is a good reason for us to revive the experimental DEP? ---
**Author:** ![carltongibson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/carltongibson/32/267_2.png) [@carltongibson](https://forum.djangoproject.com/u/carltongibson)\ **Post date:** [May 22, 2025, 11:18am UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037/4 "2025-05-22T11:18:26Z")
It’s not just about _completeness_ but whether it’s largely bug free. Are there likely to be lots of edge-cases that haven’t been exposed yet, requiring numerous/rapid fixes? (IDK but we’re talking about browsers here right?) > Maybe the inclusion of this is a good reason for us to revive the experimental DEP? The experimental APIs DEP allowed only changes without deprecation at the next .0 release. (So something introduced in 6.0 could be changed in 7.0.) It’s not _experimental_ in the sense that might be needed here. (Two years to make an API change because we realised it was wrong isn’t going to fly.) To [quote that DEP](https://github.com/django/deps/blob/main/draft/0002-experimental-apis.rst): > … to have got as far as an experimental feature in the main codebase it should have passed a certain quality threshold and the DEP process and already be somewhat fully-formed. It’s not a licence to include WIP _experiments_ as part of Django itself.\[1\] > I don’t see this doing well as a separate package and would need to be adopted to help shift community opinion. Bar adoption, the only rational given for needing this in core is potential template blocks needed to be added. Well, blocks can be added. In reference to adoption, this looks like the perfect test case for solving the _How do we promote a package without it having to be merged to core?_ that we bang our head on again and again and again. I’d suggest we take the opportunity to address it, rather than sidestep it. (We need to do so at some point.) Of course, that whole discussion is conditional on the assumption that the package is essentially not battle tested. The repo has this warning… > …very hacky and really just a proof of concept… Which implies that it would be a concern. On the positive side, if it’s a young idea, it **wants** to be free of the eight-month release cycle and stability policy so that it **can** evolve. This is something to embrace. * * * 1. The experimental APIs DEP would be perfect for django-tasks though. We’re _pretty sure_ the API for deferring tasks is correct, but who’s to say we won’t want to bring in a change once real-world usage scales up? ---
**Author:** ![CodenameTim](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/codenametim/32/31507_2.png) [@CodenameTim](https://forum.djangoproject.com/u/CodenameTim)\ **Post date:** [May 22, 2025, 12:14pm UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037/5 "2025-05-22T12:14:08Z")
> [@carltongibson](#): > > It’s not just about _completeness_ but whether it’s largely bug free. Are there likely to be lots of edge-cases that haven’t been exposed yet, requiring numerous/rapid fixes? Yes, there will be bugs, but I think it’s unfair to assume that the solution would be unstable to the point of “requiring numerous/rapid fixes”. Code won’t be merged in unless it looks good and appears to be well tested. > [@carltongibson](#): > > Of course, that whole discussion is conditional on the assumption that the package is essentially not battle tested. This explains our difference of opinions. I’m assuming this will be Django quality at the time of being merged. ---
**Author:** ![thibaudcolas](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/thibaudcolas/32/3956_2.png) [@thibaudcolas](https://forum.djangoproject.com/u/thibaudcolas)\ **Post date:** [May 22, 2025, 12:24pm UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037/6 "2025-05-22T12:24:09Z")
👋 we discussed this in [today’s accessibility team meeting](https://forum.djangoproject.com/t/accessibility-team-meeting-notes/26133/27), here’s our proposed approach: - The command palette will be better served with the DEP or [new features](https://github.com/django/new-features) treatment. It’s a solid concept, has a reasonable case to be a core feature, but requires more maturation of the concept / implementation (see previous messages). - Keyboard shortcuts are simple enough as a concept and fundamental enough to meet our accessibility requirements that we think we can proceed with a list of shortcuts + other aspects relevant for implementation. @sage and I offered to help with that spec, that will be directly inspired by our experience implementing this in Wagtail, and our understanding of related requirements in the WCAG and ATAG standards. We think this is going to be simple in big part because those standards make it clear how and why to get shortcuts. * * * For anyone wanting to do their own research already, here are the relevant references in W3C standards that help determine which shortcuts to implement, and how to implement shortcuts: - [Developing a keyboard interface: Keyboard shortcuts](https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/#keyboardshortcuts) in the ARIA Authoring Practices Guide (APG) - [ATAG 2.0 A.3.1 Provide keyboard access to authoring features](https://www.w3.org/TR/ATAG20/#gl_a31) - In particular, [Implementing Success Criterion A.3.1.3 Efficient Keyboard Access](https://www.w3.org/TR/2015/NOTE-IMPLEMENTING-ATAG20-20150924/#sc_a313) - [WCAG SC 2.1.4 Character Key Shortcuts (Level A)](https://www.w3.org/WAI/WCAG22/Understanding/character-key-shortcuts.html) ---
**Author:** ![carltongibson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/carltongibson/32/267_2.png) [@carltongibson](https://forum.djangoproject.com/u/carltongibson)\ **Post date:** [May 22, 2025, 12:26pm UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037/7 "2025-05-22T12:26:10Z")
Of course the code will look OK. No one is going to merge something that is obviously broken. New ideas though often (always?) fail to account for whole ranges of use-cases. It’s only when you put them in front of people that those appear. The whole point about _develop it in a third-party package first_ is that it allows those use-cases to appear. I contrast this with one of the other GSoC proposals we have, to merge template-partials into core. Template partials has been in a third-party package since Django 4.2. It’s gone a whole LTS cycle, with significant uptake, before we’ve even suggested merging it. Novel use-cases were indeed discovered, and addressed, quickly and quietly. That would not have been possible if instead we’d said _this can’t be developed out of core_. Of course it could. My _concern_, and it’s only that, is that the command palette here is still at proof of concept stage and it has not had the exposure to reveal the things that haven’t been thought of yet. If Tom wants to tell me, no it has all been thought of, then we can have that conversation. But minus that, we’d be wise to allow for unforeseen problems to reveal themselves. ---
**Author:** ![nessita](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/nessita/32/12194_2.png) [@nessita](https://forum.djangoproject.com/u/nessita)\ **Post date:** [May 22, 2025, 12:55pm UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037/8 "2025-05-22T12:55:51Z")
> [@CodenameTim](#): > > I’m assuming this will be Django quality at the time of being merged. That’s a fair expectation, but just to clarify: who would be responsible for ensuring that this meets “Django quality” at the point of merge? Not to sound self-important, but in practice, that bar is usually reached with substantial involvement from the Fellows. Even when there is a strong push and commitment, it’s uncommon for a non-Fellow to carry a feature all the way through to that level of quality without significant support. So realistically, if this goes ahead, the task to ensure this meets “Django quality” would likely fall on the Fellows. There are also practical considerations: this feature is mostly JavaScript (from what I can see in the repo, and this also seems untested so far?), and Fellows are not necessarily proficient in JavaScript. That adds an additional layer of difficulty in reviewing and maintaining it (now and in the mid/long term). For these reasons, I would encourage to have this as a third party package, and/or go through the usual stages of the “new feature idea” kanban to identify maturity and maintainers. ---
**Author:** ![CodenameTim](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/codenametim/32/31507_2.png) [@CodenameTim](https://forum.djangoproject.com/u/CodenameTim)\ **Post date:** [May 22, 2025, 2:55pm UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037/9 "2025-05-22T14:55:45Z")
@carltongibson and @nessita, I want to highlight this part of Thibaud’s comment. > [@thibaudcolas](#): > > Keyboard shortcuts are simple enough as a concept and fundamental enough to meet our accessibility requirements that we think we can proceed with a list of shortcuts + other aspects relevant for implementation. The keyboard shortcuts aspect (not the command palette) may be more inline with a bug fix rather than a new feature because it’s attempting to bring Django inline with our [accessibility standards](https://www.djangoproject.com/accessibility/). @nessita I’m purposely ignoring the comment about our pipeline/bottleneck problems. I’m aware of them and I don’t feel like I have anything new to contribute to that discussion and continuing it wouldn’t be beneficial to this thread. ---
**Author:** ![carltongibson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/carltongibson/32/267_2.png) [@carltongibson](https://forum.djangoproject.com/u/carltongibson)\ **Post date:** [May 22, 2025, 3:03pm UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037/10 "2025-05-22T15:03:08Z")
These would still be new features. They’ve never been supported right? Keyboard shortcuts may well be less of a risk though. I think following @thibaudcolas’ suggestion to put this through the new feature pipeline is reasonable. No reason certainly parts of it can’t be advanced if suitably well defined. (Maybe the whole thing can be but it still can be the case that it would be better off iterating rapidly until the corners are worked out.) 🤷 ---
**Author:** ![michaelschem](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/michaelschem/32/17721_2.png) [@michaelschem](https://forum.djangoproject.com/u/michaelschem)\ **Post date:** [May 22, 2025, 3:57pm UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037/11 "2025-05-22T15:57:13Z")
This feature seems to have been paralyzed with feature creep. I think we should just merge the simplest solution that achieves adding shortcuts and iterate on that. I wrote a PR for exactly that years ago. > > > \## Add Keyboard Shortcuts to Django Admin Interface > > \### Description > > This p…ull request introduces keyboard shortcuts to the Django admin interface, enhancing the user experience by allowing faster navigation and actions using the keyboard. Three main shortcuts have been implemented: > > 1. \*\*Save and Continue Editing\*\*: Allows users to save changes and remain on the current page. > 2. \*\*Save\*\*: Saves changes and returns to the admin index page. > 3. \*\*Save and Add Another\*\*: Saves the current object and opens a new form for adding another object of the same type. > > The following table summarizes the keyboard shortcuts for both Windows and Mac users: > > | Action | Windows/Linux Shortcut | Mac Shortcut | > |-------------------------|-------------------------|--------------------------| > | Save and Continue Editing | Ctrl + S | Cmd + S | > | Save | Ctrl + Shift + S | Cmd + Shift + S | > | Save and Add Another | Ctrl + Alt + S | Cmd + Option + S | > > \### Implementation Details > > \- JavaScript code has been added to \`base\_site.html\` to listen for specific key combinations and trigger the corresponding actions. > \- The script targets the \`input\` elements of the admin forms based on their \`name\` attributes (\`\_continue\`, \`\_save\`, and \`\_addanother\`). > \- The implementation ensures no conflict with existing browser or system shortcuts and is designed to enhance usability without disrupting current workflows. > > \### Testing > > \- The feature has been tested across various browsers (Chrome, Firefox, Safari) to ensure compatibility and functionality. > \- TODO: Add Additional tests to cover the new feature and ensure it does not interfere with existing admin functionalities. > > \### Documentation > > \- TODO: Add documentation to include the new keyboard shortcuts and instructions on their usage. > > This feature aims to streamline the workflow in the Django admin interface, making it more efficient and user-friendly, especially for power users who rely heavily on keyboard navigation. > > \### Discussion > > A discussion has been created \[here\](https://forum.djangoproject.com/t/django-admin-save-shortcuts/27016/2) ---
**Author:** ![carltongibson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/carltongibson/32/267_2.png) [@carltongibson](https://forum.djangoproject.com/u/carltongibson)\ **Post date:** [May 22, 2025, 4:26pm UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037/12 "2025-05-22T16:26:38Z")
Thanks for the example there @michaelschem — I’d not seen that PR. I think @thibaudcolas’ points show exactly why it is worth taking the time to specify this properly. It doesn’t look like much of an ask to get some agreement on a list of shortcuts, and then make sure they’re both functioning cross-platform and accessible before we “just merge” anything. Django is a mature project with a slow release cycle. Taking the short amount of time to _actually spec what’s being proposed_ is always going to be better than releasing something half-baked and then realising that it’s difficult to correct course. @khanxmetu From my perspective, please write up something on the new-features board — breaking it up however you think best. I agree there’s a broad consensus to do something here, so we can advance it to the _idea refinement_ phase quickly enough. From there, it sounds like, keyboard shortcuts would be a first target with the full command palette second. On that last, my **question** remains: is it a refined enough idea to target core, or should it evolve in a third party package in order to allow it to stabilise? (Note the emphasis.) ---
**Author:** ![khanxmetu](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/khanxmetu/32/28600_2.png) [@khanxmetu](https://forum.djangoproject.com/u/khanxmetu)\ **Post date:** [May 23, 2025, 9:32am UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037/13 "2025-05-23T09:32:02Z")
Carlton, thanks for your input. I think the accessibility team has a better reason aligned with their statement for wanting keyboard shortcuts merged to core than I could give. I think the question is whether such accessibility improvements belong to core or should be promoted as separate packages. I’d imagine most people find shortcuts as nice extras but not something they’d think first to add on their own, making adoption little difficult as @CodenameTim pointed. I don’t have a strong reason to believe it would need rapid adjustments/fixes once merged. I expect most of the work needed is on client-side and there are many examples of keyboard shortcuts implemented in javascript ecosystem. Sure, the scope (e.g how much configurability is expected) could be made clear beforehand and tests could be written extensively. For a full command palette, I think it makes sense to consider after keyboard shortcuts are worked. There is a concern of whether adding it would be redundant if shortcuts for the same commands would exist. I’m not entirely sure here myself, which is why I wanted to bring this up for discussion. Those are just my two cents of course. I’ve opened up a proposal at new-features board for keyboard shortcuts as a next step: [[Admin] Keyboard Shortcuts · Issue #34 · django/new-features · GitHub](https://github.com/django/new-features/issues/34) ---
**Author:** ![thibaudcolas](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/thibaudcolas/32/3956_2.png) [@thibaudcolas](https://forum.djangoproject.com/u/thibaudcolas)\ **Post date:** [May 23, 2025, 3:24pm UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037/14 "2025-05-23T15:24:25Z")
Here is the draft accessibility team spec based on the work of @tom and @khanxmetu: [GSoC 2025: Keyboard shortcuts specification](https://docs.google.com/document/d/1sFyl53B4IPWpYX7Q0vJYaNiCaJbe3Ym3_m1Dgk_gmr8/edit?tab=t.0) (still in internal review / drafting). This should fill some gaps in our shared understanding of which actions warrant shortcuts, how to assign keys / modifiers / combinations, and how to document available shortcuts. I’ve also listed five shortcuts which have already been proposed and seem clearly warranted. They all rely on modifier keys so the implementation is simpler. There is room for more shortcuts though for each it’ll be essential to go through the suggested steps (check it’s warranted, confirm the behavior, decide a key assignment). And talking about implementation, there is a bit of what I’d personally recommend, but goes well beyond the accessibility team’s remit: - A section about high-level decisions to be made - Proposed QA and review steps (at what stage to involve whom, what kinds of automated tests to write) * * * I’d recommend shelving the “command palette in core” concept for now, and any other shortcut concepts that rely on more UI than just a “available shortcuts” dialog. I think it’s very promising, as a core feature, to speed up even more of the admin actions. It also fits very well with how the Django admin is split across pluggable apps. See [Nielsen Norman’s Accelerators Maximize Efficiency in User Interfaces](https://www.nngroup.com/articles/ui-accelerators/) for more on the rationale. It’s 10x more front-end code than keyboard shortcuts though. It’s a good challenge to modernize the Django admin and bring it [much-needed UX improvements](https://www.coderedcorp.com/blog/why-is-the-django-admin-ugly/) without risking much on backwards compatibility. But for the GSoC project at least – feels simpler to me to focus on keyboard shortcuts. And if that’s easier than expected, you can work on the command palette either as a package or as a “new feature” proposal or DEP! ---
**Author:** ![michaelschem](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/michaelschem/32/17721_2.png) [@michaelschem](https://forum.djangoproject.com/u/michaelschem)\ **Post date:** [May 24, 2025, 6:38pm UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037/15 "2025-05-24T18:38:43Z")
@carltongibson yea, I’m happy to add tests and make sure to make the necessary changes to meet the quality of a mature project, I just didn’t get much traction from forms so I stopped work on it. If it’s any help to increase confidence in my PR, it’s been running in 5 fairly large Django projects for 4 years now across windows, mac, and chrome book with no issues. Not to say that we don’t need tests 😄 of course. ---
**Author:** ![jrief](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/jrief/32/17040_2.png) [@jrief](https://forum.djangoproject.com/u/jrief)\ **Post date:** [May 26, 2025, 6:42am UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037/16 "2025-05-26T06:42:16Z")
@khanxmetu An alternitive to Select2 without any dependency to jQuery is [Tom Select](https://tom-select.js.org/). I’m using it in my formset library [django-formset](https://django-formset.fly.dev/selectize/) and never experienced any issues with it. Tom Select is written in modern JavaScript and has TypeScript bindings. ---
**Author:** ![khanxmetu](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/khanxmetu/32/28600_2.png) [@khanxmetu](https://forum.djangoproject.com/u/khanxmetu)\ **Post date:** [June 19, 2025, 11:26pm UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037/17 "2025-06-19T23:26:49Z")
Hi, I want to share a quick update that I’ve created a [draft PR#19579 on Django](https://github.com/django/django/pull/19579) implementing the list of shortcuts that _so far appear to be clearly warranted_ as listed in the [GSoC 2025: Keyboard shortcuts specification](https://docs.google.com/document/d/1sFyl53B4IPWpYX7Q0vJYaNiCaJbe3Ym3_m1Dgk_gmr8/edit?tab=t.0) prepared by accessibility team. As a PoC, I hope this PR could give a better estimate of how much javascript needs to be introduced and assess the complexity vs flexibility we are aiming for. While we continue refining other proposed shortcuts, I’ll be adding more tests and also introducing new ones along. ---
**Author:** ![khanxmetu](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/khanxmetu/32/28600_2.png) [@khanxmetu](https://forum.djangoproject.com/u/khanxmetu)\ **Post date:** [August 21, 2025, 8:07am UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037/18 "2025-08-21T08:07:15Z")
Hi, We decided to continue this work as a third party package with the goal of eventually merging it into core later: [django-admin-keyshortcuts](https://github.com/khanxmetu/django-admin-keyshortcuts). The package is available via pip to try it out for anyone who finds it useful (feedback appreciated!). May I ask the [@steering\_council](https://forum.djangoproject.com/groups/steering_council) if there are any plans or updates regarding the process of endorsing third party packages by Django? ---
**Author:** ![carltongibson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/carltongibson/32/267_2.png) [@carltongibson](https://forum.djangoproject.com/u/carltongibson)\ **Post date:** [August 21, 2025, 10:22am UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037/19 "2025-08-21T10:22:38Z")
Thanks for the update @khanxmetu — that’s super! I shall install this and give it a run this week. ---
**Author:** ![CodenameTim](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/codenametim/32/31507_2.png) [@CodenameTim](https://forum.djangoproject.com/u/CodenameTim)\ **Post date:** [August 23, 2025, 1:45pm UTC](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037/20 "2025-08-23T13:45:56Z")
Thanks @khanxmetu, we’re going to discuss some possibilities internally (that’ll take a bit). However, one thing you could do is write a blog post about the package and maybe your GSOC experience as a whole? The community can boost that on their personal accounts, the Django social media team can boost it, and we can cross-post it on the [djangoproject.com](http://djangoproject.com) blog as well. If you don’t have your own blog, that’s not a problem, we can just share it from the [djangoproject.com](http://djangoproject.com) blog too. I only suggested starting with that because it helps us direct traffic and attention to you specifically. [Next page](https://forum.djangoproject.com/t/request-for-vote-admin-keyboard-shortcuts-and-command-palette/41037.md?page=2)