Exigences techniques pour le développement des produits du

Transcription

Exigences techniques pour le développement des
produits du Programme d’investissement pour les
expositions virtuelles du Musée virtuel du Canada
(MVC) – V. 2.1
Février 2014
mvc.museedelhistoire.ca
Table des matières
Exigences techniques pour le développement des produits
du Programme d’investissement pour les expositions
virtuelles du Musée virtuel du Canada (MVC) – V. 2.1 ............. 1
Table des matières...................................................................................... 2
Remarques préliminaires ............................................................................ 3
Sommaire des changements ..........................................................................3
Remarques concernant la terminologie ........................................................ 3
Remarques concernant le langage de balisage HTML5............................... 3
Remarques concernant l’optimisation mobile d’un site Web ..................... 4
Remarques concernant l’usage d’un système de gestion du contenu
(SGC) .................................................................................................................5
A) Accessibilité............................................................................................ 5
1.0 Principe 1 : Le produit doit être perceptible. (Règles 1.1 à 1.4) ............ 6
2.0 Principe 2 : Le produit doit être utilisable. (Règles 2.1 à 2.4) ................ 8
3.0 Principe 3 : Le produit doit être compréhensible. (Règles 3.1 à 3.3) .. 10
4.0 Principe 4 : Le produit doit être robuste. (Règle 4.1) ........................... 11
B) Formats ................................................................................................ 11
5.0 Balisage, présentation et scripts ...........................................................11
6.0 Répertoires, fichiers et adresses URL ...................................................16
7.0 Navigation, mise en page et conception ..............................................19
8.0 Types et formats de contenu .................................................................24
9.0 Cybermétrie et métadonnées ................................................................29
C) Technologies ........................................................................................ 35
10.0 Spécifications techniques du serveur et de la base de données ..... 35
Exigences techniques pour le développement des produits du Programme d’investissement pour les expositions virtuelles du Musée
virtuel du Canada (MVC) – V. 2.1, Février 2014
2
Remarques préliminaires
Sommaire des changements
Les Exigences techniques pour le développement des produits du Programme d’investissement pour des
expositions virtuelles du Musée virtuel du Canada (MVC), version 2.1 constituent une mise à jour des
exigences de la version précédente (version 2.0).
La mise à jour comprend les éléments suivants :
• L’intégration de HTML5 comme langage de balisage obligatoire pour la structuration et la
présentation du contenu;
• L’intégration de CSS3, qui s’avère obligatoire pour contrôler la présentation et le style de
contenu;
• La conception de sites Web adaptatifs visant l’optimisation mobile est maintenant obligatoire;
• L’instauration de nouvelles limites de taille pour les fichiers vidéo et audio optimisés;
• Changement important de la terminologie dans la section des Métadonnées, lesquelles sont
exigées dorénavant;
• Précision sur les requêtes médias;
• Une remarque importante quant à l’usage de Systèmes de gestion du contenu (SGC);
• Le retrait de l'exigence pour la validation des scripts JavaScript, et
• Le retrait de la section sur les données géospatiales. Il n’est pas permis d’inclure une
composante de réalité augmentée dans le cadre du programme d’investissement du MVC.
Remarques concernant la terminologie
Les définitions et les termes suivants, utilisés dans le présent document, sont directement adaptés de la
norme RFC 2119[title="Lien externe, RFC 2119 (en anglais seulement)]:
DOIT et DOIVENT : Ces mots indiquent une exigence absolue.
NE DOIT PAS et NE DOIVENT PAS : Ces expressions indiquent une interdiction absolue.
NE et PAS : Cette combinaison de mots indique une exclusion absolue.
PEUT et PEUVENT : Ces mots indiquent une mesure facultative qui est ni obligatoire, ni interdite.
DEVRAIT et DEVRAIENT : Ces mots indiquent une mesure recommandée qui peut être ignorée
dans certaines circonstances, et dont l’ensemble des répercussions doivent être comprises avant
la mise en œuvre de celle-ci.
NE DEVRAIT PAS et NE DEVRAIENT PAS : Ces expressions indiquent une mesure
déconseillée, mais qui peut être permise dans certaines circonstances et dont l’ensemble des
répercussions doivent être comprises avant la mise en œuvre de celle-ci.
Remarques concernant le langage de balisage HTML5
Le produit DOIT utiliser le langage de balisage HTML5 pour l’élaboration, la structuration et la
présentation du contenu Web d’une exposition virtuelle.
3
Les produits Web que sont les expositions virtuelles DOIVENT utiliser la dernière version de la norme
HTML5 ainsi que la feuille de style et les technologies de chiffrement disponibles qui assurent sa prise en
charge. L’utilisation d’une autre version de ce langage de balisage est interdite.
Pendant le cycle de développement de l’exposition virtuelle et jusqu’à sa mise en production, seulement
les balises HTML 5 supportées par les versions disponibles des principaux navigateurs, tels Internet
Explorer 9+, Firefox 23+, Google Chrome et Safari 6+, DOIVENT être utilisées dans le cadre du
programme d’investissement du MVC.
Remarques concernant l’optimisation mobile d’un site Web
Le produit qu’est l’exposition virtuelle DOIT être optimisé de façon à permettre la navigation mobile à
partir d’une tablette et/ou d’un téléphone intelligent.
Le concepteur DEVRAIT concevoir le contenu et l'interface de l’exposition en fonction des petits écrans et
des écrans de taille moyenne. Ainsi, quand l’utilisateur accède à un site Web optimisé à partir d’un
navigateur mobile, le site organise l’interface utilisateur (IU), filtre et adapte tout le contenu pour une
tablette ou un téléphone intelligent et réorganise le contenu pour la version pour ordinateur de bureau.
L’optimisation mobile DOIT suivre les règles de conception de sites Web adaptatifs avec HTML5 et CSS3
où :
•
•
L’ensemble des versions optimisées et la version pour ordinateur de bureau DOIVENT desservir
le même HTML en provenance du même site Web et du même ensemble d’adresses URL (c’est
à-dire que des adresses URL séparées pour un ordinateur de bureau et un appareil mobile NE
sont PAS prises en charge);
La présentation du contenu DOIT être contrôlée en n’utilisant que CSS3 et les requêtes de
médias (media queries [en]).
Les sites Web et les applications Web sont optimisés pour les appareils mobiles en :
•
•
Adaptant la mise en page et la conception graphique des sites Web et des applications Web pour
les petits écrans, les écrans de taille moyenne et les grands écrans, ainsi que les différentes
méthodes de saisie, comme la saisie par écran tactile et la saisie par clavier et souris.
Concevant le contenu et l'interface des sites Web et des applications Web en fonction des petits
écrans, des écrans de taille moyenne et des grands écrans, ainsi que des différentes méthodes
de saisie telles que la saisie de l’orientation de l’écran en mode portrait ou paysage, la saisie par
écran tactile et la saisie par clavier et souris.
Les exigences d’optimisation pour les petits écrans DOIVENT être appliquées lorsque :
•
•
la largeur de l'écran (media query device-width[en]) est de moins de 768 pixels; ou
la largeur de la fenêtre d'affichage (media query width[en]) est de moins de 768 pixels.
Les exigences d’optimisation pour les écrans de tablette ou de taille moyenne DOIVENT être appliquées
dans les cas suivants :
•
•
la largeur de l'écran (media query device-width[en]) est d'au moins 768 pixels, mais de moins de
1 024 pixels; ou
la largeur de la fenêtre d'affichage (media query width[en]) est d'au moins 768 pixels, mais de
moins de 960 pixels.
Les exigences pour les grands écrans DOIVENT être appliquées dans les cas suivants :
4
•
•
la largeur de l'écran (media query device-width[en]) est d'au moins 1 024 pixels; et
la largeur de la fenêtre d'affichage (media query width[en]) est d'au moins 960 pixels.
Les applications mobiles natives NE sont PAS prises en charge dans le cadre du programme
d’investissement du MVC.
L’optimisation de la navigation mobile sur une tablette ou un téléphone intelligent DOIT être en conformité
avec l’ensemble des exigences et des critères techniques du présent document, à moins d’indication
contraire.
Remarques concernant l’usage d’un système de gestion du contenu (SGC)
•
•
•
•
•
L’utilisation d’un SGC n’est PAS obligatoire, mais facultatif;
Il incombe à l’institution de garder la version de son SGC de développement à jour pour la durée
du contrat;
Toutes expositions développées avec l’aide d’un SGC DOIVENT avoir été converties en pages
statiques HTML et indépendantes du SGC lors des étapes de contrôle de qualité et lors de la
mise en production;
Les expositions produites avec l’aide d’un SGC DOIVENT répondre à toutes les exigences
énumérées dans ce document.
o Aucune exemption ne sera accordée pour toute transgression aux Exigences techniques
pour le développement des produits du Programme d’investissement pour les expositions
virtuelles du Musée virtuel du Canada (MVC) – V. 2.1, et
Les pages produites avec l’aide d’un SGC DOIVENT se conformer aux exigences pour les
Répertoires, fichiers et adresses URL de la section 6.0.
A) Accessibilité
Règles pour l’accessibilité des contenus Web du W3C – version 2.0
Les Règles pour l’accessibilité des contenus Web (version 2.0) [title="Lien externe, Web Content
Accessibility Guidelines (WCAG) 2.0 (en anglais seulement)"] s’appliquent aux produits conçus pour offrir
une expérience Web interactive riche. Elles s’appliquent également aux versions de produits optimisées
pour utilisation mobile sur tablette ou téléphone intelligent conformes aux exigences relatives aux
Expériences Web partagées[title="Lien externe, Shared Web Experiences: Barriers Common to Mobile
Device Users and People with Disabilities (en anglais seulement)"] et aux Pratiques exemplaires du Web
mobile (version 1.0) [title title="Lien externe, Pratiques exemplaires du Web mobile 1.0"]sélectionnées.
Voir aussi le tableau [title="Lien externe, Table of Shared Web Experiences: Barriers Common to Mobile
Device Users and People with Disabilities (en anglais seulement)"]sur les Expériences Web partagées et
la façon d’appliquer les Règles pour l’accessibilité des contenus Web (2.0) et les Pratiques exemplaires
du Web mobile (version 1.0) dans le contexte mobile (c.-à-d. les « MWBP 1.0 » en anglais).
Les Règles pour l’accessibilité des contenus Web (2.0) sont fondées sur quatre principes : le produit doit
être perceptible, utilisable, compréhensible et robuste. Chaque principe comporte un certain nombre de
règles et de critères de succès.
Pour s’assurer que le contenu et la fonctionnalité du produit sont accessibles au plus grand nombre de
visiteurs, toutes les versions (p. ex. ordinateur de bureau, tablette, téléphone intelligent) du produit
DOIVENT respecter comme suit les Règles pour l’accessibilité des contenus Web (version 2.0) :
•
•
Elles doivent être conformes à toutes les règles et sous-règles;
Elles doivent satisfaire tous les critères de succès de niveau A et AA;
5
•
Elles doivent également suivre les meilleures pratiques pour les tablettes et les téléphones
intelligents, p. ex. Expériences Web partagées et Pratiques exemplaires du Web mobile (version
1.0).
Pour obtenir des précisions sur les Règles pour l’accessibilité des contenus Web (2.0) ainsi que les
Pratiques exemplaires du Web mobile (1.0) du W3C, voir les sites Web de l’organisation, aux adresses
http://www.w3.org/TR/WCAG20/ [title="Lien externe, Web Content Accessibility Guidelines (WCAG) 2.0
(en anglais seulement)"]et http://www.w3.org/TR/mobile-bp/ [title="Lien externe, Mobile Web Best
Practices 1.0 (en anglais seulement)"](aussi disponibles en français aux adresses
http://www.w3.org/Translations/WCAG20-fr/ [title="Lien externe, Règles pour l'accessibilité des contenus
Web (WCAG) 2.0"]et http://www.yoyodesign.org/doc/w3c/mobile-bp/ [ title="Lien externe, Pratiques
exemplaires du Web mobile 1.0"].
IMPORTANT Le texte suivant présente les 4 principes des Règles pour l’accessibilité des contenus Web
(2.0). Les expositions DOIVENT être conformes à toutes ces règles et sous-règles.
1.0 Principe 1 : Le produit doit être perceptible. (Règles 1.1 à 1.4)
Règle 1.1
Conformément à la Règle 1.1[title="Lien externe, Règle 1.1 - Les équivalents textuels : proposer des
équivalents textuels à tout contenu non textuel qui pourra alors être présenté sous d'autres formes selon
les besoins de l'utilisateur : grands caractères, braille, synthèse vocale, symboles ou langage simplifié."] :
les équivalents textuels DOIVENT être déclarés pour tout contenu non textuel en agissant comme texte
de remplacement qui pourra alors être présenté sous d’autres formes selon les besoins de l’utilisateur :
grands caractères, braille, synthèse vocale, symboles ou langage simplifié.
Remarque : Les textes de remplacement des images DOIVENT être étoffés, descriptifs et
suffisamment détaillés. Ils DOIVENT décrire le contenu de l’image et le rôle de celleci sur la page conformément au critère de succès 1.1.1. Le texte de remplacement
DOIT être d’une longueur raisonnable. Le MCH recommande qu’il compte 125
caractères ou moins. Voir le document du W3C sur les techniques pour la mise en
place d’équivalents textuels utiles[title="Lien externe, HTML5: Techniques for
providing useful text alternatives (en anglais seulement)"] en HTML5. (Prière de noter
que ce document est une version provisoire et peut être modifié sans préavis.)
Remarque : Pour les tablettes et les téléphones intelligents, le contenu non textuel (images,
fichiers audio et vidéo) DOIT également être disponible sous forme d’équivalent
textuel en tant qu’option de remplacement en mode texte uniquement et être
dimensionné pour s’adapter à l’écran de l’appareil. Les utilisateurs d’appareils
mobiles peuvent désactiver des images, certains agents utilisateurs pour appareils
mobiles disposent d’un soutien limité pour les objets non textuels. La taille des
images peut être réduite par certains agents, rendant celles-ci inutiles. Pour obtenir
de plus amples renseignements, voir le contexte mobile et les pratiques exemplaires
connexes concernant les objets non textuels ne pouvant être remplacés par du texte.
[ title="Lien externe, Non-text objects (images, sound, video) with no text alternative
(en anglais seulement)"]
Règle 1.2
Conformément à la Règle 1.2 [title="Lien externe, Règle 1.2 - Média temporel : proposer des versions de
remplacement aux médias temporels"] : des versions de remplacement aux médias temporels DOIVENT
être fournies.
6
Remarque : Conformément aux critères de succès 1.2.1, 1.2.2 et 1.2.3 de niveau A, les
séquences uniquement audio DOIVENT comporter des transcriptions textuelles; les
séquences uniquement vidéo DOIVENT comporter une transcription et les
séquences multimédias synchronisées (audio-vidéo) DOIVENT inclure des soustitres synchronisés, ainsi qu’une transcription en texte intégral.
Remarque : Pour les tablettes et les téléphones intelligents, le contenu non textuel (images,
fichiers audio et vidéo) DOIT également être disponible sous forme de texte de
remplacement seulement et s’adapter aux dimensions de l’écran de l’appareil.
Souvent, les utilisateurs d’appareils mobiles n’entendent pas, ou éteignent, le son
dans les endroits bruyants ou les lieux publics. Les objets multimédias peuvent ne
pas apparaître correctement sur les écrans des appareils mobiles en raison d’une
palette de couleurs limitée ou d’une différence de couleur qu’on perçoit mal dans des
conditions d’éclairage faible ou à l’extérieur. Pour obtenir de plus amples
renseignements, voir le contexte mobile et les pratiques exemplaires connexes
concernant les invites audio seulement, demandant des renseignements importants
[title="Lien externe, Audio-only prompts (beeps) for important information (warnings,
errors) (en anglais seulement)"]et les multimédias sans sous-titres[title="Lien
externe, Shared Web Experiences: Barriers Common to Mobile Device Users and
People with Disabilities section Multimedia with no captions (en anglais seulement)"].
Règle 1.3
Conformément à la Règle 1.3 [title="Lien externe, Règle 1.3 Adaptable : créer un contenu qui puisse être
présenté de différentes manières sans perte d'information ni de structure (par exemple avec une mise en
page simplifiée)."] : le contenu DOIT être créé de façon à pouvoir être présenté de différentes manières
sans qu’il y ait perte de renseignements ou modification de la structure.
Remarque : Conformément aux critères de succès 1.3.1, 1.3.2 et 1.3.3 de niveau A, les différents
types de renseignements qui sont souvent encodés dans la présentation sont
également disponibles, de façon à pouvoir être présentés dans d’autres contextes.
Les renseignements doivent être incorporés dans une présentation particulière de
manière à ce que la structure et les renseignements puissent être reconnus
automatiquement par la technologie d’assistance et affichés dans d’autres formats,
selon les besoins de l’utilisateur.
Remarque : Pour les tablettes et les téléphones intelligents, tout le contenu DOIT être adapté à la
taille de l’affichage. Il doit également être structuré et hiérarchisé de façon logique
afin de faciliter l’accès à l’ensemble des renseignements et l’interaction de l’utilisateur
avec ceux-ci. La taille ou la longueur des éléments de contenu DEVRAIT être réduite
tout en conservant la richesse de l’expérience Web mobile de l’utilisateur. Les
renseignements essentiels et la structure NE DOIVENT PAS être perdus au cours du
processus. L’utilisation de tableaux DEVRAIT être évitée sur les écrans de taille
limitée, pour que l’utilisateur n’ait pas à utiliser le défilement horizontal et vertical pour
lire les tableaux. Les renseignements NE DOIVENT PAS être présentés uniquement
à l’aide de la couleur, car les écrans des appareils mobiles comportent parfois une
palette de couleurs limitée ou rendent mal les couleurs dans des conditions
d’éclairage faible ou à l’extérieur. Pour obtenir de plus amples renseignements, voir
le contexte mobile et les pratiques exemplaires connexes concernant le contenu
formaté à l’aide de tableaux ou de CSS [title="Lien externe, Shared Web
Experiences: Barriers Common to Mobile Device Users and People with Disabilities
section Content formatted using tables or CSS, and reading order not correct when
linearized (for example when CSS or tables not rendered) (en anglais seulement)"]et
les renseignements présentés uniquement à l’aide de la couleur [title="Lien externe,
Shared Web Experiences: Barriers Common to Mobile Device Users and People with
Disabilities section Information conveyed solely with color (en anglais seulement)"].
7
Règle 1.4
Conformément à la Règle 1.4 [title="Lien externe, Règle 1.4 Distinguable : faciliter la perception visuelle et
auditive du contenu par l'utilisateur, notamment en séparant le premier plan de l'arrière-plan."] : La
présentation visuelle du texte et du texte sous forme d’image DOIT répondre aux exigences minimales
relatives au contraste de couleur selon l’algorithme du W3C. Plusieurs outils sont disponibles pour faciliter
cet effort, tel que l’outil « Colour Contrast Analyser »[span =en] (en anglais seulement) disponible
gratuitement aux adresses http://www.wat-c.org/ [title="Lien externe, Web Accessibility Tools Consortium
(en anglais)"] et http://www.accessibleinfo.org.au/.[title="Lien externe, Digital Access at Vision Australia
(en anglais)"]
Remarque : Pour les tablettes et les téléphones intelligents, les combinaisons des couleurs de
premier plan et d’arrière-plan DOIVENT fournir un contraste suffisant lorsqu’une
page est consultée sous une lumière de forte intensité parallèle à l’écran. Pour
obtenir de plus amples renseignements, voir le contexte mobile et les pratiques
exemplaires connexes concernant les renseignements présentés uniquement à l’aide
de la couleur[title="Lien externe, Shared Web Experiences: Barriers Common to
Mobile Device Users and People with Disabilities, section Information conveyed
solely with color (en anglais)"] et les pages/images de grande taille.[ title="Lien
People with Disabilities, section Large pages or large images (en anglais
seulement)"]
2.0 Principe 2 : Le produit doit être utilisable. (Règles 2.1 à 2.4)
Règle 2.1
Conformément à la Règle 2.1 [title="Lien externe, Règle 2.1 Accessibilité au clavier : rendre toutes les
fonctionnalités accessibles au clavier."] : toutes les fonctionnalités DOIVENT être accessibles à partir d’un
clavier. Cette exigence inclut la capacité de remplir des formulaires en ligne, les touches de contrôle vidéo
et audio ainsi que les aides à la navigation.
Remarque : Pour les tablettes et les téléphones intelligents, les raccourcis clavier DEVRAIENT
faire partie d’une stratégie de conception faisant appel à de multiples méthodes
d’interaction [title="Lien externe, Mobile Web Application Best Practices, section
3.5.3 Design for Multiple Interaction Methods (en anglais seulement)"]et être
attribués aux liens des menus de navigation et des fonctionnalités fréquemment
utilisées. Pour obtenir de plus amples renseignements, voir le contexte mobile et les
pratiques exemplaires connexes concernant la nécessité d’interaction et navigation
avec une souris [title="Lien externe, Shared Web Experiences: Barriers Common to
Mobile Device Users and People with Disabilities, section Mouse required for
interaction and navigation (en anglais)"]et le plugiciel spécial nécessaire.[ title="Lien
People with Disabilities, section Special plugin required (en anglais seulement)"]
Toute interface utilisateur utilisable à partir d’un clavier DOIT comporter un mode de fonctionnement où
l’indicateur de focus du clavier est visible.
Remarque : Le produit PEUT comprendre un fil d’Ariane pour la navigation. Les fils d’Ariane sont
facultatifs. Si le produit comporte un fil d’Ariane :
• tous les niveaux de navigation DOIVENT être présentés et DOIVENT être actifs,
et
• chaque lien DOIT être intelligible individuellement.
8
Remarque : Pour les tablettes et les téléphones intelligents, si un fil d’Ariane est inclus, il NE
DOIT PAS avoir préséance sur la transmission de renseignements plus importants et
plus pertinents. Les utilisateurs NE DOIVENT PAS avoir à faire défiler la page avant
de trouver le menu ou le contenu principal de celle-ci. Pour obtenir de plus amples
renseignements, voir le contexte mobile et les pratiques exemplaires connexes
concernant la nécessité d’interaction et navigation avec une sourie [title="Lien
People with Disabilities, section Mouse required for interaction and navigation (en
anglais seulement)"]et les renseignements essentiels à la signification de la page. [
title="Lien externe, Pratiques exemplaires du Web mobile 1.0 section 5.3.4 Barres
de navigation, etc. (matériel extérieur) "]
Règle 2.2
Conformément à la Règle 2.2 [title="Lien externe, Règle 2.2 Délai suffisant : laisser à l'utilisateur
suffisamment de temps pour lire et utiliser le contenu"] : des moyens DOIVENT être mis à la disposition
des utilisateurs pour que ceux-ci aient suffisamment de temps pour lire et utiliser le contenu. L’exposition
DOIT se conformer aux critères de succès 2.2.1 et 2.2.2.
Remarque : Les utilisateurs doivent être en mesure de terminer les tâches entamées dans le
contenu dans les limites du temps de réponse. Les utilisateurs ayant un handicap (p.
ex. cécité, basse vision, trouble de la dextérité, limites cognitives) peuvent avoir
besoin de plus de temps pour lire le contenu et mener à bien les tâches, ou peuvent
accéder au contenu grâce à une technologie d’assistance.
Règle 2.3
Conformément à la Règle 2.3 [title="Lien externe, Règle 2.3 Crises : ne pas concevoir de contenu
susceptible de provoquer des crises"] : Le contenu NE DOIT PAS être conçu d’une manière reconnue
comme pouvant provoquer des crises.
Remarque : L’exposition DOIT se conformer aux critères de succès 2.3.1 et 2.3.2. Les pages
Web NE DOIVENT PAS comporter quoi que ce soit qui clignote plus de trois fois par
seconde.
Règle 2.4
Conformément à la Règle 2.4 [title="Lien externe, Règle 2.4 Navigable : fournir à l'utilisateur des éléments
d'orientation pour naviguer, trouver le contenu et se situer dans le site"] : des méthodes DOIVENT être
fournies pour aider les utilisateurs à naviguer, trouver le contenu et se situer dans le produit. L’exposition
DOIT se conformer aux critères de succès 2.4.1, 2.4.2, 2.4.3, 2.4.4, 2.4.5, 2.4.6 et 2.4.7.
Remarque : Pour répondre à cette exigence : appliquer une navigation cohérente; ajouter des
liens et des cibles afin de contourner des blocs de contenu tels que la navigation;
créer des textes de liens faciles à comprendre en l’absence de contexte.
Remarque : Pour les tablettes et les téléphones intelligents, un titre de page descriptif DOIT être
fourni pour aider à comprendre le contenu. Le titre doit pouvoir s’adapter aux écrans
plus petits sans être tronqué. La navigation entre les divers champs, objets et
contrôles sur la page DOIT être présentée dans un ordre logique. Cet ordre DOIT
demeurer cohérent et utilisable lorsque la commande « Tabulation » du clavier est
utilisée. Les cibles des liens DOIVENT être clairement définies. Les liens qui visent
les ressources DOIVENT définir les formats de grande taille et les formats non
textuels afin de permettre à l’utilisateur d’évaluer le lien avant de le suivre. Pour
9
exemplaires connexes concernant les titres de page manquants ou inappropriés
[title="Lien externe, Missing or inappropriate page title - W3C Article - Shared Web
(en anglais seulement)"], l’incohérence entre le parcours du focus et la séquence
logique du contenu du document [title="Lien externe, Inconsistency between focus
order and logical document content sequence - W3C Article - Shared Web
(en anglais seulement)"]et les étiquettes de liens non descriptives.[ title="Lien
externe, Non-descriptive link label - W3C Article - Shared Web Experiences: Barriers
Common to Mobile Device Users and People with Disabilities (en anglais
seulement)"]
3.0 Principe 3 : Le produit doit être compréhensible. (Règles 3.1 à 3.3)
Règle 3.1
Conformément à la Règle 3.1 [title="Lien externe, Principe 3 : compréhensible - Les informations et
l'utilisation de l'interface utilisateur doivent être compréhensibles"] : le texte DOIT être lisible et
compréhensible. Par conséquent, il faut indiquer la langue de la page et les passages rédigés dans une
autre langue. Il faut également fournir la forme au long ou la signification des abréviations et des
acronymes. L’exposition DOIT se conformer aux critères de succès 3.1.1 et 3.1.2.
Remarque :
•
•
•
Éviter d’utiliser du texte dans d’autres langues dans le texte de remplacement et
les éléments title;
Les attributs de la langue NE DOIVENT PAS être déclarés dans les autres
attributs tels que l’attribut du texte de remplacement ou l’attribut des éléments
title, et
Les acronymes et les abréviations DOIVENT être soit écrits au long, soit balisés à
l’aide de l’élément HTML abbr.
Remarque : Pour les tablettes et les téléphones intelligents, le texte DEVRAIT également être
clair et pouvoir s’adapter aux écrans plus petits. Les phrases longues et complexes
ou le jargon ne sont pas appropriés pour trouver et comprendre l’information
demandée. Pour obtenir de plus amples renseignements, voir le contexte mobile et
les pratiques exemplaires connexes concernant les longs mots, les phrases
complexes, le jargon [title="Lien externe, Shared Web Experiences: Barriers
Common to Mobile Device Users and People with Disabilities, section Long words,
long and complex sentences, jargon (en anglais seulement)"]et le caractère
approprié, la clarté et le contenu limité[title="Lien externe, Pratiques exemplaires du
Web mobile 1.0, section 5.3.1 Contenu de la page"].
Règle 3.2
Conformément à la Règle 3.2 [title="Lien externe, Règle 3.2 Prévisible : faire en sorte que les pages
apparaissent et fonctionnent de manière prévisible"] : les pages Web DOIVENT apparaître et fonctionner
de manière prévisible en offrant une navigation et une identification cohérentes. L’exposition DOIT se
conformer aux critères de succès 3.2.1, 3.2.2, 3.2.3 et 3.2.4.
Remarque : Les versions optimisées pour tablettes et téléphones intelligents NE DOIVENT PAS
ouvrir des fenêtres contextuelles multiples ou des fenêtres surgissantes, créer des
pages s’actualisant automatiquement ou rediriger automatiquement les pages. Pour
exemplaires connexes concernant le contenu lançant de nouvelles fenêtres sans
avertir l’utilisateur [title="Lien externe, Shared Web Experiences: Barriers Common
10
to Mobile Device Users and People with Disabilities, section Content spawning new
windows without warning user (en anglais seulement)"]et les fenêtres contextuelles,
l’actualisation et la redirection automatique[title="Lien externe, Pratiques exemplaires
du Web mobile 1.0 section 5.2.8 Rafraîchissement, redirection et fenêtres
engendrées"].
Règle 3.3
Conformément à la Règle 3.3[title="Lien externe, Règle 3.3 Assistance à la saisie : aider l'utilisateur à
éviter et à corriger les erreurs de saisie"] : les pages Web DOIVENT fournir de l’assistance à la saisie afin
d’aider l’utilisateur à éviter et à corriger les erreurs de saisie. L’exposition DOIT se conformer aux critères
de succès 3.3.1, 3.2.2, et 3.3.3.
Remarque : Pour les tablettes et les téléphones intelligents, les libellés sur les contrôles de
formulaires DOIVENT également être formulés de façon claire, présenter une taille
appropriée et être explicitement associés aux contrôles dans le code. Les libellés
devraient être affichés de façon uniforme et placés près des contrôles de
formulaires. Pour obtenir de plus amples renseignements, voir les pratiques
exemplaires du Web mobile concernant le libellé et l’emplacement des contrôles ,[
title="Lien externe, Pratiques exemplaires du Web mobile 1.0, règle 5.5.3 Étiquettes
des commandes de formulaire]
4.0 Principe 4 : Le produit doit être robuste. (Règle 4.1)
Règle 4.1
Conformément à la Règle 4.1,[ title="Lien externe, Règle 4.1 Compatible : optimiser la compatibilité avec
les agents utilisateurs actuels et futurs, y compris les technologies d'assistance"] : les produits DOIVENT
être compatibles avec les plateformes et les navigateurs actuels, y compris les technologies d’assistance.
L’exposition DOIT se conformer aux critères de succès 4.1.1 et 4.1.2.
Remarque : Pour les tablettes et les téléphones intelligents, les objets et les scripts incorporés
DOIVENT être utilisés avec modération, car il se peut qu’ils ne soient pas pris en
charge par certains appareils mobiles et qu’ils entraînent une hausse des délais et
des coûts d’affichage d’une page. Rendre la page lisible en mode texte seulement
peut aider l’utilisateur à évaluer l’utilité de la page avant que l’image ou l’objet
s’affiche. Pour obtenir de plus amples renseignements, voir le contexte mobile et les
pratiques exemplaires connexes concernant le balisage non valide ou non pris en
charge, les scripts requis pour créer du contenu [title="Lien externe, Pratiques
exemplaires du Web mobile 1.0 section 5.4.7 Balisage valide"]et les objets et les
scripts incorporés.[ title="Lien externe, Pratiques exemplaires du Web mobile 1.0
section 5.4.5 Éléments non textuels]
B) Formats
5.0 Balisage, présentation et scripts
5.1 Technologies de base
Les technologies de base visent à s’assurer que le contenu du produit est accessible au plus grand
nombre de visiteurs, quelle que soit la configuration technique de leur système ou de leur appareil.
Remarque : Lors de l’optimisation pour les tablettes et pour les téléphones intelligents, la
capacité de la taille mémoire des pages HTML5, des CSS3, des JavaScript et des
11
ressources individuelles (p. ex. images, fichiers vidéo et audio) DEVRAIT être
réduite afin d’éviter le dépassement des limites de la taille mémoire des pages
HTML5 (typiquement 5 Mo). Les pages et les ressources mises en cache aident à
réduire le temps de chargement et les coûts d’utilisation du réseau. Elles permettent
également aux utilisateurs de continuer à interagir avec le contenu, et ce, même
quand leur connexion réseau n’est pas disponible. Toutefois, elles réduisent la durée
de vie des piles. La mise en cache accroît la réactivité du produit, améliorant ainsi
l’expérience mobile de l’utilisateur. Pour obtenir de plus amples renseignements sur
l’utilisation d’un manifeste de cache et la mise en cache, voir le document du W3C
suivant portant sur la mise en cache en HTML5 et les applications hors ligne
[title="Lien externe, HTML5 - A vocabulary and associated APIs for HTML and
XHTML"].
5.2 HTML5
Le produit et toutes ses pages DOIVENT utiliser uniquement HTML5 [title=«Lien externe, HTML5
Introduction – W3Schools (en anglais seulement)] pour le balisage sémantique et structurel du contenu
des pages Web.
Pendant le cycle de développement de l’exposition virtuelle et jusqu’à sa mise en production, seulement
les balises HTML 5 supportées par les versions disponibles des principaux navigateurs PC et Mac
actuellement en usage: Internet Explorer 9+, Firefox 23+, Google Chrome et Safari 6+ PEUVENT être
utilisées dans le cadre du programme d’investissment du MVC. Les balises « frameset » et les variantes
des balises XHTML 1.0 Strict et XHTML5 NE DOIVENT PAS être utilisées.
Le produit et toutes ses pages, y compris le balisage généré ou modifié de manière dynamique par les
scripts DOM côté client, DOIVENT être validés en faisant appel au plus récent service de validation du
balisage HTML5 offert par le W3C.
Remarque : Avant d’aller plus loin et de mener une évaluation technique, le MCH PEUT
demander au client une preuve démontrant que le balisage HTML5 du produit a été
validé avec succès. Le service de validation du balisage du W3C est disponible à
l’adresse http://validator.w3.org/ [ title=« Lien externe, Validateur du W3C" ] (en
anglais seulement)]. Ce service du W3C est intégré au moteur de
Validator.nu[title="Lien externe, Validator.nu HTML5 (en anglais seulement)" ] qui
prend en charge le HTML5.
5.3 Format du code source
Même si le HTML5 offre de la flexibilité sur le plan de l’encodage, tous les codes, y compris les balises,
les JavaScript et les feuilles de style en cascade DOIVENT être conformes aux pratiques exemplaires en
matière d’encodage et être formatés au moyen d’une structure de regroupement claire, de balises de
fermeture et de mises en retrait.
Remarque : Les pages DOIVENT être structurées de façon à comprendre le bon niveau d’en-tête
(H1 à H6), lequel indique le niveau ou la priorité du titre de la page et des titres de
sections et de sous-sections de celle-ci.
Remarque : Cette exigence ne s’applique pas dans le cas des bibliothèques externes de tierces
parties telles que JQuery.
12
5.4 Feuilles de style en cascade (CSS)
La présentation et le style (présentation visuelle et conception) DOIVENT s’appliquer par l’utilisation de
feuilles de style en cascade (p. ex. CSS3). [title=«Lien externe, page d’accueil - Feuilles de style en
cascade» ]
Remarque : Les feuilles de style en cascade CSS3 DOIVENT être utilisées comme norme
principale de présentation visuelle et de conception pour le produit. Il n’est pas
obligatoire que chaque navigateur affiche la même présentation CSS de contenu du
produit. Pendant le cycle de développement de l’exposition virtuelle et jusqu’à sa
mise en production, seulement les balises HTML 5 supportées par les versions
disponibles des principaux navigateurs PC et Mac actuellement en usage: Internet
Explorer 9+, Firefox 23+, Google Chrome et Safari 6+ PEUVENT être utilisées dans
le cadre du programme d’investissement du MVC.
Remarque : Organiser les documents de façon que la version pour ordinateur de bureau puisse
être lue sans feuille de style. Afin de répondre à cette exigence, toutes les pages
DOIVENT être mises à l’essai lorsque les feuilles CSS sont désactivées pour
s’assurer que le contenu est présenté dans un ordre logique quand les feuilles CSS
ne sont pas prises en charge. Cela NE s’applique PAS aux tablettes et aux
téléphones intelligents étant donné que, pour l’optimisation de la navigation mobile,
les feuilles CSS DOIVENT être activées selon les exigences de conception de sites
Web adaptatifs.
Remarque : Pour les tablettes et les téléphones intelligents, la présentation et le style DOIVENT
pouvoir s’adapter à divers types de médias grâce à l’utilisation de requêtes de média
[Lien externe, site du W3C, section requête de média (en anglais seulement) ]et sont
dépendants des fonctionnalités prises en charge (p. ex. résolutions, rapports
hauteur/largeur, largeur, hauteur et couleurs de l’affichage).
Les feuilles de style CSS DOIVENT être complètement séparées du contenu et de la structure de la page
et être référencées en tant que fichiers externes dans la section head d’une page. Elles NE DOIVENT
PAS être imbriquées ou incorporées.
Remarque : Les règles relatives aux feuilles CSS appelées de manière dynamique par les scripts
DOM côté client NE DOIVENT PAS être imbriquées. Les noms de classe
DEVRAIENT plutôt être ajoutés de manière dynamique aux éléments <HTML>
pertinents, de façon à appeler les règles relatives aux feuilles CSS qui y sont
associées dans une feuille de style externe.
5.5 Scripts côté client
Les scripts côté client DOIVENT être fournis en tant que composantes d’une programmation modulaire,
être non obstructifs, complètement séparés du contenu et de la structure de la page et référencés en tant
que fichiers externes dans la section head d’une page. Ils NE DOIVENT PAS être imbriqués ou
incorporés.
Remarque : Il est interdit de placer dans la couche HTML des gestionnaires d’événements en
ligne (p. ex. onClick et onFocus). Les gestionnaires d’événements DOIVENT être
écrits de manière dynamique au DOM à l’aide de techniques de chiffrement non
obstructives et valides.
Remarque : Advenant qu’un script provenant d’une tierce partie ne puisse pas être facilement et
discrètement mis en œuvre, une autorisation DOIT être obtenue auprès du MCH
avant d’utiliser des scripts ou des éléments script incorporés.
13
Remarque : Advenant l’utilisation de scripts provenant d’une tierce partie, un schéma d’utilisation
et la version des scripts actifs DOIVENT être fournis au MCH lors des étapes de
contrôle de qualité.
Remarque : Dans le cas de l’optimisation pour le mobile, les scripts côté client DOIVENT être
utilisés avec modération, car il se peut qu’ils ne soient pas pris en charge par
certains appareils mobiles et qu’ils entraînent une hausse des délais et des coûts
d’affichage d’une page.
Les scripts côté client DOIVENT être mis à l’essai et exécutés en fonction de la prise en charge par
l’agent utilisateur des objets DOM critiques utilisés dans les scripts, contrairement à une mise à l’essai
pour les chaînes de l’agent utilisateur ou autrement la « détection par tâtonnement du navigateur ». Cela
permet de s’assurer que l’exécution des scripts se fait en fonction des objets ou des méthodes DOM pris
en charge et non pas selon l’agent de navigateur utilisé (p. ex. une détection des fonctionnalités prises en
charge plutôt qu’une détection du navigateur).
5.6 Encodage des caractères
Chaque page du produit DOIT utiliser et indiquer la norme UTF-8 comme encodage de caractères.
Remarque : Pour obtenir de plus amples renseignements sur l’encodage de caractères en
HTML5, voir les documents sur la déclaration de l’encodage de caractères du W3C
[Lien externe, Declaring character encodings in HTML (en anglais seulement)]et
l’attribut méta « charset ». [ Lien externe, Declaring character encodings in HTML The meta charset attribute (en anglais seulement)]
5.7 Protocole Secure Socket Layer (SSL)
Le produit DOIT utiliser le protocole Secure Socket Layer [span =en] (SSL) lorsque l’utilisateur est tenu
d’entrer un nom d’utilisateur et un mot de passe (c.-à-d. lors de l’ouverture d’une session).
Remarque : Une autorisation DOIT être obtenue auprès du MCH lorsqu’il s’agit de produits dans
lesquels on demande à l’utilisateur de fournir des renseignements personnels, entre
autres son nom, son adresse, son adresse de courriel, son numéro de téléphone et
son numéro de carte de crédit, qui sont mis en mémoire par le produit et conservés
aux fins d’utilisation par l’établissement responsable du produit.
Remarque : Il n’est pas nécessaire d’utiliser le protocole SSL lorsqu’on recueille des
renseignements sur un formulaire de commentaires par courriel ou qu’on demande le
pseudonyme d’un utilisateur seulement, par exemple, pour conserver un score dans
un jeu en ligne.
Lors d’une requête pour cesser d’utiliser le protocole SSL, tous les hyperliens sur les pages utilisant le
protocole SSL vers des pages n’utilisant pas ce protocole DOIVENT utiliser des adresses URL relatives
(p. ex. la déconnexion après l’ouverture d’une session).
5.8 Amélioration progressive
Le produit DOIT être réalisé en adoptant une approche axée sur l’amélioration progressive [title="Lien
externe, Wikipédia, article sur l’amélioration progressive"]de la conception Web. Le premier format de
contenu qu’un utilisateur rencontre DOIT être le format le plus accessible, sauf si la configuration du
système de l’utilisateur est compatible avec un contenu présenté dans des formes rehaussées ou en
mesure d’accepter ce genre de contenu.
14
Remarque : Par exemple, dans certaines circonstances une partie d’une exposition peut être
offerte dans un deuxième format non textuel et nécessitant que le navigateur des
utilisateurs soit pourvu d’un plugiciel spécial ou d’un composant additionnel. Dans
une telle situation, l’information ne serait probablement pas accessible aux
personnes qui utilisent des technologies d’assistance telles qu’un lecteur d’écran, et
certainement pas accessible à tous ceux qui utilisent une plateforme PC ou Mac, une
tablette ou un téléphone intelligent.
Il faut plutôt créer une version HTML et textuelle simple et l’inclure comme contenu
par défaut sur la même page HTML. Cela ferait en sorte que tous les utilisateurs
pourraient accéder à cet élément de l’exposition. De plus, si un lien est prévu entre
cette page et un fichier externe JavaScript qui vérifie si le navigateur est pourvu de la
version appropriée du plugiciel spécial ou du composant additionnel requis, le code
HTML de la page peut être modifié dynamiquement par le fichier JavaScript (dans
l’hypothèse où le navigateur est capable d’exécuter les fonctions JavaScript requises)
afin de charger la version spéciale comprenant un lien vers la version HTML. Par
conséquent, tous les utilisateurs voient apparaître la version gérée par leur
navigateur et un lien vers l’autre version du contenu, de même qu’un lien vers la page
de téléchargement du plugiciel requis.
Remarque : En adoptant une approche axée sur l’amélioration progressive de la conception, le
texte du contenu et les liens placés près du haut d’une page seront plus accessibles
et plus facilement repérables par les moteurs de recherche que le contenu se
trouvant près du bas d’une page.
Remarque : Pour les tablettes et les téléphones intelligents, l’approche axée sur l’amélioration
progressive de la conception DOIT consister à créer le contenu d’une version
principale HTML et textuelle simple avant celui comportant des images et des
séquences multimédias. De plus, l’approche devrait comprendre une navigation
simplifiée, une réduction de la taille des pages HTML, des feuilles de style CSS et
des fichiers JavaScript, et d’offrir plusieurs versions côté serveur des images et des
objets multimédias afin de répondre aux divers formats d’écran. Finalement, elle
devrait faciliter l’utilisation de la technologie de mise en cache de HTML5 pour
améliorer la réactivité du produit, même quand le réseau n’est pas disponible, et
l’expérience de l’utilisateur.
L’utilisateur DOIT d’abord être en mesure d’accéder à la version principale du produit. L’accessibilité du
produit NE DOIT PAS être assurée par la distribution d’une version secondaire (p. ex. mode texte
seulement) du site ou des pages. Seuls les composants nécessitant des JavaScript peuvent être
reproduits.
Remarque : Les versions pour ordinateur de bureau et l’ensemble des versions optimisées
DOIVENT desservir le même document HTML provenant du même site Web et du
même ensemble d’adresses URL (c.-à-d. les adresses URL séparées d’un ordinateur
de bureau et d’un appareil mobile NE sont PAS prises en charge). Voir la section
précédente comportant des remarques sur l’optimisation mobile d’un site Web.
5.9 Indépendance des scripts
Le contenu et les fonctionnalités de base du produit DOIVENT être disponibles sans script côté client.
Remarque : Les améliorations de comportement mises en œuvre uniquement par l’entremise des
scripts côté client sont permises, mais celles-ci DOIVENT être maintenues à un
minimum tandis que les améliorations sur le plan de la présentation DOIVENT être
mises en œuvre par l’entremise de feuilles de style CSS, d’après la conception d’un
site Web adaptatif. Le contenu et la fonctionnalité de base du produit DOIVENT
15
demeurer disponibles, même si les scripts côté client sont désactivés ou non pris en
charge.
Remarque : Pour les tablettes et les téléphones intelligents, les risques liés aux améliorations de
comportement tels que l’actualisation et la régénération des pages, l’utilisation non
nécessaire du réseau et les incidences sur les ressources mises en cache dans le
navigateur DEVRAIENT être évités.
5.10 Indépendance des feuilles de style en cascade (CSS)
Le contenu et la fonctionnalité de base du produit DOIVENT être disponibles sans feuilles de style en
cascade (CSS) quand on y accède à partir du navigateur d’un ordinateur de bureau. Cette exigence NE
s’applique PAS aux tablettes et aux téléphones intelligents étant donné que, pour l’optimisation mobile
des sites Web, les feuilles CSS DOIVENT être activées, conformément à la conception d’un site Web
adaptatif.
Les mesures suivantes DOIVENT être adoptées :
• Quand les feuilles CSS ne sont pas prises en charge, le contenu DOIT être présenté selon une
séquence de lecture/visualisation logique;
• La séquence du contenu DOIT être conforme à la présentation réalisée avec les feuilles CSS.
L’ordre de présentation du contenu a une incidence sur sa signification;
• Toutes les tailles de police DOIVENT être établies au moyen d’une mesure relative telle que l’em
ou le pourcentage(%) afin de s’assurer que la taille du texte puisse être agrandie sans que de
l’information soit perdue ou tronquée, et
• Si une image d’arrière-plan est utilisée, une couleur de fond DOIT également être établie.
5.11 Mise en forme du code
Le développeur DOIT respecter les meilleures pratiques de mise en forme propre du code. Par exemple,
les retours à la ligne, l'indentation et le regroupement des lignes de code ainsi que les espaces entre les
balises.
Remarque : Cette exigence ne s’applique pas dans le cas des bibliothèques externes de tierces
parties telles que JQuery.
6.0 Répertoires, fichiers et adresses URL
6.1 Structure des fichiers et des répertoires
6.1.1 Répertoire
Les fichiers du produit accessibles au public (p. ex. HTML, images, CSS, JavaScript) et dont le contenu
est commun pour toutes les versions linguistiques du produit DOIVENT être placés dans des répertoires
uniques situés dans le répertoire supérieur ou racine du produit, et ils NE DOIVENT PAS être dupliqués
pour chaque version linguistique du produit.
Remarque : Il N’EST PAS permis de créer des structures française et anglaise séparées.
6.1.2 Navigation des répertoires
La navigation des répertoires DOIT être désactivée.
16
6.2 Noms de fichiers et de répertoires
6.2.1 Caractères
Les noms des fichiers et des répertoires accessibles au public DOIVENT utiliser uniquement les
caractères suivants :
•
•
Caractères alphabétiques en minuscules seulement (de a à z), et
Caractères numériques (de 0 à 9).
Les caractères suivants sont des caractères réservés qui NE DOIVENT PAS être utilisés que dans les
cas suivants :
•
•
Le trait d’union (-) DOIT seulement être utilisé comme séparateur entre les mots, syntagmes ou
abréviations bilingues équivalents et le code à trois (3) chiffres ISO-639-2[title ="Lien externe,
International Organization for Standardization »]. Les traits d’union naturellement présents dans
les mots ou les syntagmes DOIVENT être omis et l’espace résultante DOIT être supprimée (p. ex.
« avant-garde » devient « avantgarde »), et
Le trait de soulignement (_) DOIT être utilisé uniquement pour remplacer les espaces
naturellement présentes dans les mots utilisés pour les noms de fichier (p. ex. « nouveaux
événements » devient « nouveaux_evenements »).
6.2.2 Nommage
Les noms des répertoires dont le contenu est accessible au public DOIVENT comporter :
•
•
un mot, un syntagme ou une abréviation en français, suivi(e) d’un trait d’union et d’un mot, d’un
syntagme ou d’une abréviation en anglais, ou
un mot ou une abréviation unique qui est identique dans les deux (2) langues officielles.
Exemples :
• /histoire-history/
• /images/
• /contes_autochtones-native_stories/
Remarque : Les fichiers accessibles au public (p. ex. image, fichiers audio et vidéo) DEVRAIENT
être archivés dans des répertoires classés par thèmes (p. ex. « /images/animauxanimals/ » et « /images/peintures-paintings/ »).
6.2.3 Bilinguisme
Les noms des fichiers accessibles au public dont le contenu N’EST PAS le même dans les versions
française et anglaise du produit DOIVENT être descriptifs et comprendre soit :
•
•
un mot, un syntagme ou une abréviation en français, suivi(e) d’un trait d’union et de son
équivalent en anglais, suivi d’un autre trait d’union et du code à trois lettres ISO-639-2 (c.-à-d. «
fra » et « eng »), qui indique la version linguistique du fichier; ou
un mot ou une abréviation unique qui est identique dans les deux langues, suivi(e) d’un trait
d’union et du code à trois lettres ISO-639-2 (c.-à-d. « fra » et « eng »), qui indique la version
linguistique du fichier.
Exemples :
• index-fra.html
• index-eng.html
• entete-header-fra.swf
17
•
•
•
•
•
•
•
entete-header-eng.swf
logo-fra.jpg
logo-eng.jpg
liste_de_membres-members_list-fra.html
liste_de_membres-members_list-eng.html
lm-ml-fra.html
lm-ml-eng.html
6.2.4 Cas spéciaux
Les noms des fichiers pouvant être consultés par le public et dont le contenu est identique dans les
versions française et anglaise du produit (p. ex. certaines images, certains médias et fichiers JavaScript
ou CSS) DOIVENT être descriptifs et comprendre soit :
•
•
•
un mot, un syntagme ou une abréviation en français, suivi(e) d’un trait d’union et de son
équivalent en anglais;
un mot ou une abréviation unique qui est identique dans les deux langues, ou
une chaîne numérique ou alphanumérique neutre pour les deux langues.
Remarque : Aucun code de langue à trois lettres n’est requis pour les fichiers dont le contenu est
le même dans les deux langues officielles. Les fichiers de prise en charge exclusifs
ou de tierce partie, p. ex. « jquery-1.2.6.min.js », NE DEVRAIENT PAS être modifiés
pour respecter les règles susmentionnées d’affectation des noms.
Exemples :
•
•
•
•
•
•
ferme-farm.jpg
artefact.jpg
aaD77980017.jpg
couleur-colour.css
deroulant-pulldown.js
intro.wav
6.2.5 Suffixe HTML
Tous les fichiers HTML statiques du produit DOIVENT comprendre le suffixe « .html » et NE DOIVENT
PAS inclure le suffixe « .htm ».
6.3 Adresses URL des pages d’accueil
Les adresses URL de la page de garde où l’on sélectionne la langue et les pages d’accueil unilingues,
peu importe qu’on y accède à partir d’un ordinateur de bureau, d’une tablette ou d’un téléphone intelligent,
NE DOIVENT PAS inclure aucune chaîne d’interrogation et comportant des paramètres de forme paire
nom-valeur.
Remarque : Le nom du fichier de la page de garde DOIT être index.* ou default.* (p. ex.,
index.html ou default.html).
6.4 Adresses URL relatives
Toutes les adresses URL des pages et des ressources du produit DOIVENT être relatives (c.-à-d. non
absolues), sauf pour les adresses URL présentées dans les hyperliens reliant des pages utilisant le
protocole SSL vers des pages n’utilisant pas le protocole SSL (voir l’exigence 5.7).
18
7.0 Navigation, mise en page et conception
7.1 Page de garde
Le produit DOIT comprendre une page de garde, qui est une page de choix de langue placée dans le
répertoire racine du projet. La page de garde DOIT être affichée dans la version pour ordinateur de
bureau ou la version optimisée pour tablette ou téléphone intelligent.
La page de garde DOIT comprendre les renseignements suivants, dans les deux langues officielles :
•
•
•
•
•
Dans la version pour ordinateur de bureau et la version optimisée pour tablette, le logo standard
du MVC DOIT être utilisé;
Dans la version optimisée pour téléphone intelligent, c’est le logo en version mobile du MVC qui
DOIT être utilisé;
Le titre de l’exposition DOIT être fourni en langage HTML;
Un hyperlien vers la page d’accueil unilingue pour chaque version linguistique du produit, et
Un hyperlien vers la page d’information pour chaque version linguistique du produit.
7.2 Page d’information
Le produit DOIT comprendre une page d’information séparée pour chaque version linguistique.
7.2.1 Hyperlien
Un hyperlien vers la page d’information DOIT apparaître sur chaque page du produit.
7.2.2 Contenu
La page d’« information » DOIT comprendre les renseignements suivants, dans la langue pertinente :
•
•
•
•
Un hyperlien vers une page Web distincte qui présente l’avis de droit d’auteur. (Voir la section sur
les droits d’auteur ci-dessous);
Un hyperlien vers une page distincte qui présente l’énoncé de reconnaissance. (Voir la section sur
les remerciements ci-dessous);
Un hyperlien vers une page distincte qui présente le mécanisme de rétroaction. (Voir la section
sur les exigences relatives au mécanisme de rétroaction ci-dessous), et
Un hyperlien vers une page distincte qui présente la carte du site. (Voir la section sur la carte du
site ci-dessous)
Remarque : Seuls les hyperliens vers les pages Web sur les droits d’auteur, les remerciements,
les commentaires et la carte du site DOIVENT être placés sur la page d’information
de façon à éviter que celle-ci soit inutilement longue.
Remarque : Dans le cas où les institutions voudraient conserver un avis de droit d’auteur visible
sur chaque page de l’exposition, on DOIT créer un hyperlien direct vers la page de
droit d’auteur et NON vers la page d’information. Dans ce cas, l’hyperlien de la page
de droit d’auteur DOIT quand même être inclus dans la page d’information. Les deux
hyperliens amènent les usagers vers la même page de droit d’auteur.
19
7.3 Droit d’auteur
7.3.1 L’avis de droit d’auteur
Le produit DOIT comprendre, pour chaque version linguistique, un avis de droit d’auteur intégral qui
indique les noms de tous les détenteurs de droits d’auteur.
7.3.2 Localisation de l’avis
L’avis de droit d’auteur PEUT être placé dans une section sur les droits d’auteur, sur la page d’information
ou sur une page Web distincte qui présente les droits d’auteur. Voir la section sur la page d’information cidessus.
7.3.3 Symbole
Dans le cas où le symbole du droit d’auteur – © – apparaît sur chaque page du produit et sur la page
d’information qui mène à une page présentant l’avis de droit d’auteur intégrale, le nom du détenteur de ce
droit, l’année de lancement du produit et l’énoncé « Tous droits réservés » DOIVENT compléter cet avis.
Exemple : © Musée d’histoire 2014. Tous droits réservés.
Remarque : Si l’établissement qui détient le droit d’auteur est officiellement bilingue, utiliser le
nom anglais de l’établissement dans la version anglaise du produit et son nom
français dans la version française. Si l’établissement est unilingue, utiliser le même
nom (unilingue) dans chaque version linguistique. L’attribut lang, pour HTML5,
DOIT être déclaré pour le nom de l’établissement unilingue sur les pages où une
autre langue est utilisée.
7.4 Remerciements
7.4.1 L’énoncé de reconnaissance
Le produit DOIT comprendre une page comprenant un énoncé de reconnaissance complet pour chaque
version linguistique.
7.4.2 Localisation de l’énoncé
Cet énoncé DOIT se trouver sur une page Web séparée comprenant les remerciements disponible par un
hyperlien à partir de la page d’information. Voir la section sur la page d’information ci-dessus.
7.4.3 Reconnaissance de la participation financière du gouvernement du Canada
L’énoncé DOIT reconnaître la participation financière du gouvernement du Canada de la façon suivante :
Anglais :
The [Name of Institution] gratefully acknowledges the financial
investment by the Canadian Museum of History in the creation of this
online presentation for the Virtual Museum of Canada. [lang =en]
Français :
Le [Nom de l’établissement] exprime sa reconnaissance au Musée canadian
de l’histoire pour son investissement financier dans la réalisation de
cette exposition en ligne pour le Musée virtuel du Canada.
20
7.4.4 Contenu
L’énoncé DOIT nommer tous les partenaires institutionnels participant au produit et y mener par des
hyperliens, s’ils sont disponibles.
7.5
7.6 Carte du site
7.6.1 Forme
Le produit DOIT comprendre, sous forme de page Web distincte pour chaque version linguistique du
produit, une carte du site (c.-à-d. une présentation imbriquée ou une liste hiérarchique d’hyperliens vers
toutes les principales sections et pages du produit, à au moins deux niveaux de répertoire) comportant
des hyperliens textuels, par opposition à des hyperliens graphiques ou à des boutons. La carte du site
DOIT se trouver sur une page Web séparée disponible par un hyperlien à partir de la page d’information.
Remarque : Pour accroître la capacité des moteurs de recherche à indexer toutes les pages du
produit, il est fortement conseillé d’incorporer une carte du site en format
XML.[title="Lien externe, Sitemap - Wikipédia"]
Remarque : Pour les tablettes et les téléphones intelligents, la page de la carte du site DOIT
également être optimisée afin de pouvoir s’adapter aux petits écrans.
7.6.2 Localisation de la carte du site
Chaque page du produit DOIT inclure un hyperlien textuel vers la carte du site dans la langue appropriée,
afin que les utilisateurs humains et les moteurs de recherche puissent trouver chaque page du produit.
Remarque : Pour les tablettes et les téléphones intelligents, les hyperliens DOIVENT apparaître
après les éléments de navigation de la page qui mènent au contenu.
7.7 Navigation
7.7.1 Langue de navigation
Le produit DOIT comporter une page d’accueil unilingue pour chaque version linguistique.
Chaque page du produit DOIT comprendre un hyperlien vers l’autre version linguistique ou les autres
versions linguistiques du produit. Ce lien DOIT être visible sans défilement de la page, avec une
résolution d’écran de 1024 x 768 pixels, et il DOIT diriger l’utilisateur vers le même contenu dans l’autre
langue.
Remarque : Pour les tablettes et les téléphones intelligents, le placement de cet hyperlien NE
DOIT PAS supplanter les principales options de navigation ni le contenu
d’information principal. Pour accéder au lien, il PEUT être nécessaire de faire défiler
la page.
7.7.2 Navigation vers la page d’accueil
Chaque page du produit DOIT comprendre un hyperlien vers la page d’accueil unilingue dans la même
langue.
21
Remarque : Pour les versions optimisées du produit destinées aux tablettes et aux téléphones
intelligents, l’hyperlien vers la page d’accueil DOIT être placé à la fin des options de
navigation.
7.8 Fenêtres surgissantes
Le produit NE DOIT PAS ouvrir de liens dans des fenêtres surgissantes ou de nouveaux onglets, sauf
dans les cas suivants :
•
•
L’ouverture d’une page contenant de l’information contextuelle (telle que des instructions sur
l’aide) ou un moyen de rechange pour remplir un champ du formulaire (p. ex. un sélecteur de date
basé sur un calendrier), dans la même fenêtre ou le même onglet, pourrait considérablement
perturber le flux des travaux à plusieurs étapes (p. ex. remplir et présenter un formulaire), et
L’ouverture d’une page hors d’une session sécurisée dans la même fenêtre ou le même onglet
interromprait ou détruirait la session sécurisée en cours.
Remarque : L’utilisateur DOIT être averti si un lien ouvre une nouvelle fenêtre ou un nouvel
onglet.
Remarque : Dans le cas de l’optimisation pour le mobile, les fenêtres surgissantes NE sont PAS
admises.
7.9 Titre du produit
Chaque page du produit DOIT inclure le titre principal du produit sous forme de texte en HTML, afin
d’indiquer que le contenu de la page fait partie du produit.
Remarque : Des images PEUVENT être utilisées pour remplacer la version textuelle en format
HTML du titre principal du produit, mais elles NE DOIVENT PAS empêcher les
technologies d’assistance d’accéder au texte remplacé.
7.10 Logo du MVC
Le logo du MVC approprié DOIT figurer dans le coin supérieur droit de chaque page du produit, y compris
la page de garde, sans aucune bordure d’image. Il ne peut y avoir que les liens de changement de la
langue en haut du logo du MVC. Aucun élément NE DOIT se retrouver à la droite du logo du MVC.
Remarque : Le MCH fournira, sur demande, un exemplaire du logo du MVC. Différentes versions
du logo sont disponibles pour assurer une meilleure compatibilité avec les diverses
conceptions visuelles et pour optimiser les versions du produit destinées aux
téléphones intelligents.
Le logo du MVC DOIT être installé à l’aide du code HTML suivant pour établir un hyperlien chargeant le
logo:
Logos pour les ordinateurs de bureau et les tablettes
Anglais :
<a href="http://www.virtualmuseum.ca/index-eng.jsp"><img
src="path/to/English/image" alt="Virtual Museum of Canada" /></a>
Français :
<a href="http://www.museevirtuel.ca/index-fra.jsp"><img
src="path/to/French/image" alt="Musée virtuel du Canada" /></a>
22
Remarque : Remplacer l’attribut src du code susmentionné par le bon chemin d’accès du fichier
pour l’image du logo utilisée dans le produit.
Logos pour les téléphones intelligents
Anglais :
<a href="http://www.virtualmuseum.ca/index-eng.jsp"><img
src="path/to/English/mobileimage" alt="Virtual Museum of Canada" /></a>
Français :
<a href="http://www.museevirtuel.ca/index-fra.jsp"><img
src="path/to/French/mobileimage" alt="Musée virtuel du Canada" /></a>
Remarque : Remplacer l’attribut src du code ci-dessus par le bon chemin d’accès au fichier de
l’image du logo utilisé dans le produit.
L’image du logo du MVC NE DOIT PAS faire partie d’une carte-image côté client ou d’une image de fond
CSS, sans l’autorisation expresse du MCH.
7.11 Élément HTML title
Chaque page du produit DOIT inclure, dans sa section head, un élément title contenant un titre
significatif et riche en mots clés qui comporte au maximum 60 caractères et qui est unique pour le
contenu de cette page. L’élément title DEVRAIT reprendre le titre de la page, si celui-ci est significatif du
contenu de la page.
Remarque : En tant qu’élément de page important du point de vue de l’optimisation des moteurs
de recherche (OMR), le contenu de l’élément title DOIT être rédigé dans la langue
de la page, du plus spécifique au moins spécifique, le titre unique de page
apparaissant en premier, le titre de la section du produit en deuxième, et le titre
principal du produit en dernier. Les titres DOIVENT être séparés par une barre
verticale ( | ).
Élément HTML title pour les pages unilingues : Les métadonnées DEVRAIENT être écrites dans
la langue de la page.
La syntaxe devrait être la suivante :
<title>À propos du Dr. Neville | Praticien spécialiste | Médecins dans le
nord </title>
Élément HTML title pour les pages bilingues : Les métadonnées en français et en anglais
devraient être entrées dans le même élément. Entrer d’abord le titre dans la langue officielle
principale de la province où réside le serveur hébergeant le produit, suivi du titre dans l’autre
langue officielle. Les titres DOIVENT être séparés par une barre verticale ( | ).
Si le produit est hébergé sur un serveur au Québec, la syntaxe devrait être la suivante :
<title>Musée virtuel du Canada | Virtual Museum of Canada</title>
7.12 Bannières, en-têtes et bas de page
Le produit NE DOIT PAS utiliser d’outils de navigation de sites Web commerciaux ou institutionnels,
notamment les bannières, les en-têtes ou les bas de page, sans l’approbation expresse du MCH.
23
8.0 Types et formats de contenu
8.1 Plugiciels et logiciels spécialisés
L’utilisation d’un plugiciel ou d’un logiciel spécialisé pour afficher du contenu interactif DOIT être
considérée comme une amélioration progressive [title="Lien externe,article de Wikipédia sur l’amélioration
progressive" ] d’une version principale HTML et textuelle simple.
Remarque : Un plugiciel ne DOIT PAS être utilisé en remplacement aux formats standards,
disponibles et supportés par HTML5 et les navigateurs principaux : Internet Explorer
9+, Firefox 23+, Google Chrome, Safari 6+ et ceux des appareils mobiles pour
l’affichage interactif du contenu (p. ex. MP4, MP3, WebM, Ogg, Wav, Canvas).
Ainsi, si un contenu du produit nécessite tout de même un plugiciel ou un logiciel spécialisé pour pouvoir
s’afficher, les exigences suivantes sont alors requises :
8.1.1 Accessibilité
Le plugiciel ou un logiciel spécialisé permettant de présenter le contenu DOIT être librement accessible et
pouvoir être installé sur n’importe quelle plateforme (c.-à-d. Windows, Mac et Linux ainsi que sur les
tablettes et téléphones intelligents).
Remarque : Lorsqu’un plugiciel n’est pas disponible pour une plateforme donnée, un plugiciel ou
un logiciel spécialisé compatible tel que VLC DOIT être présenté. (Par exemple, VLC
[title="Lien externe, site de VLC" ] est un cadre d’applications multimédias à code
source libre qui lit la plupart des formats sur toutes les plateformes et qui peut servir
de solution de remplacement.)
8.1.2 Indication du type et de la taille du fichier
Tous les hyperliens vers du contenu qui nécessite un plugiciel ou un logiciel spécialisé DOIVENT être
accompagnés d’une indication textuelle du type et de la taille du fichier qui s’y rattache (p. ex. : document
PDF [PDF 188 Ko]).
8.1.3 Hyperlien vers source
Un hyperlien vers la source du plugiciel ou du logiciel spécialisé pertinent DOIT être fourni sur chaque
page où ce module ou logiciel est nécessaire pour donner accès au contenu.
8.2 Texte
8.2.1 Format
Tout le contenu textuel DOIT être présenté principalement en tant que texte en format HTML.
Remarque : Même si tout contenu textuel DOIT être affiché en format HTML, pareil contenu
PEUT également être parallèlement élaboré dans un format breveté pour
visualisation ou impression au moyen d’un plugiciel librement accessible à l’aide de
toutes les plateformes. L’exemple de ce type de format est PDF d’Adobe, qui exige
l’utilisation d’Adobe Reader, le visualiseur de fichiers PDF d’Adobe, et qui est
disponible pour toutes les plateformes.8.3 Images fixes
24
8.3 Images fixes
8.3.1 Optimisation
Toutes les images fixes DOIVENT être optimisées et améliorées pour le Web, afin de réduire la taille du
fichier et le temps de téléchargement :
• Les graphiques vectoriels DOIVENT utiliser le format GIF ou PNG, et
• Les photographies, les images de haute résolution et les images en demi-teintes DOIVENT
utiliser le format JPEG (à 24 bits).
Remarque : Afin de réduire l’utilisation de la bande passante de l’utilisateur et la fréquence des
redimensionnements, des versions des images préalablement dimensionnées (p. ex.
taille et rapport hauteur-largeur) DOIVENT être disponibles côté serveur pour les
versions optimisées du produit destinées aux tablettes et téléphones intelligents.
Remarque : Des exemptions à cette exigence peuvent être accordées par le MCH dans certains
cas où l’utilisation de solutions propriétaires est nécessaire afin de répondre aux
objectifs du projet. Dans ce cas, les versions optimisées du produit destinées aux
tablettes et téléphones intelligents DOIVENT offrir le choix de poursuivre avec une
version principale HTML et textuelle simple.
8.3.2 Image de grande taille
Tous les hyperliens vers des fichiers image dont la taille est d’au moins 500 Ko DOIVENT être
accompagnés d’une indication textuelle précisant la taille du fichier afin d’alerter les utilisateurs.
8.3.3 Téléchargement
Les pages du produit NE DOIVENT PAS lancer le téléchargement d’un fichier image en taille réelle, sauf
si l’utilisateur l’a expressément demandé.
Remarque : Cette exigence vise à limiter la création de pages comportant des vignettes
associées à d’autres versions pleine taille qui sont camouflées par les feuilles CSS
jusqu’à ce que l’utilisateur place le focus sur la vignette. Ce genre de pages sont
généralement très volumineuses, nécessitent une plus grande bande passante et
obligent l’utilisateur à télécharger du contenu pour lequel il n’a pas indiqué
expressément de l’intérêt.
8.3.4 Fonctionnalités
L’utilisation d’une fonctionnalité pour les images superposées (par exemple, Lightbox) DOIT satisfaire le
principe 2 des Règles pour l’accessibilité des contenus Web (2.0).
Remarque : Les fonctionnalités DOIVENT être accessibles à partir d'un clavier.
Remarque : L’utilisateur DOIT pouvoir naviguer, trouver le contenu et se situer dans le produit.
8.4 Vidéos/animations/images
8.4.1 Taille
La taille des fichiers vidéo NE DOIT PAS dépasser 50 Mo.
Remarque : La taille des fichiers vidéo qui sont pris en charge par les tablettes et les téléphones
intelligents NE DOIT PAS dépasser 15 Mo.
25
8.4.2 Format
Les fichiers vidéo DOIVENT être disponibles dans divers formats sources (p. ex. MP4, WebM, Ogg) à
l’intérieur de l’élément vidéo, afin d’être pris en charge par divers agents navigateurs. Pour obtenir de plus
amples renseignements sur les formats vidéo et la prise en charge des navigateurs, y compris ceux pour
le mobile, voir cet article sur les fichiers vidéo en format HTML5 [title=«Lien externe, HTML5 Video –
W3Schools (en anglais seulement) »]. Le format Adobe Flash NE DOIT PAS être utilisé.
8.4.3 Bande passante
Si un fichier vidéo est préparé pour être exécuté dans un environnement à large bande passante, une
autre version à bande passante réduite DOIT également être préparée et fournie aux utilisateurs.
Remarque : Certains systèmes de diffusion en mode continu permettent aux réalisateurs de
préparer un fichier vidéo unique qui peut être lu aux diverses vitesses de diffusion
correspondant aux différentes vitesses d’accès à Internet. Lorsque ce genre de
systèmes est utilisé, une version unique du fichier vidéo suffit.
8.4.4 Transcription
Les séquences uniquement vidéo DOIVENT comprendre une transcription qui décrit l’information visuelle
importante, et les séquences multimédias synchronisées DOIVENT inclure des sous-titres synchronisés,
ainsi qu’une transcription en texte intégral.
Remarque : La transcription DEVRAIT comprendre en plus du contenu textuel, une ou plusieurs
images fixes représentant le contenu visuel de la séquence vidéo.
Remarque : Le produit DOIT être conforme aux critères de succès de niveau A et AA des règles
pour l’accessibilité des contenus Web (version 2.0)[ title=«Lien externe, Règles pour
l’accessibilité des contenus Web 2.0 « ], sauf au critère 1.2.4[title=«Lien externe,
Règles pour l’accessibilité des contenus Web 2.0 –Règle 1.2.4 »] concernant les soustitres des médias en direct, et au critère 1.2.5[title= Lien externe, Règles pour
l’accessibilité des contenus Web 2.0 –Règle 1.2.5 »] qui demande de fournir des
descriptions audio.
8.4.5 Lecteur vidéo
Les fichiers vidéo qui sont chargés dans un lecteur intégré à un navigateur NE DOIVENT PAS démarrer
automatiquement, et le lecteur DOIT inclure des contrôles pour mettre en marche, arrêter et relire le
fichier vidéo.
8.4.6 Vidéo non diffusés en mode continu
Les fichiers vidéo non diffusés en mode continu qui sont chargés dans un lecteur incorporé au navigateur
DOIVENT être accompagnés d’un hyperlien direct aux fichiers vidéo comme tels, permettant ainsi aux
utilisateurs d’y avoir accès, sans avoir à compter sur le lecteur intégré à un navigateur. Cette exigence NE
s’applique PAS à la version optimisée pour le mobile.
8.4.7 Indication de la taille du fichier
Tous les hyperliens vers des fichiers vidéo diffusés en mode continu DOIVENT être accompagnés d’une
indication contextuelle de la durée et la taille du fichier de la séquence vidéo.
26
8.4.8 Indication de la durée
Les fichiers vidéo qui sont chargés dans un lecteur intégré à un navigateur DOIVENT être accompagnés
d’une indication contextuelle de la durée de la séquence vidéo.
8.4.9 Nombre de lecteur vidéo par exposition
L’exposition DOIT compter qu’un seul lecteur vidéo par format.
Le lecteur intégré NE DOIT PAS fournir des fonctionnalités de tierce partie sur ou via le site web telles
que YouTube. Par contre les séquences vidéo PEUVENT être partagées sur les médias sociaux en
complément par rapport à l’exposition grâce à un lien textuel ou indépendamment sur le site social.
Le lecteur intégré à un navigateur DOIT respecter les Règles pour l'accessibilité des contenus Web
(WCAG) 2.0 en offrant une interface accessible.
8.4.12 Publicité
Aucune publicité NE DOIT apparaître avec la séquence vidéo.
8.4.13 Avis
Un avis DOIT être envoyé aux visiteurs dont le navigateur ne prend pas en charge le format du fichier
requis (p. ex MP4) ou le plugiciel. L’avis DOIT fournir un lien vers la page du téléchargement du plugiciel
et DOIT fournir un lien vers la transcription.
8.5 Fichiers audio/sonores
8.5.1 Taille
La taille des fichiers audio NE DOIT PAS dépasser 50 Mo.
Remarque : La taille des fichiers audio qui sont pris en charge par les tablettes et les téléphones
intelligents NE DOIT PAS dépasser 10 Mo.
8.5.2 Format
Les fichiers audio DOIVENT être disponibles dans divers formats sources (p. ex. MP3, Wav, Ogg) à
l’intérieur de l’élément audio, afin de pouvoir être lus par divers navigateurs, y compris ceux pour le
mobile. Pour obtenir de plus amples renseignements sur les formats audio et la prise en charge des
navigateurs, voir cet article sur les fichiers audio en format HTML5[title="Lien externe, W3Schools, section
HTML5 Audio (en anglais seulement) "].
8.5.3 Bande passante
Si un fichier audio est préparé pour être exécuté dans un environnement à large bande passante, une
autre version à bande passante réduite DOIT également être préparée et fournie aux utilisateurs.
Remarque : Certains systèmes de diffusion en mode continu permettent aux réalisateurs de
préparer un fichier audio unique qui peut être lu aux diverses vitesses de diffusion qui
27
correspondent aux différentes vitesses d’accès à Internet. Lorsque ces systèmes sont
utilisés, une version unique d’un fichier audio suffit.
8.5.4 Transcription
Les fichiers audio DOIVENT comprendre une transcription textuelle des renseignements importants ainsi
que tous les mots parlés. Les fichiers audio qui n’ont pas de mots parlés DOIVENT offrir un sommaire du
contenu.
Remarque : Conformément aux critères de succès 1.2.1[title="Lien externe, Understanding WCAG
2.0 -Audio-only and Video-only (Prerecorded): Understanding SC 1.2.1 (en anglais
seulement)"], 1.2.2[title="Lien externe, Understanding WCAG 2.0 -Audio-only and
Video-only (Prerecorded): Understanding SC 1.2.2 (en anglais seulement)"] et
1.2.3[title="Lien externe, Understanding WCAG 2.0- Audio-only and Video-only
(Prerecorded): Understanding SC 1.2.3 (en anglais seulement)"] de niveau A, les
séquences uniquement sonores DOIVENT comporter une transcription textuelle.
8.5.5 Lecteur audio
Les fichiers audio qui sont chargés dans un lecteur intégré à un navigateur NE DOIVENT PAS démarrer
automatiquement, et le lecteur DOIT inclure des contrôles pour mettre en marche et arrêter la lecture du
fichier audio.
8.5.6 Audio non diffusés en mode continu
Les fichiers audio non diffusés en mode continu qui sont chargés dans un lecteur intégré au navigateur
DOIVENT être accompagnés d’un lien aux fichiers audio comme tels, permettant ainsi aux utilisateurs d’y
avoir accès, sans avoir à compter sur le lecteur intégré à un navigateur. Cette exigence NE s’applique
PAS à la version optimisée pour le mobile.
8.5.7 Indication de la durée et de la taille pour l’audio diffusé en mode continu
Tous les hyperliens vers des fichiers audio diffusés en mode continu DOIVENT être accompagnés d’une
indication contextuelle de la durée et la taille du fichier de la séquence audio.
8.5.8 Avis
Un avis DOIT être envoyé aux visiteurs dont le navigateur ne prend pas en charge le plugiciel ou le
format requis (p. ex. MP3). L’avis DOIT fournir un lien vers la page du téléchargement du plugiciel et
DOIT fournir un lien vers la transcription.
8.5.9 Indication de la durée
Les fichiers audio qui sont chargés dans un lecteur intégré à un navigateur DOIVENT être accompagnés
d’une indication contextuelle de la durée de la séquence audio.
8.5.10 Nombre de lecteur audio par exposition
L’exposition DOIT compter qu’un seul lecteur vidéo.
Le lecteur intégré NE DOIT PAS fournir des fonctionnalités de tierce partie sur ou via le site web telles
que SoundCloud. Par contre les séquences audio PEUVENT être partagées sur les médias sociaux en
complément par rapport à l’exposition grâce à un lien textuel ou indépendamment sur le site social.
28
Le lecteur intégré à un navigateur DOIT respecter les Règles pour l'accessibilité des contenus Web
(WCAG) 2.0 en offrant une interface accessible.
8.5.13 Publicité
Aucune publicité NE DOIT accompagner ou s’entendre dans la séquence audio.
9.0 Cybermétrie et métadonnées
9.1 Cybermétrie
Chaque page du produit DOIT comprendre un code additionnel permettant la collecte de statistiques sur
les visiteurs relatifs au produit.
Remarque : Le MCH communiquera aux soumissionnaires retenus des directives détaillées en ce
qui a trait à l’insertion du code permettant la collecte de statistiques sur les visiteurs.
9.2 Métadonnées
9.2.1 Éléments obligatoires de métadonnées
Les éléments de métadonnées obligatoires suivants DOIVENT être incorporés au code HTML de la
page :
Élément méta « description »
Élément méta « keywords »
Élément DC « title »[lang= « en »]
Élément DC « creator » [lang= « en »]
Élément DC « subject » [lang= « en »]
Élément DC « issued » [lang= « en »]
Élément DC « modified » [lang= « en »]
Élément DC « language » [lang= « en »]
9.2.2 Élément méta « description »
Chaque page d’accueil unilingue, ainsi que chaque page de point d’intérêt et de section de l’exposition
DOIT inclure dans la section « head » [lang= « en »] un élément méta « description » (un bloc de
métadonnées).
L’élément méta « description » contient une description significative et riche en mots-clés qui décrit
globalement le contenu du produit. Cet élément apparaît souvent comme une description dans les
résultats des moteurs de recherche; il DOIT donc être exclusif à cette page, de façon à aider les
utilisateurs à déterminer le contenu de la page.
Il DEVRAIT comprendre environ 170 caractères, mais PAS plus de 200, espaces comprises. Il DEVRAIT
comprendre les mots clés de la page (voir l’élément méta « keywords » ci-dessous).
Élément méta « description » pour les pages unilingues : Les métadonnées DOIVENT être écrites
dans la langue de la page. Seuls les noms propres peuvent être écrits dans la langue originale.
29
<meta name="description" content ="Une exposition virtuelle sur la
randonnée en montagne. Apprenez comment la région sauvage du sud-ouest de
la Colombie-Britannique a séduit les alpinistes à explorer,
cartographier, profiter de sa nature et vouloir la protéger ainsi que ses
sommets.” />
Élément méta « description » pour les pages bilingues : Les métadonnées en français et en anglais
DOIVENT être entrées dans le même élément. Entrer d’abord la description en français, suivie de la
description en anglais, en les séparant par une barre verticale ( | ).
<meta name="description" content="Page d’accueil bilingue qui permet
d’accéder au Musée virtuel du Canada dans la langue de son choix. |
Bilingual splash page that provides access to the Virtual Museum of
Canada in the language of your choice." [lang= « en »] />
9.2.3 Élément méta « keywords »
L’élément méta « keywords » DOIT apparaître dans le code (bloc de métadonnées) de chaque page de
l’exposition.
L’élément méta « keywords » contient une liste des mots et/ou des syntagmes clés qui DOIVENT être
propres et exclusifs au contenu de la page.
Entrer entre trois (3) et dix (10) mots ou syntagmes clés, séparés par des virgules. Éviter les mots très
généraux ou dont la signification est ambigüe. Inclure des synonymes et des acronymes, mais n’insérer
aucune faute d’orthographe courante. Les mots clés peuvent être utilisés par les moteurs de recherche; il
faut donc être aussi exact et précis que possible. Les meilleurs mots clés sont choisis par la ou les
personnes responsable(s) de la rédaction du contenu.
Élément méta « keywords » pour les pages unilingues : Les métadonnées DOIVENT être écrites dans
la langue de la page.
<meta name="keywords" content =”randonnée en montage, escalade, ColombieBritannique” />
Élément méta « keywords » pour les pages bilingues : Les métadonnées en français et en anglais
DOIVENT être entrées dans le même élément. Entrer d’abord les mots clés en français, suivis des mots
clés en anglais, en les séparant par une barre verticale ( | ).
<meta name="keywords" content="espace interactif, expositions virtuelles,
galerie d’images, ressources d’apprentissage, répertoire national des
musées | interactive space, virtual exhibits, image gallery, learning
resources, national museum directory"[lang= « en »] />
9.3 Éléments de métadonnées DC
Les six éléments de métadonnées « DC title[lang= « en »] », « DC creator[lang= « en »] », « DC
subject [lang= « en »]», « DC issued [lang= « en »]», « DC modified[lang= « en »] » et « DC
language [lang= « en »]», DOIVENT être créés conformément aux exigences relatives à l’Ensemble
d’éléments de métadonnées du Dublin Core, version 1.1.
Les six éléments suivants DOIVENT être inclus dans le bloc de métadonnées, sur les pages suivantes :
30
•
•
•
les pages d’accueil unilingues du produit;
la page principale de chaque section majeure du produit, et
les pages qui mettent en vedette des ressources de contexte et de sens suffisants et qui méritent
d’être énumérées dans un moteur de recherche.
9.3.1 DC « title » [lang= « en »]
L’élément DC « title » contient le titre exact, tel qu’il apparaît sur la page (p. ex. « Médecins dans le nord
»). En ce qui concerne les sous-pages d’une ressource, entrer uniquement le titre de la sous-page (pas
celui de la section).
Élément DC « title » pour les pages unilingues : Les métadonnées DOIVENT être écrites dans la
langue de la page.
La syntaxe DOIT être la suivante :
<meta name="dcterms.title" content=" Médecins dans le nord ” />
DC « title » [lang= « en »] pour les pages bilingues : Créer un élément DC « title » comprenant le titre
en français et un autre comprenant le titre en anglais.
<meta name="dcterms.title" content="Musée virtuel du Canada" />
<meta name="dcterms.title" content="Virtual Museum of Canada" />
9.3.2 DC « creator[lang= « en »] »
L’élément DC « creator » [lang= « en »] comprend le nom de la personne ou de l’organisation qui était
responsable de la création du contenu de l’exposition.
Séparer les sous-divisions de l’organisation au moyen de virgules. Séparer les multiples noms
d’organisation à l’aide de points-virgules (si plus d’une organisation a créé la ressource).
Élément DC « creator » pour les pages unilingues : Les métadonnées DOIVENT être écrites dans la
langue de la page.
<meta name="dcterms.creator" content="Vancouver Art Gallery; Royal
British Columbia Museum” />
Élément DC « creator » [lang= « en »] pour les pages bilingues : Créer un élément DC « creator »
[lang= « en »] comprenant le nom en français du créateur et un autre comprenant le nom du créateur en
anglais (si le nom existe en différentes langues).
<meta name="dcterms.creator" content="Musée canadian de l’histoire.” />
<meta name="dcterms.creator" content="Canadian Museum of History” />
9.3.3 DC « subject » [lang= « en »]
L’élément DC « subject » [lang= « en »] indique le sujet de la ressource. Il comprend des termes choisis
provenant du thésaurus sur les sujets de base du gouvernement du Canada.
Sélectionner une ou plusieurs valeurs dans le thésaurus sur les sujets de base du gouvernement du
Canada. Il faut être aussi précis que possible.
Le thésaurus peut être consulté aux adresses suivantes :
31
http://en.thesaurus.gc.ca/thesf/thes_f.html [ title= « Lien externe, Thésaurus des sujets de base du
gouvernement du Canada”]
[lang=en]http://en.thesaurus.gc.ca/these/thes_e.html [title=” External link, Government of Canada
Core Subject Thesaurus”]
Élément DC « subject » [lang= « en »] pour les pages unilingues : Les métadonnées DOIVENT être
écrites dans la langue de la page.
La syntaxe DOIT être la suivante, y compris pour le titre du schéma d’encodage (gccore) :
<meta name="dcterms.subject" title="gccore" content=" Archéologie; Musées
d’art” />
Élément DC « subject » [lang= « en »] pour les pages bilingues : Créer un élément DC « subject »
[lang= « en »] comprenant les termes du sujet en français et un autre comprenant les termes en anglais.
La syntaxe DOIT être la suivante, y compris pour le titre du schéma d’encodage (gccore) :
<meta name="dcterms.subject" title="gccore" content="Exposition
virtuelle; Collection numérique; Site Web" />
<meta name="dcterms.subject" title="gccore" content="Virtual exhibitions;
Digital collections; Website" />
9.3.4 DC « issued » [lang= « en »]
L’élément DC « issued » [lang= « en »] indique la date où la ressource a été publiée pour la première fois
sur le Web. Il ne change jamais.
Entrer une date unique, selon le format AAAA-MM-JJ. Si seuls l’année et le mois sont connus, entrer « 01
» pour le jour (p. ex. 2012-04-01). Si seule l’année est connue, entrer « 01 » à la fois pour le mois et le
jour (p. ex. 2012-01-01).
La syntaxe DOIT être la suivante, y compris pour le titre du schéma d’encodage (W3CDTF) :
<meta name="dcterms.issued" title="W3CDTF" content="2012-01-01” />
9.3.5 DC « modified » [lang= « en »]
L’élément DC « modified » [lang= « en »] indique la date où la ressource a été publiée à nouveau sur le
Web, après avoir fait l’objet d’une révision importante. Cet élément PEUT être laissé vide, sauf dans le
cas d’une révision importante.
Entrer une date unique, selon le format AAAA-MM-JJ. Si seuls l’année et le mois sont connus, entrer « 01
» pour le jour (p. ex. 2012-04-01). Si seule l’année est connue, entrer « 01 » à la fois pour le mois et le
jour (p. ex. 2012-01-01).
La syntaxe DOIT être la suivante, y compris pour le titre du schéma d’encodage (W3CDTF) :
<meta name="dcterms.modified" title="W3CDTF" content="2012-01-01” />
9.3.6 DC « language » [lang= « en »]
L’élément DC « language » [lang= « en »] indique la langue de la page Web décrite.
Entrer un code langues à trois lettres, suivant le schéma d’encodage ISO639-2/T :
Par exemple, anglais=eng; français=fra
Élément DC « language » [lang= « en »] pour les pages unilingues : Les métadonnées DOIVENT être
écrites dans la langue de la page.
32
La syntaxe DOIT être la suivante, y compris pour le titre du schéma d’encodage (ISO639-2/T) :
<meta name="dcterms.language" title="ISO639-2/T" content="fra" /> OU
<meta name="dcterms.language" title="ISO639-2/T" content="eng" />
Élément DC « language » [lang= « en »] pour les pages bilingues : Créer un élément DC
« language » [lang= « en »] comprenant l’abréviation « fra » et un autre comprenant l’abréviation « eng ».
La syntaxe DOIT être la suivante, y compris pour le titre du schéma d’encodage (ISO639-2/T) :
<meta name="dcterms.language" title="ISO639-2/T" content="fra" /> OU
9.4 Sommaire – Métadonnées
9.4.1 Tableau des métadonnées requises
Tableau des métadonnées requises avec définitions et remarques
ÉLÉMENT
REQUIS POUR
DÉFINITION
9.2.2 Élément
méta
« description »
9.2.3 Élément
méta
« keywords »
[lang= « en »]
9.3.1 DC « title »
[lang= « en »]
9.3.2 DC
« creator »
[lang= « en »]
9.3.3 DC
« subject »
[lang= « en »]
Chaque page d’accueil
unilingue
L’élément méta « description »
contient une description
significative et riche en mots
clés qui décrit globalement le
contenu du produit.
Chaque page de
l’exposition
L’élément méta « keywords »
[lang= « en »] contient une
liste des mots et/ou des
syntagmes clés qui DOIVENT
être propres et exclusifs au
contenu de la page.
Pour les six éléments
DC, entrer des
métadonnées sur :
• chaque page
d’accueil unilingue;
• la page principale
de chaque section
importante du
produit;
• les pages qui
mettent en vedette
des ressources de
contexte et de
sens suffisants et
qui méritent d’être
énumérées dans
un moteur de
recherche.
L’élément DC « title »
[lang= « en »] comprend le
titre exact, tel qu’il apparaît sur
la page.
L’élément DC « creator »
[lang= « en »] comprend le
nom de la personne ou de
l’organisation qui était
responsable de la création du
contenu de l’exposition.
L’élément DC « subject »
[lang= « en »] indique le sujet
de la ressource. Il comprend
des termes choisis provenant
du thésaurus sur les sujets de
base du gouvernement du
REMARQUES
Pour une page
bilingue, utiliser :
Description en
français |
Description en
anglais (dans la
même ligne de
l’élément).
Pour une page
bilingue, entrer les
mots clés en
français, suivis des
mots clés en anglais
(dans la même ligne
de l’élément).
Pour une page
bilingue, entrer
l’élément deux fois :
une fois pour le titre
en français et une
fois pour le titre en
anglais.
Pour une page
bilingue, entrer
une fois pour le nom
en français (s’il en
existe un) et une
fois pour le nom en
anglais (s’il en
existe un).
Pour une page
bilingue, entrer
une fois pour les
termes en français
et une fois pour les
33
Canada.
9.3.4 DC
« issued »
[lang= « en »]
9.3.5 DC
« modified »
[lang= « en »]
9.3.6 DC
« language »
[lang= « en »]
termes en anglais.
L’élément DC « issued »
[lang= « en »] indique la date
où la ressource a été publiée
pour la première fois sur le
Web. Il ne change jamais.
L’élément DC « modified »
[lang= « en »] indique la date
où la ressource a été publiée à
nouveau sur le Web, après
avoir fait l’objet d’une révision
importante. Cet élément peut
être laissé vide, sauf dans le
cas d’une révision importante.
L’élément DC « language »
[lang= « en »] définit la langue
de la page Web décrite.
Pour une page
bilingue, entrer
une fois pour la
version en français
et une fois pour
celle en anglais.
9.4.2 Exemple de bloc de métadonnées
Exemple de bloc de métadonnées pour les pages unilingues :
<title>Home | Canada’s Symbolic Animals</title>
<! -- METADATA BEGINS | DEBUT DES METADONNEES -->
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<link rel="schema.dc" href="http://purl.org/dc/elements/1.1/" />
<link rel="schema.dcterms" href="http://purl.org/dc/terms/" />
<meta name="description" content=" Animaux emblématiques des valeurs et de la
culture canadiennes, représentant les peuples qui ont choisi des noms pour les
villes, les lacs, les écoles et les clubs sportifs." />
<meta name="keywords" content=" animaux, faune, emblèmes, symboles, noms de
lieux, culture canadienne, symboles canadiens, animaux symboliques, Canada" />
<meta name="dcterms.title" content="Canada’s Symbolic Animals” />
<meta name="dcterms.creator" content="New Brunswick Museum; Musée de la nature
et des sciences; University of Alberta Museums” />
<meta name="dcterms.subject" title="gccore" content="Animals; Symbols;
Emblems; Toponymy; Zoology; Games; Educational resources" />
<meta name="dcterms.issued" title="W3CDTF" content="2005-03-29” />
<meta name="dcterms.modified" title="W3CDTF" content="" />
<! -- METADATA ENDS | FIN DES METADONNEES -->
Exemple de bloc de métadonnées pour les pages bilingues :
<title>Les animaux emblèmes du Canada | Canada’s Symbolic Animals</title>
<! -- BILINGUAL METADATA BEGINS | DEBUT DES METADONNEES BILINGUES -->
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<link rel="schema.dc" href="http://purl.org/dc/elements/1.1/" />
<link rel="schema.dcterms" href="http://purl.org/dc/terms/" />
34
<meta name="description" content=" Animaux emblématiques des valeurs et de la
culture canadiennes, représentant les peuples qui ont choisi des noms pour les
villes, les lacs, les écoles et les clubs sportifs. | The animals that
symbolize Canadian values and culture, and represent the people who chose
their names for cities, lakes, schools and sports clubs." />
<meta name="keywords" content="animaux, faune, emblèmes, symboles, noms de
lieux, culture canadienne, symboles canadiens, animaux symboliques, Canada |
animals, wildlife, emblems, symbols, place names, Canadian culture, Canadian
symbols, symbolic animals, Canada" />
<meta name="dcterms.title" content="Les animaux emblèmes du Canada" />
<meta name="dcterms.title" content="Canada’s Symbolic Animals" />
<meta name="dcterms.creator" content="Musée du Nouveau-Brunswick; Musée de la
nature et des sciences; University of Alberta Museums" />
<meta name="dcterms.creator" content="New Brunswick Museum; Musée de la nature
et des sciences; University of Alberta Museums" />
<meta name="dcterms.subject" title="gccore" content=Animal; Symbole; Emblème;
Toponymie; Zoologie; Jeu; Ressources pédagogiques" />
<meta name="dcterms.subject" title="gccore" content="Animals; Symbols;
Emblems; Toponymy; Zoology; Games; Educational resources" />
<meta name="dcterms.issued" title="W3CDTF" content="2005-03-29" />
<meta name="dcterms.modified" title="W3CDTF" content="" />
<meta name="dcterms.language" title="ISO639-2/T" content="fra" />
<! -- BILINGUAL METADATA ENDS | FIN DES METADONNEES BILINGUES -->
C) Technologies
10.0 Spécifications techniques du serveur et de la base de données
10.1 Temps de réponse
Remarque : Les produits DEVRAIENT être chargés assez rapidement. Un temps de réponse lent
entraîne une hausse du taux de rebond et une baisse du nombre moyen de pages
consultées par visite.
Remarque : Dans le cas des appareils mobiles, le temps de réponse DEVRAIT aussi être rapide.
En plus, la taille du contenu et des éléments à télécharger du serveur, le nombre
d’appels au serveur ainsi que les rafraichissements de page DOIVENT tous être
réduit de manière optimale.
35

Exigences techniques pour le développement des produits du

Transcription

Documents pareils

Modifier la page ‹ Loca Service — WordPress

AB International

Agent informatique

DESCRIPTION D`EMPLOI / JOB DESCRIPTION

Coordonnateur magnétoscope TV

Adjoint réception et inventaire

Publication Ce qui se montre : de la différence iconique

Coordonnateur accueil

Centre de documentation Liste des documents / List of documents

Exposition collective