This can be done by using the Mousetrap library.
Because something can be done does not make it a good idea.
Reason: It is simpler to press just one key instead of being forced to use two fingers/two hands to complete a specific task such as save, go to the search field and so on.
However, the purpose of the s key is not to save; it is to produce the letter 's'.
Function keys exist to allow keys to produce different results than their normal action. The most straight forward of example is the shift key, which allows the s key to produce both an 's' and an 'S'. The control (ctrl) key is aptly named as the functions it provides (should) control internal aspects of the program. For example, ctrl + s will save.
These combinations also allow for actions to happen without forcing the user to remove their hands from the keyboard.
Keys have meaning. You're purposing to break that meaning for no meaningful reason.
This might also be better for accessibility reasons.
Accessibility applications already exist, with many functions built into the OS itself. They expect certain patterns to be used and adjust those patterns based on norms to make difficult tasks easier for certain deficits. For example, "sticky keys" that allow modifiers to be activated without being held down.
Although just pressing s still might be easier, it is not necessarily more usable. You've altered the norms that the user regularly follows, forcing them to learn unique patterns for your application alone.
Of course, in input fields those shortcut keys will not be avaliable.
This is exactly why this is such a bad idea.
What you are purposing introducing an abstract interface mode with no distinct activation on the part of the user.
As the user navigates around your application their keyboard is suddenly being remapped without their knowledge or consent. When I hit the caps lock key I am expressly entering a mode in which I understand the results of my actions. I've entered a mode where s will produce an 'S' by default, but a ctrl + s will still save the document.
The focus state of a text field is not an appropriate indication of what input mode the user is in. A blue tinge around my cursor does not indicate to me that it is currently impossible to save my document.
In your scenario, the user can't save the the document so long as a text field has focus. The shortest certain way to save the document is to remove my hand from the keyboard and use the mouse to remove focus from the text field so that I can press s to save.
In this case, you've actually reduced accessibility.
Alternatively, the user is forced to hit tab to get focus out of the input field. Pressing tab doesn't actually guarantee that the focus might not just go to a different input field, still locking you out of your single key shortcuts.
At best, you've just forced the user to use tab then s to save instead of ctrl then s (with sticky keys enabled) to save. No advantage to accessibility there and still a detriment to usability.
Does it ever make sense?
In remapping standard control combinations... highly unlikely.
In performing unique actions based on a specialized user interface? Maybe. In these cases, task analysis would make clear the potential for such a situation; having any text entry certainly detract from the appropriateness.
