However, there's recent work [0] from Cornell that explores the security-usability tradeoff when correcting password typos. It turns out that accepting specific classes of typos (e.g., caps lock on: if password is "Password" then allow "pASSWORD") can increase usability with minimal security impact.
Reporting caps lock usage and not also keyboard layout usage is a pretty bad usability hole IMO.
Facebook does this, in case you weren't aware.
If a field is properly declared to be a password field (<input type="password" name="pwd">) of course ideally this wouldn't happen (plus, the characters get masked with stars, and hopefully what you type doesn't end up in your autocorrect dictionary, etc etc) - but it's full of shitty browsers out there.
My name in Greek has a letter with a double accent. Perfectly valid of course. But many (Greek) sites will reply that this NOT a Greek letter :)
At least they do not strip special characters out of the password.
Here's one idea: Let's say the user's password is P. The user enters some password P' with a typo. The authentication check is "does H(T_k(P')) == H(P)" for some set of transformations {T_1, T_2, ..., T_n}. Each transformation T_i hypothesizes that the user made a specific mistake. (e.g., T_1 is the caps lock is on so we need to flip the case of all the characters)
The paper I linked to actually does a good job motivating specific classes of typos by looking at real typos from Dropbox users.