If there is no regulatory requirement, for AES-128, a good option would be splitting the SHA-256 hash into a key (128-bit), IV (96-bit), and any unused portion. That allows us to make the IV implicit (and secret, which is unnecessary, but does not harm) thus saves even so little bandwidth. For AES-192 or AES-256, we can do this with SHA-512 instead of using SHA-256.
On a related note, make sure that the same derived key is never used by a given party both to encrypt and decrypt/authenticate because that opens to mirror attacks. If the communication is bidirectional, derivation could use
as the origin of the session key and IV used by the sender to prepare its message. HMAC internally hashes the shared secret if it more than a certain size (64 bytes for SHA-256), that's fine.
For even stronger assurance:
which gives an argument that the leak of IV (which should be assumed even if the IV is not sent in clear) can't harm the secrecy of Key even if the hash has some level of defect. Also, HMAC has a parameter (now shown) to specify the output size, making the definition cleaner.