Bonjour,
Si le DOM est robuste non, dés lors qu'on peut travailler sur un DOM où,
ad-minima, les balises sont correctements imbriquées et correctement fermées il
n'y à pas de soucis.
La seule gêne d'un abus de liste sera pour l'utilisateur.
L'exemple typique sont les résultats de recherches avec des structures
complexes par exemple titre de page, chapeau, infos complémentaires où on
trouve des structures genre UL - LI - H - P - UL - LI là où une structure
concurrente H - P - UL - LI est bien plus profitable pour l'utilisateur.
En revanche du point de vue des perfs ce qui coute c'est la consolidation d'un
code buggé.
Mais encore une fois à notre époque surpuissante la chute de perfs semble
négligeable, JAWS par exemple travaillent très bien avec des pages comportant
des centaines d'erreurs d'imbrication ou de fermeture.
Mes réflexions datent d'une époque où le traitement du code relevait du
parcours du combattant.
Le problème est alors plutôt à chercher dans la robustesse des fonctionnalités
d'exploration du contenu fournies par les AT.
________________________________
Jean-Pierre Villain - Qelios - 06 98 08 50 49
________________________________
De : Carsten Meyer <[email protected]>
À : [email protected]
Envoyé le : Jeudi 12 avril 2012 9h05
Objet : Re: [Liste GTA] Re : Re : Re : Re : Souci de vitesse de verbalisation
de listes avec synthèse vocale
Bonjour la liste,
Merci Jean-Pierre pour ce riche partage d'info et d'expérience. En dehors de
l'aspect HTML5/CSS3 encore en chantier, et d'un éventuel défaut de fermeture de
balise, je voulais revenir sur l'aspect strictement sémantique des listes.
On l'a vu en formation EAE, souvent un abus de sémantique consiste à tout
transformer en liste dans la structure HTML des pages. Ainsi, on trouve des
items de liste avec une masse de contenu est une arbo HTML interne qui donne le
vertige. Est-ce que ce problème de vitesse de lecture peut être lié à l'usage
de ces listes au lieu des divisions pour les blocs ayant un contenu lourd et
complexe ?
Bonne journée à tous
Carsten MEYER
Expert Accessiweb 2.1 en évaluation
Développeur front-end free-lance
Le 11 avril 2012 21:16, jean-pierre villain <[email protected]> a écrit :
La robustesse du DOM impacte très directement les performances d'une AT.
>
>Lorsque vous vous préparer à développer un screen reader (ne faites jamais ça
>c'est trop monacal comme job) vous êtes confronté à la préparation du code et
>c'est là que commence les emmerdes.
>
>
>
>De manière un peut caricaturale il y à une première phase ruineuse qui
>consiste à récupérer la sémantique du code et des séquences exotiques comme,
>par exemple la ponctuation.
>
>
>Pour la ponctuation par exemple une solution efficace consiste simplement à
>remplacer la ponctuation par des séquences de caractères genre "point",
>"virgule" etc) à la volée lors de la vocalisation (mais attention chute de
>perfs) ou directement dans le bumper (mais attention temps de préparation plus
>long).
>
>
>J'ai le souvenir dans les années 2003/2004 que le temps de traitement dans le
>bumper en java coutait jusqu'à 2 secondes pour une page "normale" par exemple.
>A l'époque ou lorsque qu'on se bricole un screen reader dans son coin c'est la
>méthode la plus efficace : la vocalisation est du coup fluide et continue et
>surtout déchargée entièrement sur le TTS.
>
>
>Dans les AT modernes j'imagine qu'on procède plutôt à la volée. C'est ce qui
>expliquerais les petits à-coups de vocalisation qui'on peut avoir au milieu
>d'un paragraphe par exemple : rechargement du tampon de vocalisation ou
>collision avec un processus système prioritaire (le cauchemard du
>multitheading java sous windows XP :) ).
>
>
>
>Evidemment le même procédé est utilisé pour la vocalisation des "balises"
>genre "liste de trois items, puce, puce, puce...")
>
>
>Par exemple pour vocaliser une liste l'opération consiste ( là aussi de
>manière très abrégée) à stocker dans une data list, la structure en cours de
>vocalisation. Du coup, évidemment, la moindre erreur DOM rends le bouzin
>délicat : on sait où elle commence et la mission impossible consiste à trouver
>où elle termine :) .
>Si le code renvoyé par le navigateur n'est pas ou mal corrigé par exemple
>c'est le screen reader qui prends ces corrections en charge. Si insérer un
>flag de fermeture à un P défaillant n'est pas trop complexe (le nombre
>d'enfant d'un P étant limité), pour un LI, un UL ou un TABLE c'est simplement
>l'enfer, le nombre d'enfant étant illimité en type et en nombre.
>Donc on fait deux trois tests récursifs pour tenter de consolider la structure
>si on ne trouve pas le flag de fermeture ou si on détecte une incohérence et
>si c'est trop couteux on bricole, par exemple en considèrent que le LI se
>ferme avant le prochain élément de type block.
>
>La seconde phase de préparation du code consiste à assurer la navigation par
>type, là deux techniques sont possibles des techniques de navigation pas à pas
>(à partir d'un élément je cherche à la volée l'élément suivant en me basant
>sur le flag d'ouverture) ou des techniques de flags (de manière trivial on
>ajoute des ID ou des flags quelconque sur chaque élément et on gère la nav et
>la structure via des collections).
>La technique des ID étaient par exemple la technique de base des premiers
>lecteur Daisy puisqu'on assurait ensuite via JS la production d'un sommaire
>dynamique de manière très simple à partir du moteur HTML de rendu.
>
>Si généralement il suffit de gérer des collections en se basant sur le seul
flag d'ouverture dans le cas des listes ou des tableaux, du fait de
l'imbrication, le traitement récursif peut devenir très couteux.
>
>Je ne pense pas que ce soit le cas ici, les puissances disponibles rendant ces
>traitements acceptables de nos jours mais au début dans les années 2000 quand
>on s'amusait à développer des systèmes de screen reader par exemple avec le
>TTS MBrola (top niveau mais très couteux en temps) la moindre défaillance du
>DOM faisait chuter les perfs en lecture de manière dramatique.
>
>C'est la raison pour laquelle, entre autre, la robustesse du code est si
>importante la base du traitement de code c'est du récursif et le premier
>développeur de base qui à traité du récursif connait la sanction : 1 erreur,
>mille emmerdes et tant pis pour le film du soir, le ciné ou le rendez-vous :)
>
>Donc moi le premier test que je ferais c'est de vérifier la robustesse du DOM,
>ne serait-ce que pour
éliminer l'hypothèse... ;)
>
>Mais bon les cadors de chez Temesis ou Tanaguru pourraient mieux que moi
>expliquer le voyage intersidéral dans le code XML, les traitements de code
>entre un screen reader et un moteur de détection sont, à la base, strictement
>identiques et moi j'ai abandonné le développement avant que les moteurs Xpath
>ou les requêteurs genre SPARQL résolvent peut ou prou les problèmes de perfs.
>
>Mais dans le cas de Bertrand le truc est sans doute plus simple : HTML5 + CSS3
>+ JS +NAVIGATEUR + OS + AT + UTILISATEUR = grand saut dans l'inconnu, point
>barre !
>
>JPV
>
>
>
>________________________________
>
>
>
>
>________________________________
> De : Victor Brito <[email protected]>
>À : "[email protected]" <[email protected]>
>Envoyé le : Mercredi 11 avril 2012 18h51
>Objet : [Liste GTA] Re : Re : Re : Souci de vitesse de verbalisation de
>listes avec synthèse vocale
>
>
>
>Salut, Jean-Pierre,
>
>
>Tu veux dire qu'un code HTML invalide du point de vue de la syntaxe peut
>perturber une synthèse vocale, n'est-ce pas ?
>
>Victor Brito
>Intégrateur XHTML / CSS –
Expert Accessiweb en évaluation
>
>
>________________________________
> De : jean-pierre villain <[email protected]>
>À : "[email protected]" <[email protected]>
>Envoyé le : Mercredi 11 avril 2012 18h06
>Objet : [Liste GTA] Re : Re : Souci de vitesse de verbalisation de listes
>avec synthèse vocale
>
>
>Bonjour,
>
>
>Heu.... je dirais surtout ne rien faire !
>
>
>Pour ma part je ne pense pas que le problème viennent du réglage utilisateur,
>il n'y à aucune raison à ça.
>
>
>On a certainement simplement à faire avec l'utilisation irraisonnée de
>technologies (Html 5/CSS3) dont on ne cesse de dire qu'en l'état ces technos
>sont utilisables sans aucune garantie de résultats surtout avec des versions
>d'AT ou de navigateur pas maintenus.
>
>
>L'utilisation de speech serait de toute manière fortement déconseillée
>puisqu'il n'y a pas de raison à ce dysfonctionnement.
>
>
>En revanche, au cas où : vérifier le code Html, ça peut ressembler aussi à un
>joli tango artistique d'un couple AT/Navigateur épuisé de devoir corriger les
>erreurs de code ;)
>
>
>Vous n'imaginez pas combien les perfs d'un TTS peuvent être sensible aux
>erreurs de structure DOM :)
>
>
>
>Après en mode de test dégradé on doit pouvoir trouver facilement la cause :
>tester le code sans css ni JS et ainsi de suite.
>
>
>Tient nous au courant, c'est intéressant comme soucis.
>
>
>
>
>
>________________________________
>Jean-Pierre Villain - Qelios - 06 98 08 50 49
>
>
>
>________________________________
> De : Victor Brito <[email protected]>
>À : "[email protected]" <[email protected]>
>Envoyé le : Mercredi 11 avril 2012 17h42
>Objet : [Liste GTA] Re : Souci de vitesse de verbalisation de listes avec
>synthèse vocale
>
>
>Salut, Bertrand, bonjour la liste,
>
>
>À moins de recourir à la propriété CSS speech-rate (mais, malheureusement, à
>part sous Opera, l'implémentation des propriétés CSS aural ou speech est quasi
>inexistante), je crains qu'on ne puisse rien faire. Le problème vient
>certainement des (dé)réglages du lecteur d'écran employé.
>
>Victor Brito
>Intégrateur XHTML / CSS – Expert Accessiweb en évaluation
>
>
>________________________________
> De : Bertrand Cochet <[email protected]>
>À : [email protected]
>Envoyé le : Mercredi 11 avril 2012 15h51
>Objet : [Liste GTA] Souci de vitesse de verbalisation de listes avec synthèse
>vocale
>
>
>
>
>Bonjour la liste,
>J'interviens en ce moment sur la mise en conformité du site d'une importante
>université en région rhône-alpes.
>
>Le site a été créé en HTML 5 et CSS 3 avec la présence de quelques scripts.
>
>Il s'avère que des étudiants ont effectué des tests sur différentes
>thématiques. L'un d'entre eux, mal-voyant, a testé le site en recette avec une
>synthèse vocale (à priori Jaws).
>
>Il a remonté un point surprenant : la vocalisation des listes de type <ul> (et
>uniquement des listes) se ferait à un rythme qui rend la compréhension du
>contenu impossible.
>
>Les tests effectués avec NVDA et Jaws 12 sont pourtant concluants de notre
>côté !
>
>L'étudiant en question étant en stage actuellement, nous ne pouvons obtenir
>plus de précisions sur le test, la version utilisée de Jaws, etc. Notre client
>direct attend toutefois une prise en charge de ce point.
>
>Ma question est donc la suivante : avez-vous déjà rencontré ce type de retours
>sur la prise en charge d'items de liste via une synthèse vocale ?
>
>Si c'est le cas, connaissez-vous un moyen ou une technique pour normaliser la
>vocalisation sans pour autant perturber les réglages par défaut des autres
>utilisateurs de dispositifs vocaux ?
>
>Je vous remercie par avance pour vos avis éclairés !
>
>Bertrand Cochet // Webdesigner // Expert Accessiweb en Evaluation 2.0
>
> bertrand cochet
>webdesigner
>[email protected]
>tél. : +33 4 37 37 25 10
>fax : +33 4 37 37 25 19 acti
>agence digitale
>289, rue garibaldi 69007 lyon
>www.acti.fr
>blog.acti.fr
>
>
>_______________________________________________
>liste_gta mailing list
>[email protected]
>http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>
>
>
>_______________________________________________
>liste_gta mailing list
>[email protected]
>http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>
>
>
>_______________________________________________
>liste_gta mailing list
>[email protected]
>http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>
>
>
>_______________________________________________
>liste_gta mailing list
>[email protected]
>http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>
>
>
>_______________________________________________
>liste_gta mailing list
>[email protected]
>http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>
>
_______________________________________________
liste_gta mailing list
[email protected]
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
_______________________________________________
liste_gta mailing list
[email protected]
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
