What is the abbreviation for without

Zett point, bee point

Literally it says:

Abbreviations and acronyms are to be explained where they appear for the first time in the content and are to be identified by the elements provided for this in the markup language used

In (X) HTML this "identification", i.e. the markup, can be done with the elements and.

This topic is primarily about comprehensibility and the need to explain abbreviations, which many users will certainly not understand. The area of ​​tension here lies between "Everyone understands that" and "Nobody knows what that means". The more you deal with the topic, the more it will become clearer to you that the benefits cannot always be clearly delimited. At the same time, the effort for a satisfactory solution can only be kept within limits with automated processes. In this article, many questions that arise when implementing this requirement are addressed and solutions are discussed.

What are Abbreviations and Acronyms?

In order to implement the marking of abbreviations and acronyms in (X) HTML documents in a meaningful way, you could look up in the Duden dictionary what exactly is the difference between these terms.

According to the German Universal Dictionary, 5th edition (Mannheim 2003):

… 3rd abbreviated word; Abbr .: abbr.
Abbreviation formed from the first letters of several words (e.g. EDP from electronic data processing).

Admittedly, the distinction between the two terms is not clear. Also, when defining "acronym", it is obvious that the example given consists of only two words. In contrast, the acronym in the same example contains three letters.

To simplify the delimitation a bit, we assume that acronyms are also used in the spoken language in the abbreviated form; "" Means "HyperText Markup Language", but almost everyone is talking about, and that's why "HTML" is an acronym in that sense.

Does the demarcation seem too easy to you? Nevertheless, read on to the end to find out the practical benefits of this demarcation and a technically feasible solution for this requirement from the BITV.

Requirement for explanation

Conveying the content to the user

When marking acronyms and abbreviations, it is certainly not just about achieving standard conformity through semantic marking. For example, by marking “ÖPNV” as no additional information is conveyed to the reader, except that it is an acronym. That, in turn, should already be clear to the user. In some browsers, the text is marked with a dotted underline or something similar and the user may wonder why this is so.

Marking an acronym or abbreviation without the attribute can be useful under certain circumstances, for example if you want to enter the attributes at a later point in time with the help of scripts and a database.

Rather - and although one can assume that readers should know this term - a reader could ask himself what »public transport« means. In (X) HTML, the explanation can be identified by the attribute:. As a result, in most graphical desktop browsers the explanation as a balloon text (new German: Tooltip) is displayed when a user moves the mouse over »ÖPNV«.

Screen reader users also have the option of viewing the explanation instead of of the acronym. The attribute replaces the acronym or abbreviation.

Similar to JAWS, other tools offer such functions. The IBM Home Page Reader from version 3.04 offers a comparable function »Expand abbreviations and acronyms« which, as in JAWS, leads to the replacement of an abbreviation with the attribute. In contrast to JAWS, the Home Page Reader only allows the resolution of either both or neither of the (X) HTML elements.

Like the Home Page Reader, the screen readerWindow Eyes does not differentiate between and, but allows further settings. The following settings can be made in versions 4.05 and 5:

Include Type:
The abbreviation and the type are read, i.e. whether it is an acronym or an abbreviation.
Both an abbreviation and an explanation are given. The type is also indicated.
Only the explanation (attribute) of an abbreviation is output. The type is not output.
No interpretation:
The markup in the (X) HTML document is ignored and abbreviations are output as they would be output without markup.

Other applications like Webformator 2.2 or Lynx neither support nor. Accordingly, screen readers that use such software are not able to preset the attribute as a substitute for an abbreviation.

Two basic aspects when marking up abbreviations

When designating abbreviations, it is usually a question of comprehensibility, but there are also other aspects that must be taken into account when designating them.


In case of doubt, abbreviations are unknown to the user, either because the abbreviations are not generally known or because the user is not very familiar with the German language or the subject of the text. Graduations can certainly also be made here, for example:

Acronyms that are generally spoken and used as abbreviations (»EU«, »DFB«, »UKW« ...). It is assumed that most readers are familiar with their meanings: "European Union", "German Football Association" and "ultra-short wave". These acronyms are very well known in the German-speaking world.

Acronyms that are commonly spoken and used as abbreviations, but whose resolution is less known, such as "ISDN" and "Radar". Although most readers can imagine something under these terms, very few will be able to spontaneously name their resolutions: "Integrated Services Digital Network" and "Radio Detection And Ranging". This group also includes acronyms that have long since found their way into everyday language. One example is the acronym »Azubi« (trainee), which even has a feminine form with »Azubine«.

Acronyms that are not common because they are usually not of general interest are, for example, "A12" and "CWS". These are abbreviations that are known to a certain target group, but not to the general public, and can therefore be confused. This refers to Committee 12 of the North Rhine-Westphalia State Parliament and the Christian Wirth School in Usingen. This group of terms also includes (well-known) abbreviations such as »IR«, which the frequent train driver says »InterRegio«, but the management consultant says »Investor Relations« and the CSS coder »Image Replacement«.

It is doubtful whether a gradation really makes sense. Rather, it should be assumed that in case of doubt a user does not know the meaning of an acronym and that the explanation should be made accessible. If you use the Acronym Finder or www.abkuerzungen.de at the latest, you will see why the explanation is important: Most acronyms have several meanings.


In screen readers and speech output, it helps the reading flow if abbreviations that are otherwise always pronounced are also resolved by marking them in HTML. Abbreviations that are often abbreviated in writing but pronounced in the spoken language are zett dot bee dot »z. B. «,» Fig. «(Illustration) or» Dr. «(doctor).

Such abbreviations can also be incomprehensible when you consider that not every reader on the web has a good command of the German language.

The intended elements in (X) HTML

The possible elements

From HTML 4 upwards, the elements provided for marking out acronyms and abbreviations are the elements (abbreviation = Abbreviation) and.

By the way, in the mid-1990s, when the specification for HTML 4 was still being developed, the situation was exactly the opposite of the current draft of XHTML 2: it was specified, initially not. Microsoft Internet Explorer 4 was developed and released on this basis. Despite the consideration of the element in the final specification of HTML 4 and many new versions of the browser, this bug persists to this day.

In the working draft of XHTML 2, however, the element is no longer intended, only. So you could go straight to the top, but there is still a small problem here: The current major browser Microsoft Internet Explorer (including version 6) only supports.

Since it is primarily about comprehensibility for the user, in the interests of the user it is currently not possible to do without in favor of.

To make an acronym or abbreviation easier to understand, these language elements need explanations. The explanations for and belong in the attribute of the respective (X) HTML element. There are two restrictions here:

  1. In most browsers, displaying the full spelling is only triggered by touching the mouse. Dee dot ha dot, the use of (X) HTML elements to explain an abbreviation is highly mouse-dependent, since they are not displayed when using the keyboard. This technology is therefore not accessible to keyboard users.
  2. is not yet supported by Microsoft Internet Explorer, so that all explanations of abbreviations are only available to many users if they are marked with.

The semantic abuse

But because there are two (X) HTML elements, they can be used in different ways. Technically it looks like that and offer the same functionality in the access software.

A differentiation according to linguistic standards is certainly neither the task of (X) HTML nor a web developer. For this, the delimitation of the two terms is not clear enough and presumably differs from language to language. Small peculiarities in every language cannot be represented with two (X) HTML elements.

The targeted use of

  • should be used to promote intelligibility
  • can be used for reading fluency in speech output

be used. This recommendation applies until all browsers support XHTML 2.

That is semantic abuse, but that is not the intended elements, that is simply wrong? From a linguistic point of view, you are certainly right, but there are three good reasons:

  1. HTML is a markup language that cannot semantically map the complexity of a language.
  2. and work in the same way on a website. A single (X) HTML element would suffice for this function, whether it was called,, or.
  3. It's about making it easier for your readers to understand and is currently the standards-compliant alternative that most users benefit from.

(X) HTML and the semantics of a language

There are many examples of the sense and nonsense of delimiting abbreviations and acronyms. The discussion is held again and again and a final result is not expected either for the German language or at the international level. With regard to the (X) HTML elements, a single example should suffice for the banality of the discussion.

There are acronyms such as "DV" (data processing) that are also used in compound words, such as "DV-Kauffrau". Because in the German language an "s" is often added to such compound terms, i.e. "data processing clerk", the question arises as to what belongs in the attribute for "DV":


The answer depends on the later actors. The first variant is certainly better and more correct to promote comprehensibility. In alternative access software, in which the title attribute replaces the acronym, the second alternative variant is better. If you use a tool that automatically generates a list of abbreviations based on the excellent acronyms and abbreviations, you will opt for the first variant again. These, like many other peculiarities of a language, cannot be intercepted with (X) HTML.

For this and many other reasons, the linguistic discussion cannot be argued with (X) HTML specifications. (X) HTML can only be used to structure content.

Alternative without (X) HTML

A good writing style is, for example, to spell out acronyms the first time they appear in a document and to put the abbreviation in brackets after them, such as "Web Accessibility Initiative (WAI)". Since the requirement of the BITV initially only deals with the first occurrence of an abbreviation or an acronym, this procedure should be sufficient to fulfill condition 4.2, even if neither nor are used.

The point is that a user gets the information they need to understand a text. By spelling out the first occurrence, the user has at least a chance to understand the meaning of the acronym. And here is the first trap of the BITV condition. It is required that the explanation of an acronym or abbreviation be identified with the markup language used. But if the text is written in an understandable manner and acronyms are spelled out, then the use of and is useless or even bypasses the supposed beneficiaries.

For example, has

no particular use for a reader, as already described above. One of the reasons for this is that aural CSS properties such as those used by speech output are not supported. If the support were given, the spelling of the acronym could be controlled via CSS

Rather, the output of a specific abbreviation is left to the access software. Most screen readers have the option of defining the pronunciation of certain terms, including abbreviations, using a user-defined dictionary.

Such presettings can also be made system-wide. In the MacOS X speech output, these settings look like this:

Also the spelling
has one disadvantage: Users of alternative access software such as speech output, which can output the full explanation instead of the acronym, receive redundant information:

It is possible that the assignment of the resolution to the acronym is completely lost, for example if "WAI" appears again a few paragraphs later and the user does not know this acronym.

The writing out of acronyms and abbreviations as in the classic media (explanation and abbreviations in brackets at the first occurrence) should meet the requirements of the BITV. The requirement to mark abbreviations with (X) HTML elements only arises if an abbreviation is not explained in the running text.

However, this notation has its limits: Many abbreviations »u. E. «(in our opinion) would not be written out first and then put in brackets as an abbreviation.

You could switch to always spelling out certain abbreviations in the text, for example "or" instead of "or". However, this is not always possible because the texts were written in a different department and right awayshould be put online. It must therefore be seen in the context of a development that texts, also with regard to acronyms and abbreviations, are already easier to understand when they are written.

Alternatively, scripts must be developed that automatically replace the texts when they are entered or called up; this aspect is discussed at the end of the article.

The spelling out of many abbreviations such as "and so on", "if necessary" or "that is" can contribute to the understanding.

Further information on the use of and can be found in Jasper Tverskov's article "Abbr and Acronym are for user agents not for end users". An interesting article about the sense and nonsense of and, but where the needs of the different user groups are not sufficiently taken into account.

More tips for marking abbreviations


It is almost superfluous to mention that acronyms and abbreviations provided with title attributes must be optically separated from the rest of the text. If this is not the case, the mouse user does not know either where she can or should point the mouse pointer in order to obtain additional, understanding-promoting information.

It makes sense to highlight an acronym across browsers. Some browsers display an underline for excellent acronyms and abbreviations, but Microsoft Internet Explorer's default setting does not highlight. If you implement the highlighting with a background color, at least one other property should be added due to condition 2.1 of the BITV:

    The border () is set so that the highlighting can be recognized by visually impaired users even with user-defined colors:

    The disadvantage of highlighting, for example with a background color, is that the text - especially with many distinctions - can appear restless.

    However, it is advisable to highlight it so that the user can benefit from your work.Possibly, on pages with many acronyms, the marking should actually be limited to the first occurrence, as required by the BITV.

    The above CSS properties would - depending on the browser - be applied to all texts with marked texts, including those without an attribute. The CSS specification sees the declaration

      for acronyms that have an attribute; Acronyms without an attribute should not be highlighted. But unfortunately not all browsers support this context-sensitive assignment of CSS.

      When makes sense

      annotation: Screen readers basically have three options for reading information from an application:

      1. the MSAA interface
      2. the off-screen model
      3. Windows messaging

      Only the first option depends on the application used (e.g. Microsoft Internet Explorer). Screen readers can also access the DOM on websites.

      Screen readers can access the element, even when using Microsoft Internet Explorer. For a 2004 study on the benefits of tagging content with various (X) HTML elements for screen reader users, see a publication by Mary Frances Theofanos: Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers.

      Abbreviations, which are mostly abbreviated in written texts but are fully pronounced in oral language, can be marked with the following notation:

      This example with »z. B. «is initially read out as» «in speech output, regardless of whether the element is present or not. If the user has set the voice output in such a way that it resolves abbreviations, the -attribute of the abbreviation, ie "", is displayed as a substitute.

      The consequences are:

      • Screen reader users can have the resolutions of abbreviations displayed.
      • Other users of Microsoft Internet Explorer do not even notice the awards due to the lack of browser support.
      • Users of other browsers (EOMB) see a balloon text when touching the mouse and, if necessary, underlined abbreviations.

      It is advisable to adapt the display of the element to the surrounding text in the CSS, for example with

        Language change

        Of course, language changes according to condition 4.1 of the BITV must also be taken into account for abbreviations, for example

        Reason for the more complex notation with: the attribute in affects both the attribute and the enclosed text. The acronym would also be pronounced in English if the user of a voice output did not have abbreviations read aloud. However, the example shows an abbreviation that would also be pronounced German in German.

        The language change from English for the explanation to German for the acronym also has a gray area. How would you use the acronym "AFN" (American Forces Network) pronounce in the shortened form? Most people pronounce this acronym in English. Transferred in (X) HTML, the notation is as follows:

        Annotation: The language indication is not only used for pronunciation in speech output, but also for semantic and other purposes. So even if »AFN« were to be pronounced in the abbreviated form in German, the doubt as to whether the marking with is semantically correct is understandable. Since the purpose of the distinction is to be seen in the sense of comprehensibility and less of semantic perfectionism, labeling natural language for better comprehensibility in speech outputs is legitimate.

        However, the assignment of the language can also cause conflicts. It is only possible to assign a single language to the attribute. So if you have multilingual titles, you need to orientate yourself towards the target audience in order to provide a suitable language specification.

        Text modules

        There are situations in which the reader does not see the "first occurrence" of an acronym or abbreviation, for example because the link to the page points to an anchor in the middle of the text. In such cases, it makes more sense not to include the explanation at the first occurrence on the page, but rather at the first occurrence in a section or even paragraph. Especially in long documents, where the user cannot necessarily skim through the text to find the resolution of an acronym, and offer a helpful way of promoting comprehensibility.

        The requirement to mark up acronyms and abbreviations at the section level is also closely related to dynamic systems such as blogs. Individual blog entries that represent the first (or last) text module for a certain period of time can later be displayed in completely different combinations. So it boils down to acronyms and abbreviations being marked in each text module.

        The longer documents are and the more complex the information architecture, the more likely all acronyms and abbreviations should be marked with and and corresponding attributes.

        Glossary / list of abbreviations

        An alternative to marking abbreviations with (X) HTML is to provide a glossary. Here, too, there are various considerations that you can take into account before implementation, depending on the content to be implemented:

        • How is the glossary created? The creation and expansion of a glossary with abbreviations requires either manual maintenance of the glossary itself, always depending on the content of a website, or the identification of the acronyms and abbreviations in the individual contents so that a script can dynamically generate a glossary from the excellent abbreviations .
        • Should the glossary be placed as a link at the beginning or at the end of the document? The advantage of such a solution is that you could save yourself the work of marking up the acronyms and abbreviations in the content. The disadvantage, of course, is that the link to the glossary does not appear where the knowledge question arises. This can be problematic, especially for keyboard users. The accessibility of such links with a shortcut - like on www.landtag.nrw.de - is very important.
        • Alternatively, the links to the glossary could be included directly in the text. In terms of usability, linking individual abbreviations and acronyms is certainly better than providing a general link. The general link has to be reached first, the new page has to be called up and the abbreviation searched for and finally you have to find your way back to the starting page and find the place in the text. When linking in the text, however, a link can be made directly to the explanation and a "back" function can also be designed so that a reader returns directly to where he left the page or the body text.

        Solutions to include links to a list of abbreviations on a page have almost no advantages, except that editors may be relieved by not having to use acronyms and abbreviations.

        Having to call up a new page, which basically contains exactly what would otherwise be in the -attribute or, is only the second-best solution for most users. The information should be taken into account immediately in the attribute.

        A glossary is primarily to be seen as an alternative to and so that keyboard users can access the information.

        Notes to your readers

        Your help pages should explain the different ways you can access information. What about the marking of the abbreviations in the text? And if you offer a glossary, the accessibility with the keyboard should also be discussed in particular. Information should also be provided for screen reader users.

        What did we learn?

        There are many unanswered questions. The bottom line is that the following premises must be considered:

        • (X) HTML cannot adopt the semantics of a complex language
        • The needs of all users for explanations of abbreviations can probably never be determined with certainty


        • Because Microsoft Internet Explorer is (still) the dominant browser, it can hardly be used to promote comprehensibility, because most users do not even receive the measures to promote understanding. There remain the possibilities
        • to "explain" abbreviations of any kind in the running text by always spelling out acronyms the first time they appear and abbreviations and
        • Use the element when the first occurrence of an acronym is not written out.

        An acronym only needs to be explained the first time it appears on a page, after that the abbreviation can be used on its own - without the explanation and without the (X) HTML element.

        The use of with the appropriate title attribute should be applied to the first or every occurrence of an acronym, unless otherwise explanations are provided in the text. The more access options there are to the information, the more useful it is to consistently mark acronyms with.

        Alternatives for labeling with these elements should be offered with regard to the device dependency of and. If abbreviations are not written out in running text, a list of abbreviations should also be provided for keyboard users.

        Furthermore, between

        • Comprehensibility (general) and
        • Reading fluency (in speech output)

        can be distinguished. Acronyms should be explained so that a user who can not begin with a certain abbreviation can get support. Other abbreviations, which are often abbreviated when writing, but are resolved when reading (aloud), can be marked with, because reading software can usually replace the abbreviation with the content of the attribute.

        Regarding the flow of reading, it should also be said that the element should be visually highlighted. With consistent labeling, this visualization can disrupt the flow of reading. The more abbreviations that are marked on a page, the more advisable it is to limit the marking to the first occurrence of an abbreviation.

        technical realization

        The question of technical implementation remains. Whether server-side or client-side, every solution requires reworking when it comes to abbreviations and acronyms that have different meanings.

        An automated search for »CD« (Corporate design, compact disc), "AT" (Old Testament, assistive technology), or many other acronyms, require a clear assignment of the correct explanation. You can safely work with different, topic-related data records, but absolute security can often not be guaranteed with the automated assignment of explanations.

        Abbreviations such as "so-called" and acronyms such as "BITV" - even if they contain adjectives and adverbs - cause problems in implementation. These problems also arise especially in the German language with compound words such as "DV-Kauffrau" (see above).

        Another motivation for you could be the article by Ian Lloyd "Why you should use acronyms and abbreviations to increase Accessibility". It not only explains the need to mark up acronyms, but also offers a tool for automatic conversion.

        In the article "Explaining abbreviations, acronyms and symbols on Web pages" by Jukka Korpela you will find a further discussion on the subject. Although similar problems are discussed there as in this article, the semantic difference between and for a recommendation is used there. As described above, it cannot be the job of (X) HTML to take over the semantic subtleties of any language.

        If you have developed an automatic system that identifies acronyms and abbreviations accordingly, we are happy to include or document the tool here.

        Such a script should

        • search a document for abbreviations,
        • if the acronym or abbreviation is unambiguous, mark with or with the corresponding explanation in and, if necessary, supplemented with an attribute,
        • in the event of ambiguity, ask the editor which of the options is the right one
        • be independent of platform and software

        as well as of course

        • if an acronym or abbreviation is assigned, the editor must be able to correct it
        • In the event of ambiguity, there must not only be a selection option, but also the option of adding further explanations to the database.

        If you are already marking up acronyms and abbreviations in your (X) HTML documents, you could go a step further. On the website of the computer center of the University of Erlangen you will find a pearl script that creates a glossary from the acronyms you have already created. The way it works is quite simple:

        1. The pages are regularly searched for and.
        2. The explanations and language information are recorded and made available as a list for a list of abbreviations.

        Such and other tools can be found time and again on the web. Another example is the "Acronym Plug-In for Movable Type" with a patch for. Such tools support the editorial work in the daily provision of content.

        If you do not have such technical possibilities, but want to fulfill condition 4.2 of the BITV, then you should either write out the award (»«) or at least mark it for the first time if the resolution does not appear from the text. You should also move on to using abbreviations such as »e. B. «write out (» «) and generally try to put understandable texts on the web.

        Discuss with us!

        We'd love to know what you think: share your experience with us and discuss this article with other experts.