Lisez-moi S.V.P. 

W3C

Pratiques exemplaires du Web mobile 1.0

Guide de base

Recommandation du W3C du 29 juillet 2008

Cette version :
http://www.w3.org/TR/2008/REC-mobile-bp-20080729/
Dernière version :
http://www.w3.org/TR/mobile-bp/
Version précédente :
http://www.w3.org/TR/2006/PR-mobile-bp-20061102/
Rédacteurs :
Jo Rabin, mTLD Mobile Top Level Domain (dotMobi)
Charles McCathieNevile, Opera Software [pour les versions préliminaires]

Veuillez consulter l'errata de ce document, lequel peut contenir des corrections normatives.

Cf. également d'éventuelles traductions.


Résumé

Ce document spécifie les pratiques exemplaires (best practices) pour la livraison de contenu web aux appareils mobiles. L'objectif principal est d'améliorer l'expérience d'utilisation du Web en accès depuis de tels appareils.

Les recommandations concernent le contenu livré et non les processus par lesquels il est créé, ni les appareils ou les agents utilisateurs auxquels il est livré.

Le document s'adresse principalement aux créateurs, maintenants et opérateurs de sites web. Les lecteurs sont censés être au fait de la création de sites web et avoir une connaissance générale des technologies impliquées, telles que les serveurs web et HTTP. Les lecteurs n'ont pas besoin d'avoir une formation aux technologies spécifiques des appareils mobiles.

Statut de ce document

Cette section décrit le statut de ce document au moment de sa publication. D'autres documents peuvent venir le remplacer. On peut trouver une liste des publications actuelles du W3C et la dernière version de ce rapport technique dans l'index des rapports techniques du W3C à http://www.w3.org/TR/.

Ce document a été développé par le groupe de travail Best Practices (BPWG) sous l'égide de l'initiative Mobile Web.

Veuillez consulter le rapport de mise en œuvre du groupe de travail. Les modifications survenues depuis la version précédente du document sont d'ordre rédactionnel. Une liste complète des modifications apportées au document est disponible. Notez que le document est resté au stade de recommandation proposée durant plus d'un an car il dépendait de l'avancement de XHTML Basic 1.1 sur le chemin de la recommandation.

Veuillez envoyez vos remarques sur ce document à public-bpwg-comments@w3.org (avec des archives publiques).

Ce document combine l'expérience de plusieurs acteurs du Web mobile en un seul ensemble de pratiques exemplaires, vues comme essentielles par les participants du groupe de travail.

Ce document, qui a été revu par des membres du W3C, des développeurs de logiciels et par d'autres groupes du W3C et tiers intéressés, a été approuvé par le Directeur comme recommandation du W3C. C'est un document stable qui peut être utilisé comme document de référence ou cité par un autre document. Le rôle du W3C en produisant la recommandation est d'attirer l'attention sur la spécification et d'en promouvoir le large déploiement. Cela participe à améliorer la fonctionnalité et l'interopérabilité du Web.

Ce document a été produit par un groupe œuvrant sous couvert de la politique des brevets du W3C du 5 février 2004. Ce document est seulement informatif. Le W3C tient une liste publique des divulgations de brevet faites en rapport avec les produits livrables du groupe ; cette page contient également des instructions pour divulguer un brevet. Quiconque a connaissance réelle d'un brevet qu'il estime contenir des revendications essentielles doit divulguer cette information conformément à la section 6 de la politique des brevets du W3C.

Table des matières

  1. 1 Introduction
    1. 1.1 But de ce document
    2. 1.2 Organisation des pratiques exemplaires
    3. 1.3 Public
    4. 1.4 Portée
      1. 1.4.1 Mise en place
    5. 1.5 Relations avec les autres pratiques exemplaires et recommandations
    6. 1.6 Longévité et versionnage
  2. 2 Exigences
    1. 2.1 Problèmes de présentation
    2. 2.2 Saisie
    3. 2.3 Bande passante et coût
    4. 2.4 Buts de l'utilisateur
    5. 2.5 Publicité
    6. 2.6 Limitations des appareils
    7. 2.7 Avantages
  3. 3 Contexte de livraison
    1. 3.1 Un seul Web
    2. 3.2 Arrière-plan de l'adaptation
    3. 3.3 Modèle de mise en œuvre de l'adaptation
    4. 3.4 Hypothèses à propos de l'adaptation
    5. 3.5 Établissement du contexte
    6. 3.6 Choix de l'expérience d'utilisateur
    7. 3.7 Contexte de livraison par défaut
  4. 4 Structure des formules de pratique exemplaire
  5. 5 Formules de pratique exemplaire
    1. 5.1 Comportement d'ensemble
      1. 5.1.1 Cohérence thématique de la ressource identifiée par une adresse URI
      2. 5.1.2 Exploiter les capacités de l'appareil
      3. 5.1.3 Contourner les mises en œuvres déficientes
      4. 5.1.4 Tester
    2. 5.2 Navigation et liens
      1. 5.2.1 Adresses URI des points d'entrée des sites
      2. 5.2.2 Barre de navigation
      3. 5.2.3 Structure équilibrée
      4. 5.2.4 Mécanismes de navigation
      5. 5.2.5 Touches d'accès
      6. 5.2.6 Identification de la cible du lien
      7. 5.2.7 Images cliquables
      8. 5.2.8 Rafraîchissement, redirection et fenêtres engendrées
      9. 5.2.9 Ressources extérieures liées
    3. 5.3 Mise en pages et contenu
      1. 5.3.1 Contenu de la page
      2. 5.3.2 Dimension de la page
      3. 5.3.3 Défilement
      4. 5.3.4 Barres de navigation, etc. (matériel extérieur)
      5. 5.3.5 Graphiques
      6. 5.3.6 Couleur
      7. 5.3.7 Images de fond
    4. 5.4 Définition de la page
      1. 5.4.1 Titre
      2. 5.4.2 Cadres
      3. 5.4.3 Éléments structuraux
      4. 5.4.4 Tables
      5. 5.4.5 Éléments non textuels
      6. 5.4.6 Taille de l'image
      7. 5.4.7 Balisage valide
      8. 5.4.8 Mesures
      9. 5.4.9 Feuilles de style
      10. 5.4.10 Réduire
      11. 5.4.11 Types de contenu
      12. 5.4.12 Codage des caractères
      13. 5.4.13 Messages d'erreurs
      14. 5.4.14 Cookies
      15. 5.4.15 En-têtes de mise en cache
      16. 5.4.16 Fontes
    5. 5.5 Entrée de l'utilisateur
      1. 5.5.1 Saisie
      2. 5.5.2 Ordre de tabulation
      3. 5.5.3 Étiquettes des commandes de formulaire
  6. 6 Conformité et mobileOK
    1. 6.1 Classes de produits
    2. 6.2 Extensibilité

Annexes


Liste des pratiques exemplaires

Les pratiques exemplaires suivantes sont traitées dans ce document et listées ici par commodité. Il existe également un récapitulatif à part.

  1. [THEMATIC_CONSISTENCY] Vérifier que le contenu obtenu en accédant à une adresse URI produise une expérience thématiquement cohérente depuis des appareils différents.

  2. [CAPABILITIES] Exploiter les capacités de l'appareil pour offrir une meilleure expérience d'utilisateur.

  3. [DEFICIENCIES] Prendre des mesures échelonnées raisonnables en solution de contournement des mises en œuvre déficientes.

  4. [TESTING] Effectuer des tests sur les appareils réels ainsi que les émulateurs.

  5. [URIS] Écourter les adresses URI des points d'entrée des sites .

  6. [NAVBAR] N'offrir qu'une navigation minimale en haut de la page.

  7. [BALANCE] Établir un compromis entre avoir trop de liens sur une page et demander à l'utilisateur de suivre trop de liens pour obtenir ce qu'il recherche.

  8. [NAVIGATION] Offrir des mécanismes de navigation cohérents.

  9. [ACCESS_KEYS] Attribuer des touches d'accès aux liens des menus de navigation et aux fonctionnalités fréquemment utilisées.

  10. [LINK_TARGET_ID] Identifier clairement la cible de chaque lien.

  11. [LINK_TARGET_FORMAT] Signaler le format du fichier cible sauf si l'appareil est réputé le gérer.

  12. [IMAGE_MAPS] Ne pas utiliser d'images cliquables sauf si l'appareil est réputé les gérer efficacement.

  13. [POP_UPS] Ne pas provoquer l'apparition de fenêtres surgissantes ou autres et ne pas modifier la fenêtre courante sans en aviser l'utilisateur.

  14. [AUTO_REFRESH] Ne pas créer de pages qui s'autorafraîchissent périodiquement à moins d'en avoir avisé l'utilisateur et fourni un moyen de l'arrêter.

  15. [REDIRECTION] Ne pas employer de balisage pour rediriger automatiquement les pages. Configurer plutôt le serveur pour effectuer les redirections avec des codes HTTP 3xx.

  16. [EXTERNAL_RESOURCES] Réduire au minimum le nombre des ressources liées à l'extérieur.

  17. [SUITABLE] Vérifier que le contenu convienne pour une utilisation dans un contexte mobile.

  18. [CLARITY] Utiliser un langage simple et concis.

  19. [LIMITED] Limiter le contenu à ce que l'utilisateur a demandé.

  20. [PAGE_SIZE_USABLE] Diviser les pages en morceaux utilisables mais limités en taille.

  21. [PAGE_SIZE_LIMIT] Vérifier que la taille globale de la page soit appropriée aux limitations de mémoire de l'appareil.

  22. [SCROLLING] Limiter le défilement dans une seule direction, sauf si le défilement secondaire est inévitable.

  23. [CENTRAL_MEANING] Vérifier que la matière centrale de la page précède celle qui ne l'est pas.

  24. [GRAPHICS_FOR_SPACING] Ne pas utiliser d'images pour l'espacement.

  25. [LARGE_GRAPHICS] Ne pas utiliser d'images que l'appareil ne peut pas rendre. Éviter les images volumineuses ou en haute résolution sauf si des informations critiques seraient perdues sinon.

  26. [USE_OF_COLOR] Vérifier que l'information communiquée avec de la couleur le soit également sans couleur.

  27. [COLOR_CONTRAST] Vérifier que les combinaisons de couleurs d'avant-plan et d'arrière-plan offrent un contraste suffisant.

  28. [BACKGROUND_IMAGE_READABILITY] S'assurer que le contenu avec des images de fond reste lisible sur l'appareil.

  29. [PAGE_TITLE] Fournir un titre de page court mais descriptif.

  30. [NO_FRAMES] Ne pas utiliser de cadres.

  31. [STRUCTURE] Utiliser les fonctionnalités du langage de balisage pour structurer logiquement le document.

  32. [TABLES_SUPPORT] Ne pas utiliser de tables sauf si l'appareil est réputé les gérer.

  33. [TABLES_NESTED] Ne pas utiliser de tables imbriquées.

  34. [TABLES_LAYOUT] Ne pas utiliser de tables pour la mise en pages.

  35. [TABLES_ALTERNATIVES] Utiliser, si possible, une alternative à la présentation tabulaire.

  36. [NON-TEXT_ALTERNATIVES] Fournir un équivalent textuel pour chaque élément non textuel.

  37. [OBJECTS_OR_SCRIPT] Ne pas compter sur des objets ou un script incorporés.

  38. [IMAGES_SPECIFY_SIZE] Indiquer la dimension des images dans le balisage, si celles-ci ont une dimension intrinsèque.

  39. [IMAGES_RESIZING] Redimensionner les images sur le serveur, si celles-ci ont une dimension intrinsèque.

  40. [VALID_MARKUP] Créer des documents qui se valident auprès de grammaires formelles publiées.

  41. [MEASURES] Ne pas utiliser de dimensions en pixels ni d'unités absolues pour les valeurs des attributs du langage de balisage et celles des propriétés de feuille de style.

  42. [STYLE_SHEETS_USE] Utiliser des feuilles de style pour contrôler la mise en pages et la présentation, sauf si l'appareil est réputé ne pas les gérer.

  43. [STYLE_SHEETS_SUPPORT] Organiser les documents afin de pouvoir les lire sans feuille de style si nécessaire.

  44. [STYLE_SHEETS_SIZE] Réduire les feuilles de style.

  45. [MINIMIZE] Utiliser du balisage concis et efficace.

  46. [CONTENT_FORMAT_SUPPORT] Envoyer le contenu dans un format réputé géré par l'appareil.

  47. [CONTENT_FORMAT_PREFERRED] Envoyer, si possible, le contenu au format préféré.

  48. [CHARACTER_ENCODING_SUPPORT] Vérifier que le codage des caractères du contenu soit géré par l'appareil.

  49. [CHARACTER_ENCODING_USE] Indiquer le codage des caractères utilisé dans la réponse.

  50. [ERROR_MESSAGES] Fournir des messages d'erreurs informatifs et un moyen de retourner du message d'erreur à l'information utile.

  51. [COOKIES] Ne pas compter sur la disponibilité de cookies.

  52. [CACHING] Fournir une information de mise en cache dans les réponses HTTP.

  53. [FONTS] Ne pas compter sur la gestion d'un style lié à une fonte.

  54. [MINIMIZE_KEYSTROKES] Réduire au minimum le nombre des touches pressées.

  55. [AVOID_FREE_TEXT] Éviter si possible la saisie de texte libre.

  56. [PROVIDE_DEFAULTS] Fournir si possible des valeurs par défaut présélectionnées.

  57. [DEFAULT_INPUT_MODE] Spécifier un mode de saisie du texte, une langue ou un format d'entrée par défaut, si l'appareil est réputé les gérer.

  58. [TAB_ORDER] Créer un ordre logique à travers les liens, les commandes de formulaire et les objets.

  59. [CONTROL_LABELLING] Étiqueter toutes les commandes de formulaire de manière appropriée et associer explicitement les étiquettes aux commandes de formulaire.

  60. [CONTROL_POSITION] Positionner les étiquettes en bonne place vis-à-vis des commandes de formulaire auxquelles elles se rapportent.


1 Introduction

1.1 But du document

Ce document établit une série de recommandations conçues pour améliorer l'expérience d'utilisateur du Web sur des appareils mobiles.

Les recommandations s'adressent aux créateurs, aux maintenants et aux opérateurs de sites web et tiennent lieu de base d'évaluation pour la conformité au label (trustmark) mobileOK, qui est décrite dans la charte du groupe de travail Mobile Web Best Practices et qui n'est pas développée ici. Au moment de la rédaction de ce document, les documents décrivant mobileOK et les techniques pour mettre en œuvre les recommandations des pratiques exemplaires sont en cours d'élaboration.

1.2 Organisation des pratiques exemplaires

Le document est organisé comme suit :

  1. Introduction — Décrit le public, le but et la portée du document.

  2. Exigences — Une illustration des types de problèmes que les pratiques exemplaires cherchent à réduire.

  3. Contexte de livraison— Explique l'environnement dans lequel a lieu l'accès mobile au Web, avec un accent particulier sur l'adaptation.

  4. Vue d'ensemble des pratiques exemplaires — Une explication de l'organisation des pratiques exemplaires et des sources desquelles elles dérivent.

  5. Pratiques exemplaires — Les formules (statements) en question.

  6. Conformité et mobileOK — Une brève déclaration de conformité et une référence à la documentation mobileOK.

  7. Annexes

    Sources

    Lectures associées

    Remerciements

    Références

1.3 Public

Les lecteurs sont censés être au fait de la création de sites web et avoir une connaissance générale des technologies impliquées, telles que les serveurs web et HTTP. Les lecteurs n'ont pas besoin d'avoir une formation aux technologies spécifiques des appareils mobiles.

Notre intention est d'expliquer clairement à tous ceux concernés ce que sont les pratiques exemplaires et d'établir ainsi une base commune de compréhension. Une conséquence de notre volonté d'éclairer les personnes qui ne sont pas déjà engagées dans le développement de contenus compatibles avec les appareils mobiles (mobile friendly), c'est que certaines de nos formules pourront sembler évidentes ou banales à ceux qui ont une expérience dans ce domaine.

Le document ne vise pas seulement les développeurs ; d'autres personnes telles que les créateurs interactifs et graphiques sont invitées à le lire.

1.4 Portée

La portée de ces pratiques exemplaires est exposée dans le document Portée des pratiques exemplaires du Web mobile [Scope]. En résumé, ce document traite principalement de l'extension de la navigation Web aux appareils mobiles.

Les recommandations des pratiques exemplaires concernent le contenu livré. Bien que relevant clairement des processus de création et de rendu du contenu sur les appareils, ce ne sont pas des pratiques exemplaires pour ces activités.

Puisque le but du document est de spécifier des pratiques exemplaires pour la livraison à des appareils mobiles, les formules qui n'ont pas trait spécifiquement aux appareils mobiles ne sont pas incluses. En particulier, beaucoup de directives pour l'accessibilité du contenu web [WCAG] sont générales à toutes les formes d'accès web et ne sont pas répétées ici à moins d'une interprétation propre aux appareils mobiles. Les exemples de bonne pratique générale qui ont une interprétation propre aux appareils mobiles comprennent les messages d'erreurs et la couleur.

Cf. l'annexe B Lectures associées pour des renseignements à propos des thèmes apparentés de l'internationalisation, l'accessibilité du Web et l'indépendance par rapport aux appareils.

1.4.1 Mise en place

Comme expliqué dans le document de portée [Scope], les pratiques exemplaires du Web mobile revêtent beaucoup d'aspects. Aujourd'hui, par exemple, la conception et la construction de beaucoup de sites et pages web, vus sur un appareil mobile, procurent une expérience médiocre à l'utilisateur.

La qualité de l'expérience du Web par l'utilisateur dépend considérablement de la facilité d'utilisation (usability) des sites web, des navigateurs et de l'appareil en question. Bien que la facilité d'utilisation du navigateur et celle de l'appareil importent (pour interagir avec le contenu, le lire et y naviguer), ce document se concentre principalement sur des pratiques exemplaires pour améliorer la facilité d'utilisation des sites.

Dans des phases futurs, d'autres aspects pourront être considérés, par exemple des pratiques exemplaires qui s'appliqueraient à l'adaptation et aux appareils. Également, dans le futur, la portée des recommandations pourrait s'étendre au-delà de la « navigation Web traditionnelle » dans des domaines tels que l'interaction multimodale.

1.5 Relations avec les autres pratiques exemplaires et recommandations

Ces recommandations dérivent en partie des directives pour l'accessibilité du contenu du Web [WCAG]. Comme indiqué plus haut, les directives WCAG sont complémentaires des pratiques exemplaires du Web mobile, dont la portée se limite aux questions qui ont trait spécifiquement aux appareils mobiles.

Ce document repose sur quelques uns des concepts décrits par le groupe de travail Device Independence (DIWG) dans les principes de l'indépendance par rapport aux appareils [DIP]. Le document décrit les caractéristiques des appareils et des canaux de distribution, ce que le groupe de travail DIWG a appelé le contexte de livraison [DCODI]. En outre, le document emploie une terminologie empruntée au glossaire des termes de l'indépendance par rapport aux appareil du DIWG [DIGLOSS].

Le groupe de travail Best Practices développe un document d'accompagnement qui décrit les techniques [Techniques] grâce auxquelles les formules des pratiques exemplaires de ce document peuvent être mises en œuvre.

1.6 Longévité et versionnage

Les pratiques exemplaires sont formulées à un niveau de généralité qui permet de les appliquer dans une variété de langages de balisage. Elles sont écrites dans l'idée de propriétés durables de l'accès mobile au Web. Même si les facteurs identifiés à la section 3.7 Contexte de livraison par défaut, tels que les dimensions des écrans, changeront avec le temps, il est vraisemblable que les caractéristiques distinctives de l'accès mobile, telles que le coût et la difficulté de saisie, demeureront des problèmes.

Ce document peut être révisé périodiquement. Quand nécessaire, une version mise à jour paraîtra avec une documentation claire sur les changements qui auront été introduits.

2 Exigences

Cette section explique les exigences des formules de pratique exemplaire du Web mobile de la section 5. La formulation des exigences cherche à être illustrative plutôt qu'exhaustive ou définitive.

2.1 Problèmes de présentation

Aujourd'hui, beaucoup de pages web sont mises en pages pour une présentation sur des écrans d'ordinateurs de bureau, et exploitent les capacités de logiciels de navigation de bureau.

L'accès à une telle page web sur un appareil mobile se traduit souvent par une expérience médiocre ou inutilisable. Parmi les facteurs qui y contribuent, les pages qui ne sont pas disposées comme prévu. Du fait de la dimension réduite de l'écran et de la quantité limitée des données que voit l'utilisateur, le contexte et la vue d'ensemble sont perdus.

À cause de la dimension réduite de l'écran, la substance de la page peut nécessiter un défilement considérable pour être visible, en particulier si le haut de la page est occupé par des images et des liens de navigation. Auxquels cas, l'utilisateur n'obtient pas la confirmation immédiate que sa recherche a abouti au bon contenu.

Dans le contexte des appareils mobiles, il est particulièrement important d'aider l'utilisateur à créer une image mentale du site. On peut l'y aider en adoptant un style cohérent mais un style irrégulier y nuira considérablement.

2.2 Saisie

La saisie avec un appareil mobile est souvent difficile comparée à celle avec un appareil de bureau équipé d'un clavier (keyboard). Les appareils mobiles ont souvent un clavier numérique (keypad) très réduit avec des petites touches et rarement un dispositif de pointage (pointing device).

Une des difficultés du Web mobile est que les adresses URI sont très compliquées à taper. La saisie correcte des adresses URI longues et celles qui contiennent beaucoup de caractères de ponctuation est particulièrement ardue.

À cause des limitations de l'écran et de la saisie, les formulaires sont difficiles à remplir. Parce que la navigation entre les champs ne se fera pas dans l'ordre prévu et parce que l'écriture dans les champs sera mal aisée.

Tandis qu'une majorité d'appareils modernes offre un bouton de retour en arrière, ce n'est pas le cas de tous et, si la fonctionnalité existe, les utilisateurs ne sauront parfois pas comment l'invoquer. Cela signifie qu'il est souvent très difficile de récupérer sur des erreurs, des liens brisés, etc.

2.3 Bande passante et coût

Les réseaux mobiles peuvent être lents comparés aux liaisons de données fixes et leur latence mesurable est souvent plus élevée. Cela peut se traduire par des délais de récupération longs, spécialement pour du contenu volumineux et du contenu qui nécessite beaucoup de navigation entre les pages.

Le transfert mobile de données est rarement gratuit. Le fait que les appareils mobiles ne gèrent souvent qu'un nombre limité de types de contenu signifie que l'utilisateur peut suivre un lien et récupérer des données qui sont inutilisables sur son appareil.

Même si l'appareil peut interpréter le type de contenu, l'expérience est souvent peu satisfaisante — par exemple, des images trop grandes qui ne seront visibles que par petits morceaux avec un défilement considérable.

Les pages web n'ont pas toujours le contenu demandé par l'utilisateur, en particulier la publicité et les grandes images. Dans le monde de l'appareil mobile, cette matière supplémentaire contribue à une convivialité médiocre et peut gonfler considérablement le coût de la récupération.

2.4 Buts de l'utilisateur

Les utilisateurs d'appareils mobiles ont généralement des intérêts qui sont différents de ceux des utilisateurs d'appareils fixes ou de bureau. Leurs intentions seront probablement plus immédiates et axées sur un objectif que celles des utilisateurs du Web au bureau. Ils rechercheront volontiers des bouts spécifiques d'information qui sont pertinents à leur environnement. L'exemple d'une telle application axée sur un objectif serait celui d'un utilisateur se renseignant spécifiquement sur les horaires d'un trajet qu'il entreprend à l'instant.

De même, les utilisateurs d'appareils mobiles ne sont typiquement pas intéressés par les documents volumineux ou la navigation. L'ergonomie de l'appareil convient rarement à la lecture des documents longs, et les utilisateurs consulteront de tels documents depuis un appareil mobile seulement en dernier ressort, parce qu'il n'existera pas d'accès plus commode.

2.5 Publicité

Les développeurs de sites web commerciaux devraient noter que des modèles commerciaux différents sont souvent à l'œuvre pour l'accès au Web depuis un appareil mobile à comparer à l'accès depuis un appareil de bureau. Par exemple, certains mécanismes employés couramment pour la présentation de matériels publicitaires, tels que les fenêtres surgissantes (pop-ups), les fenêtres cachées (pop-unders) et les grandes bannières, ne fonctionnent pas bien sur les petits appareils et s'opposent donc aux recommandations des pratiques exemplaires telles que [CENTRAL_MEANING], [LARGE_GRAPHICS] et [POP_UPS].

L'initiative Mobile Web n'entend pas limiter ou interdire la publicité ; l'intention est plutôt que l'expérience d'utilisateur du site dans son ensemble, y compris la publicité s'il y en a, soit aussi efficace que possible.

2.6 Limitations des appareils

Comme indiqué plus haut, les contraintes imposées par le clavier et l'écran conduisent à une approche de la conception des pages qui est différente de celle des appareils de bureau. Et comme précisé dans le document de portée [Scope], d'autres limitations peuvent avoir un impact sur la facilité d'utilisation du Web depuis un appareil mobile.

Souvent les navigateurs des appareils mobiles ne gèrent pas les scripts ou les modules d'extension (plug-ins), ce qui veut dire que la gamme des contenus gérés est limitée. Dans beaucoup de cas, l'utilisateur n'a pas le choix du navigateur et sa mise à jour est impossible.

Certaines activités associées au rendu des pages web demandent beaucoup de calculs, par exemple le rafraîchissement (re-flowing) des pages, la mise en place des tableaux, le traitement de feuilles de style inutilement longues et complexes, ou la manipulation d'un balisage invalide [T-MOB]. Les appareils mobiles ont généralement une capacité de traitement très limitée, ce qui veut dire que l'achèvement du rendu des pages peut prendre un temps visible. En plus d'introduire un délai visible, un tel traitement utilise plus de puissance qu'une communication avec le serveur.

Beaucoup d'appareils ont une mémoire réduite pour les pages et les images, et le dépassement de cette mémoire peut se traduire par un affichage incomplet et causer d'autres problèmes.

2.7 Avantages

À discuter des limitations des appareils mobiles pour la livraison de contenu Web, on peut facilement perdre de vue que ceux-ci sont extrêmement populaires et répandus.

Cette popularité actuelle tient au fait d'être :

  • personnels

  • personnalisables

  • portables

  • connectés

Et de plus en plus multifonctionnels, au-delà du but initial de la transmission de la voix.

Outre ces facteurs, les appareils mobiles incluront de plus en plus les avantages suivants :

  • une connaissance du lieu

  • une fonctionnement d'une seule main

  • toujours allumé

  • un appareil universel d'alerte

À titre d'exemple de ces facteurs : le Web va où vous allez. Vous n'avez plus à vous rappeler de faire quelque chose sur le Web quand vous revenez à votre ordinateur. Vous pouvez le faire immédiatement, dans l'environnement même qui vous a incité à utiliser le Web au premier chef.

De plus, avec l'apparition d'appareils mobiles de tous les modèles et de toutes les formes, et avec la diversité grandissantes de fonctionnalités comme la technologie de la localisation, l'appareil photo, la reconnaissance vocale, les écrans tactiles, etc., le Web peut toucher une audience bien plus grande, et à tous moments dans toute les situations. Le Web a l'opportunité d'atteindre des endroits où aucun fil ne peut aller, des endroits inconcevables auparavant (par exemple, fournir un renseignement médical sur le lieu d'un sauvetage en montagne) et d'accompagner chacun aussi facilement que l'heure avec sa montre.

Enfin, il y a aujourd'hui beaucoup plus de possesseurs d'appareil mobile que d'ordinateur de bureau. C'est probablement très important dans les pays en voie de développement, où les appareils mobiles avec une capacité Web peuvent jouer un rôle dans le déploiement de masse de l'accès au Web similaire à celui du téléphone portable de fournir un service de téléphone ordinaire.

3 Contexte de livraison

Le contexte de livraison est employé au sens spécifique défini dans le Glossaire de l'indépendance par rapport aux appareils [DIGLOSS].

3.1 Un seul Web

Les recommandations dans ce document sont destinées à améliorer l'expérience du Web sur les appareils mobiles. Bien que ces recommandations ne concernent pas spécifiquement l'expérience de navigation sur un appareil de bureau, il faut comprendre qu'elles sont faites dans le cadre d'une volonté d'œuvrer vers « un seul Web ».

Comme expliqué dans le document de portée [Scope], un seul Web signifie, dans la mesure du raisonnable, mettre à la disposition des utilisateurs les mêmes informations et services, indépendamment de l'appareil utilisé. Toutefois, cela ne veut pas dire que la même information sera disponible exactement dans la même représentation à travers tous les appareils. Le contexte d'utilisation de l'appareil, les capacités variables des appareils, les questions de bande passante et les capacités du réseau mobile affectent tous la représentation. En outre, quelques services et informations conviennent mieux et s'adressent à des environnements d'utilisateur particuliers (cf. la section 5.1.1 Cohérence thématique d'une ressource identifiée par une adresse URI).

Certains services ont un appel principalement mobile (par exemple, des services fondés sur le lieu). D'autres ont un appel principalement mobile mais un aspect complémentaire de bureau (par exemple, pour des tâches de configuration complexes). D'autres encore ont un appel principalement de bureau mais un aspect complémentaire mobile (probablement pour des alertes). Enfin il restera des applications web qui ont un appel principalement de bureau (documents de référence longs, images riches, par exemple).

Les concepteurs d'applications et les fournisseurs de services voudront probablement offrir la meilleur expérience possible dans le contexte où l'appel du service est le plus grand. Toutefois, alors que l'expérience du service pourra être plus appropriée dans tel contexte ou dans tel autre, on considère une bonne pratique d'offrir une expérience aussi raisonnable que possible en fonction des limitations de l'appareil et de ne pas interdire l'accès à une classe particulière d'appareils, sauf si les limitations de l'appareil l'imposent.

Du point de vue de ce document, cela signifie que les services devraient être disponibles comme une variante HTML sur HTTP (cf. la section 3.7 Contexte de livraison par défaut).

3.2 Arrière-plan de l'adaptation

Les caractéristiques très variables des appareils mobiles peuvent compliquer la fourniture par un service web d'une expérience d'utilisateur acceptable à travers une gamme étendue d'appareils. Par exemple, des appareils différents gèrent diverses caractéristiques de balisage, et des écrans aux dimensions différentes demanderont peut-être des images dans différentes dimensions. Par conséquent, il est très courant lors de la livraison de contenu à des appareils mobiles de varier les détails du balisage, le format des images, les dimensions des images, les profondeurs de couleur, etc. pour correspondre aux caractéristiques de l'appareil en question. Le processus de modification du contenu afin d'améliorer l'expérience d'utilisateur sur des appareils particuliers est appelé adaptation du contenu.

Nous ne décrivons pas l'adaptation en détails dans ce document. Pour une description plus précise, les lecteurs sont invités à consulter les Principes de l'indépendance par rapport aux appareils [DIP].

En outre, le groupe frère du groupe de travail Best Practices, le groupe de travail Device Description, définit actuellement les conditions requises pour un référentiel des caractéristiques d'appareils mobiles, pertinentes à l'adaptation du contenu.

3.3 Modèle de mise en œuvre de l'adaptation

Il existe plusieurs modèles de mise en œuvre pour l'adaptation du contenu. D'un côté, l'adaptation peut être assez simple, et consister à déterminer le type de l'appareil et à choisir le jeu le plus approprié de contenus préparés à l'avance qui correspond aux caractéristiques de l'appareil. À l'extrême, elle peut être réalisée de manière entièrement dynamique, avec un contenu formaté au moment de la récupération, en tenant compte non seulement de propriétés déterminées statiquement, telles que la dimension de l'écran, mais aussi de propriétés déterminées dynamiquement, telles que le branchement temporaire d'un clavier complet (fully-featured).

L'adaptation peut être réalisée à divers points dans la livraison du contenu à l'appareil [DCODI] :

L'adaptation côté serveur implique que le contenu soit livré par le serveur de contenu ou l'application d'origine.

L'adaptation dans le réseau est celle où le contenu est modifié alors qu'il passe au travers d'une ou plusieurs composantes du réseau. Certains opérateurs de réseaux, par exemple, compressent les images avant de les transmettre aux appareils mobiles.

L'adaptation côté client est celle où l'appareil accepte le contenu et l'affiche de manière appropriée pour ses caractéristiques.

Quel que soit le modèle d'adaptation à l'œuvre, le processus de l'adaptation ne devrait pas diminuer l'accessibilité.

3.4 Hypothèses à propos de l'adaptation

Dans la première phase (cf. la section 1.4.1 Mise en place), on supposait que l'adaptation du contenu, le cas échéant, avait lieu côté serveur. Les phases futures pourront étudier les implications de l'adaptation du contenu ailleurs, spécialement les questions concernant la cession de l'autorité à des tiers pour effectuer l'adaptation, interdire l'adaptation, etc. Les phases ultérieures pourront également traiter de l'adaptation multiple, c'est-à-dire que l'adaptation puisse être réalisée en plusieurs points et qu'une adaptation dans le réseau puisse intervenir plusieurs fois.

On supposait également qu'il serait possible de créer un site compatible avec les recommandations des pratiques exemplaires sans réaliser d'adaptation du tout. Quoiqu'il en soit, on obtiendra vraisemblablement une expérience d'utilisateur bien meilleure et plus sophistiquée si on utilise l'adaptation.

3.5 Établissement du contexte

Offrir des variations de l'expérience d'utilisateur qui soient appropriées aux différents cas oblige le fournisseur de contenu à bien connaître les caractéristiques de l'appareil, les propriétés du navigateur utilisé et la transparence de la connexion entre le réseau et l'appareil.

Pour les sites simples qui présentent une interface semblable à travers une gamme étendue de contextes, les besoins de tels renseignements sont réduits par rapport à ceux d'un site sophistiqué qui a une structure de navigation optimisée, présente des images en plusieurs dimensions ou effectue d'autres adaptations pour correspondre au contexte de livraison particulier.

Il existe plusieurs méthodes permettant à un fournisseur de contenu de découvrir des informations à propos du contexte de livraison, telles que CC/PP, UAProf, CSS Media Queries et diverses solutions du groupe de travail Device Independence. Le document d'accompagnement des techniques [Techniques] décrit ces méthodes.

3.6 Choix de l'expérience d'utilisateur

Pour satisfaire aux critères de l'« un seul Web » (cf. la section 3.1 Un seul Web), le fournisseur de contenu peut permettre à l'utilisateur de sélectionner dans des catégories élargies, telles que la présentation mobile ou de bureau, là où celles-ci sont distinguées dans l'application. Si l'option de présentation a été déterminée automatiquement, le fournisseur de contenu peut permettre à l'utilisateur de passer outre la détermination automatique. Là où un choix de présentations est offert, une bonne pratique est d'enregistrer les préférences de l'utilisateur et d'en permettre la modification.

Étant donné un environnement de serveur approprié, il est peu probable que le fournisseur de contenu ne puisse pas découvrir quelque chose à propos du contexte de livraison. Toutefois, ça peut arriver, soit parce que les détails du contexte de livraison ne sont pas disponibles avec une granularité suffisante, soit parce que le serveur n'offre pas la possibilité d'inspecter et d'agir sur les informations fournies. Auquel cas, on devrait offrir une « expérience par défaut raisonnable ».

Les détails de l'expérience par défaut dépendent d'un certain nombre de facteurs comprenant, mais pas seulement, la région géographique dans laquelle le service est offert et l'intention première du service (par exemple, en considérant que le service vise une utilisation principalement de bureau opposé à principalement mobile).

3.7 Contexte de livraison par défaut

Afin que les fournisseurs de contenu puissent partager une vue cohérente par défaut de l'expérience mobile, le groupe de travail Best Practices a défini le contexte de livraison par défaut (default delivery context). Celui-ci permet aux fournisseurs d'offrir, faute d'adaptation, des expériences appropriées et, avec adaptation, une expérience de base (baseline). Le groupe de travail Best Practices a déterminé que le contexte de livraison par défaut était la spécification du contexte de livraison minimal nécessaire pour une expérience raisonnable du Web. Il est admis que les appareils, sans satisfaire à cette spécification, puisse fournir une expérience raisonnable d'autres services non-Web.

Il est admis également que cette spécification soit construite sur la base d'hypothèses démographiques, culturelles et économiques. Les fournisseurs de contenu peuvent choisir d'offrir des services qui demandent une spécification de contexte de livraison différente ou inférieure, mais ils devraient essayer de proposer une expérience qui exploite les capacités du contexte de livraison par défaut afin d'offrir la meilleure expérience possible pour ce contexte.

Nous insistons sur le fait que beaucoup d'appareils dépassent les capacités définies par le contexte de livraison par défaut. Nous encourageons les fournisseurs de contenu à ne pas diminuer l'expérience d'utilisateur sur ces appareils en développant seulement jusqu'au niveau de la spécification du contexte de livraison par défaut, et à adapter leurs contenus, là où c'est approprié, afin d'exploiter les capacités de l'appareil en question.

En résumé, le but de la définition du contexte de livraison par défaut est le soutien des règles suivantes :

  • Si un processus d'adaptation est utilisé, alors on devrait utiliser les données connues à propos du contexte de livraison réel (cf. la section 5.1.2 Exploiter les capacités des appareils) afin de varier le contenu livré pour le rendre plus adéquat à ce contexte de livraison spécifique ou pour offrir une meilleure expérience d'utilisateur.

  • Si le contenu livré ne provient pas d'un processus d'adaptation, par exemple le contenu est défini statiquement comme du HTML stocké dans des fichiers, ou le contexte de livraison ne peut pas être déterminé de manière adéquate, alors le contenu livré devrait être approprié au contexte de livraison par défaut et devrait être conforme aux formules des pratiques exemplaires.

Le contexte de livraison par défaut est définit comme suit :

Largeur utilisable de l'écran

120 pixels, au minimum.

Gestion du langage de balisage

XHTML Basic 1.1 [XHTML-Basic] livré avec le type de contenu application/xhtml+xml.

Codage des caractères

UTF-8 [UTF-8].

Gestion des formats d'image

JPEG.

GIF 89a.

Poid total maximum de la page

20 ko.

Couleurs

256 couleurs, au minimum.

Gestion des feuilles de style

CSS niveau 1 [CSS]. En outre, la règle de CSS niveau 2 [CSS2] @media avec les types de média handheld et all (cf. les types de média dans CSS 2).

HTTP

HTTP/1.0 [HTTP1.0] ou plus récent [HTTP1.1].

Script

Pas de gestion des scripts côté client.

4 Structure des formules de pratiques exemplaires

La rubrique

Le domaine fonctionnel couvert par les formules.

Les formules

Une ou plusieurs formules de pratique exemplaire, identifiées de la façon suivante :

[EXEMPLE] Voici une formule de pratique exemplaire.

Ce que ça signifie

Une explication de la signification des formules sous cette rubrique.

Ce qu'il faut faire

Une explication des techniques et quelques suggestions pour la mise en œuvre. Le groupe de travail Best Practices élabore un document séparé décrivant les techniques [Techniques] plus en détails.

Ce qu'il faut tester

Les aspects du contenu livré qu'un validateur externe pourrait examiner afin d'évaluer la conformité aux formules de pratique exemplaire. Cette section est absente pour les formules liées au processus.

Dans cette section, il est indiqué si la formule est testable par une machine (les tests automatisés sont possibles) ou testable par une personne (les tests nécessitent une évaluation humaine). Certaines pratiques exemplaires sont partiellement testables par une machine, c'est-à-dire qu'une interaction humaine, fondée sur le résultat d'un test automatique, sera peut être nécessaire. Auxquels cas seront présentes à la fois une formule testable par une machine et une formule testable par une personne.

Certaines formules de pratique exemplaire emploient des mots tels que « minimiser » et « éviter » volontairement non prescriptifs. Ceci afin de fournir un guide tout en laissant de la place pour tenir compte d'une grande diversité d'applications dont ne peut pas anticiper les exigences. Cela permet aussi une créativité et une diversité dans le cadre de la même pratique exemplaire. On trouvera des avis plus prescriptifs dans le document des techniques [Techniques].

Références

Là où c'est approprié, des références aux points de contrôle WCAG qui s'y rattachent et d'autres références immédiates du texte précédent.

5 Formules de pratique exemplaire

Les formules de pratique exemplaire sont regroupées dans les rubriques suivantes :

5.1 Comportement d'ensemble

Quelques principes généraux sous-tendent la livraison aux appareils mobiles.

5.1.1 Cohérence thématique de la ressource identifiée par une adresse URI

[THEMATIC_CONSISTENCY] Vérifier que le contenu obtenu en accédant à une adresse URI produise une expérience thématiquement cohérente depuis des appareils différents.

5.1.1.1 Ce que ça signifie

C'est une réalisation du principe un seul Web (cf. la section 3.1 Un seul Web), selon lequel le contenu devrait être accessible sur une variété d'appareils indépendamment des différentes capacités de présentation et du mécanisme d'accès. Les sites web peuvent paginer leurs contenus de diverses façons correspondant aux différences entre les caractéristiques des appareils ; ainsi, la structure de navigation du site et éventuellement sa réalisation technique peuvent varier selon la classe d'appareils qui est servie (cf. également [WebArch] section 3.5.1).

Un signet capturé sur un appareil devrait être utilisable sur un autre type d'appareil, même s'il ne produit pas exactement la même expérience. Si la page mise en signet ne convient pas au nouvel appareil qui l'utilise, une alternative appropriée devrait être fournie.

Les adresses URI peuvent être décorées, pour donner des informations de session ou autres. Si une adresse URI est décorée d'une information de session périmée, alors l'utilisateur devrait être conduit vers un point dans la hiérarchie de navigation qui est approprié pour son appareil, afin d'établir des paramètres de session ou autres.

5.1.2 Exploiter les capacités de l'appareil

[CAPABILITIES] Exploiter les capacités de l'appareil pour offrir une meilleure expérience d'utilisateur.

5.1.2.1 Ce que ça signifie

Bien que l'on sensibilise les fournisseurs de contenu aux nécessités du contexte de livraison par défaut, il n'est pas dans nos intentions que cela se traduise par une expérience diminuée sur les appareils capables de plus. Développez des sites qui visent le contexte de livraison par défaut. De surcroît, là où c'est approprié, utilisez les capacités des appareils capables de plus afin d'offrir une meilleure expérience d'utilisateur.

5.1.3 Trouver des solutions de contournement pour les mises en œuvres déficientes

[DEFICIENCIES] Prendre des mesures échelonnées raisonnables en solution de contournement des mises en œuvre déficientes.

5.1.3.1 Ce que ça signifie

Tout comme dans le monde de l'appareil de bureau, il y a des navigateurs qui ne respectent pas les intentions du fournisseur de contenu. Il existe des différences d'interprétation entre les navigateurs et il y a également des mises en œuvre déficientes. Par déficience, nous entendons la non-gestion des caractéristiques obligatoires d'un standard ou d'une recommandation concernés, et autres bogues ou erreurs d'implémentation.

Puisque les logiciels sont souvent intégrés aux appareils mobiles, il n'est pas facile de les corriger ou les améliorer une fois en place. C'est un défi considérable que de fournir des solutions de contournement pour ces déficiences et différences d'interprétation. Il est admis que les fournisseurs de contenu soient obligés d'enfreindre certaines pratiques exemplaires afin de soutenir leurs intentions sur des appareils qui présentent des déficiences de mise en œuvre. Si un appareil n'est pas réputé avoir de limitations particulières, alors les fournisseurs de contenu doivent satisfaire aux pratiques exemplaires.

Tout comme nous ne recommandons pas d'approche de type plus petit dénominateur commun, nous ne recommandons pas d'éviter les caractéristiques qui présentent des problèmes sur une certaine classe d'appareils.

Il n'est pas dans notre intention non plus de suggérer aux fournisseurs de contenu qu'ils limitent leur soutien à certains types d'appareils. Les fournisseurs de contenu devraient viser le soutien d'une gamme de types d'appareil aussi grande que possible.

5.1.4 Tester

[TESTING] Effectuer des tests sur les appareils réels ainsi que les émulateurs.

5.1.4.1 Ce que ça signifie

Tout site web devrait être testé dans une gamme de navigateurs. Les navigateurs des mobiles présentent des caractéristiques différentes par rapport à ceux de bureau. Comme pour la vérification du bon affichage d'un site dans un format réduit, les fournisseurs de contenu sont invités à vérifier que les fonctionnalités escomptées fonctionnent dans les appareils courants.

Les fournisseurs de contenu devraient également faire des essais sans des fonctionnalités spécifiques, telles que l'utilisation en mode texte seul et la désactivation des scripts.

5.1.4.2 Ce qu'il faut faire

Beaucoup de fabricants proposent des émulateurs de leur appareil qui peuvent fournir un moyen commode de vérification préliminaire. Toutefois, en pratique, nombreux sont ceux qui se comportent différemment des appareils qu'ils émulent. Par conséquent, la vérification devrait être effectuée sur un échantillon le plus grand possible d'appareils réels et de versions logicielles spécifiques.

À cause des limitations des mécanismes d'affichage et de saisie, de l'absence éventuelle d'un dispositif de pointage et des autres contraintes des appareils mobiles, la prudence est de mise pour définir la structure et le modèle de navigation d'un site web.

5.2.1 Adresses URI des points d'entrée du site

[URIS] Écourter les adresses URI des points d'entrée des sites .

5.2.1.1 Ce que ça signifie

La saisie des adresses URI sur les appareils mobiles peut se révéler difficile, et les utilisateurs préféreront sans doute utiliser des méthodes alternatives, s'il y en a, pour obtenir les adresses URI, telles que suivre un hyperlien (dans un message électronique, un SMS ou une autre page web), un flux WAP (WAP Push), un code barre en 2D, un code barre en couleur, une étiquette RFID (RFID tag) et Bluetooth. Quoiqu'il en soit, taper une adresse URI sera parfois la seule option disponible. En écourtant les adresses URI des points d'entrée, on réduira les risques d'erreur et offrira une expérience d'utilisateur plus satisfaisante.

5.2.1.2 Ce qu'il faut faire

En arrivant aux points d'entrée du site, les utilisateurs ne devrait pas avoir à saisir un nom de fichier avec l'addrese URI. Si possible, configurer les sites web afin de pouvoir y accéder sans devoir spécifier de sous-domaine avec l'adresse URI.

Exemple — Au lieu d'obliger l'utilisateur à taper :

"http://www.example.org/index.html"

prévoir :

"http://example.org"

et au lieu de :

"http://www.example.org/example.html"

prévoir :

"http://example.org/example"

5.2.2 Barre de navigation

5.2.2.1 Ce que ça signifie

Fournir une navigation de base, qui devrait être placée en haut de la page. Tout autre élément de navigation secondaire peut être placé en bas de la page si vraiment nécessaire. Il importe que les utilisateurs puissent voir le contenu de la page, sans défilement, après qu'elle a été chargée (cf. la section 5.3.4 Barres de navigation, etc. (matériel extérieur)).

5.2.2.2 Ce qu'il faut faire

Fournir les liens de base sur une seule ligne.

5.2.3 Structure équilibrée

[BALANCE] Établir un compromis entre avoir trop de liens sur une page et demander à l'utilisateur de suivre trop de liens pour obtenir ce qu'il recherche.

5.2.3.1 Ce que ça signifie

La conception devrait chercher à composer un équilibre entre disposer un grand nombre de liens de navigation sur une page et devoir naviguer à travers plusieurs liens pour obtenir le contenu.

Le défilement d'une page qui contient beaucoup de liens peut être très gênant, car l'action de défilement sur beaucoup d'appareils mobiles sélectionne chaque lien l'un après l'autre. Au contraire, chaque récupération d'une page de navigation prend du temps et augmente le coût, on ne devrait donc pas réduire le nombre de liens sur une page au détriment d'augmenter les récupérations de pages.

Concevoir le service afin d'obtenir les informations fréquemment demandées avec un nombre minimum de récupérations de pages. Par conséquent, la navigation vers des informations qui le sont moins demandera peut-être plus de récupérations. En règle générale, les utilisateurs seront frustrés s'il leur faut plus de quatre récupérations pour atteindre leur but. La réalisation de cet objectif dépend de la nature du site et, en particulier, du regroupement des éléments des menus afin d'offrir des thèmes compréhensibles.

5.2.4 Mécanismes de navigation

5.2.4.1 Ce que ça signifie

L'utilisation des mêmes mécanismes de navigation à travers un service aide les utilisateurs à s'orienter et leur permet de les identifier aisément.

Les utilisateurs d'appareils qui n'ont pas de dispositif de pointage doivent faire défiler d'un hyperlien à l'autre avec le clavier numérique. Un regroupement intelligent, éventuellement optimisé au travers d'une adaptation selon des modèles d'utilisation (usage patterns), peut faciliter l'utilisation.

5.2.4.2 Ce qu'il faut faire

Une méthode « forer vers le bas » (drill-down), fondée sur des rubriques principales, offre souvent un moyen de navigation efficace ; à cause de l'arrangement linéaire du contenu, d'un écran de petite taille et faute d'un dispositif de pointage, il est souvent utile de fournir un moyen de passer des sections entières de contenu.

À chaque cible de la navigation « forer vers le bas », on devrait fournir un lien « vers le haut » qui permette à l'utilisateur de passer une section entière.

5.2.4.3 Références

Cette pratique se rattache au point de contrôle 13.4 de WCAG.

5.2.5 Touches d'accès

[ACCESS_KEYS] Attribuer des touches d'accès aux liens des menus de navigation et aux fonctionnalités fréquemment utilisées.

5.2.5.1 Ce que ça signifie

Lorsqu'il n'y a pas de dispositif de pointage, attribuer une touche d'accès (raccourci clavier) à un lien peut offrir une méthode commode aux utilisateurs d'accéder au lien et leur éviter de naviguer vers le lien en répétant les pressions sur la touche de navigation.

Fournir la même touche d'accès pour les liens qui se répètent à travers les pages tels que les liens vers la page d'accueil.

5.2.5.2 Ce qu'il faut tester

Test machine : Tester la présence de l'attribut accesskey.

Test humain : Vérifier la présence de l'attribut accesskey sur des liens tels que la page d'accueil.

5.2.5.3 Références

Cette pratique se rattache au point de contrôle 9.5 du WCAG.

5.2.6 Identification de la cible du lien

5.2.6.1 Ce que ça signifie

Les utilisateurs d'appareils mobiles peuvent souffrir de délais et de coûts excessifs pour avoir suivi des liens. Il est important d'identifier à quoi mène le lien afin que les utilisateurs puissent déterminer s'il est de leur intérêt de le suivre. Bien qu'il soit peu probable que l'on puisse indiquer à un utilisateur particulier la dépense de suivre un lien donné, il devrait être possible de donner une idée de la taille de la ressource (en octets ou de manière abstraite, par exemple c'est un « gros fichier »).

Les liens vers un format ou une langue qui diffèrent de ceux de la page où se trouve le lien (c'est-à-dire un contenu qui peut seulement être interprété par d'autres applications ou téléchargé) devraient être signalés aux personnes, afin qu'elles ne soient pas conduites à télécharger un contenu que leur appareil est incapable d'exploiter. Quoiqu'il en soit, sachez que certains appareils soutiennent le rendu de ces formats à l'aide d'autres applications une fois téléchargés (par exemple, des fichiers musicaux). De plus, les utilisateurs voudront peut-être aussi télécharger un contenu à transférer plus tard sur d'autres appareils. Donc même s'il est notoire que l'agent utilisateur ne gère pas un type de contenu particulier, ce contenu devrait quand même être mis à disposition.

5.2.6.2 Ce qu'il faut faire

Formuler le texte des liens de façon claire, concise et descriptive pour aider les utilisateurs à décider de suivre ou non un lien. Identifier les implications de suivre un lien si la cible est manifestement volumineuse et l'utilisateur ne peut le deviner d'après le contexte.

Pour le contexte de livraison par défaut, tous les formats hormis XHTML, GIF et JPG devraient être signalés.

5.2.6.3 Ce qu'il faut tester

Test humain : Vérifier la pertinence des descriptions (par exemple, pas de formulations de type « cliquez ici »).

Test machine : Vérifier les liens vers des formats non-HTML.

Test humain : Si présents, vérifier s'il existe des informations sur le format du lien.

5.2.6.4 Références

Cette pratique se rattache aux points de contrôle 11.3 et 13.1 du WCAG.

5.2.7 Images cliquables

[IMAGE_MAPS] Ne pas utiliser d'images cliquables sauf si l'appareil est réputé les gérer efficacement.

5.2.7.1 Ce que ça signifie

Les images cliquables (image maps) permettent de naviguer rapidement, pourvu que l'appareil appelant puisse gérer l'image impliquée et qu'existe un moyen satisfaisant de naviguer dans l'image. La plupart des mobiles disposent de touches haut, bas, gauche, droite et entrée, même sans dispositif de pointage. Cela suffit normalement pour naviguer dans les régions actives des images cliquables côté client, où elles sont définies par des formes géométriques.

Beaucoup d'appareils mobiles n'ont pas de dispositif de pointage et les images cliquables côté serveur y sont inutilisables.

5.2.7.2 Ce qu'il faut faire

Si seules sont affichables des images réduites, découper les grandes images en morceaux plus petits et traiter les séparément.

Pour le contexte de livraison par défaut, ou si on ne peut pas afficher une image cliquable satisfaisante, utiliser une liste de liens avec du texte descriptif à la place.

5.2.7.3 Ce qu'il faut tester

IMAGE_MAPS Test machine : Envoyer une requête au site web avec un appareil qui ne gère pas les images cliquables côté client et vérifier l'absence de l'élément map.

5.2.7.4 Références

Cette pratique se rattache aux points de contrôle 1.2 et 9.1 du WCAG.

5.2.8 Rafraîchissement, redirection et fenêtres engendrées

[POP_UPS] Ne pas provoquer l'apparition de fenêtres surgissantes ou autres et ne pas modifier la fenêtre courante sans en aviser l'utilisateur.

[AUTO_REFRESH] Ne pas créer de pages qui s'autorafraîchissent périodiquement à moins d'en avoir avisé l'utilisateur et fourni un moyen de l'arrêter.

[REDIRECTION] Ne pas employer de balisage pour rediriger automatiquement les pages. Configurer plutôt le serveur pour effectuer les redirections avec des codes HTTP 3xx.

5.2.8.1 Ce que ça signifie

Chacune de ces activités est susceptible d'embrouiller l'utilisateur, ou d'ajouter un coût et un retard à leur interaction.

Certains appareils mobiles utilisent une fenêtre séparée pour l'entrée ; cette section ne concerne pas les fenêtres de ce type.

Beaucoup d'appareils mobiles ne peuvent pas gérer plus d'une fenêtre et, par conséquent, tenter d'en ouvrir une produira des résultats imprévisibles.

Les pages qui s'autorafraîchissent sont bien connues pour présenter des problèmes d'accessibilité. Dans un environnement mobile, elles peuvent exposer l'utilisateur à un coût excessif en conséquence d'une page laissée ouverte ou placée subrepticement en arrière-plan. Si l'application demande une page autorafraîchissante, toujours fournir un moyen d'arrêter le rafraîchissement et toujours informer l'utilisateur que la page se rafraîchira et pourra les exposer à des coûts d'utilisation plus élevés.

Bien que la redirection soit un mécanisme employé couramment, on doit se rappeler qu'elle impose habituellement un aller-retour au navigateur. Cela ajoute au délai sur des connexions lentes ; donc utiliser seulement un maximum d'une seule redirection par page et limiter le nombre des pages qui sont redirigées.

5.2.8.2 Ce qu'il faut tester

POP_UPS Test machine : Chercher l'attribut target sur les liens et, si présent, vérifier qu'il a une valeur différente de _self, _parent ou _top.

AUTO_REFRESH Test machine : Vérifier si la déclaration meta http-equiv="refresh" content="<la même adresse URI>" est utilisée.

AUTO_REFRESH Test humain : En cas d'autoraffraîchissement, vérifier l'existence d'options pour arrêter l'autorafraîchissement des pages.

REDIRECTION Test machine : Vérifier si la déclaration meta http-equiv="refresh" content="<une adresse URI différente>" est utilisée.

5.2.8.3 Références

Cette pratique se rattache aux points de contrôle 7.4, 7.5 et 10.1 du WCAG.

5.2.9 Ressources extérieures liées

[EXTERNAL_RESOURCES] Réduire au minimum le nombre des ressources liées à l'extérieur.

5.2.9.1 Ce que ça signifie

Chaque ressource liée (images, feuilles de style et autres objets) impose une requête distincte à travers le réseau. Cela peut augmenter considérablement le temps de chargement de la page dans le contexte mobile.

5.2.9.2 Ce qu'il faut faire

Réduire le nombre d'images sur une page et consolider l'information de style en une seule feuille de style par page (cf. également la section 5.4.9 Feuilles de style).

5.2.9.3 Ce qu'il faut tester

Test machine : Compter le nombre des images, feuilles de style et autres éléments liés.

Test humain : Revoir si on ne pourrait pas obtenir un effet similaire en utilisant moins de liens.

5.3 Mise en pages et contenu

Cette section se rapporte à la perception par l'utilisateur du contenu livré. Elle se concentre sur la conception, la langue employée dans le texte et les relations spatiales entre les composants constituants. Elle ne traite pas des aspects techniques de la manière dont le contenu livré est construit, qui sont l'objet de la section 5.4 Définition de la page.

5.3.1 Contenu de la page

[SUITABLE] Vérifier que le contenu convienne pour une utilisation dans un contexte mobile.

[CLARITY] Utiliser un langage simple et concis.

[LIMITED] Limiter le contenu à ce que l'utilisateur a demandé.

5.3.1.1 Ce que ça signifie

Les utilisateurs dans un contexte mobile recherchent souvent des bouts d'information spécifiques plutôt qu'ils ne naviguent. Les fournisseurs de contenu devraient examiner le contexte d'utilisation probable et, tout en offrant l'option d'accéder à toutes les informations, devraient d'abord proposer les informations appropriées. Cf. également les explications des sections 2.4 Buts de l'utilisateur et 3.1 Un seul Web.

La prescription générale d'utiliser un langage clair est particulièrement importante pour la livraison mobile, où concision et style direct sont plus appréciés qu'un style discursif.

Une écriture dans le style « mise au début » du journalisme traditionnel peut aider les utilisateurs à déterminer si l'information présente un intérêt, quitte à l'écarter plus facilement si ce n'est pas le cas. La disposition de renseignements distinctifs au début des rubriques, paragraphes, listes, etc. peut également aider l'utilisateur à contextualiser avec des appareils à écran réduit. Cf. également la section 5.3.4 Barres de navigation, etc. (matériel extérieur) pour une discussion sur le fait de s'assurer que le sujet principal de la page se trouve en haut.

Les utilisateurs mobiles paient souvent la bande passante, donc leur offrir du contenu qui est éloigné de leurs besoins, particulièrement la publicité, leur coûte du temps et de l'argent et contribue à une expérience non satisfaisante. En général, on devrait rechercher l'assentiment de l'utilisateur avant d'initier le chargement d'un contenu.

5.3.1.2 Ce qu'il faut tester

Test humain : Examiner le contenu pour déterminer si, par rapport au sujet principal, il est approprié dans un contexte mobile.

5.3.1.3 Références

Cette pratique se rattache aux points de contrôle 13.8 et 14.1 du WCAG.

5.3.2 Dimension de la page

[PAGE_SIZE_USABLE] Diviser les pages en morceaux utilisables mais limités en taille.

[PAGE_SIZE_LIMIT] Vérifier que la taille globale de la page soit appropriée aux limitations de mémoire de l'appareil.

5.3.2.1 Ce que ça signifie

Si les pages sont trop grandes, elles prendront un temps excessivement long à charger. En outre, les appareils mobiles ont des restrictions en ce qui concerne la taille maximum de la page qu'ils peuvent recevoir.

Au contraire, si les pages sont trop courtes, alors l'utilisateur sera obligé d'effectuer plusieurs requêtes pour lire l'information pertinente. Cela peut entraîner des retards inutiles, puisque l'accomplissement de chaque requête prend généralement un temps perceptible.

L'équilibre entre la pagination et le défilement est partie affaire de goût, partie affaire de nécessité. Les appareils aux mémoires très restreintes ne pourront recevoir que des petites pages. Également certains appareils présentent une meilleure expérience de récupération des pages que de défilement.

Des études [MF] ont été réalisées dans ce domaine afin de tester les préférences des utilisateurs. Quelques unes indiquent que les utilisateurs préfèrent faire défiler que cliquer (click-throughs) et certaines indiquent le contraire. D'autres recherches sont probablement nécessaires dans ce domaine.

5.3.2.2 Ce qu'il faut faire

Pour le contexte de livraison par défaut, adopter les limites spécifiées à la section 3.7 Contexte de livraison par défaut.

5.3.2.3 Ce qu'il faut tester

PAGE_SIZE_USABLE Test machine : Mesurer la taille totale du balisage d'une page ; vérifier que celui-ci n'excède pas 10 ko pour le contexte de livraison par défaut.

Test humain : Vérifier que la page est toujours utilisable (par exemple, qu'elle ne soit pas coupée au milieu d'une phrase, juste avant la fin d'une section, etc.)

PAGE_SIZE_LIMIT Test machine : Mesurer la taille totale du balisage et des images d'une page ; vérifier que celle-ci ne dépasse pas la taille allouée pour l'appareil — 20 ko pour le contexte de livraison par défaut.

5.3.2.4 Références

Cette pratique se rattache au point de contrôle 12.3 du WCAG.

5.3.3 Défilement

[SCROLLING] Limiter le défilement dans une seule direction, sauf si le défilement secondaire est inévitable.

5.3.3.1 Ce que ça signifie

La page devrait s'afficher de façon à ce que l'utilisateur puisse apréhender tout son contenu en répétant un défilement simple dans la même direction (axe). En revanche, certains contenus (tels que les cartes ou autres images) ne peuvent pas être affichés sans défilement secondaire (secondary scrolling).

Si un élément sur la page demande un défilement secondaire, cela ne doit pas l'imposer pour le reste de la page. Par exemple, si un objet entraîne l'affichage du texte qui suit avec une marge importante à sa gauche, alors ce texte ne sera peut-être pas visible une fois que l'utilisateur aura fait défiler la page après l'objet.

De même, si la présence d'un tel objet entraîne l'affichage du texte au-delà du bord droit de la page, alors l'utilisateur sera contraint au défilement pour lire chaque ligne de texte.

5.3.3.2 Ce qu'il faut faire

S'il est impossible d'éviter la présentation d'images plus grandes que l'écran, alors envisager de fournir ces images sur une page séparée avec un lien de retour vers le contenu principal.

Dans le contexte de livraison par défaut, adopter une largeur de 120 pixels.

5.3.3.3 Ce qu'il faut tester

SCROLLING Test machine : Vérifier les attributs width et les propriétés de style de largeur plus grand que la taille de l'écran — pour le contexte de livraison par défaut, 120 pixels.

Test humain : Si la largeur est supérieure à celle de l'écran, vérifier que le cas d'utilisation le justifie (par exemple, pour des cartes).

Parcourir les adresses URI dans un site en utilisant un appareil mobile et, sur les pages avec des éléments nécessitant un défilement secondaire, observer si le défilement secondaire est seulement nécessaire pour ces éléments et que le reste de la page ne requiert qu'un défilement primaire.

5.3.4 Barres de navigation, etc. (matériel extérieur)

[CENTRAL_MEANING] Vérifier que la matière centrale de la page précède celle qui ne l'est pas.

5.3.4.1 Ce que ça signifie

Beaucoup de pages web sont conçues avec des éléments de navigation et autres en haut ou aux côtés de la page (par exemples, des barres de menu, des chemins de navigation (breadcrumb trails) et des fonctions de recherche). Cette conception offre une métaphore de navigation pratique et bien comprise sur les grands écrans. Par contre, sur les petits écrans, cela peut se traduire par l'apparition de la navigation au lieu du contenu de la page lors de la récupération initiale de la page.

Puisqu'il est important pour l'utilisateur de se faire une idée du contenu de la page au premier coup d'œil, on devrait réduire au minimum l'encombrement qui le précède, à savoir la navigation, les images décoratives, la publicité et autres éléments non essentiels à l'expérience d'utilisateur de la page. L'utilisateur ne devrait pas faire défiler inconsidérément la page pour en découvrir le contenu principal.

Cf. également la section 5.3.1 Contenu de la page sur la façon dont le style d'écriture peut aider l'utilisateur à identifier le sens.

5.3.4.2 Ce qu'il faut faire

Les sélections des menus peuvent être placées ailleurs avec un lien simple vers la sélection en haut de la page. D'une autre façon, utiliser une méta-navigation en haut de la page avec des liens textuels simples vers les sections principales du site web.

5.3.4.3 Ce qu'il faut tester

Test humain : Parcourir les adresses URI dans un site en utilisant un appareil mobile et observer si les informations les plus importantes ou pertinentes sont communiquées en premier.

5.3.4.4 Références

Cette pratique se rattache au point de contrôle 13.5 du WCAG.

5.3.5 Graphiques

[GRAPHICS_FOR_SPACING] Ne pas utiliser d'images pour l'espacement.

[LARGE_GRAPHICS] Ne pas utiliser d'images que l'appareil ne peut pas rendre. Éviter les images volumineuses ou en haute résolution sauf si des informations critiques seraient perdues sinon.

5.3.5.1 Ce que ça signifie

L'astuce courante consistant à employer une image d'un pixel pour un positionnement absolu ne fonctionne pas sur divers écrans.

Les images qui sont plus grandes que nécessaire, par exemple avec une résolution supérieure à celle affichable sur l'appareil, ou avec trop de couleurs, gaspillent la bande passante.

5.3.5.2 Ce qu'il faut tester

GRAPHICS_FOR_SPACING Test machine : Vérifier les images très petites ou transparentes.

LARGE_GRAPHICS Test machine : Vérifier les dimensions des images.

5.3.6 Couleur

[USE_OF_COLOR] Vérifier que l'information communiquée avec de la couleur le soit également sans couleur.

[COLOR_CONTRAST] Vérifier que les combinaisons de couleurs d'avant-plan et d'arrière-plan offrent un contraste suffisant.

5.3.6.1 Ce que ça signifie

Le contraste des couleurs des appareils mobiles est souvent mauvais et les conditions d'éclairage loin d'être idéales. Les informations mises en avant avec de la couleur ne seront donc peut-être pas visibles aux utilisateurs. Si on utilise de la couleur pour indiquer une fonctionnalité, alors on devrait généralement signaler cette fonctionnalité d'une manière qui n'en dépende pas. En particulier, ne pas utiliser du texte bleu ou violet qui pourrait être confondu avec des hyperliens, spécialement sur les appareils qui ne soulignent pas les liens.

5.3.6.2 Ce qu'il faut tester

USE_OF_COLOR Test humain : Parcourir la page dans un environnement monochrome.

COLOR_CONTRAST Test humain : Parcourir la page sous une lumière forte parallèle à l'écran.

Test machine : Il existe des outils automatiques pour tester le contraste des couleurs.

5.3.6.3 Références

Cette pratique se rattache aux points de contrôle 2.1 et 2.2 du WCAG.

5.3.7 Images de fond

[BACKGROUND_IMAGE_READABILITY] S'assurer que le contenu avec des images de fond reste lisible sur l'appareil.

5.3.7.1 Ce que ça signifie

Employées sans discernement, les images peuvent nuire à la bonne lecture du contenu, en particulier avec le contraste limité souvent de mise avec les appareils mobiles et dans les conditions de visibilité hostiles où ils sont fréquemment utilisés.

Avant d'employer des images de fond, examiner soigneusement les raisons de le faire et essayer d'utiliser des techniques alternatives pour obtenir des effets similaires. Si on emploie une image de fond, s'assurer de la lisibilité du contenu avec et sans l'image pour les appareils qui ne les gèrent pas.

5.3.7.2 Ce qu'il faut tester

Test machine : Tester la présence d'une image de fond.

Test humain : Vérifier la lisibilité à la fois sur les appareils qui les gèrent et sur ceux qui ne les gèrent pas.

5.4 Définition de la page

5.4.1 Title

[PAGE_TITLE] Fournir un titre de page court mais descriptif.

5.4.1.1 Ce que ça signifie

Donner un titre descriptif à la page pour en faciliter l'identification. Garder le titre court pour réduire le poid de la page, sachant qu'il pourra être tronqué.

Beaucoup d'appareils mobiles n'affichent pas le titre de la page. Lorsque le titre s'affiche, l'espace disponible peut être limité.

L'appareil peut se servir du titre de la page comme étiquette par défaut des signets (bookmarks). L'espace étant peut-être aussi limité, donc s'en servir pour aider à identifier le contenu et non pour d'autres besoins.

5.4.1.2 Ce qu'il faut tester

Test machine : Vérifier la présence de l'élément title.

Test humain : Vérifier que le titre est descriptif du contenu.

5.4.2 Cadres

[NO_FRAMES] Ne pas utiliser de cadres.

5.4.2.1 Ce que ça signifie

Beaucoup d'appareils mobiles ne gèrent pas les cadres (frames). En outre, les cadres sont connus pour poser des problèmes en général.

5.4.2.2 Ce qu'il faut tester

Test machine : Vérifier la présence des éléments de cadre — vérifier la présence des éléments frameset et iframe.

5.4.2.3 Références

Cf. http://www.w3.org/TR/xframes/#s_intro pour une explication des problèmes liés aux cadres.

5.4.3 Éléments structuraux

[STRUCTURE] Utiliser les fonctionnalités du langage de balisage pour structurer logiquement le document.

5.4.3.1 Ce que ça signifie

Une bonne pratique est de structurer tous les documents mêmes les plus simples au travers de titres et de sous-titres. Utiliser un balisage structurel, plutôt que des effets de formatage, facilite l'adaptation du contenu, là où il est besoin de le diviser en plusieurs pages, ainsi que l'accès potentiel aux sections du document qui intéressent l'utilisateur.

Si on utilise des titres, on devrait le faire conformément à la spécification, c'est-à-dire les imbriquer correctement selon leur niveau.

On ne doit pas utiliser de balisage structurel uniquement pour créer un effet de fonte (cf. également la section 5.4.16 Fontes).

5.4.3.2 Ce qu'il faut faire

Les langages de balisage tels que HTML contiennent plusieurs constructions pour indiquer la structure.

5.4.4 Tables

[TABLES_SUPPORT] Ne pas utiliser de tables sauf si l'appareil est réputé les gérer.

[TABLES_NESTED] Ne pas utiliser de tables imbriquées.

[TABLES_LAYOUT] Ne pas utiliser de tables pour la mise en pages.

[TABLES_ALTERNATIVES] Utiliser, si possible, une alternative à la présentation tabulaire.

5.4.4.1 Ce que ça signifie

Les tables ne fonctionnent pas bien sur des écrans de dimensions limitées et peuvent obliger l'utilisateur à faire défiler la page horizontalement pour les lire. Placer les liens de navigation dans des tables l'obligera peut-être à faire défiler la page à la fois horizontalement et verticalement pour voir les choix de navigation possibles.

5.4.4.2 Ce qu'il faut tester

TABLES_SUPPORT Test machine : Envoyer une requête au site avec un appareil qui ne gère pas les tables et vérifier que l'élément table ne soit pas présent.

Test machine : Vérifier qu'il n'y ait pas de tables imbriquées.

TABLES_LAYOUT Test machine : Vérifier qu'aucune colonne ou rangée dans une table ne soit vide ou contienne seulement une image GIF transparente d'1x1 pixel.

Test machine : S'il y a un élément table, vérifier s'il y a du contenu rendu hors de l'élément. Si ce n'est pas le cas, alors la table est probablement utilisée pour la mise en pages.

5.4.4.3 Références

Cette pratique se rattache aux points de contrôle 5.1, 5.2, 5.3, 5.5 et 5.6 du WCAG.

5.4.5 Éléments non textuels

[NON-TEXT_ALTERNATIVES] Fournir un équivalent textuel pour chaque élément non textuel.

[OBJECTS_OR_SCRIPT] Ne pas compter sur des objets ou un script incorporés.

5.4.5.1 Ce que ça signifie

Le glossaire WAI [WAIGlossary] définit un élément non textuel comme étant du contenu non textuel.

Le chargement d'images vers un appareil mobile augmente le temps pour afficher l'image et le coût d'affichage de la page. Rendre la page lisible en mode texte seul peut aider l'utilisateur à en évaluer l'utilité avant que les images n'arrivent.

Beaucoup d'appareils mobiles ne gèrent pas les objets incorporés ou les scripts, et très souvent, les utilisateurs n'ont aucune latitude de charger des modules d'extension (plug-ins) afin de les gérer. Le contenu doit être conçu dans cette perspective.

Même lorsqu'un appareil gère les scripts, ne pas en utiliser sauf s'il n'y a pas d'autre moyen d'accomplir ses objectifs. Les scripts consomment de l'énergie et donc diminuent la durée de vie des piles.

5.4.5.2 Ce qu'il faut faire

Concevoir des pages qui soient utiles rendues en mode texte seul. Cf. également la section 5.1.4 Tester.

Toujours utiliser les fonctionnalités du balisage prévues pour le soutien d'autres rendus telles que les attributs longdesc et alt en XHTML.

Utiliser seulement les fonctionnalités du balisage réputées gérées par l'appareil en question.

Éviter les choses telles que le remplacement d'image CSS et les mots sous forme d'image.

Avec les scripts, ne pas utiliser les déclencheurs (triggers) onmouse et onkey ; utiliser onclick.

5.4.5.3 Ce qu'il faut tester

NON-TEXT_ALTERNATIVES Test machine : Tester la présence d'un at tribut alt sur les images et d'un contenu textuel sur les objets.

Test humain : Vérifier la pertinence du contenu des attributs alt.

OBJECTS_OR_SCRIPT Test machine : Tester la présence d'éléments object ou script dans le contenu livré à un appareil qui ne les gère pas, et s'ils sont présents, effectuer le test humain suivant.

Test humain : Si présents, vérifier que l'expérience d'utilisateur soit acceptable.

5.4.5.4 Références

Cette pratique se rattache aux points de contrôle 1.1, 3.1, 6.2, 6.3, 6.5 et 9.2 du WCAG.

5.4.6 Taille de l'image

[IMAGES_SPECIFY_SIZE] Indiquer la dimension des images dans le balisage, si celles-ci ont une dimension intrinsèque.

[IMAGES_RESIZING] Redimensionner les images sur le serveur, si celles-ci ont une dimension intrinsèque.

5.4.6.1 Ce que ça signifie

Les images telles que les images en mode point (bitmaps) ont une dimension intrinsèque. Annoncer à l'avance la dimension de l'image au navigateur lui évite de rafraîchir la page lorsqu'il la reçoit. Redimensionner les images sur le serveur réduit la quantité des données transférées et la quantité des traitements à effectuer par l'appareil pour redimensionner (scale) l'image.

Noter que cette recommandation contraste avec la section 5.4.8 Mesures, laquelle recommande d'employer des mesures relatives là où c'est possible.

5.4.6.2 Ce qu'il faut tester

IMAGES_SPECIFY_SIZE Test machine : Tester la présence d'attributs width et height sur les éléments img.

IMAGES_RESIZING Test machine : Vérifier que les attributs width et height correspondent aux dimensions de l'image.

5.4.7 Balisage valide

[VALID_MARKUP] Créer des documents qui se valident auprès de grammaires formelles publiées.

5.4.7.1 Ce que ça signifie

Si le balisage de la page est invalide, cela aboutira à une présentation imprévisible, éventuellement incomplète.

5.4.7.2 Ce qu'il faut tester

Test machine : Valider les documents.

5.4.7.3 Références

Cette pratique se rattache aux points de contrôle 3.2, 11.1 et 11.2 du WCAG.

Cf. http://www.w3.org/QA/Tools/#validators.

5.4.8 Mesures

[MEASURES] Ne pas utiliser de dimensions en pixels ni d'unités absolues pour les valeurs des attributs du langage de balisage et celles des propriétés de feuille de style.

5.4.8.1 Ce que ça signifie

Éviter les mesures en pixels et les mesures absolues permet au navigateur d'adapter le contenu pour le loger à l'écran. L'exception à la règle est celle où une image aura été dimensionnée spécifiquement pour un écran particulier (cf. la section 5.4.6 Taille de l'image). Auquel cas, les références à l'image dans le balisage peuvent spécifier les dimensions exactes de l'image en pixels, afin d'aider le navigateur à dessiner (flow) la page et d'éviter son rafraîchissement après que la page aura été récupérée. Les appareils exécuteront peut-être plus précisément les intentions des auteurs si les marges, les bordures et l'espacement (padding) sont spécifiés en pixels.

5.4.8.2 Ce qu'il faut faire

Utiliser des mesures en pourcentages et relatives telles que em, ex, bolder, larger et thick.

5.4.8.3 Ce qu'il faut tester

Test machine : Envoyer une requête auprès du site avec un appareil qui gère correctement les mesures relatives, et vérifier que les valeurs des propriétés font-size ne sont pas absolues ni en pixels.

5.4.9 Feuilles de style

[STYLE_SHEETS_USE] Utiliser des feuilles de style pour contrôler la mise en pages et la présentation, sauf si l'appareil est réputé ne pas les gérer.

[STYLE_SHEETS_SUPPORT] Organiser les documents afin de pouvoir les lire sans feuille de style si nécessaire.

[STYLE_SHEETS_SIZE] Réduire les feuilles de style.

5.4.9.1 Ce que ça signifie

L'information de style peut être contenue dans une feuille de style extérieure liée ou, en HTML, être contenue dans un élément style ou dans l'attribut style sur des éléments spécifiques.

Les appareils mobiles soutiennent diversement les feuilles de style. Certains pourvoient des mises en œuvre complètes, y compris la mise en cache des feuilles de style externes, certains ne mettent pas en cache les feuilles de style externes, certains ne gèrent pas l'élément style ; certaines implémentations ne gèrent pas plus d'une feuille de style et d'autres pas de feuille de style du tout.

Si l'interprétation des feuilles de style est désactivée ou si elles ne sont pas gérées, le contenu sera rendu dans l'ordre du document, il importe donc que le contenu ait du sens, lu dans l'ordre du document.

5.4.9.2 Ce qu'il faut faire

Il est préférable de mettre en commun l'information de style entre les pages, mais si l'appareil ne gère pas la mise en cache des feuilles de style, alors cette approche se traduira par la récupération de la même feuille de style avec chaque page. Par conséquent, en ordre de préférence : si l'appareil met en cache les feuilles de style, placer l'information de style dans une seule feuille de style externe (cf. également la section 5.2.9 Ressources extérieures liées) ; si l'appareil gère l'élément style, l'utiliser ; sinon utiliser une feuille de style externe.

Optimiser l'information de style afin que seuls soient inclus les styles utilisés.

Pour la création des feuilles de style, profiter des types de média CSS (lesquels peuvent être utilisés à la fois dans la règle CSS @media et dans l'attribut media de l'élément link) pour spécifier les styles qui s'appliquent au rendu portable (handheld). Les types de média qui s'appliquent sont "handheld" et "all". Faute de spécification d'un rendu portable, les navigateurs peuvent charger d'autres feuilles de style même si celles-si sont identifiées comme applicables à un rendu non portable.

5.4.9.3 Ce qu'il faut tester

STYLE_SHEETS_USE Test machine : Envoyer une requête auprès du site avec un appareil qui gère les feuilles de style CSS et vérifier que les feuilles de style soient bien utilisées et que la page n'emploie pas de balises de formatage (par exemple font).

STYLE_SHEETS_SUPPORT Test humain : Désactiver les feuilles de style et vérifier que la page soit encore lisible.

STYLE_SHEETS_SIZE Test machine : Vérifier que les éléments de la feuille de style soient bien utilisés dans au moins l'une des pages qui l'appellent.

5.4.9.4 Références

Cette pratique se rattache aux points de contrôle 3.3 et 6.1 du WCAG

5.4.10 Réduire

[MINIMIZE] Utiliser du balisage concis et efficace.

5.4.10.1 Ce que ça signifie

Un contenu qui est balisé dans des langages tels que XML peut souvent être réduit tout en conservant exactement la même sémantique juste en supprimant les blancs redondants (c'est-à-dire les caractères espace et saut de ligne).

Le balisage des fontes, des couleurs et autres effets de style dans le texte (in-line) peut accroître considérablement la taille par rapport à l'utilisation d'un balisage logique et de l'attribut HTML class pour l'application du style (cf. également la section 5.4.9 Feuilles de style).

5.4.10.2 Ce qu'il faut faire

Bien que l'intention ne soit pas que les auteurs créent leurs contenus sur une seule ligne pour en supprimer entièrement les caractères blancs, on leur suggère de ne pas contribuer à l'alourdissement des pages en introduisant inutilement des blancs. Noter que l'« édition conviviale » (le formatage du balisage à l'aide d'une indentation) peut générer une grande quantité de caractères blancs et donc ajouter au poids de la page.

Si l'« édition conviviale » est une partie importante du processus de création, alors essayer de faire que les caractères blancs redondants soient supprimés pour le service de la page.

Même si certains serveurs mandataires de réseau suppriment les caractères blancs jugés redondants, ce n'est pas le cas pour tous, et une bonne pratique est de ne pas compter sur un tel comportement.

L'utilisation d'un balisage structurel (cf. la section 5.4.3 Éléments structuraux) contribue à réduire la taille du balisage d'une page, tout comme la centralisation des descriptions de style avec CSS [CSS].

5.4.10.3 Ce qu'il faut tester

Test machine : Faire un compte des caractères blancs non significatifs dans le document.

5.4.11 Types de contenu

[CONTENT_FORMAT_SUPPORT] Envoyer le contenu dans un format réputé géré par l'appareil.

[CONTENT_FORMAT_PREFERRED] Envoyer, si possible, le contenu au format préféré.

5.4.11.1 Ce que ça signifie

Transférer du contenu qu'un appareil ne peut pas afficher gaspille le temps et l'argent de l'utilisateur. L'appareil peut exprimer une préférence pour des formats. Auquel cas, une bonne pratique est de respecter les préférences de l'appareil, puisque son implémentation de ces formats sera plus complète.

5.4.11.2 Ce qu'il faut faire

Afin de déterminer les formats gérés par un appareil, les sites web peuvent utiliser toute combinaison de données de profil d'appareil telles que l'en-tête HTTP User-Agent, les en-têtes HTTP Accept et le profil UAProf.

L'utilisation d'une approche à l'exclusion des autres peut poser des problèmes. Voici quelques problèmes notés par le groupe de travail Best Practices :

  • Certains appareils ne fournissent pas d'en-têtes Accept ;

  • Certains appareils présentent mal leurs capacités ;

  • Certaines passerelles d'opérateur complètent les en-têtes Accept pour y inclure des formats qu'elles adaptent ;

  • Les en-têtes des agents utilisateurs n'identifient pas toujours systématiquement (uniquely) l'appareil ;

  • L'information UAProf peut manquer ou être incomplète.

5.4.11.3 Ce qu'il faut tester

CONTENT_FORMAT_SUPPORT Test machine : Vérifier les types MIME du contenu avec divers appareils.

CONTENT_FORMAT_PREFERRED Test machine : Vérifier les types MIME du contenu avec divers appareils et vérifier que le format préféré soit envoyé, ou qu'il soit compatible avec le contexte de livraison par défaut.

5.4.12 Codage des caractères

[CHARACTER_ENCODING_SUPPORT] Vérifier que le codage des caractères du contenu soit géré par l'appareil.

[CHARACTER_ENCODING_USE] Indiquer le codage des caractères utilisé dans la réponse.

5.4.12.1 Ce que ça signifie

Comme dans la section précédente, on ne devrait pas envoyer à un appareil un contenu qu'il ne saurait utiliser.

5.4.12.2 Ce qu'il faut faire

Les codages de caractères gérés par un appareil peuvent être obtenus soit auprès du profil de l'appareil, soit en examinant la valeur de l'en-tête HTTP Accept-Charset.

Le codage des caractères utilisé dans une réponse peut être indiqué avec l'en-tête HTTP Content-Type.

Exemple :
Content-Type: text/html; charset=utf-8

Le codage des caractères des documents XML [XML] peut en outre être indiqué dans la déclaration de codage, quoiqu'elle soit généralement ignorée en présence d'une en-tête HTTP Content-Type.

Exemple :
<?xml version="1.0" encoding="UTF-8"?>

Le codage du contenu vers un codage de caractères désiré dépend des outils de création employés, de la configuration du serveur web et de la technologie de script côté serveur utilisée (le cas échéant). Cf. [CHARSET1] et [CHARSET2] pour une explication.

Unicode est un bon choix pour représenter du contenu qui est servi dans plusieurs langues. La quantité de bande passante nécessaire pour transmettre le contenu varie beaucoup selon le codage des caractères employé. Un texte composé principalement de caractères de l'alphabet Latin se codera plus efficacement en UTF-8, tandis qu'un autre composé principalement de caractères d'écritures idéographiques se codera plus efficacement en UTF-16. Pour le choix d'un codage de caractères, considérer l'efficacité des codages disponibles.

Puisque le contexte de livraison par défaut spécifie seulement l'utilisation d'UTF-8, toutes les applications devraient gérer UTF-8.

5.4.12.3 Ce qu'il faut tester

Test machine : Vérifier que le codage soit déclaré d'une façon ou d'une autre et qu'il soit géré. Le type de contenu peut être déclaré à l'aide d'une ou de plusieurs façons suivantes : l'en-tête HTTP Content-Type, la déclaration XML du contenu fondé sur XML, la règle CSS @charset pour les feuilles de style, l'élément de métadonnées Content-Type pour un contenu HTML.

5.4.12.4 Références

Cf. la section Codage des caractères dans les entités [XML] pour une explication du codage des caractères dans les documents XML.

5.4.13 Messages d'erreurs

[ERROR_MESSAGES] Fournir des messages d'erreurs informatifs et un moyen de retourner du message d'erreur à l'information utile.

5.4.13.1 Ce que ça signifie

Il est inévitable qu'en certaines occasions un utilisateur de mobile ne réussisse pas à accéder au contenu ou à l'information recherchés. Fournir une navigation facile pour sortir de l'erreur est particulièrement important dans l'arène du mobile, où les navigateurs n'auront peut-être pas de bouton « arrière » qui tombe sous la main, où la contextualisation est souvent difficile et où la resaisie d'adresses URI comme moyen de récupérer d'une erreur est particulièrement ardue.

Les erreurs dues au réseau, à la connexion et à la mauvaise saisie des adresses URI sont réputées hors du contrôle du fournisseur de contenus, qui n'a aucun moyen d'agir sur la façon de présenter de telles erreurs à l'utilisateur. En revanche, lorsque le fournisseur de contenus maîtrise les erreurs, l'utilisateur devrait recevoir une information claire concernant le défaut rencontré. Elle devrait l'aider à comprendre si le défaut est temporaire ou permanent, s'il devrait refaire une tentative pour accéder au contenu et comment surmonter le problème.

L'utilisateur devrait également avoir la possibilité d'échapper à la condition d'erreur. Il devrait pouvoir soit retourner à la page d'avant l'erreur, soit continuer vers une partie commode du service d'où il pourra réitérer ou modifier la transaction qui était entreprise.

5.4.13.2 Ce qu'il faut faire

Beaucoup de serveurs web sont réputés fournir une page d'erreur par défaut, en particulier en cas de demande d'une page inexistante (404) ou en cas d'erreur interne (500). Là où c'est possible (cf. [TOMCAT], [APACHE] et [IIS]), les applications devraient capturer toutes les conditions d'erreur en remplaçant si nécessaire les pages par défaut et en les traitant de manière conviviale et gracieuse.

Les messages d'erreur devraient être dans la même langue que celle de l'application utilisée. Ils devraient être clairs et concis, en adhérant aux mêmes pratiques exemplaires que le reste de l'application. Ils devraient être fournis dans un format accepté par l'appareil.

Le message d'erreur devrait préciser si le problème est vraisemblablement temporaire ou permanent, si l'utilisateur peut le résoudre tout seul (par exemple, en modifiant les données d'entrée ou un réglage de l'appareil), ou si ce problème peut être signalé au fournisseur de contenus ou à l'opérateur du réseau. Dans ce dernier cas, des coordonnées, telles qu'une adresse SMS ou un numéro de support technique, seraient appropriées.

Le message d'erreur devrait fournir une ou plusieurs constructions de navigation suivantes :

  1. Un lien « retour » vers la page précédente (en particulier pour les appareils qui n'ont pas de bouton retour très accessible) ;

  2. Un lien « recommencer » pour reprendre la partie pertinente de la transaction (notez que cela n'est pas un rafraîchissement de la page) ;

  3. Un lien « accueil » afin que l'utilisateur puisse retourner à la partie principale de l'application.

Le message d'erreur peut fournir un code d'erreur utilisable pour le diagnostic du problème. Toutefois, l'utilisation d'un code d'erreur ne dispense pas de fournir un message intelligible. Même si quelques utilisateurs comprendront qu'un code "404" indique une page introuvable, on ne doit pas supposer que c'est le cas pour tous.

5.4.13.3 Ce qu'il faut tester

Entrer une adresse URI de l'extérieur, qui ne représente pas une ressource réelle sur le site, et vérifier que la réponse d'erreur HTTP 404 soit accompagnée d'une page dont le balisage est approprié pour l'appareil requérant, ou le contexte par défaut.

Test humain : Vérifier que la page retournée contienne une explication de l'erreur et des actions correctives appropriées, sans présupposer un quelconque savoir technique de la part de l'utilisateur final.

5.4.14 Cookies

[COOKIES] Ne pas compter sur la disponibilité de cookies.

5.4.14.1 Ce que ça signifie

Les cookies sont fréquemment employés pour effectuer une gestion de la session, pour identifier les utilisateurs et pour enregistrer les préférences des utilisateurs. Beaucoup d'appareils mobiles ne gèrent pas les cookies ou n'offrent qu'une mise en œuvre incomplète. De plus, certaines passerelles suppriment les cookies et d'autres les simulent pour le compte des appareils mobiles.

5.4.14.2 Ce qu'il faut faire

Tester que les cookies soient gérés par l'appareil sur son chemin d'accès courant. S'ils ne sont pas gérés, utiliser une décoration URI pour la gestion des sessions, en faisant attention de ne pas excéder la longueur maximale admise par l'appareil pour de telles chaînes. Certaines passerelles permettent une identification de l'utilisateur sans cookies.

5.4.14.3 Ce qu'il faut tester

Test machine : Vérifier qu'une alternative aux cookies soit utilisée pour la gestion des sessions lorsque ceux-ci ne sont pas disponibles.

5.4.15 En-têtes de mise en cache

[CACHING] Fournir une information de mise en cache dans les réponses HTTP.

5.4.15.1 Ce que ça signifie

Une bande passante limitée et une latence élevée peuvent nuire à la facilité d'utilisation des sites web sur les appareils mobiles. L'utilisation efficace de l'information de mise en cache (caching) peut réduire le besoin de rechargement des données telles que feuilles de style, images et pages, améliorant ainsi les performances et réduisant les coûts d'utilisation. Elle peut également empêcher la réutilisation d'un contenu non approprié, par exemple le contenu adapté pour un appareil donné ne devrait pas être réutilisé par d'autres appareils. Les caches des appareils et du réseau sont tous affectés par l'information de mise en cache.

5.4.15.2 Ce qu'il faut faire

Fixer des dates d'expiration qui soient appropriées pour l'application. Penser à utiliser Cache-Control: public afin de permettre le partage des pages entre les appareils, Cache-Control: private afin de permettre une réutilisation mais seulement pour l'appareil requérant et Cache-Control: nocache afin d'empêcher la mise en cache.

La spécification HTTP 1.1 [HTTP1.1] et le document des techniques [Techniques] contiennent des explications sur la mise en cache.

5.4.15.3 Ce qu'il faut tester

Test machine : Vérifier la présence des en-têtes de mise en cache dans la réponse HTTP.

5.4.15.4 Références

La section 13 Mise en cache dans HTTP de la spécification [HTTP1.1] traite de la mise en cache.

5.4.16 Fontes

[FONTS] Ne pas compter sur la gestion d'un style lié à une fonte.

5.4.16.1 Ce que ça signifie

Les appareils mobiles ont souvent peu de fontes et un soutien limité de leurs corps et styles (gras, italique, etc.). En conséquence de quoi, l'utilisation du corps, du dessin ou du style d'une fonte, par exemple pour mettre en exergue une réponse ou accentuer un mot, n'aura pas toujours l'effet escompté. Cf. également la section 5.4.3 Éléments structuraux.

5.4.16.2 Ce qu'il faut faire

Pour le contexte de livraison par défaut, ne pas employer de style lié à une fonte.

5.4.16.3 Ce qu'il faut tester

Test machine : Vérifier la présence d'un style lié à une fonte dans un environnement qui ne le gère pas.

Test humain : Si présent, s'assurer que les intentions de l'auteur restent claires.

5.5 Entrée de l'utilisateur

Cette section contient des formules en rapport avec les entrées de l'utilisateur. La saisie est typiquement plus restrictive sur les appareils mobiles que sur les ordinateurs de bureau (et souvent beaucoup plus restrictive). Par exemple, les appareils mobiles peuvent manquer d'un dispositif de pointage et n'auront souvent pas un clavier standard pour la saisie du texte.

5.5.1 Saisie

[MINIMIZE_KEYSTROKES] Réduire au minimum le nombre des touches pressées.

[AVOID_FREE_TEXT] Éviter si possible la saisie de texte libre.

[PROVIDE_DEFAULTS] Fournir si possible des valeurs par défaut présélectionnées.

[DEFAULT_INPUT_MODE] Spécifier un mode de saisie du texte, une langue ou un format d'entrée par défaut, si l'appareil est réputé les gérer.

5.5.1.1 Ce que ça signifie

Au vu des limitations typiques de la saisie sur un appareil mobile, l'interface doit réduire autant que possible la saisie de l'utilisateur. Là où c'est possible, utiliser des listes de sélection, des boutons radios et d'autres commandes qui ne nécessitent aucune saisie.

Quelques langages de balisage permettent la spécification d'un mode de saisie, qui est particulièrement utile dans les cas où la saisie d'utilisateur doit être restreinte, par exemple seulement aux chiffres. Il est prévu que XHTML Basic [XHTML-Basic] gère cette fonctionnalité dans le futur.

5.5.1.2 Ce qu'il faut faire

Plusieurs techniques sont disponibles dans ce but, dont :

  • Là où c'est possible, utiliser les saisies précédentes comme valeurs par défaut ;

  • Permettre la sélection des éléments en utilisant les touches de navigation ou des chiffres.

5.5.1.3 Ce qu'il faut tester

AVOID_FREE_TEXT Test machine : Vérifier si input type="text" et textarea sont utilisés.

Test humain : Si présence de l'un, vérifier qu'une entrée prédéterminée puisse s'y substituer.

PROVIDE_DEFAULTS Test machine : Vérifier l'existence d'une valeur présélectionnée dans les commandes (attributs selected ou checked présents).

Test humain : Sinon vérifier qu'il puisse y avoir une présélection pertinente dans le contexte (par exemple, le choix le plus courant).

DEFAULT_INPUT_MODE Test machine : Envoyer une requête avec un appareil réputé gérer l'attribut inputmode et si la réponse est dans un langage qui soutient cet attribut, vérifier qu'il soit présent sur les éléments input type="text" et textarea.

5.5.1.4 Références

Cette pratique se rattache au point de contrôle 10.4 du WCAG.

5.5.2 Ordre de tabulation

[TAB_ORDER] Créer un ordre logique à travers les liens, les commandes de formulaire et les objets.

5.5.2.1 Ce que ça signifie

Au fur et à mesure que l'utilisateur navigue à travers la page, il importe que les divers champs et objets se présentent dans un ordre logique, surtout que plusieurs d'entre eux ne seront pas visibles en même temps que l'élément ciblé (focus item).

5.5.2.2 Ce qu'il faut faire

Utiliser l'ordre du document pour contrôler la mise en pages et l'ordre de tabulation.

5.5.2.3 Ce qu'il faut tester

Test machine : Vérifier qu'il n'y ait pas d'attributs tabindex ou d'effets de mise en pages qui affectent l'ordre de présentation.

S'il y a des attributs tabindex, vérifier que toutes les commandes aient un index de tabulation utilisé logiquement.

Test humain : Si des attributs tabindex ou bien des effets de mise en pages affectaient l'ordre de présentation, alors vérifier que l'ordre soit utilisable.

5.5.3 Étiquettes des commandes de formulaire

[CONTROL_LABELLING] Étiqueter toutes les commandes de formulaire de manière appropriée et associer explicitement les étiquettes aux commandes de formulaire.

[CONTROL_POSITION] Positionner les étiquettes en bonne place vis-à-vis des commandes de formulaire auxquelles elles se rapportent.

5.5.3.1 Ce que ça signifie

Utiliser l'élément label en HTML, ou son équivalent dans d'autres langages. S'assurer que la place de l'étiquette soit logique et proche de la commande de formulaire (form control), afin que le rafraîchissement ou l'adaptation intelligente du contenu reconnaissent toujours les commandes des étiquettes et les gardent ensemble.

5.5.3.2 Ce qu'il faut tester

Test machine : Vérifier que l'élément label soit employé dans les formulaires.

Test humain : Vérifier si les étiquettes sont correctement positionnées par rapport aux commandes.

5.5.3.3 Références

Cette pratique se rattache aux points de contrôle 10.2 et 12.4 du WCAG.

6 Conformité et mobileOK

Les formules de pratique exemplaire sont conçues afin que l'on puisse construire des déclarations de conformité autour d'elles en soutien du label mobileOK et pour d'autres besoins. Les travaux sur le label mobileOK élaboreront des exigences recommandées propres à un label, lequel sera fondé sur un profil, ou un sous-ensemble, des formules dans ce document-ci.

En tant que tel, le label mobileOK fera office de revendication de conformité principale du document des pratiques exemplaires.

Toutes les formules de pratique exemplaire possèdent un identificateur de fragment qui permet de les citer formellement et de construire les revendications de conformité qui s'y rapportent.

6.1 Classes des produits

Cette spécification s'applique à une seule classe de produit : le contenu livré à un appareil mobile, y compris les métadonnées transférées sous les hospices du protocole de livraison.

6.2 Extensibilité

Cette spécification peut être compatible avec d'autres spécifications qui décrivent un ensemble différent d'exigences pour le contenu, tant que ces exigences ne contredisent pas cette spécification-ci.

A Sources (non normatif)

Les formules des pratiques exemplaires ont été élaborées par le groupe de travail Best Practices (BPWG) à partir de nombreuses sources. Ce sont principalement :

Bien que les formules des pratiques exemplaires aient été élaborées par des travaux secondaires (secondary research), les sources de ces travaux ont pour la plupart été assemblées à partir de travaux initiaux (primary research). En outre, les contributions des membres du groupe ont été alimentées dans une certaine mesure par des travaux initiaux entrepris par leur société.

Les lecteurs intéressés par le sujet de ce document le seront aussi par diverses publications. Comme indiqué plus haut dans le paragraphe à propos de la portée, les thèmes tels que l'internationalisation et l'accessibilité ont été étudiés séparément par le W3C et ne sont pas couverts ici.

Le modèle de caractères pour le Web et les autres documents élaborés par l'activité Internationalization (i18n) du W3C couvrent des facteurs (drivers) d'interopérabilité importants pour du contenu préparé pour l'« un seul Web » et l'arène des services mobiles.

L'initiative pour l'accessibilité du Web (Web Accessibility Initiative) a élaboré diverses directives et techniques qui portent également sur la préparation et le traitement du contenu dans et pour le Web.

La section 3.2 Arrière-plan de l'adaptation plus haut introduisait l'idée d'une adaptation du contenu. Les lecteurs qui envisagent la mise en œuvre d'une adaptation côté serveur s'intéresseront aux travaux en cours de l'activité Device Independence.

C Remerciements (non normatif)

Les rédacteurs voudraient remercier les membres du BPWG pour leurs diverses collaborations. Ils voudraient aussi remercier les collaborateurs de la liste publique et ceux de la version en dernier appel, dont les commentaires ont été pris en compte pour la création de ce document.

Les rédacteurs reconnaissent les contributions écrites importantes des personnes suivantes :

D Références (non normatif)

D.1 Références MWI

Scope
Portée des pratiques exemplaires du Web mobile, Phil Archer, Ed Mitukiewicz, rédacteurs, note de groupe de travail du W3C, 20 décembre 2005 (cf. http://www.w3.org/TR/2005/NOTE-mobile-bp-scope-20051220/)
Techniques
Techniques du Web mobile des pratiques exemplaires (en développement) (cf. http://www.w3.org/2005/MWI/BPWG/techs/TechniquesIntro)
mobileOK
Tests de base mobileOK 1.0, Sean Owen, Jo Rabin, rédacteurs, version préliminaire du W3C, 10 juin 2008 (cf. http://www.w3.org/TR/2008/WD-mobileOK-basic10-tests-20080610/)

D.2 Sources

WCAG
Directives pour l'accessibilité du contenu web 1.0, W Chisholm, I. Jacobs, G Vanderheiden, rédacteurs, recommandation du W3C, 5 mai 1999 (cf. http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/)
WAIGlossary
Glossaire WAI (imprimable), Katie Haritos-Shea, Charles McCathieNevile, version préliminaire interne, 1 mars 2003 (cf. http://www.w3.org/WAI/GL/Glossary/)
iMode
iMode (cf. http://www.iMode.nl/pdf/download/How_to_create_an_i-mode_site_1_3.pdf)
Opera
Document Opera intitulé Making Small Devices Look Great (cf. http://dev.opera.com/articles/view/making-small-devices-look-great/)
OpenWave
Openwave (cf. http://developer.openwave.com/dvl/support/documentation/guides_and_references/best_practices_in_xhtml_design/index.htm)
Nokia-MP
Directives Nokia du XHTML-MP sur la série 60 (cf. http://sw.nokia.com/id/4f7b6805-47d7-4914-885c-6ef2b487adf6/Series_60_Platform_Designing_XHTML_MP_Content_v1_4_en.pdf)
Nokia-VR
Browsing on Mobile Phones, article de Virpi Roto, Nokia (cf. http://www.research.att.com/~rjana/WF12_Paper1.pdf)
LSD
Little Spring Design (cf. http://patterns.littlespringsdesign.com/index.php/Main_Page)

D.3 Indépendance par rapport aux appareils

DIP
Principes de l'indépendance par rapport aux appareils, R. Gimson, rédacteur, note de groupe de travail du W3C, 1 septembre 2003 (cf. http://www.w3.org/TR/2003/NOTE-di-princ-20030901/)
DCODI
Vue d'ensemble du contexte de livraision pour l'indépendance par rapport aux appareils, R. Gimson, R. Lewis, S. Sathish, rédacteurs, note de groupe de travail du W3C, 20 mars 2006 (cf. http://www.w3.org/TR/2006/NOTE-di-dco-20060320/)
DIGLOSS
Glossaire des termes de l'indépendance par rapport aux appareils, R. Lewis, rédacteur, version préliminaire du W3C (travail en cours), 18 janvier 2005 (cf. http://www.w3.org/TR/2005/WD-di-gloss-20050118/)

D.4 Web, protocoles et langages

WebArch
Architecture du Web tome 1, N. Walsh, I. Jacobs, rédacteurs, recommandation du W3C, 15 décembre 2004 (cf. http://www.w3.org/TR/2004/REC-webarch-20041215/)
XML
Langage de balisage extensible (XML) 1.0 (quatrième édition), Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau, rédacteurs, recommandation du W3C, 16 août 2006, édité par endroits le 29 septembre 2006 (cf. http://www.w3.org/TR/2006/REC-xml-20060816/)
XHTML-Basic
XHTML™ Basic 1.1, Shane McCarron, Masayasu Ishikawa, rédacteurs, recommandation du W3C, 29 juillet 2008 (cf. http://www.w3.org/TR/2008/REC-xhtml-basic-20080729/)
CSS
Spécification des feuilles de style en cascade niveau 1 (CSS1), Håkon Wium Lie, Bert Bos, rédacteurs, recommandation du W3C, 11 janvier 1999 (cf. http://www.w3.org/TR/1999/REC-CSS1-19990111)
CSS2
Spécification des feuilles en cascade niveau 2 (CSS2), Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs, rédacteurs, recommandatin du W3C, 12 mai 1998 (cf. http://www.w3.org/TR/1998/REC-CSS2-19980512/)
HTTP1.0
RFC 1945 — Protocole de transfert hypertexte HTTP/1.0, T. Berners-Lee, R. Fielding, H. Frystyk, mai 1996 (cf. http://www.w3.org/Protocols/rfc1945/rfc1945)
HTTP1.1
RFC 2616 — Protocole de transfert hypertexte HTTP/1.1, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, juin 1999 (cf. http://www.w3.org/Protocols/rfc2616/rfc2616.html)
UTF-8
RFC 3629 — UTF-8, un format de transformation d'ISO 10646, F. Yergeau, novembre 2003 (cf. http://www.ietf.org/rfc/rfc3629.txt)
CHARSET1
Tutorial : Jeux de caractères et codages en XHTML, HTML et CSS (cf. http://www.w3.org/International/tutorials/tutorial-char-enc/)
CHARSET2
FAQ : Établir le codage dans les applications de création Web (cf. http://www.w3.org/International/questions/qa-setting-encoding-in-applications)

D.5 Autres références

UAPROF
Open Mobile Alliance OMA-TS-UAProf-V2_0-20060206-A User Agent Profile Approved Version 2.0, 6 février 2006 (cf. http://www.openmobilealliance.org/technical/release_program/docs/UAProf/V2_0-20060206-A/OMA-TS-UAProf-V2_0-20060206-A.pdf)
TOMCAT
Tomcat FAQ How do I get a customized error page? (cf. http://wiki.apache.org/tomcat/FAQ/Miscellaneous)
APACHE
Apache Core Features ErrorDocument directive (cf. http://httpd.apache.org/docs/1.3/mod/core.html#errordocument)
IIS
IIS Custom HTTP Error Messages (cf. http://msdn.microsoft.com/en-us/library/ms525983.aspx)
T-MOB
T-Mobile International - Position Statement for W3C Mobile Web Initiative Version: 1.0, 18 décembre 2004 (cf. http://www.w3.org/2004/10/MWIWS-papers/W3C_Mobile_Web_Initiative_-_T-Mobile_Position_Statement-final.pdf)
MF
Study by Segala M Test on Scrolling vs. Pagination (cf. http://www.mobilefriendly.org)