An HMAC is a very simple construction. You could have come up with it yourself, except that HMAC is standardised which means that a lot of people looked at it and found it to be resistant against attacks. Because of the simplicity, we can just dive into the details:
hmac = hash(
(key xor opad) +
hash((key xor ipad) xor message)
So it's just some hash functions and xorring values together, nothing else. Block ciphers typically need a fixed-length key, but cryptographic hash functions "[map] data of arbitrary size to a bit string of a fixed size (a hash)". So the
key that you input, your password, can be of any size. The
hash() function in the snippet above can be any good cryptographic hash function, like SHA-3 or BLAKE2b.
Of course, longer typically gives more strength. A seven-character password, even if it is random and has symbols and digits and everything, can always be broken with modern computers. But the strength is not so much in the length, as in the method of generating it: a 22-character password that is just the string "mary had a little lamb" is not as secure as a 14-character password that was randomly generated. So be careful with how randomly you choose your passwords: a random phrase is one of a few billion options. A randomly generated seven character password already has 47 trillion possible values, and even that is insecure, though quite hard to remember for humans, so user passwords (memorized secrets) are likely to be weaker than that.
When you ask the user for a password, always run it through a "slow hash" function first. See a question like How to securely hash passwords for advice on the right algorithm and parameters to use. Only after you did that, should you use the password for anything. So before you use it as key for an HMAC, it is already strengthened and that random seven-character password would be impossible to break for the foreseeable future. This way, attacks cannot be done at the speed of that
hash() function like SHA-3, but have to be done at the speed of your slow hash, which will not be billions of guesses per second but hundreds. Going through 47 trillion options at a rate of a hundred per second takes some time!
 I don't mention SHA-2 because it's slowly getting old: it's vulnerable to length extension attacks, whereas SHA-3 and BLAKE2b are not. HMAC prevents length extension attacks, so HMAC with SHA-2 is fine, but I'd still rather recommend newer algorithms (so long as they are battle-tested; they're not that new) than something I know is vulnerable for an attack in a slightly different configuration.