La version française de cette traduction est :
http://www.la-grange.net/w3c/cuap/
Traducteur : Karl Dubost - <karl+misc@la-grange.net>
La version française peut contenir des erreurs. La version anglaise de cette note est l'unique version
normative. Version originale : http://www.w3.org/TR/2001/NOTE-cuap-20010206
Copyright © 2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
Ce document explique les erreurs communes dans les agents utilisateurs dues à une implémentation incorrecte ou incomplète des spécifications, et suggère des solutions. Il suggère également le "bon comportement" lorsque les spécifications elles-même ne préconisent aucun comportement particulier (par exemple, dans le cas d'erreurs). Ce document n'est pas un ensemble complet de règles pour le bon comportement des agents utilisateurs.
Note : Ce document n'incrimine aucun agent utilisateur spécifique. Le W3C ne trace généralement pas les bogues ou les erreurs des implémentations. Cette information est généralement maintenue par les fabricants eux-mêmes ou par de tierces parties.
Ce document est une Note mise à disposition par le W3C pour discussion uniquement. Le publication de cette Note par le W3C n'entraîne aucunement la responsabilité du W3C, ou de l'équipe du W3C, ou d'aucun membres. Le W3C n'a aucune obligation d'attribuer des ressources supplémentaires aux sujets traités par cette Note.
Les auteurs ont mis à disposition ce document pour information uniquement. Bien que les auteurs invitent aux commentaires sur ce document, ils ne garantissent pas de réponses ou de réactions. Envoyez vos commentaires à www-talk@w3.org; Les archives publiques sont disponibles.
Une liste des publications et rapports techniques du W3C, y compris les brouillons de travail et les Notes peut être trouvée à http://www.w3.org/TR/.
Ce document explique les erreurs les plus courantes dans les agents utilisateurs dues à une implémentation incorrecte ou incomplète des spécifications, et suggère des solutions. Il suggère également le "bon comportement" lorsque les spécifications elles-même ne préconisent aucun comportement particulier (par exemple, dans le cas d'erreurs). Ce document n'est pas un ensemble complet de règles pour le bon comportement des agents utilisateurs.
Chaque suggestion de ce document, appelé un "point de contrôle" commence avec une description en une phrase du "bon comportement". Les points de contrôle comprennent également des raisonnements, des exemples, et des références. Les points de contrôle ne sont pas ordonnés par ordre d'importance. Ils ne sont pas listés dans un ordre particulier.
Ce document ne traite pas des problèmes d'accessibilité pour les agents utilisateurs. Voir les règles d'accessibilité des agents utilisateurs du W3C 1.0 [UAAG10] pour avoir de l'information sur la manière de concevoir des agents utilisateurs qui sont accessibles aux personnes handicapées.
Cette section se concentre sur l'expérience utilisateur, y compris le paramétrage, l'interface utilsateur, et autres problèmes d'ergonomie.
Techniques :
Il y a de nombreuses façons d'indiquer à un utilisateur qu'un lien est cassé. Le comportement recommandé est celui-ci :
Mauvais : Certains agents utilisateurs défilent au haut ou bas du document lorsque l'utilisateur suit un lien brisé. Ce comportement est déconseillé quand une cible est au début ou à la fin d'un document.
Références :
Les agents utilisateurs peuvent être dans l'impossibilité d'afficher certains types de contenu sur le web que ce soit de façon native ou par l'intermédiaire d'un plug-in (par exemple, du contenu XML, des feuilles de style XSLT, des documents RDF, des DTDs, des schémas XML, etc). Les agents utilisateurs devraient permettre aux utilisateurs de récupérer et de sauvegarder ces ressources, a contrario les utilisateurs seront dans l'incapacité totale d'accéder à ce contenu web.
La présentation du frameset pourrait être obtenue, par example, en :
Note : Les auteurs déconseillent l'utilisation des frames par les développeurs de contenu web car les frames peuvent poser de nombreux problèmes d'ergonomie et d'accessibilité.
Références :
Il est bon de permettre à l'utilisateur d'associer un programme externe avec un schème d'URI. L'agent utilisateur devrait informer l'utilisateur lorsqu'il ne reconnaît pas un schème d'URI dans le contenu.
Exemple :
Un utilisateur voudra peut-être ajouter le schème "tel" (par exemple,
tel:+33-4-12-34) afin de le renvoyer sur son téléphone. Ou l'utilisateur voudra peut-être que le schème "irc" (par exemple,
irc://irc.example.org/) lance un client IRC sur son bureau avec une connexion au serveur spécifié.
Mauvais : Certains agents utilisateurs ignorent la partie schème (avant le ":") lorsque le schème leur est inconnu, interprêtant les deux points comme s'ils étaient encodés sous la forme '%3A' et traitant alors l'URO comme si c'était une URI relative, résultant la plupart du temps en lien cassé (et donc pertubant l'utilisateur).
Références :
Une URI absolue contient le nom du schème utilisé suivi par une double ponctuation (":") et ensuite une chaîne de caractère dont l'interprêtation dépend du schème.
De nombreux agents utilisateurs compensent les URIs incomplètes en appliquant une série de transformations dans l'espoir de créer une URI qui fonctionne. Par exemple, beaucoup d'agents utilisateurs transforment la chaîne de caractères www.w3.org en URI http://www.w3.org/. L'utilisateur devrait être capable de contrôler si, par exemple, taper un mot clé devrait appeler un moteur de recherche ou bien si l'agent utilisateur devrait compléter le mot avec http://www. au début et ajouter .org/ à la fin.
Rendre un document incomplet de la même manière d'un document complet est déstabilisant pour les utilisateurs. Une partie du document manquant, certaines ancres ne peuvent pas être affichés, cassant probablement des liens. L'agent utilisateur devrait avertir l'utilisateur que le document est incomplet.
La spécification HTTP/1.1 décrit ce comportement pour les caches au niveau du protocoles. L'utilisateur devrait avoir un avertissement explicite pour toutes les réponses partielles.
Références :
Un cache NE DOIT PAS renvoyer une réponse partielle à un client sans indiquer explicitement ce dernier, en utilisant le code de statut 206 (Contenu Partiel). Un cache NE DOIT PAS renvoyer une réponse partielle en utilisant un code de statut 200 (OK).
De nombreux navigateurs permettent la sauvegarde des informations d'uathentification HTTP [RFC2616, RFC2617] ("se souvenir de mon mot de passe"). should also allow users to "flush" that authentication information on request. For instance, the user may wish to leave the user agent running but tell it to forget the password to access the user's bank account.
Mauvais : La plupart des agents utilisateurs considèrent que l'information d'authentification (par example, mot de passe) fournie par un utilisateur pour un couplet serveur/identification pendant une session est fixe pour toute la durée de la session.
Les métadonnées – données à propos des données – peuvent fournir une information contextuelle plus complète pour les ressources du web. par exemple, les métadonnées à propos d'un livre comprennent l'auteur du livre, le titre, la date de publication, l'éditeur, etc. (voir le Dublin Core [DC] pour en savoir plus sur les métadonnées de type bibliothécaire. Les auteurs placent des métadonnées dans les documents HTML grace à une variété d'éléments et d'attributs (par exemple, les éléments TITLE et ADDRESS, les attributs "alt", "title", et
"summary", etc. Les langages tels que Resource
Description Framework [RDF] permet aux utilisateurs
d'inséminer le web avec des métadonnées riches. Les agents utilisateurs devraient fournir une interface utilisateur pour permettre aux utilisateurs de voir les métadonnées. L'interface utilisateur peut varier en fonction du langage de balisage concerné. Par exemple, de nombreux navigateurs graphiques affichent l'attribut HTML "title" (par exemple, sous la forme d'une bulle) lorsque l'utilisateur sélectionne ou pointe un élément où cet attribut est spécifié.
Références :
Les utilisateurs peuvent vouloir tracer et archiver les requêtes HTTP POST pour les mêmes raisons que celles de vouloir tracer et conserver leur courrier électronique. Par exemple, si l'utilisateur commence un livre grâce à un formulaire, et que ce formulaire utilise une requête POST, l'utilisateur devrait être capable de stocker l'information concernant cette transaction.
Références :
Le protocole HTTP/1.1 [RFC2616] permet au client de demander une représentation d'une ressource la plus adaptée en fonction de ses besoins (langue, type de média, etc) ; ce mécanisme est appelé "négotiation de contenu".
Lorsqu'une ressource est négociée, l'utilisateur peut désirer mettre en signet une version particulière. Par exemple, un doument peut être disponible en plusieurs langues à la même URI., et l'utilisateur peut vouloir donner à quelqu'un l'URI de la version canadienne de ce document, qui possède une URI différente.
Dans un tel cas, il devrait être possible de mettre en signets aussi bien l'URI originale que l'URI désire voir. L'URI originale peut être interprêtée comme étant l'objet générique et le document reçu comme une vue possible de cet objet.
Références :
HTTP/1.1 [RFC2616] permet l'encodage de transfert. Un exemple d'encodage est la compression de données, qui améliore la vitesse de navigation lors de l'utilisation d'une connexion de faible bande passante.
L'agent utilisateur devrait permettre à l'utilisateur de paramétrer l'encodage de transfert pour les requêtes HTTP envoyées.
Références :
The user should be allowed to specify the set of languages that the user agent may use for language negotiation.
In case the user does not specify any language, the user agent may use the language of its user interface as the value sent out. The user agent should allow the user to override this behavior.
Références :
Accept-Language,
voir la section
14.4 de la spécification HTTP/1.1, [RFC2616].Accept-Language, voir la section
15.1.4 de la spécification HTTP/1.1, [RFC2616].Cette section insiste sur les questions concernant les feuilles de styles et les types de liens.
Une feuille de style est un ensemble de règles qui définit comment il doit être rendu sur l'écran d'un ordinateur graphique, sur le papier, aussi bien qu'un synthétiseur vocal, etc. Un document peut avoir plus d'une feuille de style associée, et les utilisateurs devraient avoir la possibilité de choisir entre les feuilles de style alternatives.
Références :
Certains lanagages de balisage et de feuilles de style permettent aux auteurs
(par exemple, la fonction @media dans [CSS2], l'attribut media dans [HTML 4.01]) de créer des documents qui sont rendus différemment en fonction des caractéristiques du matériel de sortie : que ce soit un affichage graphique, un écran de télévision, un synthétiseur vocal, un afficheur braille, etc.
Références :
Les utilisateurs doivent être capable de voir le contenu même sans les feuilles de style.
Mauvais : Dans certains agents utilisateur, les feuilles de style manquantes provoqueront une erreur fatale ou résulteront dans le non affichage du contenu.
Références :
Pour chaque document source, [un agent utilisateur] doit tenter d'obtenir les feuilles de style associées qui sont appropriées pour les types de média supportés. S'il ne peut obtenir aucune des feuilles de style associées (par exemple, à cause d'une erreur réseau, il doit afficher le document en utilisant celles qu'il a pu obtenir.
La section
6.12 de la recommandation HTML 4.01 [HTML 4.01] liste certains types de lien qui peuvent être utilisés afin de créer des relations à propos de ressources web liées. Ceci comprend alternate,
stylesheet, start, next, prev, contents, glossary, et d'autres.
Bien que la spécification HTML 4.01 ne spécifie aucun rendu ou comportement définitif pour ces types de liens, les agents utilisateurs devraient les interprêter d'une manière utile. Par exemple, les types de liens start,
next, prev, et contents peuvent être utilisés pour construire un sommaire, ou peuvent être utilisés pour identifier l'ordre d'impression de documents, etc.
Cette section se concentre sur l'implémentation des protocoles réseaux utilisés pour télécharger les ressources du web.
Le type de média d'une ressource obtenue par HTTP [RFC2616] est déterminé par le type de contenu et l'encodage retourné par le serveur dand les entêtes de réponse.
Si l'utilisateur veut sauvegarder une ressource localement, l'agent utilisateur devrait les conventions de nommage des fichiers. (par exemples les images PNG ont généralement pour extension un .png).
Exemple :
http://www.w3.org/TR/1999/REC-html401-19991224/html40.ps
est une vue de la version Postscript gzippée de la spécification HTML 4.01
specification. Les entêtes HTTP envoyées par le serveur comprennent :
Content-Type: application/postscript; qs=0.001 Content-Encoding: gzip
Dans le cas d'une sauvegarde locale, le nom du fichier sur la plupart des ordinateurs devrait être html40.ps.gz pour permettre aux applications de reconnaître le type du fichier.
Mauvais : Sauvegarder ce document PostScript compressé sous le nom html40.ps risque de pertuber les autres applications.
Références :
Content-Type.Exemple:
Si un document HTML est renvoyé avec un Content-Typedont la valeur est text/plain, l'agent utilisateur doit rendre le document comme un texte brut sans interprêter les éléments et les attributs HTML (c'est à dire le source HTML doit être affiché).
Référence :
Extrait de la section 7.2.1 la spécification HTTP/1.1, [RFC2616]:
Si et seulement si le type de média n'est pas donné par un champ Content-Type, le récipiendaire PEUT tenter de deviner le type de média par l'inspection de son contenu et/ou du nom de l'extension de l'URI utilisée pour identifier la ressource.
Les agents utilisateurs doivent respecter le jeu de caractères quand ce dernier est spécifié dans la réponse. Le jeu de caractères peut être donné par les entêtes HTTP Content-Type et/ou par les informations internes du document (élément HTML meta, etc).
Références :
Les récipiendaires HTTP/1.1 DOIVENT respecter l'étiquette charset fournie par l'expéditeur ; et les agents utilisateurs qui ont la capacité de "deviner" un charset DOIVENT utiliser le charset du champs
content-types'ils supportent ce charset [..].
Pour résumer, Les agents utilisateurs conformes doivent respecter les priorités suivantes lorsqu'ils déterminent l'encodage de caractère du document (de la prriorité la plus haute vers la plus basse) :
- Un paramètre HTTP "charset" dans un champs "
Content-Type".- Une déclaration META avec un "
http-equiv" contenant un "Content-Type" et une valeur donnée pour le "charset".- L'attribut charset fixé sur un élément désignant une ressource externe.
La spécification HTTP/1.1 [RFC2616] spécifie plusieurs types de redirections. Les deux plus courantes sont identifiées par les codes 301 (permanente) et 302 ou 307 (temporaire):
Mauvais : Les agents utilisateurs montrent généralement à l'utilisateur (par l'interface utilisateur) l'URI qui est le réseultat d'une redirection temporaire (302 ou 307), de la même façon qu'il devrait le faire pour une redirection permanente (301).
Références :
Beaucoup de sites web ont un nom de domaine unique comme www.example.org qui consiste en plusieurs serveurs pour les besoins de load balancing
et de mirroir. Si un server est inaccessible, les autres peuvent être toujours opérationnels, ainsi les navigateurs devraient tenter de contacter tous les serveurs du site web avant de conclure que le site web est éteint.
Accept.HTTP/1.1 [RFC2616] définit la négociation du contenu. Le client envoie une requête donnant une liste des types de média qu'il est prêt à accepter ; le serveur retourne alors une représentation de l'objet demandé dans un des formats spécifiés s'il est disponible.
Lorsque des entités sont incluses dans un document (tel ques des images dans des documents HTML), les agents utilisateurs devraient envoyer seulement des entêtes Accept pour les formats qu'ils supportent.
Exemple :
Si un agent utilisateur peut afficher des images JPEG, PNG et GIF, la liste des types de média acceptés devrait être image/jpeg,
image/png, image/gif.
Mauvais : Les agents utilisateurs ne devraient pas envoyer un entête HTTP Accept: */* car le serveur peut supporter des types de contenu que le user agent ne supporte pas. Par exemple, si un serveur est configuré pour envoyer des images SVG plutôt que des images PNG, un agent utilisateur qui ne supporte que PNG, GIF and JPEG recevra un SVG (non supporté) plutôt qu'un PNG (supporté).
Références :
Accept,
voir la section
14.1 de la spécification HTTP/1.1, [RFC2616].Les ressources sont localisées sur le web en utilisant des Identificateurs Uniformes de Ressources [RFC2396]. Cette section présente comment les agents utilisateurs devraient gérer les URIs.
Lorsqu'une ressource (URI1) a changé, une redirection HTTP peut indiquer sa nouvelle localisation (URI2).
Si URI1 possède un identificateur de fragment #frag, alors la nouvelle cible que l'agent utilisateur devrait essayer d'atteindre sera URI2#frag. Si URI2 possède déjà un identificateur de fragment, alors #frag ne doit pas être ajouté et la nouvelle cible est URI2.
Mauvais : La plupart des agents utilisateurs implémente les redirections HTTP mais n'ajoute pas l'identificateur de fragment à la nouvelle URI, ce qui trouble généralement l'utilisateur parce-qu'il se retrouve avec la mauvaise ressource.
Références :
Exemple :
Supposez qu'un utilisateur réclame la ressource à http://www.w3.org/TR/WD-ruby/#changes et que le serveur redirige l'agent utilisateur vers http://www.w3.org/TR/ruby/.
Avant d'extraire cette dernière URI, le navigateur devrait ajouter l'identificateur de fragment #changes à celle ci :
http://www.w3.org/TR/ruby/#changes.
Les auteurs aimeraient remercier l'ensemble de l'équipe du W3C pour leurs commentaires.