Accessibilité, javascript intrusif et svg

Bonjour,
Plusieurs questions :
-Je vois beaucoup de conseils sur l'accessibilité et par ailleurs quand je regarde le source de la page d'accueil ici, une question me vient : pourquoi tant de href en clair dans les pages ? Je suppose que les pages sont générées et je me disais, qu'est ce qui empêche de faire, d'un côté des pages avec javascript actif et donc supprimer complétement les références en dur en reportant celles-ci dans le script/onload pour respecter au mieux le pattern MVC avec javascript non intrusif, et de l'autre côté une duplication vers des pages accessibles pour les personnes à accessibilité réduites ? Ceci se fait déjà pour les mobiles.
- SVG : en parcourant les forums, j'ai pu voir une question sur les liens/images toujours rectangulaires et la personne demandait s'il était possible de faire des liens de forme quelconque. Et oui, c'est possible en passant par le svg, j'ai réalisé une interface professionnelle sous FF qui reporte des états de chaines et permet ainsi de formaliser sur des pages schémas les zones activées ou sensibles.
Ceci pour dire que HTML 5 arrive avec sa sémantique qui intègre SVG. Et que cela nous permettra peut-être de sortir des présentations un peu figées au km des sites/blogs actuels. Un espoir, l'animation de page (un peu comme adobe digital edition) qui ne m'obligerait plus à dérouler les menus jusqu'à la fin ou de remonter en haut de page pour accéder à d'autres, même sur écran 26". Un vrai plus dans l'accessibilité.
Qu'en pensez vous ?
Bon courage à tous.

Bonjour,

dragonfire34 a écrit :
Qu'en pensez vous ?

J'en pense que je n'ai absolument rien compris à ce que tu racontais...

Bonjour aussi,

a écrit :
pourquoi tant de href en clair dans les pages ?

euh? en clair ? comprends pas... c'est quoi un href en clair ?

Moi je vois pas le rapport entre le pattern MVC et les urls "en dur"... Tu voudrais pas un href="javascript:open(url1)"... ou un href="javascript:getAjaxLink(code)" ...?! L'intéret je le cherche encore...

Bonjour,
je me suis certainement mal exprimé.
Quand je regarde la page d'accueil et les autres, vous retrouvez en clair une somme de liens avec par exemple 'href=http://www.alsacreations.com/actu/lire/956-google-accelere-disparition-ie6.html'.
Donc ma question était la suivante : pourquoi la balise<a></a> ne comprend t'elle pas un identifiant ID <a id="20100301_google'>mon _texte</a> sur lequel on peut s'appuyer ensuite en javascript dans le onload pour lancer l'ouverture du lien lors d'un évènement.
Je pose cette question parce que tous les ouvrages qui fond référence au javascript ou à Ajax recommandent le pattern MVC dans lequel nous ne devons retrouver aucun lien en dur (href="...") dans le code HTML. Alors cela bien sûr pour ceux qui activent javascript.
Et pour ceux qui ne l'activent pas, un autre 'site' avec les paramètres passés comme ici ou pour ceux enfin qui visualisent sur smartphone, des pages et/ou feuilles CSS et JS dédiées.
C'était une question sachant que notamment le futur HTML 5 tend à se rapprocher du xml où, par construction, les évènements sont traités soit dans le xsl soit dans le javascript. Laissant lisible au passage le contenu même balisé.
Merci de vos réponses.
Bye.

OK, effectivement tu t'étais mal exprimé (et ce n'est toujours pas parfait), il y a plusieurs problèmes dans ta réflexion, le principal : Alsacréations n'utilise pas JS pour le chargement des pages...

dragonfire34 a écrit :
Quand je regarde la page d'accueil et les autres, vous retrouvez en clair une somme de liens avec par exemple 'href=http://www.alsacreations.com/actu/lire/956-google-accelere-disparition-ie6.html'.

Alsacréations utilise effectivement latechnique de l'URL rewriting (je te laisse faire la recherche sur la technique, ce ne sont pas les sources qui manquent) qui, entre autre améliore le référencement.

dragonfire34 a écrit :
Donc ma question était la suivante : pourquoi la balise<a></a> ne comprend t'elle pas un identifiant ID <a id="20100301_google'>mon _texte</a> sur lequel on peut s'appuyer ensuite en javascript dans le onload pour lancer l'ouverture du lien lors d'un évènement.

Je ne vois pas d'où tu sort cet identifiant ni quel pourrait être son intérêt. Rares sont les sites full Ajax... et ce n'est pas le cas ici.

dragonfire34 a écrit :
Je pose cette question parce que tous les ouvrages qui fond référence au javascript ou à Ajax recommandent le pattern MVC dans lequel nous ne devons retrouver aucun lien en dur (href="...") dans le code HTML. Alors cela bien sûr pour ceux qui activent javascript.
Et pour ceux qui ne l'activent pas, un autre 'site' avec les paramètres passés comme ici ou pour ceux enfin qui visualisent sur smartphone, des pages et/ou feuilles CSS et JS dédiées.

Et c'est une très mauvaise pratique. Il vaut mieux faire du JS non intrusif.

dragonfire34 a écrit :
C'était une question sachant que notamment le futur HTML 5 tend à se rapprocher du xml où, par construction, les évènements sont traités soit dans le xsl soit dans le javascript. Laissant lisible au passage le contenu même balisé.

Là je crois que tu mélange un peu tout, HTML5 ne tend pas à se rapprocher de l'XML (on m'aurait menti ?) c'est XHTML (1.0, 1.1) qui cherchait à le faire. Là encore, je ne vois pas le rapport entre HTML xml, xls (tableur excel) et javascript.

Bref, toujours rien compris à ta question...
Modifié par Laurie-Anne (01 Mar 2010 - 11:13)

Je n'ai jamais vu, nulle part, quiconque recommander de proscrire les liens "en dur". L'hyperlien textuel, c'est quand même le fondement même du HTML!

De plus, je ne vois pas non plus d'où sortirait un id="20100301_google". Sa syntaxe est fausse, puisqu'un id doit commencer par une lettre.

Comme cela fait un peu de temps que j'ai posté ma réponse, je fais un nouveau message au lieu d'éditer le précédent...

Je précise ma pensée à propos des liens. Un lien dans un code source de page, c'est une information. Je ne parle pas là de l'information contenue dans la référence pointée par le lien, mais bien de la présence du lien à cet endroit-là du code.

On peut imaginer, en poussant à l'extrême le modèle MVC, que le fait de cliquer sur la représentation graphique de l'élément a, étant une réponse à une action de l'utilisateur, nécessite d'être contrôlé. Mais dans ce cas, c'est similaire au fait de ne placer aucun champ de formulaire (input et autres button) dans le code HTML. Je conçois en revanche que la réponse à ce click puisse être prise en charge par la couche contrôleur (ouverture dans une nouvelle fenêtre avec certains paramètres, action dans la page, soumission de formulaire...). Dans ce cas, si l'on s'en tient à cette conception, le MVC reste applicable, mais sans dégrader l'utilisabilité de la page quand un de ses composants est désactivé (pas de CSS, ou pas de Javascript).

Bref, avant de faire des contorsions pour essayer de faire entrer un cube dans un trou rond dont le diamètre est égal à l'arête du cube, il est préférable de se poser un instant et de réfléchir au pourquoi des choses. Si l'application du modèle demande de la part du développeur plus d'efforts, ce n'est pas fondamental. Ce n'est qu'une question de moyens, pas un obstacle essentiel. Mais si le modèle -quel qu'il soit- implique des contraintes sur l'utilisateur final, alors qu'à la base c'est pour optimiser la satisfaction de ses besoins qu'il a été conçu, c'est qu'on est allé trop loin. Cela s'applique au MVC, mais aussi aux méthodes d'application des WCAG pour l'accessibilité, ou à la validation à toute force du code HTML (je pense en particulier aux personnes qui veulent faire du HTML strict, et demandent à gauche et à droite comment faire pour faire "comme si" il y avait un attribut target -alors que la bonne question à se poser est sur la pertinence de cette exigence de DTD stricte).
Quand on développe quelque chose à destination de quelqu'un, avant de se faire plaisir, le but est quand même de répondre aux besoins de l'utilisateur de la manière la plus satisfaisante possible pour lui, compte tenu des moyens dont on dispose, et pas des contraintes que l'on s'impose.
Modifié par Gilles (01 Mar 2010 - 12:50)

Ah et puis tiens, à propos des liens dont la forme serait quelconque: sans aller jusqu'au SVG qui n'est pas supporté partout (suivez mon regard en direction de Redmond ), depuis des années il y a la possibilité de faire des liens de n'importe quelle forme: les image maps (oui, bon, je sais ce n'est pas du texte mais au moins c'est une technologie éprouvée ).

laurie-anne,
Il serait bon de ne pas mélanger xsl, xslt et xls...non. Alors effectivement ma prose est un peu trop châtiée pour ceux habitués aux sms, mais bon. De même, confondre un site full Ajax avec un site javascript, pourquoi pas, l'un étant une partie de l'autre. Quant à l'URLRewriting, je crois connaître assez mais bon, ce n'était pas ma question.

Gilles a bien compris ma demande. Personnellement, je gère mes sites en xml et pour faire ceci, je part bien sûr du trio apache/php/mysql (oracle parfois, postgresql et sqlite souvent). Mes données étant stockées en base, j'ai 2 sites : l'un en administration php et l'autre, généré par le premier, en full xml/xsl/javascript. Cela a été nécessaire pour permettre une réplication du site vers d'autres serveurs afin d'assurer la pérennité du service en cas de plantage du serveur d'administration.
D'où ma question pour assurer l'accessibilité, ne serait-il pas souhaitable de générer :
- un premier site avec, un code html sans autres paramètres (quand cela est faisable) que les ID, un javascript qui prendrait en charge les évènements puis bien sûr les CSS.
- un second site pour l'accessibilité avec un code html et les éléments nécessaires (donc sans JS).
Nous aurions ainsi une franche séparation des fonctions.

Pour le SVG, effectivement les splashscreen et leurs images map existent depuis longtemps, à une différence près avec le svg, c'est que ce dernier est vectoriel (donc zoomable sans dégradations du rendu), gère les vrais calques et les zones actives en fonctions de ceux-ci. Et que des logiciels comme Xara ou Inkscape nous permettent de le produire sans difficultés.
Quant à leur intégration dans les navigateurs, les plus récents l'incorporent en natif ou par plugins adobe, comme le flash d'ailleurs.

Pour le nommage des ID, peut-être, cela ne les empêche pas de fonctionner sans erreurs sous IE et FF. Le principal étant qu'ils soient uniques.

Et si je pose cette question c'est que, je le répète, de nombreux ouvrages et journaux spécialisés sur le sujet préconisent cette séparation MVC, pour le JS, mais aussi pour PHP en eXtrem Programming et bien d'autres langages.

C'était donc une réflexion sur la compatibilité Accessibilité/MVC.

Au risque de me répéter, je ne vois pas ce que tu gagnerais en produisant deux sites. Pourquoi ne pas te contenter de la version avec les href explicites? Du point de vue de l'utilisateur, c'est le plus satisfaisant des deux systèmes (en passant, c'est aussi beaucoup plus satisfaisant pour le référencement )? Simplement pour le plaisir d'implémenter jusqu'au bout du bout de la démarche le modèle MVC?

Mais à ce compte-là, c'est tout le balisage qui doit être revu.

Les titres par exemple servent à la navigation pour certaines aides techniques qui permettent l'exploration d'un document avec sa table des matières. Ce sont des éléments qui sont susceptibles d'entraîner une action de l'utilisateur. Il en est de même de tous les champs de formulaires, mais aussi des listes.

En mode de lecture de tableau de données, les lecteurs d'écran déclenchent la lecture des entêtes de tableau correspondants à une cellule de donnée quand l'utilisateur se place sur celle-ci.

L'attribut longdesc génère pour certains utilisateurs un lien.

Au lieu de vouloir à toute force réinventer la roue sous le prétexte d'avoir un modèle "philosophiquement" intéressant et cohérent, je trouve plus sain d'utiliser au mieux les possibilités offertes par le langage que tu choisis comme format de sortie. Ou alors, ne génère plus de l'HTML, mais envoie directement de l'XML avec un traitement côté client...

Il me semble beaucoup intéressant, si tu tiens absolument à intégrer ainsi qu'au bout la démarche MVC, de regarder dans la direction de ce que permet de faire ARIA, par exemple, que de vouloir utiliser le HTML pour quelque chose pour lequel il n'a pas été conçu. Et pour le coup, avec ARIA, tu prends peu de risque en terme d'accessibilité...

Bonjour,
Effectivement, c'est ce que je fais actuellement. Mes pages sont en xml, php étant utilisé pour la génération du site et la gestion sgbd.
Mais la difficulté de produire un site de telle ou telle façon n'est pas très chronophage étant donné que je pars de données uniques.
Donc ensuite ce n'est qu'une question de formatage des sorties et d'adaptation mineure de scripts.
Pour ARIA, cela peut être une piste, sachant qu'il faut quand même des navigateurs modernes.
Comme pour SVG, j'ai tendance à étudier les évolutions et les possibilités mais aussi à temporiser devant ce qui semble une réelle avancée mais pas forcément une vraie adoption.
Personne ne peut dire aujourd'hui, malgré les capacités de SVG et son code qui peut être généré via xml, que ce format sera retenu un jour devant la pression de Flash et consort.
Pourtant quand on connait ses capacités, notamment à zoomer des parties de page sans détruire le reste, cela apporterait du confort aux mal voyants par exemple et pas seulement en mode texte.
Avec sa vraie intégration dans HTML 5, peut-être une chance là aussi de voir les choses évoluer.
On peut souhaiter que pour ARIA il en soit autrement, d'autant que cela nécessite peu d'efforts.
Mais j'aime bien réinventer la roue, celle de ma BM n'a que peu à voir avec celle de la 2CV d'antan.
Faut pas être trop coincé non plus et les chemins de traverses apportent parfois leurs lots de bonne surprises.
Un surf + une voile ont bien donné un kitesurf !
L'évolution est toujours, quelque part, le fruit de la folie. E=MC2 !
Bye.