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
