Musée virtuel du Canada (MVC) Programme d'investissement pour des expositions virtuelles

11e appel - Annexe I - Exigences d'ordre technique pour le développement des expositions et jeux du MVC, 1.3 (novembre 2005)

Note: Pour de plus amples renseignements sur les exigences d'ordre technique suivantes, ainsi que d'autres recommandations et pratiques exemplaires, consultez le document, Exigences et recommandations d'ordre technique pour le développement des expositions et jeux du Musée virtuel du Canada (MVC), 1.3 [PDF].

Table des matières

1.0	Langages de balisage et de script Langage de balisage Scripts côté client Encodage de caractères et caractères spéciaux
2.0	Navigateurs et plugiciels Navigateurs Plugiciels et logiciel de diffusion média Protocole Secure Sockets Layer (SSL)
3.0	Types de contenu et normes de format Texte Images fixes Vidéos/images mobiles Audio/fichiers sonores Fichiers d'animation Bases de données
4.0	Désignation et structure des fichiers et des répertoires Structure des fichiers et des répertoires Noms de fichiers et de répertoires
5.0	Navigation et mise en page MVC Logo Navigation dans la version linguistique Navigation dans les fenêtres en incrustation Droit d'auteur Crédits Mécanisme de rétroaction Carte de site Titres de haut de page et de bas de page navigationnels Trames
6.0	Accessibilité Directives pour l'accessibilité aux contenus Web du W3C
7.0	Optimisation pour moteurs de recherche (OMR) Élément <Title> Éléments <Meta>« keywords » et « description »
8.0	Métadonnées (Dublin Core) Création du contenu des métadonnées Mise en œuvre des métadonnées
9.0	Exigences techniques pour le contenu hébergé par le RCIP Environnement du serveur Web du RCIP

1.0 Langages de balisage et de script

Langage de balisage

1. Le produit doit être développé pour fins d'exécution sur un navigateur Web dans la variante « Strict » ou « Transitional » des langages HyperText Markup Language (HTML) ou Extensible HyperText Markup Language (XHTML) selon la recommandation du World Wide Web Consortium (W3C). À l'heure actuelle, ces normes sont HTML 4.01 et XHTML 1.0.
   
   NOTE : L'utilisation de la variante « Frameset » de l'un ou l'autre des langages de balisage n'est pas autorisée. De plus, si l'on utilise XHTML 1.0, il est important de comprendre les enjeux à servir des documents XHTML en tant que XML (étiquetage MIME « application/xhtml+xml ») par opposition à HTML (étiquetage MIME « text/html »). Pour plus de précisions sur ces enjeux, voir le document du W3C, Les types de Media XHTML, ainsi que les tutoriaux W3C, Character sets & encodings in XHTML, HTML and CSS et Servir du XHTML 1.0.



2. Le produit et toutes ses pages doivent se valider par rapport à une définition de type de document (DTD) publiée par le W3C pour la variante « Strict » ou « Transitional » de HTML 4.01 ou de XHTML 1.0, selon le langage de balisage utilisé. Le W3C Markup Validation Service vérifiera à la fois les fichiers HTML et XHTML pour la conformité aux recommandations et normes du W3C suivant la DTD spécifiée.
   
   NOTE : Valider par rapport aux grammaires approuvées telles que définies par les DTD formelles aborde également le point à contrôler 3.2 des Directives pour l'accessibilité aux contenus Web (version 1.0) du W3C, un point à contrôler auquel le produit doit se conformer. Voir 6.0 Accessibilité.



3. Les feuilles de style en cascade (CSS) utilisées par le produit ne doivent pas être imbriquées ou incorporées, mais doivent être référencées en tant que fichiers externes suivant le format de code suivant :
   
   <link rel="stylesheet" type="text/css" href="Css/styles.css">
   
   NOTE : Remplacez « Css/styles.css » dans l'exemple ci-dessus par le nom et l'emplacement réels de votre fichier CSS. Si vous utilisez le langage XHTML, assurez-vous de bien fermer l'élément <link>, qui est un élément vide, en ajoutant un espace et une barre oblique de queue (/) avant la dernière parenthèse pointue (>) dans l'élément <link>, c.-à-d. :
   
   <link rel="stylesheet" type="text/css" href="Css/styles.css" />

Scripts côté client

4. Les scripts côté client utilisés par le produit doivent être conformes à la norme ECMAScript, version 3, également appelée ECMA-262.
   
   
5. Les scripts côté client utilisés par le produit doivent être testés et fonctionnels au moyen de navigateurs Web énumérés sous la rubrique 2.0 Navigateurs et plugiciels.
   
   NOTE : Les principales caractéristiques du produit doivent fonctionner même lorsque la capacité d'utiliser les scripts est désactivée dans un navigateur. Voir 6.0 Accessibilité, en particulier le point à contrôler 6.3.
   
   
6. Les scripts côté client utilisés par le produit ne doivent pas être imbriqués dans une page ou un objet à partir duquel elles sont appelés. Ils doivent être placés dans un ou plusieurs fichiers externes qui sont référencés dans la section <head> de la page, au moyen du format de code suivant :
   
   <script language="javascript" type="text/javascript" src="Scripts/script.js"></script>
   
   NOTE : Remplacez « Scripts/script.js » dans l'exemple ci-dessus par le nom de fichier et le chemin exacts.

Encodage de caractères et caractères spéciaux

7. Le produit doit utiliser comme encodage de caractères la norme UTF-8 ou ISO-8859-1. L'encodage utilisé doit être spécifié dans chacune des pages Web du produit.
   
   Pour les documents HTML, et les documents XHTML servis comme HTML (étiquetage MIME « text/html »), l'encodage doit être établi par la déclaration « charset » de l'élément <meta> placée le plus près possible du haut de la section <head> de la page Web, par exemple :
   
   <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
   
   Pour les documents XHTML servis comme XML (étiquetage MIME « application/xhtml+xml »), la déclaration « charset » de l'élément <meta> ne devrait pas être utilisée. À la place, mentionnez l'encodage de caractères dans la déclaration XML qui doit apparaître à la première ligne de chaque page Web servie comme XML :
   
   <?xml version="1.0" encoding="utf-8"?>
   
   NOTE : Pour une discussion des enjeux touchant l'encodage de caractères et le fait de servir des documents (X)HTML, voir le tutoriaux W3C, Character sets & encodings in XHTML, HTML and CSS et Servir du XHTML 1.0.
   
   
8. Utilisez des références d'entités de caractères (p. ex., « &lt; » pour « < ») ou des références de caractères numériques (p. ex., « &#60; » pour « < ») pour exprimer tous les caractères spéciaux.

2.0 Navigateurs et plugiciels

Navigateurs

1. Le produit doit être visualisable et entièrement fonctionnel dans les navigateurs suivants pour plates-formes Windows et Macintosh :
   
   Windows
   • Microsoft Internet Explorer, version 5.01 et supérieure;
   • Netscape Navigator, version 7.0 et supérieure;
   • Firefox, version 1.0 et supérieure.
   
   
   Macintosh
   • Microsoft Internet Explorer, version 5.1.7 et supérieure;
   • Netscape Navigator, version 7.0 et supérieure;
   • Firefox, version 1.0 et supérieure;
   • Safari, version 1.0 et supérieure.
   
   
   NOTE : La liste de navigateurs ci-dessus est à jour en date de juillet 2005, mais elle subit une évolution et une mise à jour constantes. Veuillez également noter que, conformément aux exigences sous la rubrique 6.0 Accessibilité, le produit doit être accessible sur des connexions Internet lentes ou à composition au moyen de navigateurs qui n'affichent pas de graphiques ou d'images, et il devrait donc être testé et validé au moyen d'un navigateur ou émulateur en mode texte seulement.



2. L'utilisation d'éléments et / ou de technologies propres à un navigateur (p. ex., les éléments <marquee> d'Internet Explorer ou <blink> de Netscape Navigator) n'est pas autorisée.

Plugiciels et logiciel de diffusion média

3. Les technologies plugiciels doivent être indépendantes des plates-formes et être appuyées par les navigateurs Web énumérés sous la rubrique Navigateurs.
   
   
4. Si, pour être visualisé, le produit exige un plugiciel ou un logiciel spécial de diffusion média tel que le lecteur QuickTime d'Apple, le Lecteur Windows Media de Microsoft, le Flash Player de Macromedia ou RealPlayer de Real, un lien vers la source du plugiciel ou du logiciel doit être fourni et être accessible à partir de chacune des pages principales unilingues du produit et / ou à partir de la page ou des pages sur lesquelles le plugiciel ou le logiciel est requis pour accéder au contenu.

Protocole Secure Sockets Layer (SSL)

5. Le produit doit utiliser le protocole Secure Sockets Layer (SSL) lorsque tout renseignement personnel (y compris, mais sans s'y restreindre, le nom, l'adresse, l'âge, l'adresse de courriel, le numéro de téléphone et le numéro de carte de crédit) est exigé d'un utilisateur.
   
   NOTE : Il n'est pas nécessaire d'utiliser le protocole SSL lorsqu'on demande le sobriquet d'un utilisateur seulement, par exemple, pour conserver un score élevé dans un jeu en ligne.

3.0 Types de contenu et normes de format

Texte

1. Le contenu textuel doit être développé pour fins d'exécution sur un navigateur Web dans la variante « Strict » ou « Transitional » du langage HyperText Markup Language (HTML) ou Extensible HyperText Markup Language (XHTML) selon la recommandation du World Wide Web Consortium (W3C). À l'heure actuelle, ces langages sont HTML 4.01 et XHTML 1.0.
   
   Bien que tout contenu textuel doive être affiché en tant que (X)HTML, pareil contenu peut également être élaboré dans un format breveté pour visualisation ou impression au moyen d'un logiciel enfichable librement accessible sur Internet. Un exemple de ce type de format est PDF d'Adobe, qui exige l'utilisation d'Adobe Reader, le visualiseur de fichiers PDF d'Adobe.
   
   Le contenu textuel peut également être exécuté en formats RTF ou ASCII, ou à titre de fichier de texte délimité. Le contenu produit selon pareils formats est acceptable si les fichiers sont destinés à un téléchargement, un entreposage ou un traitement par des utilisateurs provenant de l'extérieur de l'environnement du navigateur, et s'ils ne sont pas destinés à se substituer au contenu créé en (X)HTML.
   
   NOTE : Cette exigence ne s'applique pas au texte se trouvant dans des images fixes, des images mobiles, des vidéos ou des fichiers d'animation.

Images fixes

2. Tous les éléments graphiques doivent être optimisés et rehaussés pour le Web afin de réduire la taille des fichiers et la durée du téléchargement :
   
   
   • Dans le cas des graphiques vectoriels, l'utilisation des formats GIF ou PNG est requise.
   • Dans le cas des photographies, de la haute résolution et des images en demi-teintes, l'utilisation du format JPEG (à 24 bits) est requise.
   • Tous liens vers des gros fichiers d'images (c.-à-d. les fichiers de taille supérieure à 50 Ko) doivent comprendre une étiquette qui indique la taille des fichiers afin d'alerter les utilisateurs.
   
   
   
3. Des exemptions aux exigences ci-dessus peuvent être accordées par le RCIP dans certaines situations où l'utilisation de solutions brevetées est requise pour atteindre les objectifs du projet. Ces solutions doivent permettre la visualisation ou l'utilisation du contenu sans frais, p. ex., par l'utilisation d'un plugiciel ou d'un lecteur de diffusion librement accessible. Une justification doit être fournie pour l'utilisation de telles technologies dans le contexte des objectifs du projet. Cela pourrait être le cas, par exemple, lorsque des cartes géographiques sont numérisées. Dans pareils cas, des solutions spécialisées pourraient être choisies pour fournir aux utilisateurs une plus grande souplesse dans la visualisation des objets numérisés.

Vidéos/images mobiles

4. Les vidéos et les fichiers d'images mobiles doivent être préparés dans un format qui peut être lu par un lecteur librement accessible notamment le lecteur QuickTime d'Apple, le Lecteur Windows Media de Microsoft, le Flash Player de Macromedia ou RealPlayer de Real. Cela comprend les formats suivants couramment acceptés :
   
   
   • AVI (.avi)
   • Flash (.swf, .flv)
   • MPEG (.mpg, .mpeg)
   • QuickTime (.mov)
   • RealVideo (.ram, .rm)
   • Shockwave/Director (.dcr)
   • Windows Media Video (.wmv)
   
   Veuillez obtenir l'approbation du RCIP si vous prévoyez utiliser un autre format.
   
   
5. Les vidéos peuvent être diffusées en temps réel ou acheminées en tant que fichier à télécharger avant de visualiser. Si un fichier vidéo est préparé pour exécution dans un environnement à large bande passante, une autre version à bande passante réduite doit également être préparée et fournie aux utilisateurs.
   
   Certains systèmes de diffusion en temps réel permettent aux réalisateurs de préparer un fichier vidéo unique qui peut être lu à diverses vitesses de diffusion correspondant aux multiples vitesses d'accès à Internet. Dans les cas où pareils systèmes sont utilisés, une version unique d'un fichier vidéo suffit.
   
   NOTE : Le RCIP retient régulièrement à contrat les services de diffusion en temps réel de vidéos auprès d'Akamai. Si le produit doit utiliser de la vidéo à diffusion en temps réel, il lui est possible d'utiliser ce service. Pour de plus amples renseignements, communiquez avec le RCIP.
   
   
6. Les fichiers vidéo à diffusion en temps réel qui sont chargés dans un lecteur imbriqué dans un fureteur ne doivent pas démarrer automatiquement, et le lecteur doit inclure des contrôles de lancement et d'arrêt de la vidéo. Cela vise à empêcher les gros fichiers vidéo d'être diffusés automatiquement sans l'autorisation expresse ou le contrôle de l'utilisateur, surtout dans le cas de connexions Internet lentes ou à composition.
   
   
7. Tous les liens vers des gros fichiers vidéo (c.-à-d. les fichiers supérieurs à 50 Ko) doivent être accompagnés d'une étiquette indiquant la taille et la durée du fichier.
   
   
8. Lorsqu'un codec est utilisé pour comprimer le contenu de fichiers vidéo, le codec doit être inclus dans une plate-forme standard (notamment les plates-formes Apple, Real ou Microsoft) ou être librement accessible pour fins d'installation par les utilisateurs. Un lien vers le codec doit être fourni pour les utilisateurs qui ont besoin de le télécharger ou de l'installer.

Audio/fichiers sonores

9. Les fichiers sonores ou audio doivent être préparés dans un format qui peut être lu par un lecteur librement accessible tel que le lecteur QuickTime d'Apple, le Lecteur Windows Media de Microsoft, le Flash Player de Macromedia ou RealPlayer de Real. Cela comprend les formats suivants couramment acceptés :
   
   
   • Flash (.swf)
   • MP3 (.mp3)
   • RealAudio (.ram, .rm)
   • WAV (.wav)
   • Windows Media Audio (.wma)
   
   Veuillez obtenir l'approbation du RCIP si vous prévoyez utiliser un autre format.
   
   
10. Les éléments audio peuvent être diffusés en temps réel ou acheminés en tant que fichier à télécharger avant l'écoute. Si un fichier audio est préparé pour exécution dans un environnement à large bande passante, une autre version à bande passante réduite doit également être préparée et fournie aux utilisateurs.
    
    Certains systèmes de diffusion en temps réel permettent aux réalisateurs de préparer un fichier audio unique qui peut être lu à différentes vitesses de diffusion correspondant aux multiples vitesses d'accès à Internet. Dans les cas où de tels systèmes sont utilisés, une version unique d'un fichier audio suffit.
    
    
11. Les fichiers audio à diffusion en temps réel qui sont chargés dans un lecteur imbriqué dans un fureteur ne doivent pas démarrer automatiquement, et le lecteur doit inclure des contrôles de lancement et d'arrêt de l'audio. Cela vise à empêcher les gros fichiers audio d'être diffusés automatiquement en temps réel sans l'autorisation expresse ou le contrôle de l'utilisateur, surtout dans le cas de connexions Internet lentes ou à composition.
    
    
12. Tous les liens vers des gros fichiers audio (c.-à-d. les fichiers supérieurs à 50 Ko) doivent être accompagnés d'une étiquette indiquant la taille et la durée du fichier.
    
    
13. Lorsqu'un codec est utilisé pour comprimer le contenu du fichier audio, il doit être inclus dans une plate-forme standard (notamment les plates-formes Apple, Real ou Microsoft) ou être librement accessible pour fins d'installation par les utilisateurs. Un lien vers le codec doit être fourni à l'intention des utilisateurs qui ont besoin de le télécharger et de l'installer.
    
    

Fichiers d'animation

14. Les fichiers d'animation doivent être préparés dans un format qui peut être lu par tous les navigateurs énumérés sous la rubrique 2.0 Navigateurs et plugiciels ou par l'utilisation d'un plugiciel librement accessible. Cela comprend les formats suivants couramment acceptés :
    
    
    • Animated GIF (.gif)
    • Flash (.swf)
    • Shockwave/Director (.dcr)
    
    Veuillez obtenir l'approbation du RCIP si vous prévoyez utiliser un autre format.

Bases de données

15. Si le produit emploie une base de données et doit être hébergé sur le serveur du RCIP, la base de données doit utiliser le système de gestion de bases de données (SGBD) MySQL.
    
    NOTE : Voir la rubrique 9.0 Exigences techniques pour le contenu hébergé par le RCIP, pour la plus récente version de MySQL en usage sur le serveur du RCIP.
    
    
16. Si le produit emploie une base de données et doit être hébergé sur le serveur du RCIP, la base de données doit être documentée dans un dictionnaire de données qui inclut une liste de tous les fichiers de bases de données, et le nom, le type et la description de chaque champ. La documentation doit également comprendre un schéma graphique de la base de données, ainsi que des explications des principales décisions derrière la conception et la structure, la normalisation, etc. de la base de données. Cette documentation servira à plusieurs fins, y compris la facilitation des migrations éventuelles, la reprise et la préservation des données, et permettra à d'autres de mieux comprendre la base de données dans le cas de futurs travaux de maintenance et de mises à jour de logiciels.
    
    
17. Si le produit emploie une base de données et doit être hébergé sur le serveur du RCIP, toute information qui est stockée dans la base de données et qui indique l'utilisation du produit doit avoir une valeur d'horodateur associée à des fins de dépistage et de vérification.

4.0 Désignation et structure des fichiers et des répertoires

Structure des fichiers et des répertoires

1. Le répertoire supérieur ou racine du produit, ainsi que tous les répertoires contenant une ou plusieurs pages Web, doit inclure une page implicite (p. ex., index.html, default.html, index.php) qui sert de page principale pour ce répertoire. Voir la rubrique 5.0 Navigation et mise en page pour la structure navigationnelle que ces pages doit incorporer.
   
   
2. Le produit doit inclure, dans son répertoire supérieur ou racine, des répertoires distincts pour chaque version linguistique du produit. Voir la rubrique 5.0 Navigation et mise en page pour la structure navigationnelle que ces pages doit incorporer.
   
   
3. Les fichiers de produit contenant un important contenu commun à toutes les versions linguistiques du produit (p. ex., images, CSS, JavaScript) doivent être placés dans des répertoires uniques situés dans le répertoire supérieur ou racine du produit, et ne doivent pas être dupliqués.
   
   
4. Les fichiers de produit spécifiques à une version linguistique particulière du produit doivent être situés dans le répertoire de cette version linguistique.

Noms de fichiers et de répertoires

5. Les règles et conventions de désignation de noms de fichiers et de répertoires du produit doivent être documentées.
   
   
6. Tous les noms de répertoires et de fichiers du produit doivent utiliser, dans la mesure du possible, des mots reconnus, séparés par des traits d'union (-) au besoin. Les mots doivent être significatifs et descriptifs, refléter l'institution et les utilisateurs prévus, et utiliser le langage de la version de produit visée.
   
   Par exemple, un nom de répertoire tel que « HistoireManitoba » n'est pas reconnu comme un mot ou une expression, mais il peut le devenir par la séparation des mots individuels au moyen d'un trait d'union, c.-à-d. « Histoire-Manitoba ».
   
   NOTE : Pour les produits qui sont hébergés sur le serveur du RCIP, les mots individuels dans les noms de répertoires doivent tous commencer par une lettre majuscule, tandis que les noms de fichiers doivent tous être en minuscules. Par exemple, « Histoire-Manitoba » est un nom de répertoire valide, tandis que « histoire-manitoba.html » est un nom de fichier valide.
   
   
7. Tous les fichiers (X)HTML du produit doivent utiliser le suffixe « .html », et non pas le suffixe « .htm ».
   
   

5.0 Navigation et mise en page

VMC Logo

1. Le logo du MVC, qui sera fourni par le RCIP, doit figurer dans le coin supérieur droit de chaque page de produit, y compris les fenêtres en incrustation. Le logo du MVC doit être affiché sans bordure d'image. Les références JavaScript et le code (X)HTML qui suivent doivent être incorporés dans le produit.
   
   D'abord, le fichier de produit doit contenir les références suivantes à un fichier source en JavaScript :
   
   Anglais
   <script type="text/javascript" language="javascript" src="http://www.virtualmuseum.ca/Logo_Script/english.js"></script>
   
   Français
   <script type="text/javascript" language="javascript" src="http://www.museevirtuel.ca/Logo_Script/francais.js"></script>
   
   Ensuite, le code (X)HTML suivant doit être utilisé pour charger le logo auprès de la cible appropriée :
   
   Anglais
   <a href="http://www.virtualmuseum.ca" onclick="javascript:gotoVirtualMuseumofCanada(); return false;"><img src="Images/vmc_animated.gif" width="147" height="42" alt="Virtual Museum of Canada " title="See more of the Virtual Museum of Canada" /></a>
   
   Français
   <a href="http://www.museevirtuel.ca" onclick="javascript:gotoVirtualMuseumofCanada(); return false;"><img src="Images/vmc_animated.gif" width="147" height="42" alt="Musée virtuel du Canada" title="Pour voir davantage du Musée virtuel du Canada" /></a>
   
   NOTE : Remplacez « Images/vmc_animated.gif », ainsi que les attributs « width » et « height », dans le code ci-dessus par le nom, l'emplacement, et les dimensions appropriés du fichier image du logo.

Navigation dans la version linguistique

2. La page implicite (p. ex., index.html, default.html, index.php) dans le répertoire supérieur ou racine du produit doit servir de page introductive ou d'entrée de la sélection linguistique du produit et inclure un lien vers chaque version linguistique du produit.
   
   
3. La page principale de chaque version linguistique du produit doit comprendre un lien vers l'autre version linguistique ou les autres versions linguistiques. Ce lien doit être visible sans défilement de la page.
   
   
4. La page implicite (p. ex., index.html, default.html, index.php) dans le répertoire principal de chaque version linguistique du produit doit servir de page d'entrée principale pour cette version linguistique, et comprendre un lien vers chaque format particulier du produit, p. ex., Flash ou (X)HTML, le cas échéant.

Navigation dans les fenêtres en incrustation

5. Toutes les fenêtres en incrustation doivent comprendre une bannière qui :
   
   
   • Identifie le contenu de la fenêtre en incrustation en tant que partie intégrante du produit;
   • Fournit un lien vers la page d'accueil ou d'entrée de la version linguistique pertinente du produit.

Droit d'auteur

6. Le produit doit inclure, sous forme d'une page Web distincte, un énoncé de droit d'auteur intégral qui identifie tous les détenteurs de droits.
   
   
7. Le symbole de copyright, ©, le détenteur du droit d'auteur et l'année au cours de laquelle le produit a été lancé, doivent apparaître sur chaque page de produit et mener à l'énoncé de droit d'auteur intégral (voir F ci-dessus), par exemple :
   
   © Musée d'histoire 2005. Tous droits réservés.
   
   NOTE : Si l'institution qui détient le droit d'auteur est officiellement bilingue, utilisez le nom anglais de l'institution dans la version anglaise du produit, et le nom français de l'institution dans la version française. Si l'institution est unilingue, utilisez le même nom d'institution dans chaque version linguistique.

Crédits

8. Le produit doit avoir une section « Crédits » qui est reliée à la fois à la page introductive de la sélection linguistique et chaque page d'entrée unilingue, et qui reconnaît la participation financière du Gouvernement du Canada comme suit :
   
   Anglais
   The [Name of Institution] gratefully acknowledges the financial investment by the Department of Canadian Heritage in the creation of this online presentation for the Virtual Museum of Canada.
   
   Français
   Le [Nom de l'établissement] exprime sa reconnaissance au ministère du Patrimoine canadien pour son investissement financier dans la création de cette présentation en ligne dans le cadre du Musée virtuel du Canada.
   
   
9. La section « Crédits » doit nommer tous les partenaires institutionnels participant au produit et y mener.

Mécanisme de rétroaction

10. Chaque page de produit doit inclure un lien qui permet une rétroaction de l'auditoire. Le mécanisme de rétroaction doit être configuré pour permettre également l'envoi d'un courriel au RCIP (vmccc@virtualmuseum.ca ou mvccc@museevirtuel.ca) accompagné d'une identification nette du produit dans la ligne d'objet.
    
    Le RCIP fournira, sur demande, un script PERL qui pourra être utilisée pour créer le mécanisme de rétroaction par courriel requis.
    
    NOTE : Cela ne modifie en rien la responsabilité de l'institution en matière de rétroaction selon ce qui est précisé à la clause 3.11 de la Convention.
    
    
11. Les utilisateurs doivent également être avisés que leurs messages de rétroaction sont également transmis au RCIP, et doivent avoir accès à un lien vers la fenêtre en incrustation de déclaration de Politique de protection des renseignements personnels du RCIP (voir l'exemple ci-dessous). Sinon, l'information qui identifie l'utilisateur pourrait être retirée de la rétroaction.
    
    Exemple du message en anglais
    Your comments will also be forwarded to the Canadian Heritage Information Network (CHIN), which has overall responsibility for the Virtual Museum of Canada, to be used as part of its audience research. Please see the CHIN Privacy Policy for more information.
    
    Exemple du message en français
    Vos commentaires seront également acheminés au Réseau canadien d'information sur le patrimoine (RCIP), qui a la responsabilité globale du Musée virtuel du Canada. Ils seront utilisés à des fins de recherche sur le public. Veuillez consulter la Politique du RCIP sur la protection des renseignements personnels pour de plus amples renseignements.
    
    Les références JavaScript et le code (X)HTML qui suivent doivent être présents pour l'utilisation de la fenêtre en incrustation de déclaration de Politique de protection des renseignements personnels du RCIP :
    
    Référence JavaScript en anglais
    <script type="text/javascript" language="javascript" src="http://www.virtualmuseum.ca/Logo_Script/english.js"></script>
    
    (X)HTML en anglais
    <a href="http://www.virtualmuseum.ca/English/Common/copyright.html#privacy" onclick="privPolicy(this.href,this.target,'...'); return false;">Link Goes Here</a>
    
    Référence JavaScript en français
    <script type="text/javascript" language="javascript" src="http://www.museevirtuel.ca/Logo_Script/francais.js"></script>
    
    (X)HTML en français
    <a href="http://www.museevirtuel.ca/Francais/Common/copyright.html#privacy" onclick="privPolicy(this.href,this.target,'...'); return false;">Link Goes Here</a>

Carte de site

12. Chaque version linguistique du produit doit inclure une page Web avec une carte de site qui utilise des liens texte, par opposition à des liens graphiques ou à des boutons.
    
    
13. Chaque page du produit doit inclure un lien texte vers la carte de site dans la langue appropriée afin de s'assurer que les utilisateurs humains et les moteurs de recherche puissent trouver chaque page du produit.

Titres de haut de page et de bas de page navigationnels

14. L'utilisation d'une navigation de site Web corporative, notamment les titres de haut de page et de bas de page, n'est pas autorisée sans l'approbation expresse du RCIP.

Trames

15. L'utilisation de trames n'est pas autorisée.

6.0 Accessibilité

Directives pour l'accessibilité aux contenus Web du W3C

1. Le produit doit se conformer aux points à contrôler de Priorité 1 et de Priorité 2 (niveau de conformité « Double A ») des Directives pour l'accessibilité aux contenus Web (version 1.0). Si, pour quelque motif que ce soit, la conformité aux points de contrôle requis n'est pas possible, une proposition de version de rechange du produit doit être présentée au RCIP pour approbation à sa discrétion exclusive.

7.0 Optimisation pour moteurs de recherche (OMR)

Élément <title>

1. Chaque page du produit doit inclure dans sa section <head> un élément <title> contenant un titre significatif et riche en mots-clés pour le contenu de cette page. Chaque page doit donc avoir un élément <title> unique à cette page.

Éléments <meta> « keywords » et « description »

2. Chaque page de produit doit inclure dans la section <head> un élément <meta> « keywords » contenant une liste de mots-clés et d'expressions-clés pour le contenu de cette page. Chaque page doit donc avoir un élément <meta> « keywords » unique à cette page. Il est facultatif de séparer les mots-clés et expressions-clés par des virgules.
   
   
3. Chaque page de produit doit inclure dans la section <head> un élément <meta> « description » contenant une description significative et riche en mots-clés du contenu de cette page. Chaque page doit donc avoir un élément <meta> « description » unique à cette page.

8.0 Métadonnées (Dublin Core)

Création du contenu des métadonnées

1. Le contenu des métadonnées décrivant l'ensemble du projet doit être préparé pour chaque page d'entrée du produit propre à chaque langue et comprendre les sept éléments de métadonnées suivants de l'ensemble d'Éléments de métadonnées du Dublin Core, Version 1.1 :
   
   
   • Titre
   • Créateur
   • Sujet
   • Description
   • Date
   • Identifiant
   • Langue (s'il y a lieu)

Mise en œuvre des métadonnées

2. Toutes les métadonnées du produit doivent être exprimées d'une manière uniformisée qui peut être lue, interrogée et échangée par les systèmes informatiques.
   
   Les métadonnées peuvent être exprimées en (X)HTML ou RDF/XML (Resource Description Framework/Extensible Markup Language). Les métadonnées simples, notamment les éléments Dublin Core non déterminés, peuvent être facilement exprimées en (X)HTML. Les métadonnées plus complexes, telles que les éléments Dublin Core déterminés, peuvent être exprimées en (X)HTML, mais avec des restrictions. RDF/XML a été utilisé plus fructueusement pour les métadonnées complexes, hautement structurées.
   
   Consultez les documents suivants pour aider à exprimer les métadonnées :
   
   
   • Expressing Dublin Core in HTML/XHTML meta and link elements
   • Expressing Simple Dublin Core in RDF/XML
   • Expressing Qualified Dublin Core in RDF/XML

9.0 Exigences techniques pour le contenu hébergé par le RCIP

Environnement du serveur Web du RCIP

1. Les produits devant être hébergés sur le serveur du RCIP doivent être élaborés conformément aux spécifications d'environnements suivantes et conçus à leur intention :
   
   Server
   
   • UNIX - Sun Solaris 2.8
   • Apache 1.3.28
   • Les pages HTML requièrent le suffixe « .html ».
   
   CGI et PERL
   
   • Les scripts CGI requièrent le suffixe « .cgi », et peuvent être situés n'importe où dans la structure de répertoires du projet.
   • PERL 5.8 est activée.
   • Les scripts PERL et CGI requièrent la notation « shebang » suivante :
     
     #!/usr/local/bin/perl
     use strict;
     
     
   • La plupart des modules standard de PERL sont disponibles, par exemple, CGI, DBI.
   
   PHP
   
   • PHP 4.0.4 est activée.
   • Les scripts PHP doivent utiliser le suffixe « .php ».
   • Les scripts PHP peuvent être situées n'importe où dans la structure de répertoires du projet.
   • L'accès PHP à MySQL est activé.
   • Le soutien PHP de XML est activé.
   • RCIP décidera de l'ajout de suffixes PHP, au cas par cas. Si vous êtes intéressés à utiliser un suffixe PHP particulier, renseignez-vous auprès du RCIP.
   
   Inclusions côté serveur (SSI)
   Toute page HTML ayant le suffixe « .html » et l'ensemble de bits d'exécution sera analysée pour SSI.
   
   Base de données
   
   • MySQL 4.1
   • L'accès au système de gestion de base de données (SGBD) MySQL est disponible sur demande.
   
   NOTE : Toute information qui est stockée dans une base de données et qui indique l'utilisation du produit doit avoir une valeur d'horodateur associée à des fins de dépistage et de vérification.