Abbr vs. Acronym

Since I began learning accessibility, usability, and semantic web design, one rule I learned early on: regardless of whether it’s appropriate, always use <acronym> instead of <abbr>, because IE does not support <abbr>.

Reading Ian Lloyd’s tutorial on the use of these tags made me realize this is the wrong approach. I always thought that since I was using one of these tags, that was good enough. What I’m really doing is confusing those who do not use visual browsers. I’m telling a screen-reader to pronounce things that may be unpronouncable. This is worse than not completely correct — it’s flat out wrong.

What to do? Ian makes a variety of suggestions, some of which I think over-complicate the whole thing. For example, he suggests using classes to differentiate between abbreviations that should be spoken (but are not technically acronyms) and those that should be spelled-out. If you are that uptight about the whole thing, more power to you. The other person on the planet who feels that way will look at your code and smile. For the rest of us, <abbr> and <acronym> will be sufficient for usability, accessibility, and semantic purposes.

But, there’s still the problem of IE. IE still does not support the <abbr> tag, and it is likely that most people will never own a version that does. Ian suggests extra markup or JavaScript to solve this problem. However, one of the main reasons for adhering to web standards is less markup. And, it’s been my experience, when you try to solve a problem with JavaScript, you end up with more problems than when you started.

I’ve decided to take the MOSe approach that some are advocating. From now on, I will use <abbr> where appropriate. IE users will not receive any visual clues about abbreviations. My apologies, and if I can find a solution that does not involve JavaScript, browser detection, or bloated code, I’ll use it. I have a hunch that this will not adversely affect IE readers, but could save a lot of frustration for blind users. We will see.