Provided your library only uses C++11 in its implementation and doesn't expose C++11 facilities or types publically, and especially if you use static linkage, then yes, this is possible and even standard.
Consider the common case where a library exposes a C-level interface (to be usable by the widest variety of clients) but which is internally implemented in C++. Clients linking against such a library need only worry about the public binary API (exported functions), which you'll have constrained to be legacy C/C++ for maximum compatibility. A Java program can link to C-level APIs which are internally implemented in C++. This does not mean that Java needs to "support C++". Similarly, an old-style C/C++ client can link to a C-level or C++-level API which internally uses some more avant-garde version of the C++ libs or any other libs. Two separate things: what's required to link to the library's interface, and what the library itself internally links to (or pulls in statically).
You simply don't expose clients of your library to the dependencies of your implementation.
If you can statically link your dependencies (C++11 or whatever else) into your library, this is clean and self-contained. The library is a true black box: nothing but bytecode. But even if your library links to your dependencies via "implicit dynamic" linkage (not to be confused with the explicity LoadLibrary/GetProcAddress kind and the similar methods on *nix and OS X), older clients should still be able to link to that library's public interface, even if they couldn't link to the libraries the library depends on.