{"partition": "head_middle", "source_domain": "www.webaccessibilite.fr", "digest": "sha1:6XNDSQCFWQSVYAQENR7UTEDDCZEAFVE6", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2016-26/000_00010.parquet"}
Raccourcis et aides : Aller au contenu - Aller au menu -
Aide accessibilité - Plan du site - Glossaire
Vous êtes ici : Accueil > Articles et cas pratiques > Abréviations, sigles et acronymes : balises, attributs HTML et accessibilité
Site mis à jour le 8 janvier 2013
Ressources accessibilité
Référentiels accessibilitéLabellisation des sitesLiens utiles accessibilitéArticles et cas pratiquesSur le Web, actualités
Audit accessibilitéDemande de devisTest gratuitAssistance MOAFormations
Nous contacterDonnées personnellesInfos éditeur
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 Bourlon – lien 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
Balise abbr ou balise acronym : laquelle utiliser ?
Spécification HTML 4.01
WCAG 1.0 (techniques HTML)
Vers une clarification dans les nouvelles spécifications…
La balise abbr est-elle reconnue par les navigateurs, par les lecteurs d’écran ?
Alors au final, quelle est la bonne pratique ? Quelle balise utiliser ?
Les normes d’accessibilité concernant le traitement des abréviations
Clarifier les abréviations directement dans le texte ?
Traiter la première occurrence d’une abréviation ou chaque occurrence ?
Faut-il traiter toutes les abréviations utilisées ?
Le codage des abréviations appartenant à une langue étrangère
Le problème
Une solution
Vers une généralisation du procédé ?
Articles divers sur le sujet
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 : les contractions de mots par troncation des dernières lettres (ex. chap. pour chapitre, bull. pour bulletin, etc.) ;
les abréviations des mesures légales (ex. dB pour décibel, cm pour centimètre, etc.) ;
les abréviations conventionnelles (ex. cie pour compagnie, bd pour boulevard, etc.) ;
les abréviations des nombres ordinaux (ex. 1er pour premier, 2e pour deuxième, etc.) ;
les codes ISO des devises (ex. EUR pour euro, CAD pour dollar canadien, etc.)… et j’en oublie certainement.
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.
Les définitions données par la [externe]spécification sont claires :
“ABBR: Indicates an abbreviated form (e.g., WWW, HTTP, URI, Mass., etc.).”
“ACRONYM: Indicates an acronym (e.g., WAC, radar, etc.).”
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 ?
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>!…
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 ?
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…
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 :
soit, coder les acronymes avec la balise acronym et toutes les autres abréviations avec la balise abbr (en accord avec les spécifications actuelles) – c’est l’option choisie pour le codage du site WebAccessibilite.fr ;
soit, en accord avec les spécifications futures (HTML ou XHTML, sauf changement par rapport aux versions de travail actuelles), coder l’ensemble des abréviations (incluant les acronymes) avec la balise abbr.
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.
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 :
cela permet de présenter directement la signification de l’abréviation à l’utilisateur sans requérir d’action supplémentaire de sa part (lien vers un glossaire ou survol de l’abréviation avec le pointeur de la souris, par exemple) ;
cela permet, le cas échéant, en particulier pour les abréviations d’origine étrangère, d’en donner non seulement la signification, mais aussi une explication, voire une traduction ;
c’est plus adapté pour une lecture papier de la page Web imprimée ;
ce procédé peut être jugé plus aisé à mettre en œuvre que les balises abbr et acronym ou que des liens vers un glossaire.
Inconvénients :
la signification en clair s’« impose » dans le flux de lecture, y compris aux utilisateurs familiers avec l’abréviation (phrases plus longues, dégradation de la lisibilité, etc.) ;
on perd le repérage des abréviations, donné par les balises abbr ou acronym, pour un éventuel traitement automatisé – ou alors, il faut utiliser un autre procédé en parallèle ;
le procédé peut s’avérer impraticable sur des pages agrégeant des contenus en provenance de diverses sources ;
la notion de « première occurrence dans une page » n’a pas forcément beaucoup d’intérêt/de sens dans le cadre de la navigation Web (voir plus bas « Traiter la première occurrence d’une abréviation ou chaque occurrence ? ») ;
le procédé n’est pas adapté aux pages contenant un nombre important d’abréviations et en particulier pour le traitement des abréviations les plus courantes (voir plus bas « Faut-il traiter toutes les abréviations utilisées ? »).
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.
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 :
si on décide de clarifier les abréviations directement dans le texte, il sera préférable – compte tenu des inconvénients inhérents au procédé, mentionnés plus haut – de limiter au strict nécessaire les abréviations ainsi traitées ;
si par contre, on utilise le balisage HTML des abréviations – procédé moins intrusif –, on peut être plus exhaustif et traiter chacune des abréviations utilisées (et, comme abordé précédemment, chacune de leurs occurrences).
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é :
soit aux balises d’abréviation elles-mêmes (ex. : <abbr title="HyperText Markup Language" lang="en">HTML</abbr>) et dans ce cas, l’attribut lang affectera à la fois l’abréviation et sa signification (contenu de l’attribut title) ;
soit à un élément « parent » contenant l’abréviation (ex. : <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> ; dans ce cas, l’attribut lang affectera l’ensemble de la phrase, y compris l’abréviation et sa signification
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.
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>
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.
février 2008 – “JavaScript, abbr and Internet Explorer”, Jon Gibbins
février 2008 – “Screen readers and abbreviations”, Jon Gibbins
février 2007 – “Dealing with Acronyms & Abbreviations”, Mike Cherim
juillet 2006 – “Styling abbreviations and acronyms”, Russ Weakley
juillet 2006 – « Acronymes, abréviations et attribut lang », Sébastien Delorme
septembre 2005 – « Quelle est la différence entre les balises abbr et acronym ? », Chantal Ide
mars 2005 – “Abbreviations are a Breeze (French Version)”, Pamela Berman
février 2005 – « Spécifier la langue d’un document (X)HTML », Laurent Denis et Elie Sloïm
septembre 2004 – « Savoir utiliser les Acronymes, Abréviations et Sigles », Raphael Gœtter
janvier 2004 – “ABBR and ACRONYM are for user agents not for end users”, Jesper Tverskov
juillet 2002 – “HTML is not an acronym…”, Craig Saila
(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).
© 2007-2013 WebAccessibilite.fr