Éducation, société et technologie
Normes et standards

Ergonomie, compatibilité et accessibilité

pour faire un site web de qualité
jeudi 19 août 2004 par André Vincent

Les enjeux d’un site web sont multiples et sa compatibilité ainsi que sa qualité comptent parmi les premiers critères de sa réussite, tant au niveau quantitatif (trafic, nombre de commandes) que qualitatif.

Source : cet article est essentiellement une adaptation d’un article paru sur www.alsacreations.com rédigé par Raphaël GOETTER et Olivier HUBAUT

Pour être de qualité, un site doit être à la fois Utile (répondre à un besoin) et Utilisable (par tous).

Nous allons développer dans cet article trois grandes parties qui seront autant de principes universels de qualité.

Universels dans le sens où ils s’appliquent pour tous les sites web quel que soit leur thème (ludique, sobre, académique, artistique), leur concept (professionnel, commercial, associatif, amateur,...), leur objectif et le public visé.

  • Règles d’ergonomie.
  • Standards du web.
  • Normes d’accessibilité.

  Règles d’ergonomie

L’ergonomie est la façon de rendre un site utilisable par le plus grand nombre de personnes avec un maximum de confort et d’efficacité. Cette définition est souvent peu respectée au profit des technologies propriétaires (flash, scripts, balises propriétaires, etc...) qui rendent l’utilisation des sites souvent difficile.

À noter que s’il ne fallait retenir que deux principes essentiels d’ergonomie, ils seraient :

  • le Poids (de nos jours, 50 à 80ko pour une page web graphismes compris, semble correct) et
  • la Dimension (la norme reste encore la résolution 800 x 600 pixels, très largement utilisée). Cf statistiques du W3schools)

Pour analyser en profondeur l’ergonomie d’un site, il est possible de faire des audits d’accessibilité et des test utilisateurs, mais il existe des principes de bases dont voici une liste (non exhaustive) :

Objectif du site :

  • Afficher le nom et le logo de l’organisation ou de l’entreprise, en gros et bien en vue, en début de page et en permanence sur chaque page.
  • Ajouter une signature, descriptin ou slogan qui résume explicitement l’activité du site, à moins que le titre du site soit lui-même explicite.
  • Mettre en valeur les fonctions principales pour que la page d’accueil remplisse pleinement son rôle de point d’orientation.

Présentation des informations :

  • Inclure dans la page d’accueil un lien Contactez-nous ou À propos de nous qui pointe sur une page contenant toutes les coordonnées de l’organistion ou de l’entreprise.
  • Si le site receuille des informations sur les visiteurs ou les clients, ajouter sur la page d’accueil un lien Clause de confidentialité ou Politique éditoriale si le site autorise les visiteurs à laisser des commentaires ou contient une forme quelconque de forum.

Rédaction du contenu :

  • Privilégier un vocabulaire centré sur les visiteurs (pas de termes internes, trop techniques ou jargon commercial), à moins évidemment que le site d’adresse s’adresse à un public spécialisé.
  • Eviter les redondances, même pour souligner leur importance.
  • Veiller à la cohérence de la casse (majuscules/minuscules).
  • Eviter les listes à puces contenant un seul élément.
  • Décrire les actions à accomplir de façon claire, employer de préférence l’impératif (« Découvrez ce CD » est plus accrocheur et explicite que que « Vous pouvez découvrir ce CD ici » par exemple).
  • Développer la première occurence de chaque abréviation, sigle ou acronyme.
  • Éviter les points d’exclamation !
  • Ne pas abuser des majuscules, notamment dans les titres ou intertitres ; au-delà de 4 mots, la lisibilité en est progressivement réduite.

Illustration du contenu du site par des exemples :

  • Afficher une vignette, une illustration, un schéma ou une photo : ne pas se contenter de décrire.
  • Pour chaque exemple : proposer un lien direct vers l’article et non une page générique de catégorie.
  • Placer un lien vers la catégorie à côté de l’exemple.

Liens :

  • Différencier les liens et les rendre facilement identifiables.
  • Ne pas utiliser de terme générique, comme « Cliquez ici ».
  • Attribuer une couleur différente aux liens visités et non-visités.
  • Quand le libellé du lien n’est pas suffisamment explicite, fournissez aussi une description reactive comme ceci.

Navigation :

  • Installer la zone de navigation principale en un point stratégique, de préférence juste à côté du contenu principal de la page.
  • Regrouper les contrôles de navigation similaires.
  • Si le site propose une fonction de panier, insérer sur la page d’accueil un lien vers cette fonction.
  • Utiliser des icônes de navigation seulement si elles sont claires et universellement significatives.

Recherche : .

  • Proposer sur la page d’accueil une zone de saisie des critères de recherche (d’une taille suffisante et placée en haut de page). La recherche peut également être située visuellement en dessous du menu, à condition de rester sur le premier écran. Mais dans un tel cas, il faut veiller à rajouter un point d’accès en début de page.

Outils et raccourcis aux fonctions :

  • Donner aux internautes un accès direct aux fonctions principales du site (technique du « zéro clic »)
  • Ne pas proposer d’outils qui se contentent de dupliquer des fonctions du navigateur (ajout aux favoris, en page de démarrage,...)

Images et animations :

  • Se servir des images avant tout pour mettre en valeur le contenu plutôt que pour décorer simplement la page.
  • Ajouter une légende aux images et aux photos si le contexte ne suffit pas à les rendre explicites -* Ajuster les images à la taille d’affichage (plutôt rogner que rapetisser pour du jpg).
  • Eviter les éléments graphiques en filigrane (images en arrière-plan et texte au premier plan).
  • Ne pas utiliser d’animations en page d’accueil : déconseillées parce qu’elles n’apportent pas d’information et détournent l’utilisateur du contenu véritable.
  • Pas d’animation pour les éléments essentiels (logo, titre, signature) : c’est souvent assimilé à de la pub.

Conception graphique :

  • Utiliser avec modération les différentes polices de caractère et autres enrichissements typographiques. Au delà de 3 polices de caractère, la lisibilité peut s’en trouver perturbée. -* Rendre le texte lisible (contraste suffisant avec le fond de page) et taille raisonnable. Il convient de systématiquement indiquer la couleur du texte ET la couleur de fond.
  • Éviter le défilement horizontal avec une résolution 800x600 (cette résolution est encore largement utilisée). En 800x600 : les éléments les plus importants doivent être visibles d’entrée.

Interface Utilisateurs :

  • Eviter l’abondance de menus déroulants, surtout s’ils sont peu explicites.

Barre de titre :

  • Commencer le titre de la page par le terme le plus informatif (nom de l’entreprise ou de l’organisation).
  • Ne pas mettre le nom de domaine, sauf s’il fait partie du nom de l’entreprise.
  • Inclure un bref descriptif du site.
  • Limiter le nombre de mots à 7 ou 8 au total.

  Standards du web

Les langages du web (HTML, XHTML, XML, CSS,...) reposent sur des normes et des Standards. Les organisations de normalisation, comme le W3C, créent un consensus à travers ces groupes et ces experts pour maintenir et développer des principes architecturaux cohérents. Utiliser une norme permet la compatibilité du langage, de bénéficier des dernières innovations mais aussi de s’assurer de la pérennité des documents dans le futur.

La norme actuelle est le XHTML (version 2.0 en préparation), en attendant le XML. Le XHTML est l’évolution du HTML dans la mesure où il facilite la maintenance et la relecture du code grâce à sa rigidité.

De ces normes découlent plusieurs avantages importants :

  • Utiliser les dernières technologies standard vous assurent une site web fait pour durer, tout au long de l’évolution des langages et des navigateurs
  • La norme est universelle et votre site sera compatible avec tous les navigateurs respectant cette norme. Fini les codes propriétaires qui ne fonctionnent que sous certains navigateurs ou systèmes d’exploitation !
  • Des coûts et du temps de maintenance réduits ; en effet, la rigueur du XHTML permettent une lecture facile du code et une mise à jour très simple du design et de la mise en forme, celle-ci étant séparée du contenu.
  • Un design accessible. L’accessibilité aux divers handicaps (visuels, moteurs, auditifs, ...) a été intégrée dans un nombre important de normes. Un site doit pouvoir être disponible pour des utilisateurs aux demandes toujours plus importantes (voir partie suivante)
  • Allègement du code et accélération des pages : le code xhtml strict est léger du fait de sa séparation en feuilles de styles. La feuille de style étant placée en mémoire sur l’ordinateur (cache), la vitesse d’affichage des pages s’en trouve grandement améliorée.

Le XHTML repose sur le HTML (il ne lui rajoute rien mais lui retire certaines balises et attributs) ni plus, ni moins. La grande différence du XHTML avec son jumeau HTML est que sa syntaxe ne souffre d’aucune souplesse.

Pourquoi alors avoir créé le XHTML si c’est pareil à du HTML ? Pour habituer les webdesigners à la rigidité syntaxique du XML qui détrône peu à peu le HTML. Mais le XHTML n’est pas uniquement destiné à servir de transition, il reste un langage à part qui suit lui-aussi des évolutions.

Syntaxe

La grammaire du XHTML répond à certaines règles :

  • Les noms des balises et des attributs sont en minuscules. On écrit :
    <p> et plus <P>.
  • Les valeurs des attributs sont entre simple ou doubles quotes. On écrit : <p class="center"> et plus <p class=center>.
  • Tout attribut doit impérativement avoir une valeur. On écrit :
    <input type=&quot;checkbox&quot; checked= &quot;checked&quot;>et plus <input type=&quot;checkbox&quot; checked>..
  • Toute balise ouvrante doit être refermée. On écrit :
    <p>blabla</p> et plus <p>blabla.
  • Toute balises unique doit également être refermée. On écrit :
    <br /> et plus <br> ou encore : <hr class="top" /> et plus <hr class="top">.
  • Les balises doivent être correctement imbriquées. On écrit : <p><i>blabla</i></p> et pas <p><i>blabla</p></i>.

Tout document qui se conforme strictement à ces règles sera dit bien formé syntaxiquement.

Mise en forme logique

Le XML étant un système de balisage du contenu, les mises en forme qu’il opère sont purement logiques. Ainsi avec le XML, on ne se préoccupe que de la structure logique du document. Pour la mise en forme (caractères, couleurs, marges...), on utilisera les feuilles de styles.

Voici donc la principale ligne de conduite du XHTML : séparer le contenu de la mise en forme.

De même, en XHTML, il est recommandé d’abandonner les balises de mise en forme physique comme <i> (italic - pour mettre en italique) au profit des balises de mise en forme logique comme <em> (emphase pour mettre en valeur) ; idem pour la balise <strong> utilisée au profit de la balise <b>.

La sémantique

La sémantique d’un objet, c’est son SENS, ce pour quoi il est FAIT. Pour des questions d’Accessibilité (aux handicaps par exemple) et de maintenance , il est recommandé d’utiliser chaque balise de façon sémantiquement correcte.

Exemple imagé :

Quand vous buvez une soupe, vous utilisez une cuillère à soupe. Après, si vous tombez à cours, vous pouvez toujours vous rattraper en utilisant une cuillère à café. Ca sera moins pratique mais vous arriverez quand même à boire votre soupe. Le problème, c’est qu’elle risque d’être froide avant que vous l’ayez terminée.

Pour le (X)HTML, c’est pareil. Pour définir un titre, on utiilise la balise <h1>, mais on pourrait arriver au même résultat VISUEL avec un <p font-face=7><b>. Seulement, c’est plus long à écrire, c’est pas fait pour, lorsque vous aurez à changer tous vos titres, vous mettrez nettement plus de temps que si vous aviez simplement à modifier UNE feuille de style.

Dans le respect des règles, il y a non seulement l’aspect syntaxique, déjà souvent rapelé par divers sites, mais également l’aspect sémantique, trop souvent oublié. Il est tout a fait possible de faire un site rempli de tableaux pour la mise en page qui passera sans problème au validateur.

Or un tableau est conçu initialement pour afficher des données... tabulaires (un forum par exemple) et non pour faire la présentation de sa page.

Feuilles de styles

L’idéal est d’abandonner toute balise de mise en forme pour n’utiliser que les deux balises suivantes : span et div. Ainsi, fini les font, center et autres aberrations !

Evidemment, ces deux balises devront être associées à des feuilles de style pour pouvoir mettre en forme les pages.

Exemple : <div style="font-family:verdana,arial; font-weight:bold; color:red;"> ou mieux : <div class="erreur">.

Note : Les balises <div> sont des balises neutres servant de conteneurs, de blocs. Ils désignent une boite rectangulaire invisible.

Généralement, la balise <div> est assimilée au concept de "calque" (surtout sur les éditeurs html comme Dreamweaver).

Un calque est un <div> qui a été positionné avec la propriété "position : absolute", "position : relative" ou "position : fixed" .

Mais rien ne nous oblige à imposer cette propriété de position, on peut souvent s’en passer en plaçant les div les uns par rapport aux autres grâce à diverses autres propriétés telles float ou margin.

Pourquoi le XHTML, pourquoi valider ?

Le HTML 2 date de 1994 et le 3.2 de 1996. Le langage évoluait surtout suivant l’impulsion des éditeurs de navigateurs (d’abord Netscape puis Microsoft). La guerre entre MS et NS a vraiment éclaté avec Netscape 3 en 1996, soit à peu près en même temps que la recommendation 3.2. Le HTML 4.0 est le résultat d’un véritable travail de mise en commun des acteurs du net dont MS et NS ont fait partie. Les principaux ajouts dans cette version sont des balises sémantiques (les span entre autres) et quelques balises moins heureuses (le iframe).

Devant cette jungle et le danger réel pour que chacun parle son propre langage sur le Web, ce qui allait à l’encontre des principes d’Internet (libre accès aux données, interopérabilité), le W3C a sorti plusieurs normes sur le HTML (2.0, 3.2, 4.0...) qui se sont efforcées de coller le plus possibles aux fonctionnalités des navigateurs. Aujourd’hui la situation est inversée : les normes actuelles sont clairement en avance par rapport aux navigateurs dans plusieurs cas.

Le XHTML n’apporte rien d’autre qu’une simplification du langage, par la suppression d’attributs et un formalisme plus strict. On ne peut donc pas dire qu’il soit tellement « en avance » vu qu’il se base sur le HTML 4 qui date de 1997 et que tous les navigateurs actuels supportent à 99%.

Pour ce qui est du CSS, effectivement, il est encore en avance, bien que le CSS 1 soit compris par tous les navigateurs dignes de ce nom... même si certains navigateurs populaires (IE entre autres) buttent encore parfois sur certaines propriétés.

Le XHTML 1.0 et le HTML 4.01 existent en fait en 2 versions :

  • une version dite Transitional. Cette version sert juste à valider la syntaxe par étape. Elle se contente donc de vérifier que le balisage est correct sans traiter les attributs qui sont retirés par après lors du passage à la version strict.
  • une version dite Strict. Beaucoup de d’éléments ou d’attributs sont dépréciés (et donc interdits). Ce sont en particuliers les balises de mise en forme (<center>, <font>...). Le but est de pousser les développeurs à utiliser le CSS pour la présentation et de ne laisser dans le document HTML que le contenu.

Faire un site aux normes, revient à faire 2 choses :

  • Déclarer quelle version du HTML ou du XHMTL on utilise. On doit pour cela déclarer au début du document HTML un DOCTYPE (cf Références ci-dessous) .
  • Se conformer à cette déclaration. On peut pour cela utiliser les Validateurs du W3C, en sachant que le Validateurs ne font pas tout : un document peut être valide sans pour autant être propre sémantiquement parlant.

Le validateur (X)HTML : http://validator.w3.org/

Le validateur CSS : http://jigsaw.w3.org/css-validator/

Bien entendu, rien n’oblige un développeur à se conformer à une norme, mais cela présente plusieurs avantages : assurance que le site ne sera pas dégradé dans le futur, affichage correct sur une plus large palette de navigateurs, meilleure accessibilité, etc.

De plus, faire un site aux normes strict c’est faire un code plus propre et plus facilement évolutif (par rapport aux futures normes). L’inconvénient est qu’il est beaucoup plus difficile d’avoir un site qui passe parfaitement sur les anciens navigateurs et sur les nouveaux. (mais on peut aussi tourner la question autrement. Avec les anciennes « techniques », peut-on faire la même chose qu’avec les CSS ? La réponse est non. Les torts sont donc partagés.)

  Normes d’Accessibilité

Chaque individu est différent et internet doit être adapté à tout le monde, quel que soit son handicap (physique, auditif, visuel, ...).

C’est pour cela qu’il existe également des standards et des normes d’Accessibilité du Web (WCAG)

Pour info : l’agence fédérale américaine pour le handicap considère que l’obligation d’accessibilité aux lieux publics s’applique aussi à tous les sites Web. Rappelons que la Section 508 oblige déjà les sites gouvernementaux (ainsi que ceux qui sont financés en partie par le gouvernement, dont les fournisseurs du gouvernement) à être accessible. Plusieurs gouvernement occidentaux songent à emboîter le pas, dont le gouvernement du Canada.

Un mot sur l’Accessibilité

Les handicaps affectant l’accès au web peuvent être regroupés en quatre catégories :

  • Les déficiences visuelles. L’utilisateur peut être aveugle, avoir une vision très faible, ne pas reconnaître les couleurs ou tout simplement porter des verres correcteurs. Les objets graphiques qui n’ont pas d’intitulé ou de descriptif, des caractères trop petits ou des couleurs peu contrastées sont autant de barrières pour accéder à l’information.
  • Les déficiences auditives. Le manque d’explications ou de transcription des éléments sonores peut priver les personnes malentendantes de certaines informations.
  • Les handicaps physiques. Certains utilisateurs peuvent avoir du mal à manipuler le clavier ou la souris. S’il existe des périphériques optiques ou manuels mieux adaptés, il n’en demeure pas moins que des caractères trop petits, notamment au niveau des liens, ne permettront pas à certains utilisateurs de pointer ou de sélectionner convenablement, ce qui les privera d’un accès complet au site. Il en est de même pour certains scripts ou menu qui exigent la souris et qui sont inutilisables pour cette catégorie de personnes.
  • Les déficiences mentales ou neurologiques. Le manque de repères clairs et précis ainsi qu’un système de navigation non intuitif peuvent troubler de nombreux utilisateurs. L’utilisation excessive de certains jargons dans des sites grand public peut fortement réduire l’intérêt ou la compréhension. L’abus d’effets visuels de type clignotement ou d’animations dont la fréquence est trop élevée peut avoir de sérieuses conséquences sur des sujets sensibles ou épileptiques.

On estime que de 10 à 20% des individus présentent l’unfe ou l’autre de ces déficiences dans la plupart des pays dits développés. Certaines de ces déficiences ne sont pas un obstacle pour accéder au web, mais n’oublions pas que nous serons tous plus ou moins affectés un jour ou l’autre par le vieillissement.

Le W3C a donc lancé une Initiative pour l’Accessibilité du Web (WAI) en 1997 qui se donne pour objectif de s’assurer que les nouvelles technologies prennent en charge les questions d’accessibilité.

C’est dans cette optique qu’a été créé le WCAG (Web Content Authoring Guidelines).

Il s’agit de 14 directives qui décrivent les principes généraux du concept d’Accessibilité.

Des points spécifiques sont proposés pour chacune des directives et donnent des applications pratiques pour chaque principe.

Ces points de contrôle ont trois niveaux de priorité :

  • niveau 1 : le point DOIT être satisfait,
  • niveau 2 : le point DEVRAIT être satisfait,
  • niveau 3 : le point POURRAIT être satisfait.

La conformité à ces trois niveaux est codée de la manière suivante : A lorsqu’un site répond à toutes les exigences d’un point de contrôle AA lorsque le site répond à deux points de contrôle. AAA lorsque le site répond à toutes les exigences.

Il existe sur le net plusieurs outils de validation :

Chacun de ces sites web propose des outils de validation et de correction des erreurs.

À l’heure actuelle la plupart des sites internet, même professionnels ou soi-disant « Grand Public », ne sont pas du tout accessibles aux handicapés.

C’est pourtant la moindre des choses à faire, surtout lorsque ça ne nécessite pas de gros travail pour le mettre en oeuvre. Dans la vie « réelle », les choses bougent petit à petit pour les handicapés : places de parking, accès reservés, toilettes, accès spéciaux aux lieux publics... La prise en compte du handicap est devenu une évidence dans tous les cahiers de charges des travaux publics ou en architecture.

Pourquoi le web devrait-il laisser cette population à l’écart ? La proportion de sites institutionnels ou gouvernementaux qui ne respectent ni les Standards ni l’Accessibilité est considérable (http://jerotito.org/validations/).

En annexe : liste des points de contrôle pour l’Accessibilité

  Références :

  • developpez.com
  • Hardware.fr
  • L’art de la page d’accueil de Jakob Nielsen et Marie Tahir, éditions Eyrolles.
  • XHTML de Ann Navarro, aux éditions solutions.net

Liste des points de contrôle pour l’Accessibilité :

Le doctype :

Pour une liste complète des points à vérifier lors de production d’un site web, voir :


Accueil | Contact | Plan du site | | Statistiques du site | Visiteurs : 9239 / 1816296

Suivre la vie du site fr  Suivre la vie du site Cours Web  Suivre la vie du site Sites web statiques  Suivre la vie du site Normes et standards   ?    |    titre sites syndiques OPML   ?

Site réalisé avec SPIP 3.1.4 + AHUNTSIC

Creative Commons License

Visiteurs connectés : 7