Pages :
(reprise du message précédent)

Le problème d'accessibilité du javascript va un petit peu plus loin. En l'absence de contrôles spécifiques en HTML, on utilise inévitablement des subsituts à base de javascript et d'éléments HTML génériques. Il est extrèmement difficile de permettre aux outils d'aide de manipuler ceux-ci, pour donner en particulier accès via le clavier...
Mais les outils comme jaws lisent parfaitement les contenus générés et modifiés par javascript.
QuentinC : le problème de l'accessibilité ne se limite pas aux handicapés visuels, et parmi ceux-ci, aux utilisateurs (avancés) de Jaws ! Smiley cligne

Je comprends très bien que chacun, dans ce cas, voit midi à sa porte. Mais ce qui semblera accessible dans un lecteur d'écran pourra être très problématique pour un simple accès au clavier dans un navigateur graphique, ou via un dispositif d'agrandissement, ou pour un handicap cognitif (complexité de l'interface, mécanismes et logique non-dites, mémorisation exigeante, etc.)

L'accessibilité ne peut pas se construire sur une agrégation d'approches partielles, en faisant une somme du genre : celles des utilisateurs de telle ou telle solution, plus celles des utilisateurs ayant tel ou tel handicap.

C'est (malheureuseument ?), d'ailleurs, l'approche qui guide l'élaboration des outils d'aides dans l'industrie. Voir les remarques d'Aaron Leventhal , dans http://blog-and-blues.org/weblog/2005/03/18/418-aaron-leventhal-firefox-accessibilite :

a écrit :
ceux qui créent les logiciels veulent répondre aux préoccupations prioritaires de leurs clients. Ils ont beaucoup à faire, et n'ont pas de temps à consacrer à quelque-chose qui n'a pas de raison-d'être commerciale. Quand ils lisent les normes, ils peinent à y trouver ce qui pourrait leur être utile, pour diverses raisons : outre le fait d'être difficiles à comprendre, ces documents peuvent très bien être de simples redites de ce que la plupart d'entre-eux savent déjà, tout en laissant de côté pas mal de vrais problèmes tels que l'interopérabilité (...) Le revers de la médaille est que, de cette manière, des problèmes cruciaux à un plus haut niveau de réflexion ne seront parfois pas traités (...) Si un problème est perçu comme marginal, il ne recevra probablement aucune solution, même s'il peut être très important pour une catégorie donnée d'utilisateurs


(A noter : Leventhal est justement un des rares personnes à travailler pour l'accessibilité DHTML).

Raisonner en termes d'accessibilité, c'est raisonner sur des choix techniques qui permettent à tous les outils de manipuler le contenu pour y donner accès. Autrement-dit, sur une base technique commune, dans laquelle javascript est aujourd'hui problématique, même si on peut espérer des progrès à court terme.
Modifié par Laurent Denis (15 Aug 2005 - 07:54)
QuentinC a écrit :
Mais les outils comme jaws lisent parfaitement les contenus générés et modifiés par javascript.


Tout ce qu'il y a de plus faux. Jaws (et ne pas y inclure les autres lecteurs d'écran qui ne sont pas du même niveau), qui est de loin le plus performant des outil de synthèse vocale parvient à supporter un Javascript simple, sans plus.

Par exemple, dès que l'instance d'un contenu est modifié par Javascript, hop, ça ne fonctionnera pas sous Jaws (changer l'instance d'un display none à un display block par exemple). Dès que tu utilises JavaScript pour des tâches plus complexes, les probabilités d'échec sous Jaws grimpent en flèche... et je ne parle pas ici des autres, comme Homepage Reader, encore plus frileux face au Javascript.

Et tout ceci, sans compter que plus ton Javascript est propriétaire (donc du vrai Javascript ou du "JScrapt", pas de l'ECMA-262), plus tes chancessont grandes de sortir des paramètres entre lesquels un synthétiseur vocal peut interpréter cette technologie.
Un handicapé cognitif est une personne qui a du mal à comprendre en raison d'un handicap mental.
Bonjour,
Revenons un peu sur le sujet pdf. Hier soir mon pote m'apelle, il me dit : "Franck faut que tu mettes en ligne un produit spécifique pour que l'installateur de la Guadeloupe puisse imprimer la planche pour un de ces client. 5mn après la page était en ligne. Exemple dans le lien ci dessous
http://www.ams-tec.com/TECHNO_EM_serrure_electrique_pdf.php
Comme vous pouvez le voir dans cette page il y a des tableaux avec des références. Combien de temps, aurai-je mis pour le faire en CSS+xhtml?
Je crois que pour les doc techniques constructeurs le pdf est génial surtout pour l'utilisateur qui est au bout et qui vous demande un document de qualité pour le présenter soit à son patron , soit à son client

J'ai fait des pages avec d'enorme tableau un exemple sur les extincteurs ci-dessous rien que cette page me vaut quelques heures de bouleau
http://www.ams-tec.com/extincteur_arex_pression_permanente.phpnull
Modifié par finpiet (19 Jan 2006 - 04:41)
Bonjour à tous !
Suis nouveau Smiley biggrin
Juste une petite remarque, j'ai assisté à la présentation de la suite Macromedia V8 (Flash, Dreamweaver, etc) cet automne. Les personnes qui nous ont fait leur petite démonstration ont parlé d'une éventuelle disparition du format PDF (pour le web bien évidement). Adobe ayant "absorbé" Macromedia, Adobe pourrait développer un outil couplant PDF et Flash, rendant ainsi les "PDF" qui n'en seront plus, beaucoup plus léger pour le web. Malheureusement, plus aucune nouvelle de cet outil depuis cette présentation Smiley ohwell , quelqu'un aurait-il des infos sur le sujet ?
FrenchConneXion a écrit :
Les personnes qui nous ont fait leur petite démonstration ont parlé d'une éventuelle disparition du format PDF (pour le web bien évidement). Adobe ayant "absorbé" Macromedia, Adobe pourrait développer un outil couplant PDF et Flash, rendant ainsi les "PDF" qui n'en seront plus, beaucoup plus léger pour le web.


Smiley eek

C'est LA

La fin du PDF? Le PDF a me semble-t-il de longues heures devant lui, car (en gardant bien l'idée qu'il n'est pas destiné pour rendre le web plus accessible) il permet l'échange de documents via une plateforme informatique sans perte de mise en page. Il est très pratique pour les imprimeurs.
Il peut donc être affiché sur le web de la même manière qu'il peut être imprimé sur papier (on voit que le PDF n'est pas dédié à l'accessibilité, comme tout ce qui est destiné à être imprimé). Je ne vois pas a priori comment un outil couplant le PDF au Flash pourrait faire la même chose... à cause du Flash destiné principalement à de l'animation pour le web...

Ce nouvel outil serait donc uniquement pensé pour le web? Ils disent dans l'article "hors ligne" également, soit, à condition d'avoir toujours sur soi un support numérique? et toujours non accessible et qui ne remplacera pas le PDF chez l'imprimeur?

Ne pas oublier non plus la facilité avec laquelle on obtient un joli doc en PDF. Avec un logiciel open source comme OOo 2.0, il suffit de saisir son texte, ses tableaux complexes, de le mettre en page avec sa numérotation des pages et ses notes de bas de page et de faire "exporter", "pdf", et hop, c'est tout... aussi simple que de faire enregistrer sous...

Là, avec Adobe on sait pas ce qui nous attend...

A+
Modifié par Vajra (10 Feb 2006 - 14:02)
Administrateur
Le PDF peut être accessible si on rajoute la sémantique qui va bien à la création du document Smiley smile
Felipe a écrit :
Le PDF peut être accessible si on rajoute la sémantique qui va bien à la création du document Smiley smile


En plus! quid du nouvel outil prévu PDF-Flash?
Je me permet d'intervenir dans ce sujet car il me semble que l'ambiance générale ici est "hors de CSS point de salut". Il n'y a pas que des pages web dans la vie même si ces dites pages web permettent de diffuser plus rapidement et plus économiquement un certain nombre d'informations.

Je prends l'exemple du site du journal officiel : le JO se doit d'être diffusé sous format PDF en parallèle de sa version HTML car le JO PDF (dit électronique) est maintenant juridiquement équivalent de l'antique "JO papier".

Et un PDF c'est aussi pratique parce que c'est totalement indépendant du navigateur ! Ca permet de diffuser à moidre frais un document imprimé que les internautes veulent avoir en version "print" et non pas dans une version web (cf. mise en page et typo).

Bref, de grâce, voyez au delà des problématiques purement web !
Administrateur
Entièrement d'accord avec toi, j'ai précisé quelque chose de similaire à la page précédente (et comme nous sommes dans des domaines proches si j'en crois ton email d'inscription, il y a des choses qui sont impossibles à rendre sur une page web à moins de maintenir 2 tonnes de plug-ins pour la plupart propriétaires n'est-ce pas? Smiley smile - et que n'a de toute façon pas le grand public)
Juste une petite contribution. (j'avoue n'avoir pas tout lu sur le thread, si je répète ce qui a été déja dit, je m'en excuse d'avance).

Un autre interet du PDF concèrne les normes qualité ISO/OPQF etc...

Ces normes forcent à avoir des mises en page précises avec des mentions/contenus absolument obligatoires dans le cadre d'une démarche qualité.

Ces mises en page sont extrèmement difficiles à certifier pour une page web, vu les problèmes d'interprétation des différents navigateurs/machines/réglages.

Avec le PDF on est sur que les normes qualités de présentation des documents seront respectées.
Bon, j'ai pas tout lu, mais comme ca me gonfle ces polémiques de geek ..

Alors voilà : PDF est un format devenu universel defacto.

Quant on TRAVAILLE avec l'outils informatique on se tamponne de savoir comment c fait et pourquoi, MAIS on veut facilement avoir accès à l'info, la diffuser et l'échanger .

Pour le moment on est TRES loin du sans papier et du bureau virtuelle - y'a quà voir le nombre de services publics ou privés qui vous gonglent avec " ah mais non je peux pas l'envoyer par email, il faut un fax.."

Offrir la possibilité de télécharger un PDF et SURTOUT PAS un format modifiable de manière évidente participe d'un principe de diffusion de docs de références, n'étant pas destinés à subir une modif qqconques par "l'utilisateur' [même si aujourd'hui c'est assez facile]
Reste le blocage par PW, comme dans les TTX.

Avoir un Acrobat reader ou compatible dans un coin permet de visualiser des plaquettes, doc et autres info avec une grande qualité, une fluidité de navigation (pages, glisser, zoom, etc) sans avoir un ttx ouvert (perso Open Off même en v2 me saoul qd il prend 3 minutes à se lancer sur un ATHLON à 2GHz. ).

Maintenant si le propos est UNIQUEMENT d'imprimer, alors oui, bon, un css 'print' c'est pas mal, mais ce n'est pas suffisant si l'on veut un JOLI doc structuré qui garde toute sa valeur (artistique, culturel, commerciale) et représente l'image de l'émetteur.
Bonjour elz64,

a écrit :

Bon, j'ai pas tout lu, mais comme ca me gonfle ces polémiques de geek ..


Tu aurais dû tout lire ...
Beaucoup de membres partagent ton opinion (geek ou pas) et ce sujet n'a pas pour objectif de livrer une polémique ...

Tu pouvais donc participer à ce débat sans risquer d'en provoquer une, justement !

Smiley cligne
petite contribution en tant qu'utilisateur :

je voulais imprimer cet article
http://dcabasson.developpez.com/articles/javascript/ajax/ajax-autocompletion-pas-a-pas/


Mon premier réflexe a été de me servir du pdf mis à disposition, car cela me donne la certitude que le document sera imprimé exactement comme l'auteur l'a rédigé, avec les sauts de page adéquats etc...

Si je la compare avec un print preview du site, je vois nettement les différences de rendus
Modérateur
Hello,

J'ai une petite question... Où en est-on au niveau de l'implémentation du xsl-fo ? A priori, si les navigateurs en permettaient le rendu, la transformation en pdf ne serait plus nécessaire non ? Je me trompe peut-être, vu que je ne pratique pas, mais j'ai tendance à croire que çà supprimerait les limitations du pdf...

PS: Je n'ai pas tout lu non plus, je n'ai fait que survoler... Désolé, j'y arrive pas à c'te heure-ci... Smiley fatigue
Je crois que ce support ne serait tout simplement pas possible. En effet, XSL-FO a pour but de produire des documents PDF, dans le but de les imprimer. Il y a donc des commandes permettant de présenter le texte sous telle ou telle forme, mais aussi stipulant les sauts de page, les entêtes et pieds sur chaque page... bref, plein de choses qui sont pertinentes dans le cas de l'impression d'un ouvrage, mais qui n'ont pas de sens dans un navigateur.
Pages :