Mettant à profit les creux de l'été pour développer un navigateur internet un peu sérieux dans Second Life (on peut zoomer, scroller, désactiver les couches graphiques, augmenter les tailles de textes, soumettre des formulaires, ouvrir des liens, enregistrer des bookmarks, surfer dans l'historique, alterner pages web, vidéos ou images slides, etc etc) je me suis rendu compte de deux choses importantes.
La première c"est qu'il n'y a pas de différence notable entre accessibilité et interopérabilité des contenus puisque les conditions à remplir pour qu'un contenu web devienne utilisable dans SL (ou n'importe quel autre metavers) sont exactement celles requises pour être conformes aux Wcag. Comme on ne peut pas cliquer sur un lien (en fait on ne fait que "toucher" l'objet-écran, exactement comme si vous touchiez maintenant votre écran : les liens ne s'ouvriraient pas pour autant...) on est donc dans la situation d'un utilisateur ne pouvant se servir ni de sa souris ni de son clavier... On pilote donc le site "à la voix" via le canal de chat/IM. Il suffit de "dire" l'URL pour ouvrir la page, ou de de "dire" un mot d'un lien (dans l'intitulé) pour ouvrir la page, etc. Donc un lien constitué d'une image (même avec alt) est inutilisable en l'absence d'intitulé textuel ; donc un menu déroulant (ou tout autre dispositif Javascripto-ajaxien) est inutilisable en l'absence d'action-utilisateur déclenchante ; donc une série de liens identiques (type "lire la suite..." après chaque extrait) ne permettra que de lire le premier en boucle, etc. La liste est très longue. Quant à Flash j'en parle même pas
La seconde chose importante concerne la validation. Un jeu de regex analyse le contenu de la page appelée pour en extraire les choses utiles : liens, formulaires, etc. afin de rendre l'interaction possible. J'ai donc tout un dispositif qui analyse les balises utiles (a href, form, input...), les attributs disponibles (action, name, title...) et les valeurs correspondantes. Ces valeurs, pour que la page soit valide, doivent être mises entre guillemets. Les séries de tests menés ont toujours échoué sur les pages invalides, puisque les regex ne retrouvaient pas les valeurs non-guillemettées (par exemple retrouver la destination d'un formulaire est impossible si au lieu de <form action="search" le script rencontre <form action=search, comme dans Google par exemple. Pourtant ils ont les moyens de faire propre chez Google, non ?). J'ai donc dû développer tout un jeu complémentaire d'outils "quirks" permettant de corriger ces erreurs.
La conclusion de cette expérience fort intéressante est que hors des normes point de salut pour l'interopérabilité de vos sites sur des outils pour lesquels ils ne sont pas originellement conçus (c'est-à-dire des navigateurs web), et hors des normes point de salut pour l'accessibilité et l'utilisabilité de vos sites par un utilisateur "non-standard" dans des conditions "non-standard".
Alors bien sûr que les internautes qui consulteront vos pages depuis un metavers 3D représentent moins de 0,000001%, mais rien ne dit que les années qui viennent ne proposeront pas des outils de plus en plus performants (SL est maintenant dispo sur mobiles, ce qui rend les choses plus rigolotes), et rien ne dit que vos sites savamment élaborés passeront ce cap.
Le développement de codes supplémentaires pour "quirkser" les contenus est très lourd - et attention, je sais de quoi je parle maintenant, hein
- en termes de temps, d'énergie, de budget, etc. et donc il est probable que ces démarches seront à terme abandonnées par les grands éditeurs. Autant s'y préparer en produisant dès maintenant du "conforme", du "standard", du "valide", de l'"accessible" et de l'"interopérable"... Y'a rien à y perdre, y'a tout à y gagner
Tout ça pour dire qu'à côté de ces enjeux pour demain portant sur des questions de "convergences de contenus" (un contenu unique pour des utilisateurs multiples et porté sur des outils différents : téls mobiles, metavers 3D, etc.), celle de savoir si une page s'affiche rigoureusement pareil dans IE et dans FF est plutôt ringarde, non ?
Modifié par Arsene (08 Aug 2008 - 10:56)
La première c"est qu'il n'y a pas de différence notable entre accessibilité et interopérabilité des contenus puisque les conditions à remplir pour qu'un contenu web devienne utilisable dans SL (ou n'importe quel autre metavers) sont exactement celles requises pour être conformes aux Wcag. Comme on ne peut pas cliquer sur un lien (en fait on ne fait que "toucher" l'objet-écran, exactement comme si vous touchiez maintenant votre écran : les liens ne s'ouvriraient pas pour autant...) on est donc dans la situation d'un utilisateur ne pouvant se servir ni de sa souris ni de son clavier... On pilote donc le site "à la voix" via le canal de chat/IM. Il suffit de "dire" l'URL pour ouvrir la page, ou de de "dire" un mot d'un lien (dans l'intitulé) pour ouvrir la page, etc. Donc un lien constitué d'une image (même avec alt) est inutilisable en l'absence d'intitulé textuel ; donc un menu déroulant (ou tout autre dispositif Javascripto-ajaxien) est inutilisable en l'absence d'action-utilisateur déclenchante ; donc une série de liens identiques (type "lire la suite..." après chaque extrait) ne permettra que de lire le premier en boucle, etc. La liste est très longue. Quant à Flash j'en parle même pas
La seconde chose importante concerne la validation. Un jeu de regex analyse le contenu de la page appelée pour en extraire les choses utiles : liens, formulaires, etc. afin de rendre l'interaction possible. J'ai donc tout un dispositif qui analyse les balises utiles (a href, form, input...), les attributs disponibles (action, name, title...) et les valeurs correspondantes. Ces valeurs, pour que la page soit valide, doivent être mises entre guillemets. Les séries de tests menés ont toujours échoué sur les pages invalides, puisque les regex ne retrouvaient pas les valeurs non-guillemettées (par exemple retrouver la destination d'un formulaire est impossible si au lieu de <form action="search" le script rencontre <form action=search, comme dans Google par exemple. Pourtant ils ont les moyens de faire propre chez Google, non ?). J'ai donc dû développer tout un jeu complémentaire d'outils "quirks" permettant de corriger ces erreurs.
La conclusion de cette expérience fort intéressante est que hors des normes point de salut pour l'interopérabilité de vos sites sur des outils pour lesquels ils ne sont pas originellement conçus (c'est-à-dire des navigateurs web), et hors des normes point de salut pour l'accessibilité et l'utilisabilité de vos sites par un utilisateur "non-standard" dans des conditions "non-standard".
Alors bien sûr que les internautes qui consulteront vos pages depuis un metavers 3D représentent moins de 0,000001%, mais rien ne dit que les années qui viennent ne proposeront pas des outils de plus en plus performants (SL est maintenant dispo sur mobiles, ce qui rend les choses plus rigolotes), et rien ne dit que vos sites savamment élaborés passeront ce cap.
Le développement de codes supplémentaires pour "quirkser" les contenus est très lourd - et attention, je sais de quoi je parle maintenant, hein
- en termes de temps, d'énergie, de budget, etc. et donc il est probable que ces démarches seront à terme abandonnées par les grands éditeurs. Autant s'y préparer en produisant dès maintenant du "conforme", du "standard", du "valide", de l'"accessible" et de l'"interopérable"... Y'a rien à y perdre, y'a tout à y gagner Tout ça pour dire qu'à côté de ces enjeux pour demain portant sur des questions de "convergences de contenus" (un contenu unique pour des utilisateurs multiples et porté sur des outils différents : téls mobiles, metavers 3D, etc.), celle de savoir si une page s'affiche rigoureusement pareil dans IE et dans FF est plutôt ringarde, non ?
Modifié par Arsene (08 Aug 2008 - 10:56)