You may use any symmetric encryption which works by generating a key-dependent stream of bytes which is then XORed with the data to encrypt. This is the case of most stream ciphers; this also applies to a block cipher in CTR mode (which practically turns a block cipher into a stream cipher).
Such ciphers are a bit delicate to use, because you shall never reuse a given key-dependent stream (that would be the infamous "two-times pad"). This means that either a given key will be used to encrypt only one message, or that you use a stream cipher with an initialization vector which will need its own management. Crucially, in your case, this means that potential attackers should not be allowed to observe E(k1,t), E(k2,t) and E(k1,E(k2,t)), because this would enable them to recover t (namely by XORing all three streams together).
If your specific scenario make the stream cipher solution inapplicable, then you would have to use more esoteric solutions which are non-standard, thus cannot be recommended in practice (but are fine for research). For instance, given Diffie-Hellman group parameters (a modulus p, and a generator g which is such that gq = 1 mod p for a prime q which divides p-1), a subgroup element (a gx for some integer x) can be "encrypted" with key a by raising it to the power a (E(a,h) = ha mod p). "Decryption" implies raising to power 1/a mod q (inverse modulo q is computed with the extended euclidean algorithm). With this "encryption" algorithm, you get the commutativity you look for (E(a,E(b,h)) = E(b,E(a,h))) AND you can publish E(a,h), E(b,h) and E(a,E(b,h)) without revealing h.
... but that's just a variant of Diffie-Hellman. The good question is then: why do you want your commutative encryption thing ? What are you trying to do, that Diffie-Hellman cannot do ?