Réponse à l'appel à commentaires sur le Référentiel Général d'Accessibilité pour les Administrations

Objet : appel à commentaires sur le Référentiel Général d'Accessibilité pour les Administrations

Document transmis à l'adresse suivante : dgme-rgaa arobase finances.gouv.fr

Bonjour,

En introduction de notre commentaire sur le Référentiel Général d'Accessibilité pour les Administrations (RGAA), notre groupe de travail tient tout d'abord à vous féliciter pour la qualité du contenu des documents produits (Descriptions des scénarios, Points de contrôles canal web, Tests canal web) et l'expertise évidente qui a présidée à l'ensemble.

L'accessibilité numérique est indissociable de l'interopérabilité.

Les utilisateurs de systèmes basés sur des logiciels libres ayant longtemps été exclus de certains services et sites web (ces situations se produisant d'ailleurs toujours) nous sommes très sensibilisés et sensibles à l'accessibilité numérique.

Nous envisageons donc l'accessibilité numérique, à la fois comme une volonté de non-exclusion des personnes et à la fois comme la qualité globale d'un système informatique de donner l'accès à tout type d'information sous forme numérique quels que soient le moyen d'accès, les contenus et le mode de consultation. Ce dernier point est très pratique pour les interactions non-humaines réalisées par des processus (moteurs de recherche, processus de supervision, fonction d'export pour assurer la pérennité des données, etc.).

Comme vous le savez en informatique, il n'y a pas d'accessibilité sans interopérabilité. L'inverse n'est pas forcément vrai, mais les notions d'accessibilité et d'interopérabilité sont tellement liées qu'il est difficile de concevoir l'interopérabilité sans l'accessibilité. C'est pour toutes ces raisons nous avions répondu à http://www.aful.org/gdt/interop/reponse-adae-2005 et c'est aussi pourquoi nous répondons aujourd'hui à l'appel à commentaires sur le RGAA.

Vous pouvez retrouver cette contribution en ligne à l'adresse canonique http://www.aful.org/gdt/interop/reponse-appel-commentaires-dgme-rgaa

Pour plus de précisions sur les points évoqués dans notre contribution n'hésitez pas à nous contacter.

---

1. Commentaires généraux

1.1 Numérotation des pages

Dans cette contribution toutes les références aux numéros de pages sont faites par rapport à la numérotation des fichiers PDF. Il a en effet fallu choisir entre se référer à la numérotation des fichiers PDF ou à celles des fichiers OpenOffice.org.

1.2 Besoin d'une navigation puissante

Une fois le RGAA validé dans sa première version il faudra le mettre en ligne dans une version HTML. C'est essentiel pour en rendre l'accès plus facile. Il faudra que le RGAA dispose d'une navigation dédiée et efficace pour faciliter sa consultation et les recherches en son sein. Une nagivation en HTML statique sera la plus appréciée, pas de menu dynamique JavaScript ni d'applet Java.

Plusieurs barres de navigation devraient être disponibles : Une barre simple avec seulement les points de contrôles et une barre complète avec les points de contrôles et les tests (comme la table des matières du fichier PDF sur tous les points de contrôles).

Il serait aussi nécessaire que la navigation puisse se faire selon plusieurs axes :

• axe par profil d'acteur (rédacteur/contributeur, graphiste/ergonome, développeur/intégrateur, communicant)
• axe par type de handicap (handicap visuel, handicap moteur, handicap congnitif)
• axe par type de technologie (HTML, CSS, JavaScript, images)

Le site web d'OpenWeb dispose par exemple d'une navigation selon plusieurs axes tout à fait exemplaire.

Un moteur de recherche restreint aux points de contrôles serait nécessaire.

Enfin, il faudrait que chaque point de contrôle et que chaque test soit atteignable directement par un URL. De cette manière on faciliterait les situations :

• où une administration explique à son fournisseur qu'il y a des erreurs dans la prestation
• où un administré explique à une administration qu'il y a un manque d'accessibilité

1.3 Trop nombreux tests parfois redondants

Le RGAA dans sa forme actuelle présente à notre sens un trop grand nombre de tests, d'autant plus qu'il nous semble discerner des redondances non justifiées entre certains tests successifs.

Il est plus facile à la consultation et la compréhension d'avoir moins de tests. Avec la quantité actuelle on a vraiment du mal à s'y retrouver. Nous trouvons que parfois une granularité moins fine serait donc préférable. On donnera les tests trop nombreux et dans certains cas redondants dans la partie Commentaires pourtant sur les Points de contrôles canal web.

1.4 Manque d'automatisation

Il est dommage que globalement les tests proposés pour les points de contrôle ne soient pas plus automatisés alors que dans certains cas c'est possible. Et c'est ce que nous proposons dans la partie Commentaires pourtant sur les Points de contrôles canal web.

Pour que les profils développeur/intégrateur arrivent à bien s'approprier le RGAA il faut leur fournir un maximum de tests automatisables. Si ce n'est pas le cas le RGAA risque de n'être que l'outil des spécialistes en accessibilité.

1.5 PNG et GIF

Dans tous les exemples des documents nous conseillons de remplacer les noms d'image du type XXX.gif par des noms d'image du type XXX.png. Cela incitera à la bonne pratique d'une plus grande utilisation du format PNG en place du format GIF. Cette démarche de mettre en avant les bonnes pratiques est déjà présente dans le RGAA qui donnent tous les exemples HTML en XHTML 1.0 et non en HTML 4.01.

1.6 Accessibilité côté boutique (côté backoffice)

La loi oblige actuellement que les sites/portails web publics soient accessibles à la consultation. Mais qu'en est-il de l'accessibilité pour les personnels qui travaillent et alimentent en informations ces portails/sites web ?

Actuellement on peut avoir une administration qui a commandé un portail/site web accessible pour le public mais avec le côté boutique (backoffice) de l'application qui est non-accessible ou seulement partiellement accessible. C'est souvent rédhibitoire pour les personnes touchées par le handicap et cette situation est particulièrement absurde dans les administrations qui ont des obligations quant à l'embauche de travailleurs handicapés.

Aussi nous souhaitons que le RGAA spécifie explicitement que le système de publication et de mise à jour des sites/portails web doit être accessible dans les mêmes conditions que le reste de l'application. Pour bien borner cette obligation on pourra spécifier que certaines parties boutique de l'application n'ont pas l'obligation d'être accessibles, notamment le système de configuration de l'apparence graphique de l'application.

1.7 Label

Compte-tenu de la qualité du RGAA, il pourrait être bon d'avoir un label officiel basé dessus.

---

2. Commentaires pourtant sur les Points de contrôles canal web

Point de contrôle 1.1

Les exemples de ce point de contrôle sont très bons et très parlants. Particulièrement bon le point indiquant que préciser une alternative vide pour une image est acceptable et conseillé si il y a un texte satisfaisant dans le contexte adjacent à l'image.

p. 8 Taille maximum de l'alternative textuelle : nous sommes pour une limite de 80 caractères et non une limite de 80 à 120 caractères. Notre expérience est que 80 caractères est une taille suffisante et correspond également au nombre maximum de colonnes de certains terminaux qui sont très souvent utilisés en informatique. Avoir donc une limite indéfinie de 80 à 120 caractères ne nous semble pas une bonne option.

p. 21 Test 1.1.14 : remplacer Si le contenu de l'attribut alt est le plus concis possible par Si le contenu de l'attribut alt a une longueur de moins de 80 caractères. Cela permettra notamment d'automatiser complètement ce test et limitera les problèmes d'interprétation car sinon le point de contrôle 1.1 ne fixe aucune valeur précise dans aucun de ses tests.

Point de contrôle 1.3

p. 27 : il y a un intitulé Exemple sans contenu associé.

Point de contrôle 1.4

p. 30 : définir concrètement la notion de synchronisation, notamment avec plusieurs exemples, de manière à ne pas laisser de place à différentes interprétations.

Point de contrôle 3.2

p. 52 : remplacer Permettre aux aides techniques de fonctionner correctement. En effet, la présence d'erreurs dans l'utilisation d'une grammaire formelle définie par le W3C peut perturber le bon fonctionnement des aides techniques. par Permettre aux aides techniques de fonctionner correctement. En effet, la présence d'erreurs dans l'utilisation d'une grammaire formelle définie par le W3C peut perturber le bon fonctionnement des aides techniques. La présence de ces erreurs diminue également l'interopérabilité.

p. 53, p. 54 : regrouper les tests 3.2.1 et 3.2.2 en un seul. Ces tests agissent exactement au même niveau et ont la même priorité, les séparer est contre-productif.

p. 54 Test 3.2.3 : mettre

Priorité
année N: Obligatoire
année N+1: Obligatoire
année N+2: Obligatoire

au lieu de

Priorité
année N: Recommandé
année N+1: Recommandé
année N+2: Recommandé

Pour nous la présence d'une DTD est essentielle. Elle indique comment comprendre le document. C'est la plus grande et plus importante critique que nous faisons au RGAA. Comment bien comprendre un document si on ne sait pas quelle grammaire et quelle sémantique il suit ?

La présence de déclaration d'une DTD et la validation qu'on peut ensuite effectuer sont l'un des rares points automatisables et pour lesquels il existe plein d'outils. Il serait complètement contre-productif de se passer de ce point de contrôle et de ne pas rendre ce test obligatoire. Le site web des statistiques de sites web conformes aux recommandations du W3C en donne un très bon exemple concret.

Sinon la présence du lien vers la recommended list of DTDs est une très bonne chose.

Mettre le point 3.2.3 avant le point 3.2.1.

p. 55 Test 3.2.4 : la validité en regard de la DTD déclarée utilisée est essentielle. La validité par rapport à une DTD est l'un des rares points automatisables et pour lesquels il existe plein d'outils. Il serait complètement contre-productif de se passer de ce point de contrôle et de ne pas rendre ce test obligatoire. De plus notre expérience nous montre que la validité en regard d'une DTD est l'un des rares points facilement compris par les profils développeur/intégrateur. Ne pas rendre obligatoire la validité en regard d'une DTD c'est priver les entreprises et leurs collaborateurs (les commerciaux qui rédigent les propositions, les chefs de projets qui pilotent et les développeurs qui réalisent) d'un moyen d'auto-évaluation efficace. Car en effet si ce n'est pas obligatoire, les entreprises et leurs collaborateurs l'utiliseront peu ou pas.

Mettre

Priorité
année N: Recommandé
année N+1: Obligatoire
année N+2: Obligatoire

au lieu de

Priorité
année N: Recommandé
année N+1: Recommandé
année N+2: Obligatoire

Mettre

Vérification
1. Si la page est envoyée sous forme de text/html et qu'elle est valide selon la DTD déclarée, le test est validé, sinon le test est invalidé.

au lieu de

Vérification
1. Si la page est envoyée sous forme de text/html et qu'elle est invalide selon la DTD déclarée, poursuivre le test, sinon le test est validé.
2. Si les erreurs de validation ne concernent pas l'imbrication des balises dans l'arbre du document ou l'écriture des balises et des attributs, le test est validé, sinon le test est invalidé.

La difficulté de mise en oeuvre devient alors Facile et l'automatisation Oui.

Point de contrôle 3.3

p. 56 : rajouter à la fin de Objectifs et intérêts Cela favorise également l'interopérabilité car la réutilisation (copier-coller/export-import) des contenus dans un autre contexte est ainsi facilitée.

Point de contrôle 3.5

p. 65 : vous écrivez A noter : il est autorisé d'avoir plusieurs h1 si votre structure de document le nécessite ce que nous approuvons. Il est très important de traiter ce point dans le RGAA car c'est un point qui fait souvent débat. Il serait souhaitable de rajouter quelques exemples de structures de documents qui nécessitent l'utilisation de plusieurs h1. On peut par exemple citer la présence de plusieurs entités documentaires dans une même page. Il faudrait aussi couvrir le cas de boîtes de contenus dans une page web, préciser si elles peuvent ou non avoir des titres h1.

p. 68, p. 69 : regrouper les tests 3.5.4 et 3.5.5. Qu'ils soient ainsi séparés est inutile et ne facilite en rien la compréhension et les tests.

Point de contrôle 3.7

p. 77 : il serait bon de donner les exemples de code HTML pour les citations des types suivants qu'on retrouve souvent dans les communiqués de presse et autres annonces :

Que les choses soient claires : Firefox 7 Beta 1 n'est pas encore sorti ! explique Tristan Nitot sur son blog.

Comme le dit Tristan Nitot sur son blog : Que les choses soient claires : Firefox 7 Beta 1 n'est pas encore sorti !

Point de contrôle 4.2

p. 85 : tout d'abord nous apprécions la pertinence et la précision de la définition entre l'acronyme et l'abréviation.

Par contre nous préconisons de toujours utiliser les éléments acronym et abbr avec l'attribut title pour les éléments dans le champ d'application. En effet des bouts d'une page peuvent être utilisés ailleurs et se retrouver dans un autre contexte que celui de la page initiale, par exemple dans un flux RSS. Dans ces conditions, la notion de première occurrence n'a plus vraiment de sens. De plus le remplacement des acronymes et des abréviations se fera sûrement automatiquement à partir d'un dictionnaire. Techniquement il n'y a pas de barrière, que le processus de remplacement automatique traite 1 ou N remplacements.

Point de contrôle 4.3

p. 88 : il serait plus logique de mettre ce point de contrôle sur l'identification de la langue et du sens de lecture des pages dans le point de contrôle 4.1, avant les points sur les changements de langues.

Point de contrôle 5.2

p. 95, p. 96 : les tests 5.2.1 et 5.2.2 d'une priorité obligatoire sur la déclaration d'attributs scope et headers nous semblent inutiles car ces informations peuvent être déduites de la structure du tableau de données si la structure du tableau est conforme à la grammaire (test 3.2.3 et test 3.2.4) et si il y a utilisation des éléments propres aux tableaux de données (test 5.2.3).

p. 96 : le test 5.2.3 devrait pour nous être obligatoire en année N+1 et nous vous faisons remarquer qu'il parait complètement illogique de rendre obligatoire les tests 5.2.1 et 5.2.2 dès l'année N alors que le test 5.2.3 qui est nettement plus naturellement structurant ne serait lui obligatoire qu'à partir de l'année N+2.

Point de contrôle 5.3

p. 98 : utilisez une formulation homogène avec le reste des libellés. Mettre Ne pas utiliser de tableaux pour la mise en page, à moins qu'ils gardent un sens une fois linéarisés. au lieu de N'utilisez pas de tableaux pour la mise en page, à moins qu'ils gardent un sens une fois linéarisés.

Point de contrôle 5.4

p. 102 : mettre dans Objectifs et intérêt

Si des attributs ou des éléments propres aux tableaux de données sont utilisés pour des tableaux de mise en page cela ajoute de la sémantique à du contenu qui n'en est pas porteur. Cela peut entraîner un changement du mode de navigation de certaines aides techniques, et perturber ainsi la lecture et la compréhension des contenus. au lieu de Si des attributs ou des éléments propres aux tableaux de données sont utilisés pour des tableaux de mise en page, cela peut entraîner un changement du mode de navigation de certaines aides techniques, et perturber ainsi la lecture et la compréhension des contenus.

Point de contrôle 6.5

p. 134, p. 135 : les tests 6.5.5 et 6.5.6 devraient être regroupés en un seul.

Point de contrôle 7.1

p. 139 : mettre une formulation couvrant tous les types d'images animées possibles et pas seulement les types mentionnés.

Mettre Ne pas utiliser d'éléments object, embed, applet, ou d'images animées comme par exemple des images au format GIF, MNG ou APNG à la place de Ne pas utiliser d'éléments object, embed, applet, ou d'images animées au format gif ou mng

Le format d'image APNG de par sa compatibilité ascendante avec PNG est promis à un bel avenir : APNG Specification, a simpler alternative to MNG

p. 140 : dans champ d'application, mettre img avec ressource graphique animée (GIF, MNG, APNG) au lieu de img au format gif ou png

Point de contrôle 9.5

p. 176 : typo mise en place de raccourcis clavier au lieu de mise en place de raccourci clavier

Point de contrôle 10.2

p. 186 : utilisez une formulation homogène avec le reste des intitulés de test. Mettre Bon positionnement des étiquettes par rapport aux champs dans les formulaires. au lieu de Recherche d'éléments de formulaire ayant des étiquettes mal positionnées.

Point de contrôle 11.1

p. 195 : nous vous invitons à partout toujours mentionner XHTML avant HTML de manière à inciter à choisir XHTML plutôt que HTML.

Point de contrôle 11.2

p. 198 : dans ce point de contrôle il nous semble qu'il faudrait rajouter la notion de passer de HTML à XHTML avec une priorité recommandée et non obligatoire car l'utilisation de XHTML augmente l'interopérabilité (facilité d'export-import, traitements XSL automatisés, etc.) et facilite ainsi notamment l'ajout de processus de traitement des contenus pour les rendre plus accessibles.

Point de contrôle 11.3

p. 201 : typo, mettre les éléments textuels soient sélectionnables au lieu de les éléments textuels soit sélectionnables .

Point de contrôle 12.2

p. 219 : typo, mettre l'ensemble au lieu de l'nsemble.

Point de contrôle 12.3

p. 223 : typo, mettre le test est validé au lieu de le tests est validé .

Point de contrôle 12.4

p. 227 : typo, mettre De plus, la mise en place d'étiquettes permet au lieu de De plus, la mise en place d'étiquette permet .

p. 228 : vous donnez l'exemple d'un formulaire de recherche et vous écrivez que ce formulaire ne nécessite pas d'étiquette via un label. Nous ne sommes pas d'accord car les étiquettes sont vraiment très utiles car elles agissent comme un « agrandissement » (comme vous le spécifiez d'ailleurs bien) de la zone à cliquer. L'utilisation d'étiquettes est ainsi une aide majeur pour les personnes avec des difficultés motrices ou les personnes ayant du mal à sélectionner une zone pour toute autre raison (véhicule en mouvement, périphériques mal adaptés, etc.).

On pourra ajouter l'exemple suivant sur l'utilisation d'une image conjointement avec des étiquettes :

      <label for="champRecherche"><img src="search_icon.png" alt="Rechercher"></label>
      <input id="champRecherche" name="recherche" size="15" type="text"/>
      <input value="OK" type="submit"/>
    

p. 229 test 12.4.1 : typo, mettre input type="text" au lieu de input type="texte"

Regrouper 12.4.1 et 12.4.2 en un seul test plus efficace en vue de rendre obligatoire la présence d'id et d'étiquette pour tous les champs de formulaire. De cette manière on obtient un nouveau test complètement automatisable.

Point de contrôle 13.1

p. 232, p. 234 : il nous semble important que vous mentionniez explicitement l'utilisation possible de l'élément button qui a l'avantage par rapport à l'élément input d'avoir le label qui va être affiché comme texte contenu et non comme attribut value. L'utilisation de l'élément button permet ainsi de réaliser des applications souvent plus propres et plus efficaces au niveau de leur code, notamment en ce qui concerne l'internationalisation :

      <button type="submit" name="add">Ajouter</button>
    

p. 238 test 13.1.5 : préciser la valeur de 80 caractères maximum de manière à rendre le test automatisable.

Point de contrôle 13.2

p. 239 : nous recommandons l'utilisation de l'encodage UTF-8, essentiellement pour des raisons d'internationalisation. Une application de l'administration commandée pour être en UTF-8 sera capable de gérer toutes les langues alors que si l'application a été commandée en Latin9 (ISO-8859-15) l'adaptation et la migration des données posera des problèmes. On peut en effet très bien avoir un site gouvernemental comme celui du Ministère de la Culture qui voudrait publier des articles ou communiqués de presse en chinois pour réaliser la promotion de musées ou autres expositions.

p. 240 : mettre l'exemple en UTF-8 avant l'exemple en ISO-8859-15.

p. 240, p. 241 test 13.2.1 et 13.2.2 : regrouper ces deux tests en un seul.

Point de contrôle 13.3

p. 247 test 13.3.4 : au niveau priorité, la présence d'un fil d'ariane devrait être obligatoire au moins en année N+2. Cette aide est en effet précieuse pour naviguer et pour comprendre la structure d'un site. De plus cette fonctionnalité n'est pas compliquée à mettre en place au niveau des applications. Il n'y a donc aucune raison de s'en priver.

Point de contrôle 13.4

p. 250 : regrouper les tests 13.4.2 et 13.4.3.

Point de contrôle 13.6

page 255, mettre

Fonctionnellement une ancre est soit un élément avec a avec un attribut name, soit n'importe quel élément muni d'un attribut id. À cause d'une erreur de synchronisation de la navigation au clavier lors de la prise de focus d'une ancre sur Internet Explorer, il est temporairement recommandé d'utiliser comme ancre un élément a. Cet élément a devra avoir un attribut id et un attribut href dont les valeurs sont identiques.

à la place de

L'ajout de l'attribut id sur n'importe quel élément HTML permet théoriquement d'en faire une ancre pouvant être la destination d'autres liens. Néanmoins, à cause d'une erreur de synchronisation de la navigation au clavier lors de la prise de focus d'une ancre sur Internet Explorer, il est préférable d'utiliser comme ancre un élément a. Cet élément a devra avoir un attribut id et un attribut href dont les valeurs sont identiques.

Le RGAA ne doit pas imposer une pratique non-optimale basée sur les défauts temporaires d'un navigateur qui a déjà beaucoup nuit à l'interopérabilité et à l'accessibilité du web (très mauvais support des CSS, box model erroné, mauvaises interprétations des DOCTYPE, les innombrables sites web accessibles uniquement à Internet Explorer, etc.). Voilà pourquoi nous préconisons la formulation temporairement recommandé.

Point de contrôle 13.10

p. 268 : dans Objectifs et intérêt préciser que l'art ASCII peut servir par exemple à représenter un diagramme simple sans avoir à recourir à une image bitmap. Un exemple de diagramme pourrait ainsi être donné plutôt qu'une représentation d'un lapin. Les administrations seront plus amenées à utiliser des diagrammes qu'à représenter des lapins. Enfin si on ne mentionne pas d'exemples sérieux d'utilisation d'art ASCII certains pourrait avoir l'idée de bannir complètement l'utilisation de ce type de représentation, alors qu'elles sont en fait plus accessibles que les images bitmap qui nécessitent elles l'utilisation d'un logiciel de visualisation au lieu d'un simple éditeur de texte du type VIM ou Notepad.

Point de contrôle 14.3

p. 275 : typo, mettre la mise en oeuvre de ce point de contrôle est grandement facilitée au lieu de la mise en oeuvre de ce point de contrôle est grandement facilité .

---

3. Commentaires pourtant sur la Consultation sur les scénarios envisageables

3.1 Au sujet des scénarios envisageables

p. 14 : Le choix porte sur la taille d'un échantillon de pages qui doit être valide. Nous conseillons de choisir le scénario A. Nous précisons tout d'abord que la notion d'échantillon de pages est très bonne car elle est applicable à des situations réelles de sites et portails web aux très nombreux contenus. Les autres scénarios ne nous semblent pas pertinents car :

• Ils n'introduisent en réalité aucune mesure d'obligation.
• Rien ne garantit qu'un site ou portail web soit globalement accessible si une partie seulement de pages prédéfinies est accessible. La notion d'échantillon est essentielle pour correspondre à la réalité de la vie des publications en ligne et à la réalité de leur consultation.

3.2 Au sujet des pages obligatoires

p. 15 : selon nous voici les pages représentatives et obligatoirement accessible pour qu'un site puisse être accessible :

• page d'accueil
• page de contact
• page de recherche et résultats de recherche
• page de déclaration de conformité
• page d'aide (si présente)
• page de plan de site (si présente)
• page questions fréquentes (si présente)
• page d'accès aux contenus principaux (ex : rubriques de premier niveau dans une arborescence, etc.)

Notez-bien qu'en ce qui concerne la page d'accueil, contrairement au document original, nous ne précisons pas (si contient un formulaire). En effet les pages de contact ne disposent pas toutes forcément d'un formulaire (même si cela peut être dans certains cas une obligation de disposer d'un tel formulaire) pour gérer la mise en contact. De plus certains sites pourraient mettre en place des images représentant des adresses courriel, au lieu de HTML décrivant ces adresses courriel, pour se protéger des pourriels.

3.3 Au sujet de la méthode d'échantillonnage

p. 15 : la notion d'échantillonnage est presque suffisante en elle-même en terme de qualité, de manière quasi-indépendante du pourcentage de pages concernées. En effet toutes les pages des sites et portails web sont généralement générées à partir de modèles et suivent un ensemble fini de traitements identiques. Aussi nous ne sommes pas pour proposer un pourcentage de pages trop important pour constituer l'échantillon.

Quantitativement l'échantillon devra être composé d'un nombre de pages égal à 10% du nombre total de pages du site/portail web avec un maximum de 40 pages (pages obligatoires exclues).

Qualitativement l'échantillon sera composé à part égale des pages les plus consultées et des pages les moins consultées du site/portail web.

Nous justifions l'importance des pages les moins consultées par le fait que des pages non-accessibles seront forcément moins visitées.