Je ne suis pas la première à crier haro sur les frames, pas la dernière non plus...

Il faut bien le constater, alors que les défauts de cette technologie sont souvent montrés du doigt et qu'il existe aujourd'hui des solutions de remplacement efficaces et robustes, les frames sont encore utilisées pour de nouveaux sites créés par des professionnels. Pourquoi ?

La situation

La technique des frames (ou cadres) a été utilisée pour la première fois par Netscape Navigator 2.0 en 1996 [1] et proposée au W3C qui l'a introduit dans les spécifications HTML 4 deux ans plus tard :

HTML frames allow authors to present documents in multiple views, which may be independent windows or subwindows. Multiple views offer designers a way to keep certain information visible, while other views are scrolled or replaced. For example, within the same window, one frame might display a static banner, a second a navigation menu, and a third the main document that can be scrolled though or replaced by navigating in the second frame.

Outre le gain de bande passante, en divisant la page en partie(s) fixe(s) et en partie(s) scrollable(s), en partie(s) qui ne se recharge(nt) pas, les frames facilitaient la maintenance d'un site (plus besoin de modifier le menu sur toutes les pages, par exemple). Mais la facilité n'était qu'apparente, bien des webmasters se sont cassés les dents... je me souviens d'un site où les frames s'emboîtaient les unes dans les autres chaque fois que je cliquais sur un lien...

Aujourd'hui l'utilisation des feuilles de style (notamment la propriété overflow) et des technologies serveur (avec un langage de programmation comme php) permet de retrouver ces avantages, sans utiliser de frames.

Les principaux reproches

Ces différents points sont expliqués dans un article publié par Denis Boudreau sur OpenWeb : Pour en finir avec les cadres

  • Dénaturation radicale du document Web
  • Impossibilité d'ajouter aux favoris
  • Indexation déficiente
  • Imprécision de l'impression
  • Aucune séparation entre structure et contenu
  • Economie de fichiers illusoire
  • Utilisabilité conceptuelle bafouée
  • Programmation compensatoire
  • Une technologie en perte de vitesse

Le point de vue des experts

Les spécifications du W3C

Il est tout à fait possible d'utiliser des frames et d'avoir un code valide, il suffit de choisir le bon doctype

Les directives WCAG

Selon la Web Accessibility Initiative, les frames peuvent être utilisées à condition de respecter un certain nombre de directives (version en français) mais ne sont pas recommandées [2]

In the following sections, we discuss how to make frames more accessible. We also provide an alternative to frames that uses HTML 4.0 and CSS and addresses many of the limitations of today's frame implementations.

AccessiWeb

L'utilisation des cadres figure bien-sûr parmi les critères Accessiweb. Dans ce tableau de correspondance AccessiWeb - WCAG 1.0, vous remarquerez la présence d'un critère (2.9) absent des directives WCAG

Y a-t-il un maximum de trois cadres dans la page ?

Les raisons de ce choix, que je trouve très pertinent :

  • Pour naviguer dans un site utilisant des frames l'utilisateur d'un lecteur d'écran dispose d'une liste des cadres. Si les directives sont respectées, il aura suffisamment de points de repère pour se déplacer dans le site sans trop de difficulté. Mais plus le nombre de cadres et leur imbrication augmente, plus l'arborescence devient complexe, plus la navigation devient laborieuse.
  • Plus le nombre de cadres augmente, plus l'espace dévolu au cadre principal se réduit. Les mal-voyants ou les personnes ayant des difficulté de lecture peineront à se repérer dans la page, à utiliser les ascenceurs, ou encore à agrandir la taille du texte.

Le RGAA

Les auteurs du référentiel ont retenu :

Mais rien (dans la version actuelle, soumise à vos commentaires) ne fait allusion au nombre de cadres... à proposer ?

Des exemples de problèmes d'accessibilité

Le site officiel d'une ville canadienne

<frame src="actu-navig.htm" name="NAV" noresize marginwidth="0" marginheight="0" scrolling="NO">

noresize et scrolling="NO", un choix trop fréquent... le menu de ce site étant plutôt long, j'ai dû afficher la fenêtre en taille maximum pour le voir dans son entièreté. Que font ceux qui ne disposent que d'une plus petite résolution ?

<noframes>
<body bgcolor="#FFFFFF"><font face="Verdana" size="3" color="#000066">
<b>Attention...</b><br>Pour afficher ce site, il vous faut un Navigateur capable d'utiliser les cadres...</font>
</body>
</noframes>

C'est tout simplement une fin de non recevoir pour un certain nombre de visiteurs !

Un site du Gouvernement français

Capture d'écran de Lynx, frames sans nom significatif

Ici il n'y a que 4 frames (capture d'écran du site vu avec Lynx), mais le nombre est parfois nettement plus élevé encore et peut dépasser la dizaine ! Que font les utilisateurs d'un navigateur texte, d'une synthèse vocale ou d'une tablette braille ? J'ai apprécié la réponse non dénuée d'humour d'une formatrice AccessiWeb, non-voyante, dans ce cas, je navigue à l'aveugle.

De plus je suis arrivée sur ce site sur un lien profond via une recherche (j'avoue, c'est un peu de la triche... on ne doit pas souvent y arriver en cherchant <frameset) et quand j'ai cliqué sur le lien qui aurait dû me conduire à la page d'accueil, j'ai eu droit à une page avec ce message

Not Found
The requested object does not exist on this server. The link you followed is either outdated, inaccurate, or the server has been instructed not to let you have it. Please inform the site administrator of the referring page.

Utiliser les frames, oui ou non ?

Sans aller comme certains jusqu'à affirmer que les frames c'est le mal, je répondrais non à ma question.

Mais... je cite Laurent Denis dans une discussion que je vous invite à lire (sur le forum Alsacréations) :

Il n'est pas question de proscrire quoi que ce soit, et surtout pas des technologies valides prenant en compte les nécessités de l'accessibilité. Mais de servir des éléments normalisés à bon escient.

Un iframe (ou un frameset) respectant les règles WCAG pourra être accessible là où diverses astuces de contournement des cadres ne le seront pas.

Inversement, un frameset ou un iframe lui-même utilisé comme contournement (l'iframe si "pratique" pour masquer un bug d'élément fenêtré, par exemple), ou de manière aberrante (je pense à un grand site d'e-commerce ne comportant pas moins de 12 frames) posera évidemment des problèmes d'accessibilité.

Les webmasters amateurs, désireux avant tout de communiquer et partager des informations, utilisent généralement un éditeur WYSIWYG parce qu'ils ne souhaitent pas se lancer dans l'apprentissage de toute forme de programmation. C'est un choix que je comprends très bien. Ils pourraient encore être tentés par l'utilisation des Frames. Mais même avec un éditeur WYSIWYG, la mise en oeuvre de cette technique demande un minimum d'apprentissage, sous peine de résultats désastreux. Pour eux, l'utilisation d'un CMS (SPIP, Plume, Pluxml...) est une solution intéressante.

Pour les sites réalisés par des professionnels, ma position est beaucoup plus tranchée. J'attends encore les exemples qui me convaincront que l'utilisation d'un frameset est le meilleur choix (une exception peut-être pour un iframe qui contient un bout de code sur lequel le webmaster n'a pas la maîtrise).

Alors si vraiment vous restez un inconditionnel des frames, s'il vous plaît, respectez au moins les directives d'accessibilité, y compris le critère ajouté par AccessiWeb ! La multiplication des cadres, en réduisant les zones de contenu, rendra impossible l'accès aux informations ou aux services proposés pour certains visiteurs (en fonction de leur type de handicap), rendra la consultation du site inconfortable pour tous (au même titre que les espaces de contenu ridiculement réduits sur beaucoup de sites en flash, que les champs de saisie minuscules où il est impossible de lire et encore moins de relire ce qu'on écrit... [3])

Notes

[1] pour les curieux, une page présentant ce navigateur retrouvée sur web.archive.org

[2] A lire, le chapitre consacré aux frames de Building Accessible Websites, le livre de Joe Clark

[3] si, comme moi, vous râlez souvent contre les champs de saisie minuscules sur certains blogs, forums... installez l'extension Resizeable Form Fields, c'est magique, un pur bonheur !

Trackbacks

1. Le mardi juin 2007 à 15:27, de taggle.org

Les frames, ça vous dit ?

Il faut bien le constater, alors que les défauts de cette technologie sont souvent montrés du doigt et qu'il existe aujourd'hui des solutions de remplacement efficaces et robustes, les frames sont encore utilisées pour de nouveaux sites créés par des...

Commentaires

1. Le mardi juin 2007 à 16:44, par Neovov

En plus frame, frameset et noframes seront (probablement) supprimés de HTML5.

Très bon article Monique ;-) !

2. Le mercredi juin 2007 à 09:29, par Benja

Bonjour Monique,
Ton article est intéressant et je suis tout à fait d'accord avec toi. J'avais déjà lu un article en 2003 allant dans le même sens sur openweb:
openweb.eu.org/articles/f...

3. Le jeudi juin 2007 à 01:47, par Laurent

Très belle compilation !!!! mais disons que le sujet est clos depuis longtemps ;-) Par contre l'Iframe est par contre encore beaucoup utilisée.

4. Le jeudi juin 2007 à 22:11, par Monique

Bonjour,

@Laurent : au vu de questions posées sur les forums, au vu des nombreux sites que je visite quotidiennement, non, le sujet n'est pas clos pour tout le monde. Les frames sont encore utilisées, et toujours aussi mal :(

Amicalement,
Monique

5. Le dimanche juin 2007 à 13:05, par Saternius

Ah les frames... la plus belle abbération du web :)
Je me demande encore comment certains peuvent encore faire des sites pro avec ce truc complètement obsolète. Et niveau référencement, c'est un vrai massacre. Vivement HTML 5 que cela soit enterré pour de bon :)

6. Le jeudi juin 2007 à 21:07, par jux

Tout le monde est d'accord : les frames c'est pas bien.
Mais comment les remplacer efficacement ? oui, car personnellement je rencontre des cas où j'aurais besoin d'appliquer ce principe : nécessité de ne pas faire appel à une technologie serveur pour des soucis de performances, et malgré tout offrir un contenu relativement dynamique. Dans ce cas que préconisez vous, sachant que l'utilisation de l'Ajax ne répond pas à toutes les problématiques d'accessibilité ?
Connaissez-vous la technologie ESI ? elle est fourni par Akamai et permet d'inclure des bloc de contenus au sein de pages HTML.. c'est ce que j'utilise actuellement. Le problème : c'est propriétaire et très couteux.
.. bref.. d'autres idées ?