OpenSSL naturally will prefer newer MACs for **otherwise-equivalent** cipher suites. For example, the lengthy `openssl ciphers -v` output for your cipher string starts with:

    ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2  Kx=ECDH        Au=RSA    Enc=AESGCM(256)    Mac=AEAD
    ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH        Au=ECDSA  Enc=AESGCM(256)    Mac=AEAD
    ECDHE-RSA-AES256-SHA384        TLSv1.2  Kx=ECDH        Au=RSA    Enc=AES(256)       Mac=SHA384
    ECDHE-ECDSA-AES256-SHA384      TLSv1.2  Kx=ECDH        Au=ECDSA  Enc=AES(256)       Mac=SHA384
    ECDHE-RSA-AES256-SHA           SSLv3    Kx=ECDH        Au=RSA    Enc=AES(256)       Mac=SHA1
    ECDHE-ECDSA-AES256-SHA         SSLv3    Kx=ECDH        Au=ECDSA  Enc=AES(256)       Mac=SHA1

Of course, TLS will only use cipher suites supported mutually by both the server and client, and neither Chrome nor Firefox support HMAC-SHA256 cipher suites. Since HMAC-SHA1 (and even HMAC-MD5) are still considered secure, I believe their developers (and those of NSS, the TLS library they both use) are skeptical of wasting developer effort and TLS handshake size adding new, unnecessary, and backwards-incompatible cipher suites.

Look at, for example, [Chrome 33's supported cipher suites in order of preference](https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&version=33&platform=Win%207):

 1. ChaCha20-Poly1305,
 2. AES-128-GCM,
 3. AES-256-CBC with HMAC-SHA1,
 4. RC4 (ugh) and AES-128-CBC with HMAC-SHA1, ...

OpenSSL doesn't support ChaCha20-Poly1305. If yours doesn't support AES-GCM either (???) and uses an RSA certificate, `ECDHE-RSA-AES256-SHA` is naturally the cipher suite Chrome will use. (Firefox 29 would use `ECDHE-RSA-AES128-SHA`.)

(The "SHA-256" cipher suites you've seen being used on other websites are presumably ChaCha20-Poly1305 or AES-128-GCM, whose cipher suites use SHA-256 in the PRF.)