Acronym Aberrations Abbreviated
To comply with the requirements of web accessibilities, developers should identify and define any acronyms and abbreviations used in their web documents. Sounds simple, right? Things are not as they seem. Problems exist which cannot be countered so considerations need to be given and concessions made. The main problem: abbreviations are not supported by Microsoft’s Internet Explorer (MSIE), only acronyms are. But before going into the problems and solutions too far, let’s first determine what’s what as this also seems to be a source of disagreement.
I will start with dictionary meanings…
Acronym (n): A word formed from the initial letters of a name, such as WAC for Women’s Army Corps, or by combining initial letters or parts of a series of words, such as Radar for RAdio Detecting And Ranging.
(The American Heritage® Dictionary of the English Language, Fourth Edition - Copyright © 2000 by Houghton Mifflin Company.)
Abbreviation (n): A shortened form of a word or phrase used chiefly in writing to represent the complete form, such as Mass. for Massachusetts or USMC for United States Marine Corps.
(The American Heritage® Dictionary of the English Language, Fourth Edition - Copyright © 2000 by Houghton Mifflin Company.)
Notice the overlap, blurred lines, and potential for confusion? It befuddles many people. Personally, I always felt an acronym is when initial letters are used. However, based on these meanings, it seems it’s an acronym only when the initials form a pronounceable word, such as WAC (sounds like whack), or Radar. The rest, it seems, are, in fact, abbreviations. This could be ones guide. One, from what I can tell, the W3C agrees with as on their pages the letters HTML (not pronounceable as a word) are an “abbreviation,” short for HyperText Mark-up Language.
Okay, no problem, right? If we can define and differentiate, we can simply mark-up our documents with <acronym title=" "></acronym> or <abbr title=" "></abbr> as needed and where required. But wait, not so fast, due to MSIE’s lack of abbreviation recognition these methods present a problem: If we want to throw these things in our documents to be of help to our visitors, we can’t very well overlook this MSIE oversight, even if the methodology of such use is semantic. I mean what’s the point of using <abbr title=" "></abbr> if it won’t be supported or helpful? To be semantically correct?! I say no, but I don’t have the answers, nobody does from what I can determine by asking around — some say go with semantics while others say not to. Well, here’s I what I tried. It’s not the semantic approach, but one which helps the web document reader better understand the content and give all visitors equal access. I felt it was a good fix at the time.
I marked up all abbreviations and acronyms as acronyms. I did this so people using MSIE — which is a lot of people — will see what I wanted them to see. With this line of thinking, I also make sure I put information in my CSSs for the same reason, so they will be seen. You see, a standardized browser like Firefox will identify acronyms with a dotted underline without CSS support, but MSIE does not; it will not reveal a thing. When I first started doing this I decided, as a concession, to not only mark-up my documents with acronym only, but to then further define them in the title text, as follows:
<acronym title="[Abbreviation] HyperText Mark-up Language">HTML</acronym>
Instead of using the more proper…
<abbr title="HyperText Mark-up Language">HTML</abbr>
This seemed like a good fix. It would not only show the reader something was there worth checking out with the proper CSS support, but would explicitly define what it was too. I ran into a big problem, though, which was uncovered when I asked Experts [to] Perform Jaws Testing. Jaws, being a screen reader, would read that above as: Acronym, left-bracket abbreviation right bracket HyperText Mark-up Language, HTML. Not very friendly. I realized I needed to drop the [Abbreviation] part. This was disappointing as I thought I was onto a nice work around. hence I was back to the drawing board being stuck with a choice of doing right by the reader, but providing less information, or opting for semantic usage foregoing full access and information to all. (Note: Another problem revealed during testing was overuse, which lead to redundancy. I now keep it to one definition per acronym per page, and if I can, I define it right in the text, as in… HTML, or HyperText Mark-up Language, is part of this sentence. I do this to maintain smoothly readability and a better flow.)
These are my new rules, based on what I did before:
1) I still use acronym only as I refuse to use something unsupported just so I can say “I’m right” and “MSIE is wrong.” I choose to give my visitors an acronym they can see and further investigate. As so…
<acronym title="World Wide Web Consortium">W3C</acronym>
Here’s what it looks like: W3C
2) I limit usage on any given page and define the acronym/abbreviation within the text if it reads well enough. If there was a lot of them, I might consider adding an acronyms glossary.
3) I style acronyms in my CSS for the sake of MSIE. As so…
acronym , abbr {
cursor : help;
border-bottom : 1px dotted #666633;
}
Again, here’s what it looks like: W3C, when marked as an acronym.
And here’s what it looks like marked as an abbreviation: W3C (See this with MSIE).
Notes: I do add abbr so that part will be done if it is ever supported. The help cursor adds a question mark to the pointer on mouseover. The dotted line will be dashed in MSIE, but at least it’s an identifier (the color used is what I used for this blog).
4) I ignore the semantics argument and identify the acronym or abbreviation posing as an acronym for my visitors.
Update: I now use abbr for abbreviations not spoken as a word, and I use acronym on those that are. The most common of the two is abbr, by far.
Mike Pepper responds:
Posted: April 15th, 2005 at 11:20 am →
Great minds and all that ;o)