Abréviations, sigles et acronymes : balises, attributs HTML et accessibilité

Date de publication initiale : 2008-03-26 – Révision : 2008-07-11 (références AccessiWeb®) – Révision des conventions adoptées sur le site WebAccessibilite.fr : 2011-01-27

Auteur : [courrier électronique]Patrice Bourlonlien permanent

Résumé : l’écriture et le codage des abréviations au sein des pages Web ont donné lieu à de multiples articles et échanges, la plupart du temps en relation avec l’accessibilité numérique. Périodiquement, le débat est relancé sur tel ou tel aspect : faut-il coder une abréviation avec la balise abbr ou avec acronym ? Faut-il clarifier les abréviations dans le texte ? Faut-il traiter seulement la première occurrence d’une abréviation ou toutes ses occurrences ? etc.
Il n’y a d’évidence pas une seule « bonne réponse » pour le traitement des abréviations sur le Web. Cet article vise d’une part, à passer en revue différentes solutions/réponses possibles et d’autre part, à essayer de dégager quelques bonnes pratiques en la matière.

Sommaire de l’article

Abréviations, sigles et acronymes

Avant d’entrer dans le vif du sujet, un petit rappel concernant les abréviations, les sigles et les acronymes.

En français, un sigle ou un acronyme sont des abréviations.

Un sigle est une abréviation formée avec la première lettre de chacun des mots qui le composent et se prononce lettre à lettre (ex. SNCF, IBM…). Il s’écrit sans point d’abréviation entre les lettres, selon les conventions typographiques en vigueur (1).

Un acronyme est une abréviation formée avec la ou les première(s) lettre(s) des mots qui le composent et se prononce comme un mot ordinaire. Selon les conventions typographiques en vigueur, il s’écrit dans certains cas avec une majuscule initiale comme un nom propre (ex. Capes, Afnor…), ou sans majuscule, comme un nom commun (radar, laser, etc.).

Le mode d’écriture de l’abréviation pourrait à lui seul, dans un certain nombre de cas, définir s’il s’agit d’un sigle ou d’un acronyme. Exemple : URSS est un sigle et devrait être prononcé lettre à lettre ; Urss est un acronyme et devrait être prononcé comme un mot.

Ces 2 définitions correspondent sensiblement dans la langue anglaise aux 2 formes d’abréviations que sont un initialism (2) qui se prononce lettre à lettre et un acronym (3) qui, à l’instar de notre acronyme, se prononce comme un mot. Les conventions d’écriture en anglais peuvent toutefois être différentes des usages français.

Si les notions de sigle et d’acronyme sont assez proches entre le français et l’anglais, il peut bien entendu y avoir des compréhensions très différentes de ces termes dans d’autres langues.

Pour conclure cette introduction, notons au passage qu’il existe, outre les sigles et acronymes, de nombreuses autres formes d’abréviations parmi lesquelles :

Sommaire

Balise abbr ou balise acronym : laquelle utiliser ?

Au départ, les choses sont simples. Il existe en HTML 2 balises : abbr et acronym.

Partant des définitions habituelles des termes abréviations, sigles et acronymes, rappelées ci-dessus, on peut logiquement en déduire que toutes les formes d’abréviations doivent être codées avec abbr, à l’exception des acronymes qui ont leur balise spécifique, la balise acronym. Et en fait, il n’y avait là pas tellement de sujet à débat… Mais, la confusion sur le sujet a été créée, ou du moins a été entretenue, par les spécifications HTML et WCAG.

Sommaire

Spécification HTML 4.01

Les définitions données par la [externe]spécification sont claires :

Cela se complique toutefois, quelques lignes plus bas, quand la même spécification indique : “Western languages make extensive use of acronyms such as 'GmbH', 'NATO', and 'F.B.I.'.” GmbH ou FBI, des acronymes ?

Sommaire

WCAG 1.0 (techniques HTML)

Le document [externe]HTML Techniques for WCAG 1.0” indique : “Mark up abbreviations and acronyms with ABBR and ACRONYM and use “title” to indicate the expansion”.
Très bien, là encore pas de problème, mais dans la ligne juste en-dessous, la confusion se réinstalle par un des exemples donnés : <P>Welcome to the <ACRONYM title="World Wide Web">WWW</ACRONYM>!

Sommaire

Vers une clarification dans les nouvelles spécifications…

Voici donc des spécifications claires au départ, perturbées par quelques exemples malencontreux… Cette confusion est d’ailleurs reconnue par le W3C puisqu’on s’achemine vers un abandon de la balise acronym dans les prochaines versions HTML 5 (4) ou XHTML 2.0 (5) : à terme, c’est la balise abbr qui semble devoir être la balise unique pour toutes les formes d’abréviations, y compris les acronymes.

La version 2.0 des WCAG (6), dans sa version de travail, est plus floue sur ce point. Ne pouvant contredire les spécifications HTML ou XHTML, elle indique que la balise abbr peut être utilisée pour toutes les formes d’abréviations (incluant les acronymes) et, dans le même temps, elle indique également que, dans le cadre des standards en cours, la balise acronym peut être utilisée aussi bien pour un acronyme que pour un sigle (usage en fait introduit par les exemples non pertinents, mentionnés plus haut)… ces balises seraient-elles devenues interchangeables ?

Sommaire

La balise abbr est-elle reconnue par les navigateurs, par les lecteurs d’écran ?

Les navigateurs actuels reconnaissent les 2 balises. Parmi les versions récentes des navigateurs, seules font exception les versions 5 et 6 d’Internet Explorer. Mais il est assez facile d’y remédier par une simple ligne de code
(document.createElement("abbr");) ou par d’autres moyens (voir plus bas, articles divers sur le sujet).

Les lecteurs d’écran reconnaissent également les 2 balises. Ils en font cependant aujourd’hui une exploitation limitée : ils ne distinguent pas les différents types d’abréviations, n’énoncent pas toujours le contenu de l’attribut title

Sommaire

Alors au final, quelle est la bonne pratique ? Quelle balise utiliser ?

Sauf à adopter le point de vue consistant simplement à dire que le choix de telle ou telle balise n’a finalement pas d’importance compte tenu de l’exploitation limitée de ces balises par les lecteurs d’écran, ou que celles-ci sont interchangeables, deux modalités de codage peuvent être recommandées :

Sommaire

Les normes d’accessibilité concernant le traitement des abréviations

Les WCAG 1.0 ([externe]point de contrôle 4.2, de priorité 3) recommandent l’utilisation de l’attribut title (pour donner la signification de l’abréviation) des balises abbr ou acronym lors de la première occurrence d’une abréviation dans une page.

Les WCAG dans leur version 2.0 (version de travail), requièrent qu’un mécanisme soit disponible permettant d’accéder à la signification des abréviations ([externe]critère de succès 3.14). Les mécanismes possibles peuvent reposer sur l’utilisation des balises abbr et acronym, mais également sur d’autres procédés (glossaire, signification de l’abréviation en clair dans le texte à la première occurrence, etc.).

Le référentiel AccessiWeb dans sa version 1.0 requérait, conformément aux WCAG 1.0, d’utiliser l’attribut title des balises abbr et acronym au moins lors de la première occurrence d’une abréviation dans une page (critère 13.9). Il recommandait par ailleurs d’utiliser les points d’abréviation lorsque ces balises ne sont pas utilisées (critère 13.11).
La version 1.1 du référentiel AccessiWeb, publiée en juin 2008, apporte une clarification quant à l’usage de ces balises au travers des critères [externe]8.11, [externe]8.12 et [externe]8.13. La recommandation concernant les points d’abréviation est à juste titre abandonnée.

Le Référentiel général d’accessibilité pour les administrations (RGAA), [externe]dans sa version de travail (version finalisée non disponible à ce jour), est aligné sur le point de contrôle 4.2 des WCAG 1.0.

Sommaire

Clarifier les abréviations directement dans le texte ?

Il est souvent proposé/préconisé de clarifier les abréviations directement dans le texte lors de leur première utilisation. C’est d’une façon générale une bonne pratique rédactionnelle, initialement mise en œuvre pour le support papier et qu’on peut en effet utiliser au sein des pages Web.

Il faut toutefois être conscient des limites du procédé avant d’en envisager une généralisation.

Avantages :

Inconvénients :

Sommaire

Traiter la première occurrence d’une abréviation ou chaque occurrence ?

Qu’il s’agisse de donner la signification d’une abréviation directement dans le texte ou d’implémenter les balises abbr et acronym, le traitement « obligatoire » des abréviations, recommandé par les différents référentiels accessibilité, dans leurs versions actuelles, concerne généralement uniquement la première occurrence de l’abréviation dans une page. Ces mêmes référentiels ne portent toutefois pas de contre indication à un traitement plus systématique des abréviations.

Le fait de limiter le traitement à la première occurrence de l’abréviation sur une page est un héritage de la convention utilisée pour une lecture sur support papier. A l’écran, cela ne correspond pas à grand chose (lecture d’écrémage/de repérage beaucoup plus répandue que sur le papier, ancres qui pointent au sein de la page en sautant des blocs, etc.). C’est d’autant plus vrai si on n’a pas la vision globale de la page ; ex. : en naviguant avec un lecteur d’écran en mode entêtes/titres (balises h), un utilisateur peut tout à fait arriver dans un paragraphe qui contient une abréviation dont la première occurrence est 3 ou 4 paragraphes plus haut…

De plus, le fait de ne pas utiliser systématiquement les balises abbr et acronym – avec leur attribut title, ou sans – me semble une erreur sur le plan sémantique. Les abréviations devraient être repérées comme telles pour les agents utilisateurs – malgré les limites des versions actuelles des lecteurs d’écran, déjà évoquées plus haut… ces outils peuvent évoluer, de nouveaux traitements automatisés mis en œuvre, etc.

Enfin, notons que le traitement systématique des abréviations avec les balises ad hoc n’a pas d’effet de bord négatif sur les utilisateurs : les utilisateurs d’aides techniques ne sont pas obligés de « subir » le title de ces balises s’ils ne le souhaitent pas ; de la même manière, rien n’oblige les utilisateurs des navigateurs graphiques à survoler une abréviation s’ils n’en n’ont pas le besoin.

Sommaire

Faut-il traiter toutes les abréviations utilisées ?

Certains acronymes sont passés dans le langage courant et sont présents dans le dictionnaire comme des noms communs : radar, ovni, etc. Par ailleurs, certaines abréviations sont banalisées : M. pour Monsieur, Mme pour Madame, tél. pour téléphone, etc. Faut-il les traiter comme des abréviations ?

Les références normatives, dans leur version actuelle (7), ne font à ma connaissance pas d’exception pour ces acronymes passés dans le langage dans leur forme abrégée ou ces abréviations « courantes » (il serait effectivement impossible d’en faire une liste). On peut donc considérer que toutes les abréviations doivent être traitées par un procédé ou un autre.

Au-delà de l’aspect normatif, cela reposera surtout sur un choix éditorial. Ce choix devra toutefois prendre en compte la nature du procédé utilisé pour clarifier les abréviations :

Sommaire

Le codage des abréviations appartenant à une langue étrangère

La langue principale doit être indiquée au début de chaque page Web (balise meta, en-tête HTTP ou attribut HTML). Tout changement de langue au sein de la page doit ensuite être indiqué par l’attribut lang (ou xml:lang en XHTML) appliqué à l’élément contenant le fragment concerné. Ces indications sont particulièrement utiles pour les lecteurs d’écran ou autres traitements automatisés des pages et font partie des normes/recommandations d’accessibilité.

Le respect des normes d’accessibilité par l’application de l’attribut lang aux abréviations d’origine étrangère ne pose pas de problème particulier. L’attribut lang peut être ainsi appliqué :

Sommaire

Le problème

Un problème se pose cependant concernant la facilité de compréhension d’une abréviation. En effet, si une abréviation appartient à une langue étrangère et qu’elle est correctement codée, comme dans les exemples ci-dessus, l’attribut lang affectera à la fois la signification de l’abréviation mais aussi l’abréviation elle-même. Or, de nombreuses abréviations ne seront pas – ou difficilement – comprises par un utilisateur français non anglophone si elles sont prononcées en anglais : W3C, HTML, CIA, etc. alors que de ces abréviations peuvent par ailleurs être connues de l’utilisateur et seraient bien reconnues avec une prononciation française.

Ce problème peut bien entendu se poser avec des abréviations appartenant à d’autres langues que l’anglais et peut aussi bien concerner un utilisateur de langue allemande, espagnole, etc. même si ce n’est pas forcément sur les mêmes abréviations : ce n’est a priori pas un problème spécifiquement français.

Sommaire

Une solution

Une solution, déjà évoquée par différents auteurs (voir plus bas articles divers sur le sujet), consiste à différencier la langue dans laquelle sera prononcée l’abréviation et la langue dans laquelle sera prononcée la signification de l’abréviation.

Cela donnerait ainsi : <abbr title="HyperText Markup Language" lang="en"><span lang="fr">HTML</span></abbr>

Sommaire

Vers une généralisation du procédé ?

Peut-on automatiser/industrialiser le procédé ? Cela semble difficile car il y aura différents contextes et des exceptions à gérer. On peut toutefois essayer de définir quelques règles permettant une forme de généralisation et une application cohérente – à défaut d’une complète industrialisation.

Voici ci-dessous, quelques règles possibles pour l’application du procédé.

Définitions préalables :

Abréviation d’origine étrangère
Abréviation appartenant à une langue différente de la langue principale du document.
Contexte spécifique
Phrase, paragraphe, section, chapitre… au sein d’un document dont la langue principale est identifiée.

Cas 1 : le contexte spécifique dans lequel apparaît l’abréviation d’origine étrangère est dans la langue de l’abréviation (contexte lui-même affecté par un attribut lang si le codage est correct).

Solution : pas de traitement particulier. Si l’utilisateur est en train d’écouter un passage dans une langue étrangère, on peut raisonnablement penser que l’abréviation prononcée dans cette langue ne le dérangera pas.

Par exemple, la phrase W3C Publishes HTML 5 Draft, Future of Web Content” sera codée de la manière suivante : <p lang="en"><abbr title="World Wide Web Consortium">W3C</abbr> Publishes <abbr title="HyperText Markup Language">HTML</abbr> 5 Draft, Future of Web Content</p>

Cas 2 : le contexte spécifique dans lequel apparaît l’abréviation d’origine étrangère est dans la langue principale du document.

Solution : traitement de l’abréviation pour en obtenir une lecture dans la langue principale du document. Si un utilisateur est en train d’écouter une page dans une certaine langue, on peut raisonnablement penser qu’il lui sera la plupart du temps plus facile de comprendre l’abréviation formulée dans cette langue.

Par exemple, la phrase « Premier brouillon de HTML5 » sera codée de la manière suivante  <p>Premier brouillon de <abbr title="HyperText Markup Language" lang="en"><span lang="fr">HTML</span></abbr>5</p>

Cas 3 : et c’est la limite de la généralisation, une abréviation comme FBI qui est passée dans le langage courant avec sa prononciation anglo-saxonne… et dans ce cas, il est préférable de conserver la prononciation dans la langue d’origine de l’abréviation.

Il faut être clair, nous ne sommes pas ici dans le domaine normatif. Les standards d’accessibilité n’abordent pas ce point spécifique. Ce qui est évoqué ici sera plutôt à ranger dans la catégorie des bonnes pratiques, visant à améliorer la facilité de compréhension des pages (objectif indissociable toutefois de la notion d’accessibilité) et à éviter que certains utilisateurs ne soient pénalisés par la barrière du langage.

Sommaire

Articles divers sur le sujet

Sommaire

Notes

(1) Guéry (Louis), [externe]Abrégé du code typographique à l’usage de la presse, Victoires Éditions, Paris, 2005 (ISBN : 978-2-908056-97-6).
Perrousseaux (Yves), [externe]Manuel de typographie française élémentaire, Éditions Perrousseaux, Paris, 1996 (ISBN : 978-2-911220-00-5).

(2) “Initialism: an abbreviation consisting of the first letter or letters of words in a phrase (for example, IRS for Internal Revenue Service), syllables or components of a word (TNT for trinitrotoluene), or a combination of words and syllables (ESP for extrasensory perception) and pronounced by spelling out the letters one by one rather than as a solid word.” – American Heritage Dictionary

(3) “Acronym: 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.” – American Heritage Dictionary

(4) [externe]HTML 5 differences from HTML, Working Draft:“acronym is not included because it has created lots of confusion. Authors are to use abbr for abbreviations.”

(5) [externe]XHTML™ 2.0, Working Draft:“The abbr element indicates that a text fragment is an abbreviation […] this includes acronyms.”

(6) [externe]WCAG 2.0: “It is always appropriate to use the abbr element for any abbreviation, including acronyms and initialisms. When using HTML 4.01, XHTML 1.0 or XHTML 1.1, initialisms and acronyms may be marked up using the acronym element. XHTML 2.0 proposes eliminating the acronym element in favor of the more general abbr element.”

(7) La dernière version de travail des WCAG 2.0 apporte toutefois une précision sur ce point, au travers de la définition du terme abréviation dans le glossaire. Une abréviation est ainsi définie comme « une forme raccourcie d’un mot, d’une phrase ou d’un nom dont la signification originale n’a pas été rejetée par l’organisation à laquelle elle réfère et quand l’abréviation n’est pas passée dans le langage » (traduction non officielle, voir la définition dans le [externe]document normatif en anglais).

Sommaire