Descriptive and Prescriptive Grammars
A useful distinction linguists make in describing grammars is “prescriptive” vs. “descriptive” grammars. Simply put, the difference is the prescriptive grammar is what your teacher tells you to do, but descriptive grammar is what actually happens. Sometimes they overlap, but sometimes it’s different, and generally speaking linguists will say that the descriptive is the one that’s “correct”.
A classic example of prescriptive grammar is to “not split an infinitive” meaning that the classic Star Trek phrase “to boldly go” is considered “ungrammatical” by some teachers. The reality is that it’s descriptively fine which is why it made it to the airwaves. Indeed, I would argue that the alternative “to go boldly” sounds clunky and “Boldly to go” sounds even worse.
As it turns out, “to boldly go” is perfectly consistent with spoken English grammar and has been around since Middle English. It was only later grammarians who declared this construction to be “wrong”…even though it has been in active use in spoken English.
Descriptive and Prescriptive Standards
Lately, I’ve been finding the same happening in some standards discussion, and I think it’s useful distinction there as well. Most Web and accessibility standards are important to maintain as there are real world consequences for violating them, but there are a few I would say are more “prescriptive”. They were invented with the best of intentions, but for whatever reason are too confusing for developers or not actually filling a need we thought was needed. In addition, the real world consequences for using one of the other other may be minimal.
One of these in my opinion is the infamous STRONG vs B debate (paralleled by the EM vs I debate). The theory is that B/I are visual formatting instructions only while STRONG/EM are levels of emphasis which could be indicated by bolding/italicized OR by a change in pronunciation in a screen reader.
The reality though is that almost all real world implementations treat B/STRONG and I/EM as tag synonyms. The most egregious cases are WYSIWYG editors which do “correctly” use STRONG and EM tags, but the icons are actually B and I. In other words, the non-saavy editor is just randomly adding visual formatting according whatever editorial rules are in place but never really distinguishing use cases. That editor is not really thinking semantically at all…because it’s a bit confusing to most editors. (BTW – This is not my original observation…but I really can’t find the person who pointed this out on a blog. It’s an excellent point though).
In another twist, screen readers also treat B/STRONG and I/EM as synonyms. In almost all modern screen readers, these tags are generally ignored by default – that is the words are pronounced with no distinction from regular text. There are modes in which formatting changes may be identified…but then either tag is picked up.
From a descriptive point, there is no distinction between the two tags and I am not sure one is needed by either the sighted or unsighted community. bolding/italics is a benefit for the sighted, but may be a distraction on a screen reader (just like color coding). In any case there is no distinction and there are plusses and minuses for each tag set. STRONG/EM is a good choice if you are translating texts between languages where formatting conventions can vary, but you have to admit that B/I is a lot leaner code-wise.
The truth is that I don’t have a recommendation, not even consistency because I am in a system which doesn’t really enforce it. I would however like this issue to just be permanently tabled until an actual real-world scenario is found.
Headings – Descriptively Important
I would contrast the above situation with the “heading” (H tag) situation in which standards experts note that section headings in a digital document should be specifically marked or tagged as a heading (vs. changing font formatting). This IS important for screen reader users who rely on the ability of their screen reader to jump between tagged headings. Screen readers recognize tags, but not formatting changes as valid headings.
Other Overly Prescriptive Standards?
I don’t have an exhaustive list, but I can detect the symptoms. If you are having a hard time explaining the importance of a standard or finding any real-world consequences, you may have a standard which is prescriptively valid but descriptively irrelevant, at least for everyday use.
One that comes to mind is the ACRONYM (NASA) vs. ABBREVIATION (Dr.). Aren’t these synonyms? Well, yes and no. Both acronyms and abbreviations are shortened written forms of longer phrases or words, but if the shortened word can be pronounced as a new word (e.g. NASA /næsa/ and not “N-A-S-A” for “National Aeronautics and Space Administration”) THEN it’s an acronym.
To be honest though, I’ve never heard phonologists (linguists who work with sound) much less everyday citizens make a systematic distinction, and usually it’s not that important, unless you are phonetics. While you do want to make sure you pronounce any abbreviated form correctly, knowing which is which is fairly trivial in most cases.
HTML gurus will know there are two gags – ABBR and ACRONYM. Unsurprisingly though, there are wide variations in how they are treated by different browsers with Internet Explorer only supporting ACRONYM at one point. Ironically though only ABBR is in the HTML 5 spec.