Re: [Liste GTA] mises à jour multiples "in page"

[Olivier Nourry]

Ma crainte sur la double vocalisation est que les 2 infos soient restituées
durant la lecture initiale du tableau. Mais effectivement un aria-hidden
pourrait régler le problème, avec gestion de ce paramètre selon
l'activation de la mise à jour de cette zone (soit en régénérant tout le
.message, ce qui était mon intention première, soit avec aria-atomic, en
vérifiant le support).

Merci pour cette piste!




[image: --]
Olivier Nourry
[image: http://]about.me/oliviernourry



Le 18 octobre 2016 à 16:01, Aurélien Levy  a
écrit :

> Bonjour,
>
> une zone masquée dans le aria-live ne fonctionnera que si tu regénère le
> message à chaque fois ou alors il faudra utiliser aria-atomic pour forcer à
> tout revocaliser et non pas juste la partie qui change.
>
> pour la double vocalisation dans la mesure où ton bouton déclenchant la
> mise à jour est après le tableau il faudra pour avoir le problème que
> l'utilisateur revienne en arrière jusqu'au th du tableau ça me semble pas
> un cas d'usage très courant. Un moyen d'éviter cela tout de même serait de
> mettre un aria-hidden true sur ton texte masqué au blur du bouton
> déclenchant la mise à jour du texte et le repasser à false au focus de ce
> meme bouton si l'utilisateur s'amuse à faire des aller retours
>
> Aurélien
>
> Re-bonjour,
>
> Dans un tableau, très chargé en informations par ailleurs, on a 3 formules
> d'abonnement avec 3 prix différents. A la suite du tableau, l'utilisateur a
> la possibilité d'ajouter ou enlever des options qui vont modifier les 3
> prix. Les formules et montants associés étant affichés à l'écran quelque
> soit la position de lecture courante, l'utilisateur visuel est en mesure de
> voir les changements dès qu'il active ou désactive une option.
> Pour les  utilisateurs non visuels c'est plus compliqué... J'ai fait un
> essai sous NVDA et Firefox: on peut signaler les 3 changements de prix avec
> un aria-live assertive sur chaque cellule contenant un prix qui change. Par
> contre je n'ai pas trouvé le moyen de transmettre en plus l'information
> importante qu'est le nom de la formule. J'ai essayé avec un TH, et un
> aria-labelledby. Le seul recours qu'il semble y avoir est un texte caché
> dans la zone live, mais dans ce cas on a du contenu redondant à chaque fois
> que l'on navigue dans le tableau: celui du TH et celui du texte caché.
>
> Une idée?
>
>
> Olivier Nourry
> [image: http://]about.me/oliviernourry
> 
>
>
>
> ___
> liste_gta mailing 
> listliste_gta@list.accessiweb.orghttp://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>
>
>
> --
> Aurélien Levy
> 
> Temesis
>
>
> ___
> liste_gta mailing list
> liste_gta@list.accessiweb.org
> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>
>
___
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org

Re: [Liste GTA] mises à jour multiples "in page"

[Aurélien Levy]

Bonjour,

une zone masquée dans le aria-live ne fonctionnera que si tu regénère le 
message à chaque fois ou alors il faudra utiliser aria-atomic pour 
forcer à tout revocaliser et non pas juste la partie qui change.


pour la double vocalisation dans la mesure où ton bouton déclenchant la 
mise à jour est après le tableau il faudra pour avoir le problème que 
l'utilisateur revienne en arrière jusqu'au th du tableau ça me semble 
pas un cas d'usage très courant. Un moyen d'éviter cela tout de même 
serait de mettre un aria-hidden true sur ton texte masqué au blur du 
bouton déclenchant la mise à jour du texte et le repasser à false au 
focus de ce meme bouton si l'utilisateur s'amuse à faire des aller retours


Aurélien

Re-bonjour,

Dans un tableau, très chargé en informations par ailleurs, on a 3 
formules d'abonnement avec 3 prix différents. A la suite du tableau, 
l'utilisateur a la possibilité d'ajouter ou enlever des options qui 
vont modifier les 3 prix. Les formules et montants associés étant 
affichés à l'écran quelque soit la position de lecture courante, 
l'utilisateur visuel est en mesure de voir les changements dès qu'il 
active ou désactive une option.
Pour les  utilisateurs non visuels c'est plus compliqué... J'ai fait 
un essai sous NVDA et Firefox: on peut signaler les 3 changements de 
prix avec un aria-live assertive sur chaque cellule contenant un prix 
qui change. Par contre je n'ai pas trouvé le moyen de transmettre en 
plus l'information importante qu'est le nom de la formule. J'ai essayé 
avec un TH, et un aria-labelledby. Le seul recours qu'il semble y 
avoir est un texte caché dans la zone live, mais dans ce cas on a du 
contenu redondant à chaque fois que l'on navigue dans le tableau: 
celui du TH et celui du texte caché.


Une idée?


Olivier Nourry
http://about.me/oliviernourry





___
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org



--
Aurélien Levy

Temesis

___
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org

[Liste GTA] mises à jour multiples "in page"

[Olivier Nourry]

Re-bonjour,

Dans un tableau, très chargé en informations par ailleurs, on a 3 formules
d'abonnement avec 3 prix différents. A la suite du tableau, l'utilisateur a
la possibilité d'ajouter ou enlever des options qui vont modifier les 3
prix. Les formules et montants associés étant affichés à l'écran quelque
soit la position de lecture courante, l'utilisateur visuel est en mesure de
voir les changements dès qu'il active ou désactive une option.
Pour les  utilisateurs non visuels c'est plus compliqué... J'ai fait un
essai sous NVDA et Firefox: on peut signaler les 3 changements de prix avec
un aria-live assertive sur chaque cellule contenant un prix qui change. Par
contre je n'ai pas trouvé le moyen de transmettre en plus l'information
importante qu'est le nom de la formule. J'ai essayé avec un TH, et un
aria-labelledby. Le seul recours qu'il semble y avoir est un texte caché
dans la zone live, mais dans ce cas on a du contenu redondant à chaque fois
que l'on navigue dans le tableau: celui du TH et celui du texte caché.

Une idée?


Olivier Nourry
[image: http://]about.me/oliviernourry

___
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org

Re: [Liste GTA] forçage de valeurs de champ et gestion des messages

[Olivier Nourry]

C'est bien de la validation à la volée.
Effectivement, une live region assertive paraît se justifier dans ce cas de
figure. A tester, comme tu dis...

Sinon, personnellement je n'aime pas les pages où le focus est positionné
sur un champ de saisie à l'ouverture. Car dans ce cas de figure on se
retrouve en mode saisie et non navigation. Et c'est déroutant lorsque l'on
veut utiliser les raccourcis clavier tels que Espace et Backspace pour
naviguer.

Merci en tous cas pour ces éclairages!




[image: --]
Olivier Nourry
[image: http://]about.me/oliviernourry



Le 18 octobre 2016 à 13:04, Alex Bernier  a
écrit :

> Le contrôle de la valeur est-il fait "à la volée" (i.e. par exemple via un
> script, juste après que le focus ait quitté le champ), ou après validation
> du formulaire ? Si on est dans le premier cas, le déplacement du focus est
> à proscrire (cela invaliderait le critère 7.4 sur les changements de
> contexte); si on est dans le second, OK.
>
> Maintenant, parlons d'utilisabilité : ce qui me semble intrusif, dans le
> cas d'utilisation d'un lecteur d'écran, c'est le fait de déplacer le focus
> sur un champ, ce qui va redéclencher le mode formulaire de manière assez
> "impromptue"... (Il faudrait tester pour avoir une idée précise du
> comportement.) On pourrait donc mettre un « aria-live="asertive" » pour
> minimiser le risque que l'utilisateur passe à côté de l'info, sans pour
> autant provoquer un changement de focus.
>
> Alex
>
> Alex Bernier
> --
> Directeur
>
> Association BrailleNet - AccessiWeb
> 12bis avenue Maurice Thorez
> 94200 Ivry sur Seine
>
> Tél. + 33 1 85 09 05 13
>
> Fax  + 33 1 46 70 35 84
>
>
>
> On Tue, Oct 18, 2016 at 12:05:21PM +0200, Olivier Nourry wrote:
> >Merci Alex pour cette suggestion. De fait on mettrait un "polite",
> dans
> >la logique de ne pas être trop intrusif. Mais du coup je me demande
> >s'il n'y a pas un risque que l'utilisateur manque l'info, dans le cas
> >où il poursuit sa saisie et ne laisse pas le temps à l'information
> >d'être restituée. Il peut aussi arriver que l'information soit
> >restituée tardivement, et devienne source de confusion alors que
> >l'utilisateur est arrivé à un stade ultérieur. Qu'en penses-tu?
> >
> >
> >--
> >Olivier Nourry
> >http:// about.me/oliviernourry
> >
> >
> >Le 18 octobre 2016 à 11:57, Alex Bernier
> ><[1]alex.bern...@braillenet.org> a écrit :
> >
> >  Bonjour Olivier,
> >  Plutôt qu'un changement de focus, on peut mettre un "aria-live" sur
> >  le conteneur de l'étiquette/du texte visible référencé via
> >  "aria-labelledby", ce qui permettrait à l'utilisateur d'avoir l'info
> >  sans que ce soit trop intrusif.
> >  Alex
> >  Alex Bernier
> >  --
> >  Directeur
> >  Association BrailleNet
> >  12bis avenue Maurice Thorez
> >  94200 Ivry sur Seine
> >  Tél. [2]+ 33 1 85 09 05 13
> >  Fax  [3]+ 33 1 46 70 35 84
> >  On Tue, Oct 18, 2016 at 11:25:36AM +0200, Olivier Nourry wrote:
> >  >Bonjour la  liste,
> >  >Besoin de vos avis et suggestions sur la situation suivante...
> >  >Un champ de formulaire attend une saisie dont la valeur est
> >  bornée. Par
> >  >exemple: montants mini et maxi. Je prévois de fournir cette
> >  information
> >  >dans l'étiquette, donc avant la saisie.
> >  >Si l'utilisateur saisit une valeur hors bornes, le contrôle de
> >  surface
> >  >modifiera la valeur saisie pour la faire rentrer dans les
> >  bornes (par
> >  >exemple: ramenée à la valeur max si la valeur saisie dépasse la
> >  valeur
> >  >max).
> >  >Auquel cas je vais préconiser de ramener le focus sur le champ
> >  forcé,
> >  >et de soit modifier l'étiquette, soit rajouter l'info que la
> >  valeur a
> >  >été forcée, via un aria-labelledby vers un texte visible.
> >  >Cette approche vous paraît-elle correcte? D'autres suggestions?
> >  >
> >  >--
> >  >Olivier Nourry
> >  >http:// [4]about.me/oliviernourry
> >  >
> >  > Références
> >  >
> >  >Liens visibles
> >  >
> >  >Liens cachés :
> >  >2. [5]http://about.me/oliviernourry
> >  > ___
> >  > liste_gta mailing list
> >  > [6]liste_gta@list.accessiweb.org
> >  > [7]http://list.accessiweb.org/mailman/listinfo/liste_gta_
> >  list.accessiweb.org
> >  ___
> >  liste_gta mailing list
> >  [8]liste_gta@list.accessiweb.org
> >  [9]http://list.accessiweb.org/mailman/listinfo/liste_gta_
> >  list.accessiweb.org
> >
> > Références
> >
> >Liens visibles
> >1. mailto:alex.bern...@braillenet.org
> >2. tel:+ 33 1 85 09 05 13
> >3. tel:+ 33 1 46 70 35 84
> >4. 

Re: [Liste GTA] forçage de valeurs de champ et gestion des messages

[Alex Bernier]

Le contrôle de la valeur est-il fait "à la volée" (i.e. par exemple via un 
script, juste après que le focus ait quitté le champ), ou après validation du 
formulaire ? Si on est dans le premier cas, le déplacement du focus est à 
proscrire (cela invaliderait le critère 7.4 sur les changements de contexte); 
si on est dans le second, OK.

Maintenant, parlons d'utilisabilité : ce qui me semble intrusif, dans le cas 
d'utilisation d'un lecteur d'écran, c'est le fait de déplacer le focus sur un 
champ, ce qui va redéclencher le mode formulaire de manière assez 
"impromptue"... (Il faudrait tester pour avoir une idée précise du 
comportement.) On pourrait donc mettre un « aria-live="asertive" » pour 
minimiser le risque que l'utilisateur passe à côté de l'info, sans pour autant 
provoquer un changement de focus.

Alex

Alex Bernier
--
Directeur

Association BrailleNet - AccessiWeb
12bis avenue Maurice Thorez
94200 Ivry sur Seine

Tél. + 33 1 85 09 05 13

Fax  + 33 1 46 70 35 84



On Tue, Oct 18, 2016 at 12:05:21PM +0200, Olivier Nourry wrote:
>Merci Alex pour cette suggestion. De fait on mettrait un "polite", dans
>la logique de ne pas être trop intrusif. Mais du coup je me demande
>s'il n'y a pas un risque que l'utilisateur manque l'info, dans le cas
>où il poursuit sa saisie et ne laisse pas le temps à l'information
>d'être restituée. Il peut aussi arriver que l'information soit
>restituée tardivement, et devienne source de confusion alors que
>l'utilisateur est arrivé à un stade ultérieur. Qu'en penses-tu?
> 
> 
>--
>Olivier Nourry
>http:// about.me/oliviernourry
> 
> 
>Le 18 octobre 2016 à 11:57, Alex Bernier
><[1]alex.bern...@braillenet.org> a écrit :
> 
>  Bonjour Olivier,
>  Plutôt qu'un changement de focus, on peut mettre un "aria-live" sur
>  le conteneur de l'étiquette/du texte visible référencé via
>  "aria-labelledby", ce qui permettrait à l'utilisateur d'avoir l'info
>  sans que ce soit trop intrusif.
>  Alex
>  Alex Bernier
>  --
>  Directeur
>  Association BrailleNet
>  12bis avenue Maurice Thorez
>  94200 Ivry sur Seine
>  Tél. [2]+ 33 1 85 09 05 13
>  Fax  [3]+ 33 1 46 70 35 84
>  On Tue, Oct 18, 2016 at 11:25:36AM +0200, Olivier Nourry wrote:
>  >Bonjour la  liste,
>  >Besoin de vos avis et suggestions sur la situation suivante...
>  >Un champ de formulaire attend une saisie dont la valeur est
>  bornée. Par
>  >exemple: montants mini et maxi. Je prévois de fournir cette
>  information
>  >dans l'étiquette, donc avant la saisie.
>  >Si l'utilisateur saisit une valeur hors bornes, le contrôle de
>  surface
>  >modifiera la valeur saisie pour la faire rentrer dans les
>  bornes (par
>  >exemple: ramenée à la valeur max si la valeur saisie dépasse la
>  valeur
>  >max).
>  >Auquel cas je vais préconiser de ramener le focus sur le champ
>  forcé,
>  >et de soit modifier l'étiquette, soit rajouter l'info que la
>  valeur a
>  >été forcée, via un aria-labelledby vers un texte visible.
>  >Cette approche vous paraît-elle correcte? D'autres suggestions?
>  >
>  >--
>  >Olivier Nourry
>  >http:// [4]about.me/oliviernourry
>  >
>  > Références
>  >
>  >Liens visibles
>  >
>  >Liens cachés :
>  >2. [5]http://about.me/oliviernourry
>  > ___
>  > liste_gta mailing list
>  > [6]liste_gta@list.accessiweb.org
>  > [7]http://list.accessiweb.org/mailman/listinfo/liste_gta_
>  list.accessiweb.org
>  ___
>  liste_gta mailing list
>  [8]liste_gta@list.accessiweb.org
>  [9]http://list.accessiweb.org/mailman/listinfo/liste_gta_
>  list.accessiweb.org
> 
> Références
> 
>Liens visibles
>1. mailto:alex.bern...@braillenet.org
>2. tel:+ 33 1 85 09 05 13
>3. tel:+ 33 1 46 70 35 84
>4. http://about.me/oliviernourry
>5. http://about.me/oliviernourry
>6. mailto:liste_gta@list.accessiweb.org
>7. 
> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>8. mailto:liste_gta@list.accessiweb.org
>9. 
> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
> 
>Liens cachés :
>   11. http://about.me/oliviernourry

> ___
> liste_gta mailing list
> liste_gta@list.accessiweb.org
> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org


___
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org

Re: [Liste GTA] forçage de valeurs de champ et gestion des messages

[Alex Bernier]

Bonjour Olivier,

Plutôt qu'un changement de focus, on peut mettre un "aria-live" sur le 
conteneur de l'étiquette/du texte visible référencé via "aria-labelledby", ce 
qui permettrait à l'utilisateur d'avoir l'info sans que ce soit trop intrusif.

Alex

Alex Bernier
--
Directeur

Association BrailleNet
12bis avenue Maurice Thorez
94200 Ivry sur Seine

Tél. + 33 1 85 09 05 13

Fax  + 33 1 46 70 35 84



On Tue, Oct 18, 2016 at 11:25:36AM +0200, Olivier Nourry wrote:
>Bonjour la  liste,
>Besoin de vos avis et suggestions sur la situation suivante...
>Un champ de formulaire attend une saisie dont la valeur est bornée. Par
>exemple: montants mini et maxi. Je prévois de fournir cette information
>dans l'étiquette, donc avant la saisie.
>Si l'utilisateur saisit une valeur hors bornes, le contrôle de surface
>modifiera la valeur saisie pour la faire rentrer dans les bornes (par
>exemple: ramenée à la valeur max si la valeur saisie dépasse la valeur
>max).
>Auquel cas je vais préconiser de ramener le focus sur le champ forcé,
>et de soit modifier l'étiquette, soit rajouter l'info que la valeur a
>été forcée, via un aria-labelledby vers un texte visible.
>Cette approche vous paraît-elle correcte? D'autres suggestions?
> 
>--
>Olivier Nourry
>http:// about.me/oliviernourry
> 
> Références
> 
>Liens visibles
> 
>Liens cachés :
>2. http://about.me/oliviernourry

> ___
> liste_gta mailing list
> liste_gta@list.accessiweb.org
> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org


___
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org

[Liste GTA] forçage de valeurs de champ et gestion des messages

[Olivier Nourry]

Bonjour la  liste,

Besoin de vos avis et suggestions sur la situation suivante...

Un champ de formulaire attend une saisie dont la valeur est bornée. Par
exemple: montants mini et maxi. Je prévois de fournir cette information
dans l'étiquette, donc avant la saisie.
Si l'utilisateur saisit une valeur hors bornes, le contrôle de surface
modifiera la valeur saisie pour la faire rentrer dans les bornes (par
exemple: ramenée à la valeur max si la valeur saisie dépasse la valeur max).
Auquel cas je vais préconiser de ramener le focus sur le champ forcé, et de
soit modifier l'étiquette, soit rajouter l'info que la valeur a été forcée,
via un aria-labelledby vers un texte visible.

Cette approche vous paraît-elle correcte? D'autres suggestions?



[image: --]
Olivier Nourry
[image: http://]about.me/oliviernourry

___
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org