Foregoing any visual controls in your interface has numerous issues. Such an approach breaks 3 of Nielsen's 10 heuristics most obviously.
First, this breaks the concept of Graphical User Interface and user expectations of interaction. People are used to manipulating objects on the screen directly, meaning most people will expect to be able to use their mouse when dealing with a web-app.
Secondly, this creates the expectation of people to memorize all commands at the first use. This will force them to recall the available functions instead of recognizing them from the list on the screen. Chances are that most testers will give up after getting frustrated for forgetting something. This was one of the reasons why GUI took over CLI in mainstream computing.
Thirdly, this takes away the ability to choose input tools. Keyboard shortcuts are an alternative to direct manipulation that was created to minimize the time loss on input context changes (keyboard-to-mouse-to-keyboard). Forcing people to use only the keyboard to interact with your application without a justification isn't a good practice.
In terms of designing the shortcuts, you can create any keyboard shortcuts you like. There's only 1 rule for implementing them: don't break any native functions in the browser. This means that you need to account for differences in commands across browsers and platforms (e.g., CMD key on Macs and different shortcuts to launch private/incognito modes).
In terms of guiding users to discover, there are several good patterns.
- Just have the option mentioned in help documentation. GMail is very good at it. But also keep a shortcut for quick help available. The convention nowadays seems to be SHIFT+/ (or ?).
Mention the shortcuts in tooltips (like software used to do back in the day) and somewhere on the screen. Asana does this fantastically. The main section has quick help footer with some of the shortcuts listed:
And if you hover over task action buttons, the tooltips show the shortcuts: