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

Annexe II - Exigences techniques pour le développement des Produits du Programme d’investissement pour les expositions virtuelles Musée virtuel du Canada (MVC) V1.0

Aussi disponible en format [PDF 240 Ko | À propos du logiciel PDF]

Haut de la page

Table des matières

Les exigences techniques pour le développement des expositions et jeux du Musée virtuel du Canada (MVC) fut renommé au Exigences techniques pour le développement des Produits du Programme d’investissement pour des expositions virtuelles du Musée virtuel du Canada V 1.0.

Les exigences techniques pour le développement des Produits du Programme d’investissement pour des expositions virtuelles ont été modifiées pour inclure quelques changements et deux nouvelles sections.

Les modifications inclus :

La taille maximale d’un fichier vidéo a été augmenteé à 25 Mo.
La section « Spécifications techniques du serveur et de la base de données » (7.0) a été mis au courant.
Une nouvelle section pour les Exigences techniques pour le développement des collections d'objets d'apprentissage (previously a peparate document) a été ajoutée. Voyez B. Collections d'objets d'apprentissage.
Une nouvelle section pour les Exigences techniques pour le développement des applications web mobile a été ajoutée. Voyez C. Application web mobile.

Haut de la page

Notes sur la terminologie

Les définitions et les termes suivants, utilisés dans le présent document, sont directement adaptés du RFC 2119 :

DOIT et DOIVENT : Ces mots indiquent une exigence absolue.

NE DOIT PAS et NE DOIVENT PAS : Ces expressions indiquent une interdiction 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 de procéder à la mise en œuvre de telles mesures.

NE DEVRAIT PAS et NE DEVRAIENT PAS : Ces expressions indiquent une mesure déconseillée, mais qui pourrait être permise dans certaines circonstances et dont l’ensemble des répercussions doivent être comprises avant de mettre en application ce genre de mesures.

Haut de la page

A. Expositions et jeux

1.0 Balisage, présentation et scripts

Technologies de base

Pour s'assurer que le contenu du produit soit accessible au plus grand nombre de visiteurs, quelle que soit la configuration technique de leur système ou dispositif :

XHTML 1.0 Strict

1.1 Le produit et toutes ses pages DOIVENT utiliser XHTML 1.0 Strict pour le balisage sémantique et structurel du contenu des pages Web. Les variantes Frameset et Transitional de XHTML 1.0 NE DOIVENT PAS être utilisées.
Nota : Il est important de comprendre les enjeux à servir des documents XHTML en tant que HTML (étiquetage MIME « text/html ») par opposition à XML (étiquetage MIME « application/xhtml+xml »). Pour plus de précisions sur ces enjeux, voir le document du W3C intitulé Les types de Media XHTML, ainsi que les tutoriaux du W3C intitulés Character sets & encodings in XHTML, HTML and CSS et Servir du XHTML 1.0. Les produits qui ne seront pas hébergés sur le serveur du RCIP PEUVENT servir les pages du produit comme « application/xhtml+xml » pour les agents utilisateurs compatibles. Cependant, le serveur du RCIP envoie tous les documents XHTML en tant que « text/html ».

1.2 Le produit et toutes ses pages XHTML, y compris le balisage généré ou modifié de façon dynamique par les scripts DOM côté client, DOIVENT se valider par rapport à la définition de type de document (DTD) publiée par le W3C pour XHTML 1.0 Strict.
Nota : Le site W3C offre un service de validation du codage, l'outil est disponible en anglais seulement, au http://validator.w3.org/.

Feuilles de style en cascade (CSS)

1.3 La présentation et le style (présentation visuelle et conception) DOIVENT s'appliquer à travers l'utilisation de Feuilles de style en cascade (CSS) valides.
Nota : Les CSS1, CSS 2.1 et CSS3, pour lesquelles le W3C accorde une validation, DEVRAIENT être utilisées. Il n'est pas obligatoire que chaque navigateur affiche la même présentation CSS de contenu du produit. Dans certains cas, il peut être préférable de n’envoyer aucune CSS à certains navigateurs (p. ex. IE 6, 7 et 8, Firefox 3.6 et 4.0, Chrome, Safari, Opera en plus d'autres fureteurs pour PC et les Macintosh).

Nota : Organiser les documents afin qu'ils puissent être lus sans les feuilles de style en cascade (CSS). Pour rencontrer cette exigence, toutes les pages du produit DOIVENT être visionné et évalué en utilisant un fureteur avec les styles désactivé pour s'assurer que les documents sont présentés d'ordre logique lorsque les CSS sont désactivée.

1.4 Les CSS DOIVENT être complètement séparées du contenu et de la structure des pages, et 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.
Nota : Les règles des CSS générées de façon dynamique par les scripts DOM côté client NE DEVRAIENT PAS être imbriquées. Plutôt, les noms de classes DEVRAIENT être dynamiquement ajoutés aux éléments pertinents des documents XHTML, invoquant ainsi les règles associées des CSS contenues dans une feuille de style externe.

Scripts côté client

1.5 Les scripts côté client DOIVENT respecter le DOM du W3C (scripts DOM) et être conformes à la norme ECMAScript, version 3 (ECMA-262).
Nota : La propriété innerHTML et l’objet XMLHttpRequest sont des exceptions à la règle susmentionnée et ils PEUVENT être utilisés.

1.6 Les scripts côté client DOIVENT être complètement séparés du contenu et de la structure des pages et référencés dans la section head d'une page, en tant que fichiers externes. Ils NE DOIVENT PAS imbriqués ou incorporés.
Nota : Les gestionnaires d'événements en ligne (p. ex. onclick, onfocus) dans la couche XHTML sont interdits. Les gestionnaires d'événements DOIVENT être écrits de façon dynamique dans le DOM à l'aide de techniques de scripts DOM valides et discrètes.
Nota : Dans le cas où un script de tiers ne puisse pas être facilement et discrètement mis en œuvre, l’autorisation d’utiliser des scripts ou des éléments script incorporés doit être sollicitée auprès du RCIP.

1.7 Les scripts côté client DOIVENT être mis à l’essai et exécutés en fonction du soutien de l’agent utilisateur pour les objets critiques du DOM mis en œuvre dans les scripts, contrairement à une mise à l’essai pour les chaînes de l’agent utilisateur ou autrement la « détection d’erreurs dans le navigateur ».

Encodage des caractères

1.8 Chaque page du produit DOIT utiliser et indiquer la norme UTF-8 comme encodage de caractères.
Nota : Pour une discussion des enjeux touchant l'encodage de caractères et le fait de servir des documents XHTML, voir le tutoriel du W3C intitulé Character sets & encodings in XHTML, HTML and CSS.

Protocole Secure Sockets Layer (SSL)

1.9 Le produit DOIT utiliser le protocole Secure Sockets Layer (SSL) lorsque l’utilisateur est tenu d’entrer un nom d’utilisateur et un mot de passe (p. ex., accès) ou tout renseignement personnel (y compris, mais sans s'y restreindre, le nom, l'adresse, l'adresse de courriel, le numéro de téléphone et le numéro de carte de crédit) pour être stocké par le produit et conservé afin d'être utilisé par l'établissement responsable du produit.
Nota : Il n’est pas nécessaire d'utiliser le protocole SSL lorsqu'on recueille de l'information sur un formulaire de commentaires par courriel ou qu'on demande le sobriquet d'un utilisateur seulement, par exemple, pour conserver un score élevé dans un jeu en ligne.

1.10 Tous les hyperliens vers des pages n'utilisant pas le protocole SSL DOIVENT utiliser des URL absolus.

Haut de la page

2.0 Accessibilité

Règles pour l’accessibilité des contenus Web (WCAG) du W3C – version 2.0

Pour s'assurer que le contenu du produit soit accessible au plus grand nombre de visiteurs, le produit DOIT se conformer aux critères de réussite de niveau A et AA des Règles pour l'accessibilité des contenus Web (WCAG) version 2.0.

Les règles pour l'accessibilité des contenus Web 2.0 sont basées sur quatre principes fondamentaux. Ceux-ci sont ; perceptible, utilisable, compréhensible et robuste.

Chaque principe a un nombre de règles dont chaque critère DOIT être rencontré. Plusieurs de ces règles ne sont souvent pas rencontrés. Votre attention est apportée à quelques règles en particulier mais, votre produit DOIT RENCONTRER TOUTES LES RÈLGES.

Pour des informations détaillés, veuillez consulter les règles pour l'accessibilité des contenus Web au : http://www.w3.org/Translations/WCAG20-fr/)

Principe 1 : Le produit doit être perceptible. (Règles 1.1 à 1.4)

2.1 Les équivalents textuels DOIVENT être déclarés pour tout contenu non textuel qui pourra alors être présenté sous autres formes selon les besoins de l'utilisateur : grands caractères, braille, synthèse vocale, symboles ou langage simplifié.
Nota : Les textes de remplacement DEVRAIENT être étoffés et descriptifs. Ils DOIVENT décrire le contenu de l’image et le rôle de cette dernière sur la page. Des détails suffisants DEVRAIENT être fournis afin que le texte de remplacement puisse servir d’équivalent textuel à l’image concernée. Le texte de remplacement DEVRAIT être d’une longueur raisonnable. Le RCIP recommande qu’il compte 125 caractères ou moins.

2.2 Des versions de replacement aux médias temporels DOIVENT être fournies.
Nota : Conformément aux critères de réussite 1.2.1, 1.2.2, et 1.2.3 de niveau A, les séquences uniquement vidéo DOIVENT avoir 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.

2.3 La présentation visuelle du texte et du texte sous forme d'image DOIVENT répondre aux exigences minimales pour le contraste de couleur selon l'algorithme de W3C. Plusieurs outils sont disponible pour faciliter cet effort tel que l'outil « Color Contrast Analyser » (en anglais seulement) disponible gratuitement au : http://www.wat-c.org/ et http://www.accessibleinfo.org.au/.

Principe 2 : Le produit doit être utilisable. (Règles 2.1 à 2.4)

2.4 Toutes les fonctionnalités du contenu DOIVENT être utilisables à l'aide d'une interface 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.

2.5 Toute interface utilisable au clavier DOIT comporter un mode de fonctionnement où le focus est visible.
Nota : Le fils d'Ariane est optionnel. Si votre produit inclut un fil d'Ariane :

toutes les niveaux de navigation DOIVENT être présenté dans le fil d'Ariane et DOIVENT être formé en hyperliens ;
chacun des liens DOIVENT être intelligibles individuellement, et;
les acronymes et les abréviations DOIVENT être soit définis ou balisées de l'élément HTML <abbr>.

2.6 Des méthodes DOIVENT être fournies pour aider les utilisateurs à naviguer, trouver le contenu et se situer dans le produit.
Nota : 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.

2.7 Le contenu textuel DOIT être lisible et compréhensible. Cette exigence est atteint en identifiant la langue de la page, en identifiant le texte d'une langue autre que déclaré pour la page, et en fournissant la définition de chaque acronyme et abréviation.
Nota : Éviter l'utilisation de texte d'une autre langue dans le texte de remplacement et dans l'élément <title>. Les attributs de langue NE PEUVENT PAS être déclarés dans d'autres attributs tels que les attributs de replacement « alt » et les attributs fournis dans l'élément <title>.

Principe 3: Le produit doit être compréhensible. (Règles 3.1 à 3.3)

2.8 Toutes les pages du produit DOIVENT apparaître et fonctionner de manière prévisible en fournissant une navigation qui est consistante et cohérente (les liens sont répété dans le même ordre) et ; les composants sont identifiés de la même façon.

Principe 4: Le produit doit être robuste. (Règle 4.1)

2.9 Le produit DOIT être compatible avec les agents utilisateurs actuels et futurs, y compris les technologies d'assistance.

Amélioration progressive

2.10 Compte tenu de l’approche sur l’amélioration progressive de la conception Web, le premier format de contenu rencontré par un utilisateur 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.
Nota : Par exemple, une chronologie des grands événements historiques peut être créée au moyen d’Adobe Flash et nécessite que le navigateur des utilisateurs soit pourvu au minimum de la version 8 de Flash Player. Dans une telle situation, l’information dans la chronologie ne serait probablement pas accessible aux personnes qui utilisent des technologies d’assistance telles qu’un lecteur d’écran, et elle ne le serait certainement pas à celles qui emploient un Mac avec le système MacOS 9.1, qui peut tout au plus exécuter la version 7 de Flash Player.

Il faut plutôt créer une version textuelle simple de la chronologie en langage HTML et l’inclure comme contenu par défaut sur la même page (X)HTML. Cela ferait en sorte que tous les utilisateurs pourraient accéder à la chronologie. 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 module d’extension Flash, le code (X)HTML de la page peut être modifié automatiquement 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 Flash de la chronologie 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 module d’extension requis.

2.11 La version principale du produit DOIT être accessible ; autrement dit, l'accessibilité du site NE DOIT PAS être accommodée en fournissant une version secondaire du site (p. ex. texte seulement). Seulement les composants exigeant un logiciel spécialisé ou le JavaScript PEUVENT être reproduits.

Indépendance des scripts

2.12 Le contenu et la fonctionnalité de base du produit DOIVENT être disponibles sans script côté client.
Nota : Les améliorations de présentation ou de comportement mises en œuvre uniquement par l’entremise des scripts côté client sont permises, mais le contenu et la fonctionnalité de base du produit DOIVENT demeurer disponibles, même si les scripts côté client sont désactivés ou non pris en charge.

Indépendance des feuilles de style en cascade (CSS)

2.13 Le contenu et la fonctionnalité de base du produit DOIVENT être disponibles sans feuille de style en cascade (CSS).

Les mesures suivantes DOIVENT être adoptées :

L'ordre de lecture DOIT être consistant avec la présentation réalisée avec les CSS. L'ordre de présentation du contenu affecte sa signification.
Toutes les tailles de polices 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.
Si un fond d’image est utilisé, on DOIT aussi déterminer une couleur de fond.

Haut de la page

3.0 Répertoires, fichiers et URL

Structure des fichiers et des répertoires

3.1 Les fichiers du produit comportant un important contenu commun pour toutes les versions linguistiques du produit (p. ex. documents XHTML, 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 ils NE DOIVENT PAS être dupliqués pour chaque version linguistique du produit.
Nota : Il n’est PAS permis de créer des structures française et anglaise séparées.

3.2 La navigation des répertoires DOIT être désactivée.

Noms de fichiers et de répertoires

3.3 Les noms de fichiers et de répertoires accessibles au public DOIVENT utiliser uniquement les caractères suivants :
- caractères alphabétiques en minuscules seulement (de a à z);
- caractères numériques (de 0 à 9).
Les caractères suivants sont des caractères réservés et ne DOIVENT être utilisé sauf pour :
- traits d'union (-) ; DOIT seulement être utilisés comme séparateur entre des mots, phrases ou abréviations bilingues équivalents et le code à trois (3) chiffres ISO-639-2 (p. ex. « fra » et « eng »&). Les traits d’union naturellement présents dans les mots ou les phrases DOIVENT être omis et l’espace résultante DOIT être supprimée (p. ex. « avant-garde » devient « avantgarde » ;
- traits de soulignement (_) ; les espaces naturellement présentes dans les phrases DOIVENT être remplacées par un trait de soulignement (_), p. ex. « nouveaux événements » devient « nouveaux_evenements ».
3.4 Les noms des répertoires dont le contenu est accessible au public DOIVENT comporter :
- un mot, une phrase ou une abréviation en français, suivi(e) d’un trait d’union et d’un mot, d’une phrase 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_aborigenes-native_stories/
- /ca-ns/
3.5 Les noms des fichiers dont le contenu est accessible au public DOIVENT comporter :
- un mot, une phrase ou une abréviation en français, suivi(e) d’un trait d’union et d’un mot, une phrase ou une abréviation équivalent(e) en anglais, suivi(e) d’un trait d’union et du code à trois (3) chiffres ISO-639-2 (p. ex. « fra » et « eng ») pour refléter la version linguistique du fichier; ou
- un mot ou une abréviation unique qui est identique dans les deux (2) langues officielles, suivi d’un trait d’union et du code à trois (3) chiffres ISO-639-2 (p. ex. « fra » et « eng ») pour refléter la version linguistique du fichier.
  Exemples :
  - index-fra.html
  - index-eng.html
  - entete-header-fra.swf
  - 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
3.6 Les noms des fichiers dont le contenu accessible au public est identique dans les versions française et anglaise du produit (p. ex. certaines images et certains fichiers médiatiques, fichiers JS et CSS) DOIVENT comporter :
- un mot, une phrase ou une abréviation en français suivi(e) d’un trait d’union et d’un mot, d’une phrase ou d’une abréviation équivalent(e) en anglais ;
- un mot ou une abréviation unique qui est identique dans les deux (2) langues officielles ; ou
- une chaîne numérique ou alphanumérique neutre pour les deux (2) langues officielles.
  Nota : Aucun code de langue à trois (3) lettres (p. ex. « fra » et « eng ») n’est requis pour les fichiers dont le contenu est identique dans les deux (2) langues officielles. Les fichiers de soutien 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.swf
3.7 Tous les fichiers XHTML statiques du produit DOIVENT utiliser le suffixe « .html » et ils NE DOIVENT PAS utiliser le suffixe « .htm ».

URLs

URL de pages d'accueil

3.9 Les URL pour les pages d'accueil unilingues et la page introductive de la sélection linguistique du produit (voir les paragraphes 4.14 et 4.15) NE DOIVENT INCLURE AUCUN paramètre d’URL (chaîne d’interrogation paire nom-valeur).
Nota : Le nom du fichier de la page d’accueil DOIT être nommé index.*, ou defaut.*, par exemple, index.html, index.php, defaut.html, defaut.php.

Haut de la page

URLs relatives

Toute URL pour les pages et les ressources du produit DOIVENT être relatives (c.-à-d. non absolues), sauf pour les URL présentées dans les hyperliens reliant des pages utilisant le protocole SSL vers des pages n'utilisant pas le protocole SSL (voir le paragraphe 1.9).

Haut de la page

4.0 Navigation, disposition et conception

Page de choix de langue

4.1 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.

4.2 La page de garde DOIT comprendre les informations suivantes, dans les deux langues officielles :
- Le logo du MVC ;
- Le titre de l’exposition (qui DOIT être fourni en langage HTML) ;
- Un hyperlien vers la page d’accueil unilingue, dans chaque langue disponible du produit ;
- L’avis de droit d’auteur ;
- Un lien vers le générique.
Nota : Tous les textes et liens dans la langue autre que celle indiquée dans l’élément <html> DOIVENT être identifiés comme étant dans une autre langue en précisant les attributs lang et xml:lang, y compris les logos.

Droit d’auteur

4.3 Le produit DOIT comporter, sous forme de page Web distincte pour chaque version linguistique, une page « Droit d’auteur » qui présente un énoncé de droit d’auteur intégral qui identifie tous les détenteurs de droits d’auteur.

4.4 Le symbole de copyright, ©, le détenteur du droit d'auteur et l'année au cours de laquelle le produit a été lancé et la terminologie « Tous droits réservés » DOIVENT apparaître sur chaque page du produit et mener à l'énoncé de droit d'auteur intégral (voir le paragraphe 4.3 ci-dessus), par exemple :
Exemples : © Musée d’histoire 2005. Tous droits réservés.

Nota : Si l'établissement qui détient le droit d'auteur est officiellement bilingue, utilisez 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, utilisez le même nom unilingue dans chaque version linguistique.

Remerciements

4.5 Le produit DOIT avoir une page de « Remerciements », pour laquelle il y a un hyperlien, tant à partir de la page introductive de la sélection linguistique et à chaque page d'accueil unilingue.

4.6 La page des « Remerciements » DOIT reconnaître la participation financière du gouvernement du Canada comme ci-dessous :
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 réalisation de cette exposition en ligne pour le Musée virtuel du Canada..

4.7 La page des « Remerciements » DOIT nommer tous les partenaires institutionnels participant au produit et y mener par des hyperliens, s’ils sont disponibles.

Mécanisme de rétroaction

4.8 Chaque page du produit DOIT inclure un hyperlien donnant accès à un simple formulaire en XHTML où le public peut indiquer ses messages de rétroaction. Ce formulaire DOIT être configuré pour permettre également l'envoi d'un courriel à l'établissement responsable du produit et une copie conforme au RCIP (à vmccc@virtualmuseum.ca, pour la version anglaise, ou à mvccc@museevirtuel.ca, pour la version française), accompagné d'une identification nette du nom du produit sur la ligne de l'objet.
Nota : Si le produit est hébergé sur les serveurs du RCIP, le RCIP fournira, sur demande, une URL personnalisée pour le formulaire de rétroaction du MVC, à utiliser dans le cadre du mécanisme de rétroaction du produit.

Le mécanisme de rétroaction DOIT être organisé dans un ordre logique. Le formulaire DOIT inclure les éléments suivants :
- Un champ pour le courriel, une zone texte pour les commentaires et un bouton d’envoi suivi d’un bouton d’annulation.
- Les étiquettes DOIVENT être associées à leurs commandes et les groupes logiques d’éléments de forme DOIVENT être compris dans le <fieldset> avec une <legend> pour chaque groupe.
4.9 Pour les produits hébergés sur les serveurs du RCIP, le mécanisme de rétroaction du produit DOIT être relié à l’interface API anti-pollupostage du RCIP avant la transmission de tout message de rétroaction pour confirmer que ce dernier n’est pas un pourriel ou qu’il ne provient pas d’une source douteuse.
Nota : Le RCIP fournira la documentation relative à son interface API anti-pollupostage aux candidats retenus. Si le produit utilise le formulaire de rétroaction du MVC, la fonctionnalité de l’interface API anti-pollupostage du RCIP y est implicitement incluse. Si le produit n’est pas hébergé sur le serveur du RCIP, il NE DOIT PAS se brancher à l’API anti- pollupostage du RCIP.
4.10 Les utilisateurs DOIVENT être avisés que leurs messages de rétroaction sont également transmis au RCIP, et doivent avoir accès à un hyperlien vers la 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 VMC 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 MVC sur la protection des renseignements personnels pour de plus amples renseignements.

URL de la Politique de protection des renseignements personnels du MVC – en anglais :
http://www.museevirtuel-virtualmuseum.ca/avis_importants-important_notices-eng.jsp#pp

URL de la Politique de protection des renseignements personnels du MVC – en français :
http://www.museevirtuel-virtualmuseum.ca/avis_importants-important_notices-fra.jsp#pp
4.11 Les utilisateurs DOIVENT être avisés des problèmes de confidentialité associés à l'envoi de messages de rétroaction par courriel en recevant l'avis suivant :
Anglais :
The Internet is a public forum and electronic information can be intercepted. For reasons of security and privacy, we ask that you not send us any personal or confidential information, such as your Social Insurance Number (SIN), home or business address.

Français :
L'Internet est un forum public et l'information électronique peut être interceptée. Pour des raisons de sécurité et de respect de la vie privée, nous vous demandons de ne pas nous faire parvenir de renseignements personnels ou confidentiels, tels votre numéro d'assurance sociale, l'adresse de votre domicile ou de votre bureau.

Carte du site

4.12 Le produit DOIT comprendre, sous forme de page Web distincte pour chaque version linguistique du produit, un plan du site (p. ex., une hiérarchie organisée par liste d’hyperliens à 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.
Nota : Pour rehausser 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 dans le produit.
4.13 Chaque page du produit DOIT inclure un hyperlien textuel vers le plan du site dans la langue appropriée, afin que les utilisateurs humains et les moteurs de recherche puissent trouver chaque page du produit.

Navigation

Navigation dans la version linguistique

4.14 Le produit DOIT comporter une page d’accueil unilingue pour chaque version linguistique du produit.
4.15 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.

Navigation dans la page d’accueil

4.16 Chaque page du produit DOIT comprendre un hyperlien vers la page d'accueil unilingue, dans la langue pertinente.

Fenêtres secondaires/flash

4.17 Le produit NE DOIT PAS ouvrir de liens dans de nouvelles fenêtres ou de nouveaux onglets, sauf dans les situations suivantes :
- L’ouverture d’une page contenant de l’information de contexte délicat (p. ex. instructions d’aide) ou un moyen de rechange pour remplir un champ de 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).
- 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.

Nota : L’utilisateur DOIT être averti, si un lien ouvre une nouvelle fenêtre ou un nouvel onglet.

Titre du produit

4.18 Chaque page du produit DOIT inclure le titre principal du produit sous forme de texte en XHTML, afin d'identifier le contenu de la page comme faisant partie du produit.
Nota : Les fichiers ou les images Flash PEUVENT être utilisés pour remplacer la version textuelle en format XHTML du titre principal du produit, mais ils NE DOIVENT PAS empêcher les technologies d’assistance d’accéder au texte remplacé.

Logo du MVC

4.19 Le logo du MVC DOIT figurer dans le coin supérieur droit de chaque page du produit et sans aucune bordure d'image.
Nota : Le RCIP 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.

4.20 Le logo du MVC DOIT être installé à l’aide du code XHTML suivant pour charger le logo et y établir un hyperlien :
Anglais
<a href="http://www.museevirtuel-virtualmuseum.ca/index-eng.jsp"><img src="path/to/English/image" alt="Virtual Museum of Canada" /></a>

Français
<a href="http://www.museevirtuel-virtualmuseum.ca/index-fra.jsp"><img src="path/to/French/image" alt="Musée virtuel du Canada" /></a>

Nota : Remplacez 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.

4.21 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 RCIP.

Élément title

4.22 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.
Nota : En tant qu’élément de page le plus important d’une perspective d’optimisation de moteur de recherche (OMR), le contenu de l’élément title DOIT être rédigé du plus spécifique au moins spécifique, le titre unique de page apparaissant en premier et le titre principal du produit en dernier (p. ex. « À propos le docteur Neville | Docteurs du nord »).

Bannières, en-têtes et bas de page

4.23 Le produit NE DOIT PAS utiliser d'outils de navigation de sites Web corporatifs ou institutionnels, notamment les bannières, les en-têtes ou les bas de page, sans l'approbation expresse du RCIP.

Haut de la page

5.0 Types et formats de contenu

Modules d’extension et logiciels spécialisés

Si un contenu du produit nécessite un module d'extension ou un logiciel spécialisé pour pouvoir s'afficher :

5.1 Le module ou le logiciel spécialisé pour présenter le contenu DOIT être librement accessible et pouvoir être installé sur n'importe quelle plateforme (p. ex. Windows, Mac et Linux).
Nota : Lorsqu’un module d’extension n’est pas disponible pour une plateforme donnée, un module d’extension/logiciel spécialisé compatible tel que VLC DOIT être présenté (p. ex., VLC est un cadre d’applications multimédia à code source libre qui lit la plupart des formats sur toute plateforme et qui peut servir de solution de remplacement).

Nota : Le service de diffusion de fichiers audio du RCIP, est disponible uniquement aux produits qui sont hébergés sur les serveurs du RCIP. Si le produit n'est pas hébergé sur les serveurs du RCIP, il ne peut pas faire usage du service de diffusion de fichiers audio du RCIP.

5.2 Tous les hyperliens vers contenu nécessitant un module d'extension ou un logiciel spécialisé DOIT être accompagné d’une indication textuelle du type de fichier et de la taille du fichier (Par example : Un document en format PDF [PDF 188 Ko]).

5.3 Un hyperlien vers la source du module d'extension ou du logiciel spécialisé pertinent DOIT être fourni sur chaque page qui a besoin de ce module ou de ce logiciel pour donner accès au contenu.

Texte

5.4 Tout le contenu textuel DOIT être présenté principalement en tant que texte dans la variante XHTML 1.0 Strict.
Nota : Bien que tout contenu textuel DOIT être affiché en format XHTML, pareil contenu PEUT également être élaboré dans un format breveté pour visualisation ou impression au moyen d'un module d’extension 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.

Images fixes

5.5 Tous les graphiques composés d'images fixes DOIVENT être optimisés et améliorés pour le Web afin de réduire la taille des fichiers et la durée du téléchargement :
- Les graphiques vectoriels DOIVENT utiliser les formats GIF ou PNG.
- Les photographies, la haute résolution et les images en demi-teintes DOIVENT utiliser le format JPEG (à 24 bits).
Nota : Des exemptions à ce critère PEUVENT être accordées par le RCIP dans certains cas où l'utilisation de solutions brevetées est nécessaire pour atteindre les objectifs du projet.

5.6 Tout hyperlien vers des gros fichiers d'images de taille supérieure à 500 Ko DOIT être accompagné d’une indication textuelle précisant la taille des fichiers afin d'alerter les utilisateurs.

5.7 Les pages du produit NE DOIVENT PAS initier le téléchargement de fichiers d’images pleine taille, sauf si l’utilisateur le demande expressément.
Nota : Cette exigence vise à limiter la création de pages comportant des vignettes et d’autres versions pleines tailles associées qui sont camouflées par les feuilles CSS jusqu’à ce que l’utilisateur mette au point la vignette. Ces pages sont habituellement de très grande taille et elles exigent une plus grande largeur de bande, ce qui oblige l’utilisateur à télécharger du contenu pour lequel il n’a pas nécessairement exprimé d’intérêt.

Vidéos/animation/images mobiles

5.8 La taille d’un fichier vidéo NE DOIT PAS excéder 25 Mo.

5.9 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 DEVRAIT également être préparée et fournie aux utilisateurs.
Nota : Certains systèmes de diffusion en continu permettent aux réalisateurs de préparer un fichier vidéo unique qui peut être lu aux diverses vitesses de diffusion qui correspondent aux différentes vitesses d'accès à Internet. Lorsque ces systèmes sont utilisés, une version unique d'un fichier vidéo suffit.

Le service de diffusion de fichiers vidéo du RCIP, est disponible uniquement aux produits qui sont hébergés sur le serveur du RCIP. Si le produit n'est pas hébergé sur le serveur du RCIP, il ne peut pas faire usage du service de diffusion de fichiers vidéo du RCIP.

Le RCIP retient régulièrement à contrat les services de diffusion de médias en continu. Si le produit doit utiliser de la vidéo, il lui est possible d'utiliser ce service. Pour obtenir de plus amples renseignements, veuillez communiquer avec le RCIP.

5.10 Les séquences uniquement vidéo DOIVENT avoir 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. La transcription DEVRAIT comprendre une ou plusieurs images fixes représentant le contenu visuel de la séquence vidéo.
Le produit DOIT se conformer aux critères de réussite de niveau A et AA de la version 2.0 des Règles pour l’accessibilité aux contenus Web (WCAG), sauf pour les critères de réussite 1.2.4 (sous-titres pour les médias en direct) et 1.2.5 (exigence de descriptions audio).

5.11 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 rejouer la vidéo.

5.12 Les fichiers de diffusion vidéo non séquentielle qui sont chargés dans un lecteur intégré à un navigateur PEUVENT ê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.

5.13 Tout hyperlien vers de gros fichiers vidéo transmis en continu DOIT être accompagné d'une étiquette indiquant la durée du fichier en continu.

5.14 Un avis DOIT être présenté aux visiteurs dont le système ne gère pas le module d’extension requis, par exemple, Flash, et/ou ne gère pas JavaScript. L’avis doit fournir un lien vers la page de téléchargement du module d’extension et de la transcription.

5.15 Lorsqu'un codec est utilisé pour comprimer le contenu de fichiers vidéo, il DOIT être inclus dans une plateforme ou un progiciel standard ou être librement accessible aux utilisateurs qui ont besoin de le télécharger et de l'installer. En plus, un hyperlien vers le codec DOIT être fourni aux utilisateurs.

Fichiers audio/sonores

5.16 La taille d’un fichier audio NE DOIT PAS excéder 25 Mo.

5.17 Si un fichier audio est préparé pour être exécuté dans un environnement à large bande passante, une autre version à bande passante réduite DEVRAIT également être préparée et fournie aux utilisateurs.
Nota : Certains systèmes de diffusion en continu permettent aux réalisateurs de préparer un fichier audio unique qui peut être lu aux diverses vitesses de diffusion qui correspondent aux différentes vitesses d'accès à Internet. Lorsque ces systèmes sont utilisés, une version unique d'un fichier audio suffit.

Le RCIP retient régulièrement à contrat les services de diffusion de médias en continu. Si le produit est hébergé sur les serveurs du RCIP et que le produit doit utiliser de l’audio, il lui est possible d'utiliser ce service. Pour obtenir de plus amples renseignements, veuillez communiquer avec le RCIP.

5.18 Les fichiers audio diffusés en continu, 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 de lancement et d'arrêt de l'audio.

5.19 Les séquences sonores DOIVENT avoir une transcription textuelle des informations important ainsi que tous les mots parlés. Les séquences sonores qui n'ont pas de mots parlés DOIVENT offrir un sommaire du contenu.
Nota : Conformément aux critères de réussite 1.2.1, 1.2.2, et 1.2.3 de niveau A, les séquences uniquement sonores DOIVENT avoir une transcription textuelle.

5.20 Les fichiers de diffusion vidéo non séquentielle qui sont chargés dans un lecteur intégré à un 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.

5.21 Tous les hyperliens vers des fichiers audio transmis en continu DOIVENT être accompagnés d'une étiquette indiquant la durée du fichier transmis en continu.

5.22 Un avis DOIT être présenté aux visiteurs dont le système ne gère pas le module d’extension requis, par exemple, Flash, et/ou ne gère pas JavaScript. L’avis doit fournir un lien vers la page de téléchargement du module d’extension et de la transcription.

5.23 Lorsqu'un codec est utilisé pour comprimer le contenu de fichiers audio, il DOIT être inclus dans une plateforme ou un progiciel standard ou être librement accessible aux utilisateurs qui ont besoin de le télécharger et de l'installer. En plus, un hyperlien vers le codec DOIT être fourni aux utilisateurs.

Haut de la page

6.0 Cybermétrie et métadonnées

Cybermétrie

6.1 Chaque page et composante Flash (s’il y a lieu) du produit DOIT comprendre un code additionnel permettant la collecte de statistiques sur les visiteurs pour ce qui est du produit.
Nota : Le RCIP 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.

Élément métadonnées

Nota : Les pages bilingues répètent l’attribut méta dans la deuxième langue, à moins d’indications contraires ci-dessous.

Attribut méta `« description »`

6.2 Chaque page d'accueil unilingue DOIT inclure dans la section head un attribut méta « description » contenant une description significative et riche en mots-clés comportant au maximum 150 caractères et qui décrit globalement le contenu du produit.
Nota : Si d’autres pages du produit comprennent un élément méta « description », ce dernier DOIT être spécifique et unique pour le contenu de la page.

Attribut méta `« title »`

6.3 Chaque page du produit DOIT inclure dans sa section head un élément title contenant le titre de la page ainsi que le titre du produit, p. ex., "À propos du docteur Neville | Les médecins du nord."

Attribut méta `« keywords »`

6.4 Les pages du produit DOIVENT inclure dans la section head un attribut méta « keywords » contenant une liste de mots clés et phrases clés qui DOIVENT être spécifiques et uniques pour le contenu de la page. Trois mots clés / expressions-clés est suffisant.
Nota : L’attribut « keywords » NE DOIT PAS être répété dans les pages bilingues. On DOIT utiliser un seul élément et inscrire les mots clés français et anglais en les séparant avec des points-virgules.

Éléments des métadonnées DC

6.5 Les éléments de métadonnées Title, Creator, Subject, Issued, Modified, et Language de l’Ensemble d’éléments de métadonnées du Dublin Core, version 1.1 DOIVENT être inclus dans chacune des pages suivantes :
- les pages d'accueil unilingues du produit ;
- la page principale de chaque section majeure du produit ;
- les pages qui mettent en vedette des ressources de contexte et sens suffisant et qui méritent d’être énumérées dans un moteur de recherche.
Nota : Le contenu des métadonnées DC pour les pages ou ressources anglaises DOIT être en anglais et le contenu des métadonnées pour les pages françaises DOIT être en français.

Haut de la page

7.0 Spécifications techniques du serveur et de la base de données

Nota : Les produits qui ne seront pas hébergé sur le serveur du RCIP DEVRAIT être élaborés en conformité avec le cahier des charges pour l'environnement serveur du RCIP comme le produit pourrait, éventuellement, être hébergé sur le serveur du RCIP.

Environnement du serveur du RCIP

7.1 Les produits qui seront hébergé sur le serveur du RCIP DOIVENT être élaboré pour et en conformité avec les spécifications d'environnement suivantes :

Serveur

Linux — RHEL 5.5
Apache 2.2.14
Les pages statiques XHTML DOIVENT utiliser l'extension « .html ».

CGI et PERL

Les scripts CGI DOIVENT utiliser le suffixe « .cgi » et PEUVENT être situés n'importe où dans la structure de répertoires du projet.
PERL 5.14 est activée.
La plupart des modules standard de PERL sont disponibles, par exemple, CGI, DBI.
Les scripts PERL et CGI DOIVENT commencer par la notation « shebang » suivante :
#!/usr/local/bin/perl use strict;

PHP

PHP 5.2.9 est activée.
Les scripts PHP DOIVENT utiliser le suffixe « .php ».
Les scripts PHP PEUVENT être situés n'importe où dans la structure de répertoires du projet.
La ligne register_globals est réglée à « OFF » (désactivée).
L'accès PHP à MySQL est activé.
Le soutien PHP de XML est activé.
Le RCIP décidera de l'ajout d’extension PHP, au cas par cas. Si vous souhaitez utiliser une extension PHP particulière, renseignez-vous auprès du RCIP.

Inclusions côté serveur (SSI)

Toute page XHTML ayant le suffixe « .html » et le bit d'exécution activé sera analysée pour SSI.

Base de données

MySQL 5.77
Si le produit doit être hébergé sur le serveur du RCIP, un fichier SQL étant MySQL-compliant DOIT être envoyé au RCIP pour faire créer la structure de la base de données ou pour faire charger les données d'un tableau.

Validation des scripts

7.2 Si le produit doit être hébergé sur le serveur du RCIP, les scripts PHP et PERL DOIVENT respecter les règles de validation suivantes :
- Tous les paramètres intégrés aux scripts DOIVENT être validés avant d'être utilisés.
- Toutes les variables locales DOIVENT être explicitement initialisées avant d'être utilisées.
- Les paramètres qui peuvent contenir seulement des valeurs provenant des ensembles contraints DOIVENT être validés pour garantir que leurs valeurs se situent dans ces ensembles contraints.
- Les paramètres DOIVENT être validés pour garantir que leurs valeurs sont du type prévu. Par exemple, si un paramètre doit contenir seulement des chiffres, la valeur intégrée DOIT être validée en tant que chaîne numérique.
- Les paramètres utilisés comme critères pour les énoncés SQL générés de façon dynamique NE DOIVENT CONTENIR AUCUNE apostrophe non échappée.
- Les fichiers inclus/requis DOIVENT être validés pour garantir que leurs chemins d'accès existent sur le serveur hôte.
- Les fichiers inclus/requis DOIVENT être validés pour garantir qu'ils sont bel et bien des fichiers.
- Les fichiers inclus/requis DOIVENT être validés pour garantir qu'ils sont bel et bien des fichiers.
- Toutes les requêtes SQL construit en utilisant les données de requêtes HTTP (cookies, GET / PUT / POST) DOIVENT être échappés.
- Les scripts NE DOIVENT PAS écrire au système de fichiers.
Nota : Voir « CGI et PERL » et « PHP » au paragraphe 7.1 pour obtenir les dernières versions de PERL et de PHP utilisées sur le serveur du RCIP.

Conception des bases de données

Chaînes de connexion

7.3 Pour tout produit qui emploie une base de données et qui doit être hébergé sur le serveur du RCIP, toutes les connexions DOIVENT être faites en utilisant la méthode de connexion aux bases de données du RCIP. Veuillez communiquer avec le RCIP avant d'entreprendre le développement afin d'obtenir la documentation concernant les bases de données.
Pour tout produit qui emploie une base de données et qui doit être hébergé sur le serveur du RCIP, toutes les chaînes de connexion à une base de données DOIVENT être extraites du produit et placées une fois seulement dans un fichier à l’extérieur du répertoire racine du produit auquel le serveur Web n'a pas accès.

SGBD

7.4 Pour tout produit qui emploie une base de données et qui doit être hébergé sur le serveur du RCIP, la base de données DOIT utiliser le système SGBD du serveur de la base de données MySQL.
Nota : Voir « Base de données » au paragraphe 7.1 pour obtenir la dernière version de MySQL utilisée par le serveur du RCIP.

Normalisation

7.5 Pour tout produit qui emploie une base de données et qui doit être hébergé sur le serveur du RCIP, les modèles de données logiques DOIVENT être en troisième forme normale (3FN), ce qui veut dire que tous les attributs d'un tableau relationnel particulier DOIVENT dépendre fonctionnellement de la clé principale.
Nota : Dans le modèle de données logiques, une clé candidate formée d'attributs réels DEVRAIT servir de clé principale. Une auto-incrémentation, ou une autre forme de clé artificielle, PEUT être utilisée dans le modèle de données physiques. Les tableaux PEUVENT être dé-normalisés en modèles de données physiques pour des raisons de rendement, mais ces exceptions DOIVENT être justifiées par des preuves quantitatives (p. ex. Dans quelle mesure la structure dé-normalisée est-elle plus rapide ?).

Normes de dénomination

7.6 Pour tout produit qui emploie une base de données qui doit être hébergé sur le serveur du RCIP, les normes de dénomination de base de données suivantes DOIVENT être observées :
- Les bases de données DOIVENT avoir un nom descriptif et une abréviation courte (maximum de 5 caractères).
- Les tableaux DOIVENT avoir un nom descriptif préfixé avec l'abréviation de leur base de données et une abréviation courte (maximum de 5 caractères).
- Les champs DOIVENT avoir un nom descriptif préfixé avec l'abréviation de leur tableau.
- Les vues DOIVENT avoir un nom descriptif préfixé avec l'abréviation de leur base de données.
- Les noms des index DOIVENT commencer par un « U » pour index uniques, ou un « S » pour index non uniques, suivis par l'abréviation du tableau et ensuite, le nom de chaque champ participant à l'index.
- Les noms des déclencheurs DOIVENT commencer par un « T », suivi d’un « B »(avant) ou d’un « A » (après) pour indiquer le temps, puis d’un « D » (supprimer), d’un « I » (insérer) ou d’un« U »(mettre à jour) pour indiquer l’événement de déclenchement, et enfin du nom du tableau.

Dictionnaire de données

7.7 Pour tout produit qui emploie une base de données et qui doit être hébergé sur le serveur du RCIP, tous les éléments de la base de données (base de données, tableau, champ, index, vue, déclencheur, etc.) DOIVENT avoir un nom, un titre et une description. Les champs DOIVENT également contenir de l'information sur le type de données et leur valeur implicite.

Nota : La description des vues DEVRAIT inclure la définition de la vue et la description des déclencheurs DEVRAIT contenir le code source annoté.

7.8 Pour tout produit qui emploie une base de données et qui doit être hébergé sur le serveur du RCIP, toute information qui est placé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 suivi et de vérification.

Haut de la page

B. Collections d'objets d'apprentissage

NOTA : La liste qui suit donne la limite maximale de caractères, les formats média et les tailles exigées du contenu à des fins d'utilisation avec l'Outil de saisie des objets d'apprentissage. Tout champ qui ne figure pas dans la présente liste ne possède aucune limite.

Profil institutionnel

Nom de champ	Format	Taille maximale
Logo de l'institution	taille du fichier taille de l'image format du fichier	80Ko 200L x 90H pixels GIF ou JPEG(24-bit)

Haut de la page

Collection d'objets d'apprentissage

Nom de champ	Format	Taille maximale
Nom de la collection	case textuelle	200 caractères
Description	case textuelle	200 caractères
Introduction	case textuelle	1250 caractères

Haut de la page

Image Accueil

Nom de champ	Format	Taille maximale
Titre	case textuelle	200 caractères
Image Accueil	taille du fichier taille de l'image format du fichier	400 Ko 450L x 300H pixels GIF ou JPEG(24-bit)
Description abrégée (texte alt.)	case textuelle	125 caractères
Légende	case textuelle	500 caractères
Créateur	case textuelle	100 caractères
Emplacement(s) pertinent(s)	case textuelle	Voyez les NOTES (1) et (2)

Haut de la page

Objet d'apprentissage

Nom de champ	Format	Taille maximale
Titre	case textuelle	200 caractères
Description	case textuelle	200 caractères
Objectif d'apprentissage	case textuelle	1250 caractères
Emplacement(s) pertinent(s)	case textuelle	Voyez les NOTES (1) et (2)

Haut de la page

Texte

Nom de champ	Format	Taille maximale
Titre	case textuelle	200 caractères
Texte	case textuelle	Voyez les NOTES (3)
Notes en bas de page	case textuelle	Voyez les NOTES (3)
Créateur	case textuelle	100 caractères
Description	case textuelle	200 caractères
Emplacement(s) pertinent(s)	case textuelle	Voyez les NOTES (1) et (2)

Haut de la page

Audio

Nom de champ	Format	Taille maximale
Titre	case textuelle	200 caractères
Texte	case textuelle	Voyez NOTES (3)
Fichier audio	taille du fichier format du fichier	2Mo .wma (Windows Media Audio)
Légende	case textuelle	500 caractères
Créateur	case textuelle	100 caractères
Description abrégée (texte alt.)	case textuelle	125 caractères
Emplacement(s) pertinent(s)	case textuelle	Voyez les NOTES (1) et (2)

Haut de la page

Vidéo

Nom de champ	Format	Taille maximale
Titre	case textuelle	200 caractères
Fichier WMV vidéo	taille du fichier taille du vidéo format du fichier	2Mo 320L x 240H pixels .wmv (Windows Media Video)
Fichier MOV vidéo	taille du fichier taille du vidéo format du fichier	2Mo 320L x 240H pixels .mov (QuickTime Player)
Vignette (image)	taille du fichier taille de l'image format du fichier	80Ko 225L x 225H pixels GIF ou JPEG(24-bit)
Légende	case textuelle	500 caractères
Créateur	case textuelle	100 caractères
Description abrégée (texte alt.)	case textuelle	125 caractères
Emplacement(s) pertinent(s)	case textuelle	Voyez les NOTES (1) et (2)

Haut de la page

Image

Nom de champ	Format	Taille maximale
Titre	case textuelle	200 caractères
Fichier image	taille du fichier taille de l'image format du fichier	400Ko 450L x 300H pixels GIF ou JPEG(24-bit)
Vignette (image)	taille du fichier taille de l'image format du fichier	80Ko 225L x 225H pixels GIF ou JPEG(24-bit)
Description abrégée (texte alt.)	case textuelle	125 caractères
Légende	case textuelle	500 caractères
Créateur	case textuelle	100 caractères
Emplacement(s) pertinent(s)	case textuelle	Voyez les NOTES (1) et (2)

Haut de la page

Flash

Nom de champ	Format	Taille maximale
Titre	case textuelle	200 caractères

Text	case textuelle	Voyez NOTES (3)
Fichier Flash	taille du fichier taille flash format du fichier	2Mo 680L x 410H pixels .swf (Shockwave Flash)
Vignette (image)	taille du fichier taille de l'image format du fichier	80Ko 225L x 225H pixels GIF ou JPEG(24-bit)
Légende	case textuelle	500 caractères
Créateur	case textuelle	100 caractères
Description abrégée (texte alt.)	case textuelle	125 caractères
Emplacement(s) pertinent(s)	case textuelle	Voyez les NOTES (1) et (2)

Haut de la page

NOTES :

(1) Les emplacements canadiens doivent respecter la liste des noms officiels de RNCAN. Pour consulter la liste des noms officiels, cliquez sur le lien Noms géographiques de RNCAN à partir de la page « Ajout d'emplacements pertinent » qui apparaît lorsque vous sélectionnez « CANADA » dans la liste déroulante « Pays ».

(2) Les emplacements internationaux doivent se conformer à la norme internationale du « Répertoire Getty des appellations géographiques » (TGN). Vous pouvez accéder au TGN à partir de ce lien : http://www.getty.edu/research/conducting_research/vocabularies/tgn/.

(3) Seuls les 1 000 premiers caractères ne seront affichés lorsque vous prévisualisez du texte à partir de sa page d'objet d'apprentissage.

Haut de la page

C. Applications Web Mobile

Toutes les applications web mobile DOIVENT adopter les recommandations Mobile Web Best Practice 1.0 (MWBP 1.0) du W3C.