Re: [Liste GTA] Carousel embla

[Aurélien Levy]

Les exemples dispo sur
https://davidcetinkaya.github.io/embla-carousel/examples ne sont pas du
tout accessibles en tout cas.
Après ce que je comprend de ce script c'est surtout qu'il offre une API
pour pouvoir se construire soit même son carrousel sur mesure plus
facilement un peu comme https://swiperjs.com/

Aurélien Levy
Directeur général
--
Temesis
06 64 17 64 61


Le ven. 13 nov. 2020 à 19:34, giuseppe.rosa <
giuseppe.r...@dgfip.finances.gouv.fr> a écrit :

> Bonjour la liste,
>
> Je ne suis pas trop pour les carousels, mais on m'affirme que le carousel
> embla est "super".
>
> Je voulais savoir si certains avait regardé s'il était accessible.
> https://github.com/davidcetinkaya/embla-carousel
>
> J'ai jeté un rapide coup d'oeil, sur un exemple donné, mais bien qu'il
> soit utilisable au clavier, je n'ai pas l'impression qu'il soit en mesure
> de vocaliser les commandes (plus de lecteur installé). Je reste très
> sceptique bien que celui qui veut me le faire adopter affirme qu'il est
> accessible (et même développé par des membres d'une société travaillant sur
> ce domaine).
>
> Si vous avez des retours, je suis preneur.
>
> Bon week-end à tous...
>
> Cordialement,
> Giuseppe ROSA
>
>
>
> ___
> 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] critère 11.13 (RGAA 4) et autocomplete=on

[Aurélien Levy]

Bonjour Olivier,

le fonctionnement correct du navigateur tiens alors à la déduction qui est
faite automatiquement coté navigateur sur la nature du champ donc pas
forcément fiable  (ou alors avec proposition simplement basé sur historique
de saisie) et par ailleurs cela ne répondra pas au but initial de ce
critère qui est de permettre à des outils de reconnaitre les champs pour
par exemple y ajouter des icônes.

Donc personnellement j'aurai tendance à invalider.

Par contre il y a un cas non couvert par wcag problématique c'est lorsqu'il
est demander par exemple un code postal avec des suggestions de saisies
custom et donc le format nécessite forcément l'usage des suggestions custom
pour remplir le champ. Sur ce genre de cas si on met l'autocomplete tel que
recommandé par wcag la fonction native du navigateur remplira le champ avec
une valeur erronée et le menu de suggestions du navigateur aura tendance à
se mettre par dessus les suggestions custom

Aurélien Levy
Directeur général
--
Temesis
06 64 17 64 61


Le sam. 25 janv. 2020 à 08:26, Olivier Nourry  a
écrit :

> Bonjour la liste,
>
> J’aimerais avoir votre avis sur l’utilisation de autocomplete=on, dans le
> cadre du critère 11.13 du RGAA4: « La finalité d’un champ de saisie
> peut-elle être déduite pour faciliter le remplissage automatique des champs
> avec les données de l’utilisateur ? »
>
> Dans le RGAA4 et les WCAG 2.1, il est fait mention de valeurs explicites
> (et pertinentes) pour autocomplete. Mais si on utilise « on » comme valeur
> d’autocomplete, avec des étiquettes de champ non ambigües comme « Nom », «
> Prénom », etc., le navigateur se débrouille très bien, et fournit le
> service attendu. Pour ma part j’aurais donc tendance à valider cette
> pratique, dans ces limites, en faisant tout de même une reco pour une
> valeur plus explicite.
>
> Qu’en pensez-vous?
>
>
> Olivier Nourry
> Access First
>
>
> ___
> 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] Plan de marquage / Statistique lecteurs d'écran

[Aurélien Levy]

c'est simple tu ne peux pas ;)

Aurélien Levy
Directeur général
--
Temesis
06 64 17 64 61


Le ven. 10 janv. 2020 à 17:16, ESTELLE RENAUD <
estelle.ren...@recherche.gouv.fr> a écrit :

> Bonjour,
>
> Nous aimerions récupérer des stats sur les lecteurs d’écrans utilisés sur
> nos sites (en cours de refonte sous Drupal).
>
> L’un d’entre vous a-t-il une expérience sur ce sujet ? Y-a-t-il des points
> à spécifier au niveau du plan de marquage ?
>
> D’avance merci pour vos retours et bon week-end,
>
> Estelle
>
>
>
>
>
> 
>
> *Estelle Renaud*
>
> Chef de projet web . accessibilité numérique
> SG | Delcom | Bureau de la communication pour l'Enseignement supérieur et
> la Recherche
> Ministère de l'Enseignement supérieur, de la Recherche et de l'Innovation
> 1, rue Descartes - 75231 Paris cedex 05
> Tél. +33 (0)1 55 55 89 49
>
> esr.gouv.fr
>
> etudiant.gouv.fr
>
>
>
>
> ___
> 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] Applis mobiles (& React Native)

[Aurélien Levy]

il y a tout ce qu'il faut dans la norme européenne
https://www.etsi.org/deliver/etsi_en/301500_301599/301549/02.01.02_60/en_301549v020102p.pdf

Aurélien Levy
Directeur général
--
Temesis
06 64 17 64 61


Le ven. 22 nov. 2019 à 12:52, Frédéric Lecourbe  a
écrit :

> Bonjour la liste,
> Je me permets de rebondir sur ce mail car je recherche également des
> informations mais sur *l'accessibilité des bornes* (achat de tickets en
> gare par exemple, bornes interactives, etc). Un sujet intéressant puisqu'il
> associe des questions d'accessibilité numérique et physique.
>
> Merci et bonne journée,
>
> Frédéric Lecourbe
> Designer - Publicis Sapient
>
> Le ven. 22 nov. 2019 à 12:39, Audrey Williamson  a
> écrit :
>
>> Merci beaucoup pour vos réponses !
>> Super docs et articles !
>>
>> à+
>> Audrey
>>
>> Le ven. 22 nov. 2019 à 10:50, Aurélien Levy 
>> a écrit :
>>
>>> Bonjour Audrey,
>>>
>>> La documentation de Facebook sur le sujet est plutôt pas mal :
>>> https://facebook.github.io/react-native/docs/accessibility
>>>
>>> Deux autres articles intéressant
>>> https://callstack.com/blog/react-native-android-accessibility-tips/
>>> https://medium.com/substantial/accessibility-in-react-native-5b47047ca346
>>>
>>> Aurélien Levy
>>> Directeur général
>>> --
>>> Temesis
>>> 06 64 17 64 61
>>>
>>>
>>> Le ven. 22 nov. 2019 à 10:11, Maud DUPUIS-CAILLOT <
>>> mdup...@polymorphe-design.fr> a écrit :
>>>
>>>> Il y a celle de 2016 :
>>>> http://www.braillenet.org/wp-content/uploads/GTA22_LivreBlanc_Mobile.pdf
>>>>
>>>> L'accessibilité des sites Web et des applications pour les mobiles
>>>> Livre Blanc – Août 2016 Coordonné par Olivier NOURRY
>>>>
>>>>
>>>> *Maud DUPUIS-CAILLOT*
>>>> Eurl Polymorphe Design
>>>> 166 rue du gros bois 69380 Chazay d’Azergues - France
>>>> +33 (0)4 78 66 08 72
>>>> +33 (0)6 14 30 05 50
>>>> *mdup...@polymorphe-design.fr  *
>>>> *www.polymorphe-design.fr* <http://www.polymorphe-design.fr>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Le 22 nov. 2019 à 10:03, Audrey Williamson  a écrit
>>>> :
>>>>
>>>> Hello la liste,
>>>>
>>>> Est-ce que vous auriez des références / lectures récentes à me
>>>> conseiller à propos de l'accessibilité des applications mobiles ?
>>>> Dans mon cas il s'agit d'une appli développée en React Native donc si
>>>> vous avez connaissance de recommandations liées à l'utilisation de cette
>>>> techno je suis preneuse aussi !
>>>>
>>>> Merci d'avance pour vos conseils,
>>>>
>>>> Bonne journée,
>>>> Audrey Williamson
>>>>
>>>>
>>>> ---
>>>> UX & Product Manager – Mediapart
>>>> ___
>>>> 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 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 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] Applis mobiles (& React Native)

[Aurélien Levy]

Bonjour Audrey,

La documentation de Facebook sur le sujet est plutôt pas mal :
https://facebook.github.io/react-native/docs/accessibility

Deux autres articles intéressant
https://callstack.com/blog/react-native-android-accessibility-tips/
https://medium.com/substantial/accessibility-in-react-native-5b47047ca346

Aurélien Levy
Directeur général
--
Temesis
06 64 17 64 61


Le ven. 22 nov. 2019 à 10:11, Maud DUPUIS-CAILLOT <
mdup...@polymorphe-design.fr> a écrit :

> Il y a celle de 2016 :
> http://www.braillenet.org/wp-content/uploads/GTA22_LivreBlanc_Mobile.pdf
> L'accessibilité des sites Web et des applications pour les mobiles
> Livre Blanc – Août 2016 Coordonné par Olivier NOURRY
>
>
> *Maud DUPUIS-CAILLOT*
> Eurl Polymorphe Design
> 166 rue du gros bois 69380 Chazay d’Azergues - France
> +33 (0)4 78 66 08 72
> +33 (0)6 14 30 05 50
> *mdup...@polymorphe-design.fr  *
> *www.polymorphe-design.fr* <http://www.polymorphe-design.fr>
>
>
>
>
>
> Le 22 nov. 2019 à 10:03, Audrey Williamson  a écrit :
>
> Hello la liste,
>
> Est-ce que vous auriez des références / lectures récentes à me conseiller
> à propos de l'accessibilité des applications mobiles ?
> Dans mon cas il s'agit d'une appli développée en React Native donc si vous
> avez connaissance de recommandations liées à l'utilisation de cette techno
> je suis preneuse aussi !
>
> Merci d'avance pour vos conseils,
>
> Bonne journée,
> Audrey Williamson
>
>
> ---
> UX & Product Manager – Mediapart
> ___
> 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 mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org

Re: [Liste GTA] Image utilisée au sein d'un mot

[Aurélien LEVY]

Oui ou sinon ton mot avec iconeton mot sans icone 

Aurélien 



De: "Corinne Schillinger"  
À: "liste gta"  
Envoyé: Lundi 2 Octobre 2017 12:26:48 
Objet: [Liste GTA]Image utilisée au sein d'un mot 

Bonjour à tous, 

Je me trouve face à un problème d'intégration que je ne voie pas comment régler 
de manière accessible. 
Du coup, je m’en remets à vos lumières. :) 

Sur la maquette que je dois traiter, une icône est utilisée au sein d’un mot en 
substitution d’une lettre. 
Une image valant mille mots, voici ce dont il est question : 

Le « A » est remplacé par l’icône de la marque Alsace, que je ne peux obtenir 
qu’en utilisant une image. 
La solution qui me semble la plus appropriée consiste à transformer le titre « 
nos prestations » en une image en renseignant l’alternative de cette dernière. 

Mais peut-être avec-vous une suggestion plus pertinente ? 

Je vous souhaite à tous un bon appétit et une bonne après-midi, 
Corinne 

— 
Mail : [ mailto:cori...@inseo.fr | cori...@inseo.fr ] 
Téléphone : 03 88 74 72 37 
Site internet : [ http://www.inseo.fr/ | http://www.inseo.fr ] 




___ 
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] Lien composite

[Aurélien LEVY]

non pas besoin puisque décoratif par contre il te faut un lang="en" sur le span 
ou le lien du coup.
Seul cas où tu pourrais en avoir besoin c'est si le drapeau est utilisé pour 
indiqué un pays et non une langue par exemple canada - english, canada - 
français

Aurélien

- Mail original -
De: "Karine Bardary" 
À: "liste gta" 
Cc: "Karine Bardary" 
Envoyé: Lundi 2 Octobre 2017 10:00:28
Objet: [Liste GTA] Lien composite

Bonjour,

Je me pose une question métaphysique sur l'évaluation du critère 6.1 pour un
lien composite :  le lien est composé d'une image avec alternative vide
représentant un drapeau, et d'un texte donnant la langue.
Le tout est bien restitué par NVDA. 
Faut-il une alternative dans ce cas ou pas ? 

  https://...;> 
  https://.../images/header_topbar_language-united-kingdom.png; /> 
  English 

Merci de vos lumières et bonne journée !

Karine Bardary
Mobile : 06 07 36 18 77





___
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] questions graphiques associés à des tableaux statistiques

[Aurélien Levy]

La solution du futur sans humain des gens riches et fortunés :
tableau des données brutes + ce genre de service 
https://automatedinsights.com/

(ça commence à 1000$ par mois)

Aurélien


Bonjour,

Plus simple, une liste des point saillants de la courbe :

  * 5 janvier 2010 : 55
  * 2 mai 2011 : 82
  * 2 juillet 2011 : 71
  * 9 juin 2012 : 89

A priori, selon la description que tu en fait, les tendances 
croissante ou décroissante n'apporte pas d'information utile, c'est 
juste une manière de présenter une liste de valeur.


Le problème dans la description que tu propose c'est le "bruit" qui 
nuit à la compréhension de l'information et l'information c'est les 
valeurs.


Tu peux également utiliser, en complément une description des 
tendances si tu penses que c'est nécessaire.


Par exemple en introduction de la liste de valeurs. : "Depuis janvier 
2010  la tendance a suivie une hausse régulière sauf entre mai et 
juillet 2011."


JPV


Le 07/03/2017 à 17:18, ERWAN LE GALL a écrit :

Bonjour,

En phase d’exploration sur le sujet de la production de rapports 
statistiques accessibles et surtout les graphiques qui les 
synthétisent, auriez-vous connaissance de bibliothèques logicielles 
permettant de générer des textes descriptifs de type :


« courbe statistique : depuis la valeur 55 au 5 janvier 2010 
l’augmentation linéaire régulière jusqu’à la valeur 82 au 2 mai 2011 
se transforme en décroissance rapide sur les deux mois suivants à la 
valeur 71 pour repartir ensuite avec une hausse plus modérée jusqu’au 
9 juin 2012 où la valeur 89 est atteinte ».


Est-ce la bonne stratégie pour décrire un tel graphique, par exemple 
à une personne aveugle ? Comment sinon synthétiser des tableaux 
statistiques où le foisonnement des données et leur fractionnement 
nuit à leur intelligibilité ?


Merci de vos retours,

Bien cordialement,

Erwan le Gall
Chef de projet applications, expert accessibilité, expert Afnor & ISO
Direction Numérique pour l'Éducation
Ministère de l’Éducation nationale,de l'Enseignement supérieur et de 
la Recherche

Pièce 120 bis — Bât. A
107, rue de Grenelle - 75 007 Paris - tel. : 01.55.55.98.77/ 
06.24.45.84.69 (mercredi)


[ merci de me placer en (co)destinataire principal en cas de demande 
d’action ]


Information :
Ce message et toutes les pièces jointes (ci-après le « message ») 
sontconfidentiels et établis à l’intention exclusive
de ses destinataires. Toute utilisation de ce message non conforme à 
sa destination, toute diffusion ou toute publication,
totale ou partielle, ne peut être fait qu’avec l’autorisation 
expresse de l’émetteur. Si vous recevez ce message par erreur,
merci de le détruire sans en conserver de copie et d’en avertir 
immédiatement l’émetteur.
Internet ne permettant pas de garantir l’intégrité de ce message, la 
responsabilité de l’émetteur ne peut être engagée
s’il a été modifié, altéré, déformé ou falsifié, s’il n’a pas été 
signé électroniquement.


« L'informatique n'est pas plus la science des ordinateurs que 
l'astronomie n'est celle des télescopes. »  Michael R. Fellows, Ian 
Parberry /Computing Research News/



___
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



--
Aurélien Levy

Temesis

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

Re: [Liste GTA] Panneau dépliant et menu de navigation

[Aurélien Levy]

Bonjour


Bonjour la liste,

...

1)Panneau  dépliant :

Sur quels tests invalider ce composant d’interface qui ne fait pas 
appel à un rôle ARIA correspondant à un motif de conception ?


aucun il n'y aucune obligation d'utiliser les motifs de conception 
(heureusement) et le fonctionnement c'est plutôt : tu utilises tel ou 
tel role aria -> tu es dans un motif de conception -> tu dois 
l'implémenter correctement. Particulièrement le design pattern menu est 
totalement à proscrire pour ce qui concerne des menus de navigation dans 
un site, il s'agit d'un design pattern pour faire des menus applicatifs 
(copier / coller / autres actions dans la page). Enfin pour rappelle dès 
que tu fais des motifs de conception tu devras vérifier leur rendu dans 
la base de référence.


Sur la thématique des scripts ?

pas contre oui tu peux par exemple demander l'ajouter de aria-expanded 
ou aria-haspopup ou des titles ou de textes cachés pour véhiculer des 
infos sur le nom, l'état, le role des composants


La prise de focus n’est pas circonscrite aux éléments focusables de ce 
panneau. Non conforme sur le 12.3.2 ?


oui tu peux invalider l'ordre logique de navigation au clavier (mais en 
soit si en dehors d'un motif de conception rien n'oblige à bloquer le 
focus dans le menu)


2)Mécanisme de navigation sur plusieurs niveaux

L'utilisateur non-voyant n'est pas informé du mécanisme de navigation 
sur plusieurs niveaux de profondeur (avec rechargement de la liste).



il l'est si il y a bien une structure de liste imbriquée


Il ne peut pas distinguer les items qui ouvre un niveau inférieur 
(indiqué visuellement par un chevron).


èNon conforme sur le 7.1.1 ? Le nom n’est pas explicite et les 
changements d’états ne sont pas accessibles aux technos d’assistance.


oui c'est pour cela que tu as besoin de aria-expanded par exemple + cela 
devrait être des button et non des lien


--
Aurélien Levy

Temesis

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

Re: [Liste GTA] utilisation de l'attribut scope sur un tableau à double entrée ?

[Aurélien Levy]

Bonjour Hervé,

oui c'est possible du moment que tu n'as pas plusieurs lignes d'entête 
ou plusieurs colonne d'entête dans le même tableau


Aurélien


Bonjour,

Pouvez-vous, svp, m'ôter un doute ?

Pouvez-vous me confirmer si on peut utiliser des attributs scope à la 
fois sur les entêtes de colonnes et sur les entêtes de lignes d'un 
tableau (simple) à double entrée ?


(bien sûr dans le cas où le scope s'applique bien à toute la colonne 
ou à toute la ligne)


En relisant le RGAA 3, je pense que oui mais ce qui me met le doute ce 
sont de vieilles notes datant d'AccessiWeb V1 dans lesquelles je 
m'étais noté que scope était réservé aux tableaux à simple entête (on 
ne pouvait mettre que du scope="row" ou que du scope="col" dans un 
même tableau mais pas les deux à la fois).


Je ne sais pas si c'est une consigne qui effectivement était valable 
en AccessiWeb V1 ou si c'est une erreur dans mes notes.


Merci pour votre éclairage.

*Hervé CHUZEVILLE*



___
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

Re: [Liste GTA] Ouverture de menu et critère 7.1

[Aurélien Levy]

Bonjour,


Bonjour,

"(pour ma part je ne met pas d'aria-controls car cela force un 
comportement applicatif sur voiceover osx qui est particulièrement 
rébarbatif pour les utilisateurs surtout si tu en as plusieurs (oblige 
à faire un raccourci clavier à trois touches pour entrer et sortir du 
sous menu)"


Je suis un peu dubitatif sur cette approche, Voiceover osx ne 
représente pas, loin de là, la majorité des utilisateurs et si je 
comprends bien qu'on veuille en améliorer le comportement il y a le 
risque important de désactiver le support de fonctionnalités liées à 
aria-controls dans d'autres technologies d'assistance et qui seraient 
pour ces utilisateurs indispensables.


à ma connaissance hormis sur jaws 18 aria-controls n'est pour l'instant 
pas pris en charge ce qui limite quand même son intérêt (surtout que la 
base de référence est en encore en jaws 17)


Du coup je ne supprimerais pas aria-controls, au contraire je 
l'implémenterais "au cas où".


Les utilisateurs de VO seront certes légèrement impactés mais je 
préfère ça à la situation où un utilisateur serait empêché.


J'aurais la même approche sur le fait que lorsque le contenu qui 
active est adjacent à la zone contrôlée, dans ce contexte 
aria-controls peut paraitre redondant mais on ne sait jamais, cela 
peut par exemple permettre à un utilisateur de retrouver le bouton 
permettant de refermer la zone très simplement au lieu de devoir 
parcourir l'ensemble des éléments de la zone.


à ce jour même sur jaws 18 l'implémentation de aria-controls ne permet 
pas de revenir au bouton de contrôle depuis une zone donnée


De manière générale, je me méfie comme de la peste de toute approche 
qui consiste à optimiser un comportement pour tel ou tel utilisateur. 
La diversité des AT et surtout leur très grande capacité de 
personnalisation fait que lorsqu'on optimise on prends toujours le 
risque de poser un problème important pour un autre utilisateur.


En l’occurrence, il n'y aucun problème important à ne pas le mettre 
surtout dans le cas présent (bouton juste avant la zone)


Petit article en anglais sur le sujet 
http://www.heydonworks.com/article/aria-controls-is-poop



JPV


Aurélien

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

Re: [Liste GTA] Ouverture de menu et critère 7.1

[Aurélien Levy]

Bonjour

aucune obligation d'utiliser aria si tu met à jour le title sur ton 
bouton de manière dynamique pour dire ouvrir le menu / fermer le menu en 
fonction de l'état du menu.
Si tu décide d'utiliser de l'aria effectivement l'exemple de Jean Pierre 
est bon (pour ma part je ne met pas d'aria-controls car cela force un 
comportement applicatif sur voiceover osx qui est particulièrement 
rébarbatif pour les utilisateurs surtout si tu en as plusieurs (oblige à 
faire un raccourci clavier à trois touches pour entrer et sortir du sous 
menu)


Aurélien


Bonjour marie,

Si tu n'est pas dans un contexte applicatif :

menu



Le bouton "fermer" est inutile.

Si tu es dans un contexte applicatif, faut voir...

Au sujet de l'accordéon : ne jamais (!!!) utiliser ce DP 
particulièrement pourri qui a été transmuté en ARIA 1.1 avec une 
implémentation similaire à celle indiqué ci-dessus.


Et au passage dans l'exemple une utilisation totalement absurde à base 
de dl/dd/dt.


JPV


Le 12/01/2017 à 16:28, Marie Hanotte a écrit :


*Bonjour la liste,*

J'ai une question sur un système d'ouverture de menu, en regard du 
critère 7.1.


J'en ai fait un test réduit sur Codepen : 
http://codepen.io/mh-nichts/pen/GrZBxg


Comme il n'y a pas ici, de base, de motif ARIA utilisé, je ne suis 
pas sûre de quels points m'assurer.
Est-ce-qu'il est ici suffisant que le contenu ouvert se trouve après 
le bouton, et que le CSS gère de manière directe (display none/block) 
l'affichage ?
Ou est-ce-qu'il faudrait ajouter par exemple un aria-controls sur les 
boutons, un aria-expanded sur le parent ?
Ou enfin faudrait-il absolument passer par un motif ARIA (accordion 
par exemple) avec tous les attributs ARIA correspondants ?
J'aurais tendance à répondre par la négative à cette dernière 
question, mais pour les 2 autres je ne suis pas sûre.


Je vous remercie par avance pour vos retours.

Cordialement,

*Marie Hanotte* // Intégratrice multimédia - /Interactive Designer/

	Experte Accessiweb 
<http://www.accessiweb.org/index.php/fiche_gta_experts/items/hanotte-marie.html> 
Opquast certified <https://certified.opquast.com/fr/>


<http://www.acti.fr>  

Tél. : +33 4 37 37 25 10
289, rue Garibaldi
69007 Lyon


<http://www.acti.fr/> 	<https://www.linkedin.com/company/acti> 
<https://twitter.com/acti> 	<https://www.facebook.com/agence.acti>


acti recrute 
<http://www.acti.fr/recrutement-acti-lyon/?utm_source=signature>




___
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



--
Aurélien Levy

Temesis

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

Re: [Liste GTA] liens dont la nature n'est pas évidente: cas du lien "tel"

[Aurélien Levy]

fait gaffe tu vas finir par faire de la qualité web ;)

Aurélien
Ce qui est perturbant sur cet exemple, c'est la présence dans la même 
phrase de texte plat de la même couleur. La présence de texte noir 
entourant le lien permet de satisfaire le critère 10.6. Mais il faut 
un coup de chance pour se rendre compte qu'il est cliquable... Alors 
ok, c'est techniquement accessible, mais l'ergonomie est mauvaise.


Remarque annexe: il serait peut être opportun d'étendre le critère 
10.6 aux éléments cliquables, et pas uniquement aux liens ?


Le mercredi 26 octobre 2016, Aurélien Levy <aurelien.l...@temesis.com 
<mailto:aurelien.l...@temesis.com>> a écrit :


Bonjour,

ahma le caractère cliquable est bien indiqué au niveau
technique/sémantique puisqu'il s'agit d'un lien et visuellement
puisqu'il prend le focus, est suffisamment contrasté par rapport
au texte et que le curseur est modifié au survol.

Aurélien

Bonjour

Non il n y a rien dans le rgaa ou wcag qui demande que le
caractère cliquable d un objet soit indiqué et heureusement sinon
comment ferais tu avec une image cliquable ?
le test sur les liens dans un environnement de texte assure juste
qu il est possible de discerner une différence visible entre le
lien et le texte.
le fait que l intitulé peut être ambiguïté n est pas traité et
pas traitable.Ton cas est identique à celui d une adresse mail
par exemple. la différence c est que dans le cas d un mail l
utisateur aura plus tendance à tenter un clic...

JPV


Le 26 octobre 2016 04:21:30 GMT-06:00, Olivier Nourry
<olv.nou...@gmail.com>
<javascript:_e(%7B%7D,'cvml','olv.nou...@gmail.com');> a écrit :

Bonjour,
Sur une page que j'audite il y a un lien de type "tel"
(href="tel:0123456789" ). Il est dans une
autre couleur que le texte, non souligné. J'ai bien vu la
différence de couleur, mais cela ne m'a pas donné l'idée que
c'est un élément cliquable, je ne l'ai découvert qu'en tabulant.

Considéreriez-vous que c'est dans le scope du critère 10.6?
Car le contraste (suffisant au regard du critère) en lui-même
ne m'a pas renseigné sur le caractère cliquable du numéro.
J'ai cru à un simple effet de style, car la même couleur est
utilisée pour d'autres textes, qui ne sont pas des liens. Du
coup, ça enfreint le critère 3.1, voire 3.2?

-- 
Olivier Nourry

http://about.me/oliviernourry <http://about.me/oliviernourry>



liste_gta mailing list
liste_gta@list.accessiweb.org
<javascript:_e(%7B%7D,'cvml','liste_gta@list.accessiweb.org');>

http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org

<http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org>

-- Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser
ma brièveté.

___
liste_gta mailing list
liste_gta@list.accessiweb.org
<javascript:_e(%7B%7D,'cvml','liste_gta@list.accessiweb.org');>
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
<http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org>


-- 
Aurélien Levy


Temesis

--
--
Olivier Nourry
http://about.me/oliviernourry

<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

Re: [Liste GTA] Sourds et Malentendants > lecture

[Aurélien Levy]

Bonjour,

Le chiffre resté dans les mémoires date de 1998 et provient de ce rapport
http://www.ladocumentationfrancaise.fr/rapports-publics/984001595/index.shtml
il indique je cite "80% des sourds profonds sont illettrés" mais par 
contre aucune source citée sur la provenance exacte de ce chiffre.


De plus, cela est souvent réduit à "80% des sourds sont illettrés" ce 
qui n'est pas tout à fait la même chose.


Aurélien Levy

Bonjour à tous,

Je travaille dans une Organisation internationale et un de nos 
services s'occupant du handicap a reçu une proposition qui m'interroge :


- une société spécialisée en WAI propose de doubler en langage des 
signes non-seulement les vidéos, mais aussi les pages importantes d'un 
site web.


> Ils argumentent sur le fait que les sourds et malentendants / muets, 
sont très nombreux à ne pas savoir lire.


Avez-vous des infos / arguments dans ce sens ?

Merci beaucoup d'avance

--
*Jean-Jacques *




___
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

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

<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

Re: [Liste GTA] Critère 11.10 Champs obligatoires versus champs facultatifs

[Aurélien Levy]

Pour garder une trace de la discussion :
https://github.com/DISIC/rgaa_referentiel_3-2016/issues/44

au passage quelques précisions complémentaires:
- ce problème concerne aussi 11.10.5, 11.10.8
- la solution du title pose le même problème puisque non autorisée sur 
11.10.2, 11.10.5, 11.10.8 mais autorisé sur 11.10.1, 11.10.4, 11.10.7
- 11.10.2 et le 11.10.8 ne précisent pas si le texte doit être visible 
contrairement à 11.10.5


Aurélien


Bonjour Giuseppe,

Tu peux tout à fait interpréter de cette manière.

Aurélien à remonté une issue légitime sur le 11.10.2 qui sera traité à 
la prochaine MAJ.


JPV


Le 11/10/2016 à 19:11, ROSA Giuseppe (93) a écrit :

Merci Olivier et Aurélien pour vos réponses.

Pour rebondir sur l'exemple d'Aurélien si j'ai un élément de ce type :

Tous les champs sont obligatoires
Nom

Nous avons là deux moyens pour remplir le test 11.10.1 (passage de 
texte + attribut required).
Concernant le test  11.10.2, je le considérerai le comme NA car 
l'élément principal pour indiquer l'obligation serait déjà rempli par 
le passage de texte avant les champs et celui-ci ne demandant pas 
d'indication visuelle.
L'attribut required serait un élément complémentaire pour gérer une 
erreur de saisie mais non le vecteur principal de l'information 
"obligatoire".


J'applique peut-être les règles avec trop de souplesse ?

Cordialement,

DGFiP   Giuseppe ROSA
Inspecteur Analyste
Expert Accessibilité et RGAA

Atelier SODA - bureau SI-1A

Site SI-1A :
SODA : http://si1a.intranet.dgfip/soda
RGAA : http://si1a.intranet.dgfip/rgaa
tel : 01.573.36.997
pièce : 2387



*Adoptez l'éco-attitude.*
N'imprimez ce mail que si c'est vraiment nécessaire



 Message original 
Sujet : Re: [Liste GTA]  Critère 11.10 Champs obligatoires versus 
champs facultatifs

De : Aurélien Levy <aurelien.l...@temesis.com>
Pour : liste_gta@list.accessiweb.org
Date : 11/10/2016 17:38

Bonjour,

Il m'avait été répondu par Olivier puis confirmé par Jean Pierre 
suite à un commentaire sur le github du RGAA (et même si je suis en 
désaccord avec cela) que le test 11.10.1 et donc 11.10.2 qui en 
découle ne s'appliquent qu'une fois la validation effectuée.


Du coup aucune obligation d'indiquer ce qui est obligatoire ou 
optionnel avant la validation mais tu seras obligé de l'indiquer 
après la validation.


Au passage le 11.10.2 n'est pas cohérent avec le 11.10.1 puis le 
11.10.1 autorise comme solution :
- L’indication de champ obligatoire est donnée par un passage de 
texte situé avant le champ de formulaire 
<http://references.modernisation.gouv.fr/rgaa-accessibilite/glossaire.html#champ-de-saisie-de-formulaire> ;
sans qu'il soit nécessaire que ce passage de texte soit associé au 
champ via aria-describedby ou aria-labelledby alors que le 11.10.2 
ne l'autorise pas.


On peut donc se retrouver avec quelque chose comme :
le champ "Nom" est obligatoire
Nom

Qui sera conforme 11.10.1 mais pas 11.10.2

Aurélien


Bonjour Giuseppe,

Intéressant cas d'école!
J'aurais tendance à dire que l'information sur le caractère 
obligatoire du champ doit figurer explicitement au niveau du champ 
lui-même, ou être associée au formulaire dans son ensemble. Avec 
l'exemple que tu donnes, si je consulte en version très agrandie, 
ou en lecture linéaire, je vais avoir une information (indirecte) 
que je vais découvrir en arrivant sur les champs marqués 
facultatifs; ce qui va m'obliger, potentiellement, à revenir sur 
les champs précédents. Donc a minima il faudrait prévenir 
l'utilisateur en amont de ce mode atypique de signalement. A coté 
de cela je suis d'accord avec le fait que cela allège l'interface 
pour les formulaires très longs avec beaucoup de champs obligatoires.
Je pense que j'invaliderais l'absence d'indicateur visuel direct 
uniquement en l'absence de message préliminaire. Et pour les 
formulaires très longs, je pourrais suggérer cette approche "inversée".


J'espère t'avoir été utile.


--
Olivier Nourry
http://about.me/oliviernourry

<http://about.me/oliviernourry>


Le 11 octobre 2016 à 10:49, ROSA Giuseppe (93) 
<giuseppe.r...@dgfip.finances.gouv.fr 
<mailto:giuseppe.r...@dgfip.finances.gouv.fr>> a écrit :


Bonjour la liste,

Ceci est une question théorique.

Je vois désormais des formulaires mentionnant non pas les
champs obligatoires mais les champs facultatifs, par exemple :

  * Nom
  * Prénom
  * Age (faculatif)
  * Adresse
  * 

Ce procédé, du point de vue ergonomique et psychologique, me
semble intéressant :

  * on souligne les éléments facultatifs au lieu de ceux
obligatoires = les mots ont un impact ("obligatoire" =
contrainte) ;
  * dans les formulaires où pour ainsi dire tous les champs ou
presque sont obligatoires, le préciser à chaque fois peut
être &qu

Re: [Liste GTA] Critère 11.10 Champs obligatoires versus champs facultatifs

[Aurélien Levy]

Hello,

oui mais ahma ça devrait pas être le 11.10.2 qui porte sur l'indication 
du caractère obligatoire mais le 11.1.4 qui demande du texte visible et 
accolé au champ permettant de comprendre la nature de la saisie si 
aria-label.


D'ailleurs à ce propos je t'invite à regarder 
https://github.com/DISIC/rgaa_referentiel_3-2016/issues/1 car ce test 
est également buggé


Aurélien

Hello,
Sur ton exemple, Aurélien: dans la situation où l'utilisateur a saisi 
quelque chose dans le champ, il n'y a plus d'indication visuelle 
permettant d'identifier le champ concerné par le message, puisque le 
placeholder est alors remplacé par le texte saisi. La seule 
information récupérable est aria-label, qui ne sera disponible qu'aux 
lecteurs d'écran (et aux power users capable de lire le code source. 
BREF).

Il est donc, pour moi, parfaitement logique de signaler une NC ici.
Si le champ en question est le seul dans le formulaire, on a plutôt un 
problème de wording, qui ne relève pas de l'accessibilité mais de 
l'ergonomie. Evidemment, ceci fera l'objet d'une alerte dans tout bon 
audit qui se respecte ;-) [clin d'oeil]




--
Olivier Nourry
http://about.me/oliviernourry

<http://about.me/oliviernourry>


Le 12 octobre 2016 à 09:24, Aurélien Levy <aurelien.l...@temesis.com 
<mailto:aurelien.l...@temesis.com>> a écrit :


Bonjour Guiseppe,

c'est effectivement une façon de considérer les choses mais cela
ne changerait rien pour cet exemple :
Le champ Nom est obligatoire


Conforme 10.11.1 et NC 10.11.2

Aurélien

Merci Olivier et Aurélien pour vos réponses.

Pour rebondir sur l'exemple d'Aurélien si j'ai un élément de ce
type :

Tous les champs sont obligatoires
Nom

Nous avons là deux moyens pour remplir le test 11.10.1 (passage
de texte + attribut required).
Concernant le test  11.10.2, je le considérerai le comme NA car
l'élément principal pour indiquer l'obligation serait déjà rempli
par le passage de texte avant les champs et celui-ci ne demandant
pas d'indication visuelle.
L'attribut required serait un élément complémentaire pour gérer
une erreur de saisie mais non le vecteur principal de
l'information "obligatoire".

J'applique peut-être les règles avec trop de souplesse ?

Cordialement,

DGFiP   Giuseppe ROSA
Inspecteur Analyste
Expert Accessibilité et RGAA

Atelier SODA - bureau SI-1A

Site SI-1A :
SODA : http://si1a.intranet.dgfip/soda
<http://si1a.intranet.dgfip/soda>
RGAA : http://si1a.intranet.dgfip/rgaa
<http://si1a.intranet.dgfip/rgaa>
tel : 01.573.36.997
pièce : 2387



*Adoptez l'éco-attitude.*
N'imprimez ce mail que si c'est vraiment nécessaire



 Message original 
Sujet : Re: [Liste GTA]  Critère 11.10 Champs obligatoires versus
    champs facultatifs
De : Aurélien Levy <aurelien.l...@temesis.com>
<mailto:aurelien.l...@temesis.com>
Pour : liste_gta@list.accessiweb.org
<mailto:liste_gta@list.accessiweb.org>
Date : 11/10/2016 17:38

Bonjour,

Il m'avait été répondu par Olivier puis confirmé par Jean Pierre
suite à un commentaire sur le github du RGAA (et même si je suis
en désaccord avec cela) que le test 11.10.1 et donc 11.10.2 qui
en découle ne s'appliquent qu'une fois la validation effectuée.

Du coup aucune obligation d'indiquer ce qui est obligatoire ou
optionnel avant la validation mais tu seras obligé de l'indiquer
après la validation.

Au passage le 11.10.2 n'est pas cohérent avec le 11.10.1 puis le
11.10.1 autorise comme solution :
- L’indication de champ obligatoire est donnée par un passage de
texte situé avant le champ de formulaire

<http://references.modernisation.gouv.fr/rgaa-accessibilite/glossaire.html#champ-de-saisie-de-formulaire>
 ;
sans qu'il soit nécessaire que ce passage de texte soit associé
au champ via aria-describedby ou aria-labelledby alors que le
11.10.2 ne l'autorise pas.

On peut donc se retrouver avec quelque chose comme :
le champ "Nom" est obligatoire
Nom

Qui sera conforme 11.10.1 mais pas 11.10.2

Aurélien


Bonjour Giuseppe,

Intéressant cas d'école!
J'aurais tendance à dire que l'information sur le caractère
obligatoire du champ doit figurer explicitement au niveau du
champ lui-même, ou être associée au formulaire dans son
ensemble. Avec l'exemple que tu donnes, si je consulte en
version très agrandie, ou en lecture linéaire, je vais avoir
une information (indirecte) que je vais découvrir en arrivant
sur les champs marqués facultatifs; ce qui va m'obliger,
potentiellement, à revenir sur les champs précédents. Donc a
minima il faudrait prévenir l'utilisateur en amont de ce mode
atypique

Re: [Liste GTA] Critère 11.10 Champs obligatoires versus champs facultatifs

[Aurélien Levy]

Bonjour Guiseppe,

c'est effectivement une façon de considérer les choses mais cela ne 
changerait rien pour cet exemple :

Le champ Nom est obligatoire


Conforme 10.11.1 et NC 10.11.2

Aurélien

Merci Olivier et Aurélien pour vos réponses.

Pour rebondir sur l'exemple d'Aurélien si j'ai un élément de ce type :

Tous les champs sont obligatoires
Nom

Nous avons là deux moyens pour remplir le test 11.10.1 (passage de 
texte + attribut required).
Concernant le test  11.10.2, je le considérerai le comme NA car 
l'élément principal pour indiquer l'obligation serait déjà rempli par 
le passage de texte avant les champs et celui-ci ne demandant pas 
d'indication visuelle.
L'attribut required serait un élément complémentaire pour gérer une 
erreur de saisie mais non le vecteur principal de l'information 
"obligatoire".


J'applique peut-être les règles avec trop de souplesse ?

Cordialement,

DGFiP   Giuseppe ROSA
Inspecteur Analyste
Expert Accessibilité et RGAA

Atelier SODA - bureau SI-1A

Site SI-1A :
SODA : http://si1a.intranet.dgfip/soda
RGAA : http://si1a.intranet.dgfip/rgaa
tel : 01.573.36.997
pièce : 2387



*Adoptez l'éco-attitude.*
N'imprimez ce mail que si c'est vraiment nécessaire



 Message original 
Sujet : Re: [Liste GTA]  Critère 11.10 Champs obligatoires versus 
champs facultatifs

De : Aurélien Levy <aurelien.l...@temesis.com>
Pour : liste_gta@list.accessiweb.org
Date : 11/10/2016 17:38

Bonjour,

Il m'avait été répondu par Olivier puis confirmé par Jean Pierre 
suite à un commentaire sur le github du RGAA (et même si je suis en 
désaccord avec cela) que le test 11.10.1 et donc 11.10.2 qui en 
découle ne s'appliquent qu'une fois la validation effectuée.


Du coup aucune obligation d'indiquer ce qui est obligatoire ou 
optionnel avant la validation mais tu seras obligé de l'indiquer 
après la validation.


Au passage le 11.10.2 n'est pas cohérent avec le 11.10.1 puis le 
11.10.1 autorise comme solution :
- L’indication de champ obligatoire est donnée par un passage de 
texte situé avant le champ de formulaire 
<http://references.modernisation.gouv.fr/rgaa-accessibilite/glossaire.html#champ-de-saisie-de-formulaire> ;
sans qu'il soit nécessaire que ce passage de texte soit associé au 
champ via aria-describedby ou aria-labelledby alors que le 11.10.2 ne 
l'autorise pas.


On peut donc se retrouver avec quelque chose comme :
le champ "Nom" est obligatoire
Nom

Qui sera conforme 11.10.1 mais pas 11.10.2

Aurélien


Bonjour Giuseppe,

Intéressant cas d'école!
J'aurais tendance à dire que l'information sur le caractère 
obligatoire du champ doit figurer explicitement au niveau du champ 
lui-même, ou être associée au formulaire dans son ensemble. Avec 
l'exemple que tu donnes, si je consulte en version très agrandie, ou 
en lecture linéaire, je vais avoir une information (indirecte) que 
je vais découvrir en arrivant sur les champs marqués facultatifs; ce 
qui va m'obliger, potentiellement, à revenir sur les champs 
précédents. Donc a minima il faudrait prévenir l'utilisateur en 
amont de ce mode atypique de signalement. A coté de cela je suis 
d'accord avec le fait que cela allège l'interface pour les 
formulaires très longs avec beaucoup de champs obligatoires.
Je pense que j'invaliderais l'absence d'indicateur visuel direct 
uniquement en l'absence de message préliminaire. Et pour les 
formulaires très longs, je pourrais suggérer cette approche "inversée".


J'espère t'avoir été utile.


--
Olivier Nourry
http://about.me/oliviernourry

<http://about.me/oliviernourry>


Le 11 octobre 2016 à 10:49, ROSA Giuseppe (93) 
<giuseppe.r...@dgfip.finances.gouv.fr 
<mailto:giuseppe.r...@dgfip.finances.gouv.fr>> a écrit :


Bonjour la liste,

Ceci est une question théorique.

Je vois désormais des formulaires mentionnant non pas les champs
obligatoires mais les champs facultatifs, par exemple :

  * Nom
  * Prénom
  * Age (faculatif)
  * Adresse
  * 

Ce procédé, du point de vue ergonomique et psychologique, me
semble intéressant :

  * on souligne les éléments facultatifs au lieu de ceux
obligatoires = les mots ont un impact ("obligatoire" =
contrainte) ;
  * dans les formulaires où pour ainsi dire tous les champs ou
presque sont obligatoires, le préciser à chaque fois peut
être "lourd" (j'ai vu un questionnaire de satisfaction avec
environ 40 questions, toutes sauf une, obligatoires).

L'attribut |required| règle la problématique technique pour
signaler à l'utilisateur un oubli éventuel, par contre, on ne
respecterai pas le test 11.10.2

"Test 11.10.2 : Chaque indication de champ obligatoire qui
utilise... l’attribut |required| doit être accompagnée d’une
indication visuelle explicite dans l’étiq

Re: [Liste GTA] Critère 11.10 Champs obligatoires versus champs facultatifs

[Aurélien Levy]

/listinfo/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



--
Aurélien Levy

Temesis

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

Re: [Liste GTA] RGAA - critère 7.1 Scripts

[Aurélien Levy]

Bonjour,

aucune obligation d'utiliser ARIA quand cela n'est pas nécessaire ou non 
souhaité


il y a dans la définition de nom, role, valeur... : 
http://references.modernisation.gouv.fr/rgaa/glossaire.html#le-nom-le-rle-la-valeur-le-paramtrage-et-les-changements-dtats


- Le rôle correspond au type d’élément défini*par la spécification HTML 
ou* l’API WAI-ARIA


- " Note : *un état peut également être transmis **/via/**le nom*, 
lorsque l’intitulé est changé dynamiquement pour correspondre à l’état 
de la zone contrôlée notamment."


- *Ces paramètres ne sont pas obligatoires* mais peuvent être requis 
s’ils sont indispensables pour rendre le composant accessible. C’est à 
l’auditeur de considérer les cas où ces paramètres sont indispensables 
en fonction du contexte lié à l’utilisation du composant.


Pour ma part je ne considère pas que ce soit à l'auditeur de décider de 
cela (en tout cas clairement pas à postériori) mais au concepteur car 
c'est lui qui est à même de savoir l'expérience utilisateur qu'il veut 
fournir avec ou sans aria


Aurélien



Bonjour,

Quand je lis le critère "7.1 [A] Chaque script est-il, si nécessaire, 
compatible avec les technologies d’assistance ?" et le test 7.1.1 dans 
le référentiel (cf. 
http://references.modernisation.gouv.fr/rgaa/criteres.html#scripts), 
je comprends qu'on est obligé d'utiliser ARIA pour qu'un script soit 
accessible à moins qu'il ait une alternative.
Lors de ma formation AccessiWeb, on avait bien vu que ARIA était 
obligatoire à moins d'avoir une alternative accessible utilisant ARIA 
ou d'avoir une alternative sans JavaScript.


Mais, quand je lis le test 7.1.1 dans la méthodologie (cf. 
http://disic.github.io/rgaa_methodologie/#script), je comprends 
qu'ARIA n'est pas obligatoire.


Il doit y avoir, quelque part, un problème de formulation.
Bref, je suis perdue.

Mon script n'a pas d'alternative et n'utilise pas ARIA et la question 
est de savoir si je dois préconiser l'utilisation d'ARIA à chaque fois 
ou si remplir les conditions du test de la méthodologie est suffisant.


Quelqu'un saurait-il éclairer ma lanterne ?

En vous remerciant,

Julie Moynat




___
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

Re: [Liste GTA] RGAA 3 2016 balise object et embed

[Aurélien Levy]

Bonjour Jean Pierre,

mes commentaires dans le contenu :


Bonjour,

Ce n'est pas un bug mais une application du raisonnement suivant :

1. title ou les liaisons Aria sur des objets (object et embed) peuvent 
ne pas être restitués sur certaines AT, donc on ne peux pas les 
utiliser comme alternative, d'où leur absence en 1.3.4 et 1.3.6



"peuvent ne pas" et "certaines AT" ça fait bcp flou dans une même phrase.
Ce qui nous intéresse ici c'est surtout est ce que ça fonctionne dans la 
base de référence.


De plus y a t il une source ou des testcases "officiels" pour cela ou 
c'est juste du doigt mouillé invérifiable par tout à chacun


D'après mes tests (cf http://s.codepen.io/goetsu/debug/WxymRE ) si on 
utilise une des trois solutions cela fonctionne parfaitement avec :

- VO+safari dernière version,
- Jaws 16+FF dernière version,
- NVDA dernière version + IE11 ou FF dernière version.

Seul souci title qui ne fonctionne pas sur Jaws 16 + IE11 mais sachant 
que le test IE n'est pas une obligation dans la base de référence on 
pourrait également le considérer comme bon


2. mais ces alternatives peuvent être présentes, donc il faut bien 
s'assurer que si elles sont présentes elle correspondent bien au 
fonctionnement proposé par le calcul du nom accessible.


Si elles sont sensés ne pas fonctionner je ne vois pas l’utilité mais vu 
qu'en réalité elles fonctionnent il faut effectivement que le contenu 
soit pertinent (ce qui n'est pas testé actuellement).
Si plusieurs techniques cumulées alors effectivement 1.3.5 et 1.3.7 sont 
pertinents et utiles



...

Nous ne l'avons pas fait pour la raison suivante : les images objet ne 
possédant pas de dispositif permettant d'associer une description 
courte à une description détaillée (comme les image avec ALT et 
LONGDESC ou son équivalent via un lien ou une description adjacente) 
il pourrait être jugé utile par les auteurs d'utiliser un title ou une 
propriété ARIA pour reproduire ce mécanisme pour les AT les prenant en 
charge. Donc il n'est pas possible de demander que les textes liés 
soient identiques à l'alternative ce qui tuerait cette utilisation pas 
complètement accessible mais néanmoins possible.


bah en réalité vu que ça fonctionne, ça pourrait tout à fait être 
utilisé avec les conditions suivantes :
- Il existe un attribut title, aria-label contenant la référence à une 
description détaillée adjacente à l’image ;


Se pose ici également la question du réel support et non du support 
présumé non compatible de aria-describedby comme solution possible pour 
pointer une description longue dans la page


Aurélien

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

Re: [Liste GTA] RGAA 3 2016 balise object et embed

[Aurélien Levy]

Bonjour,

je pense que cela fait parti des bugs que j'ai remonté :
https://github.com/DISIC/rgaa_referentiel_3-2016/issues/5

en gros pas très logique de demander de tester title identique à 
aria-label et aria-labelledby car ni title ni aria-label ni 
aria-describedby ne sont autorisés pour donner une alternative sur ces 
éléments.


Sinon cela revient à dire que ces 3 techniques restituent bien qqchose 
et donc que ce qqchose devrait être pertinent hors le test ne vérifie 
pas la pertinence mais juste que les 3 sont identiques.


Aurélien


Bonjour Giuseppe,

Selon moi, ce ne sont pas des alternatives car si l'image embed/object 
ne s'affiche pas pour x raison, l’utilisateur lambda n'aura plus accès 
à l'information (les attributs aria lui sont inutiles). Les aria* ne 
seront utiles qu'au personnes mal voyantes.



Bien cordialement,

*Cyril Lamotte*
Développeur Front-end / Référent accessibilité

clamo...@jouve.fr

02 43 08 39 97

Jouve <http://www.jouve.com/fr>
1, rue du docteur Sauvé, 53101 Mayenne CEDEX
www.jouve.com <http://www.jouve.com>

Le 27/07/2016 à 18:54, ROSA Giuseppe (93) a écrit :

Bonjour la liste,

Je prends un peu de temps pour lire la version 2016 du RGAA.

Je bute actuellement sur la compréhension des tests 1.3.4/1.3.5 et 
1.3.6/1.3.7. concernant les images porteuses d'information, les deux 
premiers via une balise object et les deux suivants via une balise embed.


J'ai l'impression en lisant ces tests, que les propriétés aria-label 
et aria-labeledby ne sont pas des alternatives aux images object ou 
embed, mais qu'ils peuvent uniquement être utilisés en "surcharge" à 
une alternative préconisée respectivement dans les tests 1.3.4 et 1.3.6.


Mon analyse est-elle selon vous correcte ?

Merci par avance et bonne soirée.

Cordialement,

DGFiP   Giuseppe ROSA
Inspecteur Analyste
Atelier SODA - bureau SI-1A
Site SODA : http://si1a.intranet.dgfip/soda tel : 01.573.36.997
pièce : 2388



*Adoptez l'éco-attitude.*
N'imprimez ce mail que si c'est vraiment nécessaire





___
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



--
Aurélien Levy

Temesis

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

Re: [Liste GTA] Titre ou pas ?

[Aurélien Levy]

Bonjour,

/
/
Le critère *10.3 [A] Dans chaque page Web, l’information reste-t-elle 
compréhensible lorsque les feuilles de styles sont désactivées ?*


En effet, c'est ta mise en forme (mise en exerguere etc...) qui permet 
de faire un lien entre la thématique et le titre qui la suit. un 
utilisateur aveugle typiquement, qui navigue linéairement, ne pourra 
pas percevoir ce lien entre thématique et titre si la thématique est 
un simple paragraphe situé AVANT.
pour moi l'information reste bien compréhensible en lecture linéaire 
puisque dans le bon ordre. Le critère potentiellement invalidable par 
rapport à wcag est le 1.3.1 ou le 4.1.2 car effectivement on pourrait 
considérer que tu as visuellement un titre mais que cela n'en est pas un 
au niveau du code.


L'autre solution serait donc d'utiliser un h1 "vidéo" puis un h2 "titre 
de ton bloc" (à noter que d'après wcag tu peux également faire h3 
"vidéo" puis h2 "titre de ton bloc" mais que pour l'heure ce ne serait 
pas conforme RGAA)


Néanmoins personnellement je déconseillerai ces solutions car :
- dans le cas où tu as plusieurs blocs avec cette structure cela va 
démultiplier le nombre de hx et donc complexifier l'usage de la 
navigation par hx
- tu vas avoir plusieurs hx identiques ce qui en fonction de la 
structure globale de la page pourrait rendre difficile la compréhension 
de celle-ci et je doute également que le SEO soit ravi d'avoir plusieurs 
hx identiques


Par contre tu peux faire :
Video
Vidéos : Tout comprendre sur le 
changement 


--
Aurélien Levy

Temesis

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

Re: [Liste GTA] Critère 10.7 - Outline

[Aurélien Levy]

Bonjour,

si tu es sur base RGAA 3 oui tu dois l'invalider car le test rgaa 
n'autorise pas d'autre solution que outline pour la visibilité du focus, 
si tu es sur base wcag non car wcag autorise bien d'autre solution


Aurélien

Bonjour à tous,

Invalidez vous le fait que l'outline soit supprimé mais qu'il soit 
remplacé par autre chose comme dans l'exemple ci-dessous en LESS. Si 
oui je veux bien une explication :D


input, textarea {
  transition: all ease .3s;
&:hover, &:focus {
border: 1px solid @color-2;
background: @color-5;
outline: none;
}
}

Merci

--
Steven Mouret


___
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

Re: [Liste GTA] contrastes et critère 13.15

[Aurélien Levy]

Attention à priori cela ne corrigera pas les éventuelles images dans 
lesquels il y aurait du texte pas suffisamment contrastée. D'ailleurs, 
je me demande dans quelle mesure on pourrait arriver à quelque chose 
avec les filtres css / svg notamment 
https://docs.webplatform.org/wiki/svg/elements/feColorMatrix


Aurélien

Merci Philippe pour la réponse.
Je suis d'accord sur le positionnement du bouton, pas idéal, mais pas 
vraiment eu le choix.


La réalisation est comme suit : le css est du Sass compilé, un fichier 
spécifique (compilé en dernier) reprends toutes les déclaration de 
couleur (color, background-color, border, outline) présentes dans les 
autres fichiers et modifie leurs couleurs (sur la base de map de 
couleurs, une contrastée, l'autre non); lorsque l'utilisateur utilise 
le bouton, une classe est ajoutée sur l'élément , et cette 
classe permet d'appliquer les modifications de couleurs au reste des 
éléments; l'utilisation du bouton provoque aussi le dépôt d'un cookie 
coté utilisateur, de manière à garder ce "réglage" de manière persistante.


Il n'y a pas de rechargement de page, dans les faits, cela provoque un 
"saut" visible, d'ou ma question d'origine.



2016-05-11 11:57 GMT+02:00 Philippe Vayssière 
<phili...@alsacreations.fr <mailto:phili...@alsacreations.fr>>:


Bonjour,

il est non seulement annoncé mais également déclenché par
l'utilisateur.
Je considérerais qu'il s'agit d'une nouvelle page plus que d'un
effet même si c'est réalisé en JS sans passage par le serveur ; ça
rend le test 13.15.2 non applicable.

Concernant le positionnement du bouton dans le pied de page, à
défaut de pouvoir le mettre en début de page j'ajouterais si
possible une copie de celui-ci bien en évidence au début de la
page Accessibilité qui est un autre endroit où amha un utilisateur
s'attend à le trouver.
Un point bonus si le bouton dans le footer est lui assez contrasté
dans la version par défaut (huhu).

Si ce n'est pas un secret industriel, quel choix technique a-t-il
été fait pour la réalisation de cette surcouche ? À la main ou
bien une 2e CSS "contrastée" compilée via un préprocesseur mais
avec des variables de couleurs "/accessibles///contrastées/" ou
via l'utilisation des "variables" ("custom properties") CSS
définies globalement ?


Cordialement,
Ph. Vayssière
-- 
alsacreations.fr <http://alsacreations.fr> - alsacreations.com

<http://alsacreations.com>


Le 11/05/2016 à 11:33, Matthieu Marseille a écrit :

Bonjour la liste,

Je me pose une question, par pure curiosité, et je serais curieux
d'avoir des avis.

J'ai récemment eu à intégrer un bouton "accentuer les contrastes"
sur un site en développement. La maquette n'est, de base, pas
assez contrastée pour atteindre un niveau Argent, mais il a été
décidé de l'intégrer et d'en faire une version contrastée, puis
d'ajouter un bouton dans le footer permettant de charger la css
qui surcouche les couleurs.

La question que je me pose est au regard du critère 13.15, je me
demande si un changement de couleur brusque, même s'il est
clairement annoncé (et plutôt vers des couleurs plus sombres
d'une manière générale) peut gêner les utilisateurs ?

-- 
Matthieu MARSEILLE

DFO - F6 TECH
mmarsei...@fullsix.com <mailto:mmarsei...@fullsix.com>
+33 (0)1 49 68 24 55FullSIX France
157 rue Anatole France
92309 Levallois Perret Cedex

<http://maps.google.fr/maps?q=fullsix+levallois+perret=utf-8=firefox-a=UTF8=fr=fullsix=Levallois-Perret=48.900189,2.279363=0.016673,0.045447=15=A>
http://www.fullsix.com
<http://www.fullsix.com/>



___
liste_gta mailing list
liste_gta@list.accessiweb.org <mailto: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 <mailto:liste_gta@list.accessiweb.org>
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org




--
Matthieu MARSEILLE
DFO - F6 TECH
mmarsei...@fullsix.com <mailto:mmarsei...@fullsix.com>
+33 (0)1 49 68 24 55FullSIX France
157 rue Anatole France
92309 Levallois Perret Cedex 
<http://maps.google.fr/maps?q=fullsix+levallois+perret=utf-8=firefox-a=UTF8=fr=fullsix=Levallois-Perret=48.900189,2.279363=0.016673,0.045447=15=A>

http://www.fullsix.com
<http://www.fullsix.com/>



___
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

Re: [Liste GTA] SVG et alternative

[Aurélien Levy]

Bonjour,

ce critère est totalement à reprendre cf ce que j'ai remonté :
https://github.com/DISIC/rgaa_referentiel/issues/12

Aurélien

Bonjour le groupe,

J'ai un doute sur la manière d'interpréter le test 1.2.4 du RGAA :
***
Critère 1.2 [A] Pour chaque image de décoration ayant une alternative 
textuelle, cette alternative est-elle vide ?
Test 1.2.4 : Chaque image vectorielle de décoration (balise |svg|) 
non porteuse d'information et possédant une alternative vérifie-t-elle 
ces conditions ?


  * La balise |svg| possède un |role="img"|

***
J'ai une icone en svg (), non porteuse d'information (le texte 
adjacent porte l'information). Celle-ci n'a pas de role="img".
Par contre je ne suis pas sur de comprendre comment interpréter le 
test 1.2.4 quand il indique "et possédant une alternative".


Auriez-vous un cas exemple d'un  de _décoration_ avec 
_alternative_, ou sinon que doit-on entendre par "alternative".


Par avance merci.

Cordialement,

DGFiP   Giuseppe ROSA
Inspecteur Analyste
Atelier SODA - bureau SI-1A
Site SODA : http://si1a.intranet.dgfip/soda tel : 01.573.36.997
pièce : 2388



*Adoptez l'éco-attitude.*
N'imprimez ce mail que si c'est vraiment nécessaire




___
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

Re: [Liste GTA] Alternatives aux critères de contraste ?

[Aurélien Levy]

Bonjour,

par contre si il y a des images avec du texte informatif dedans qui 
n'est pas assez contrasté pour ma part je continue à invalider le 
critère puisque ce genre de switcher n'a pas pour effet d'augmenter le 
contraste dans les images (on peut bricolé un truc à coup de css filter 
mais c'est difficilement industrialisable)


Aurélien

Bonjour Antoine,

Du point de vue conformité, oui, cette manière de faire permet de 
satisfaire le critère.
Je te rejoins sur le fait que dans l'idéal on ne devrait pas avoir 
besoin de ce type de béquille, mais on n'a parfois pas le choix, 
notamment lorsque l'on hérite d'une charte, ou que les couleurs 
corporate ne permettent pas de passer les seuils du critère.
Il faut bien alerter sur le fait que cela a un impact sur le code 
(montage HTML et CSS au poil), et qu'il ne faut pas oublier de 
maintenir les 2 versions de style, en particulier lorsque le site est 
amené à évoluer (ajout de modules, de templates, etc.).


J'espère avoir répondu à ta question.


--
Olivier Nourry
http://about.me/oliviernourry

<http://about.me/oliviernourry>


Le 22 janvier 2016 à 15:40, Antoine Bouet <antoine.bo...@cimeos.com 
<mailto:antoine.bo...@cimeos.com>> a écrit :


Bonjour la liste,

On m'a posé une question que je vais vous soumettre car je
voudrais être certain de la réponse :)

Nous avons récupéré une maquette que je dois intégrer et qui ne
respecte clairement pas les critères de contrastes de couleurs ...
La solution proposée par cette agence est de laisser ces couleurs
en place mais d'ajouter en haut de page un outil de changement de
contraste Noir / blanc.
Pour eux, une alternative existe, donc le site reste accessible.

Question : est-ce suffisant ?

Personnellement, je suis plutôt "intégriste" sur le sujet des
contrastes et je pense qu'ils doivent respecter les critères dès
le premier chargement de la page.
Vous en pensez quoi ?

Merci pour vos réponses :)

-- 
Cordialement,


Antoine BOUET
Ingénieur Développement
Expert AccessiWeb en Evaluation

CIMEOS
Besançon - Rennes
e-mail : antoine.bo...@cimeos.com <mailto:antoine.bo...@cimeos.com>
www.cimeos.com <http://www.cimeos.com>


___
liste_gta mailing list
liste_gta@list.accessiweb.org <mailto: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



--
Aurélien Levy

Temesis

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

Re: [Liste GTA] W3C/WAI publie User Agent Accessibility Guidelines (UAAG 2.0) and UAAG 2.0 Reference

[Aurélien Levy]

Bonjour Dominique,

Merci de cette information, je profite de l'occasion pour t'interroger 
concernant la mise à jour d'Accessiweb vers le RGAA 3.0 ou vers  une 
version nettoyée de html5/aria (le RGAA 3.0 ayant également une série de 
bugs connus).


Il me semble que ce point n'as pas été évoqué lors du dernier séminaire. 
Il est étrange à l'heure actuelle de continuer de garder cette 
différence sachant que c'était un des principaux arguments justifiant le 
passage à Accessiweb. Il me semble également important de savoir si 
Accessiweb va continuer à vivre en parallèle du RGAA.


Merci d'informer le GTA quand à la position et à l'agenda que compte 
avoir Braillenet vis à vis de ce sujet qui nous impacte tous.


A Bientôt

Aurélien

Bonjour à tous,
Pour votre information je vous fais suivre ci dessous le message de 
Jeanne Spellman, UAWG W3C.

Cordialement,
Dominique Burger
Présidnet de BrailleNet

The User Agent Accessibility Guidelines Working Group (UAWG) has 
published User Agent Accessibility Guidelines (UAAG 2.0) and UAAG 2.0 
Reference as W3C Working Group Notes.

http://www.w3.org/TR/UAAG20/
http://www.w3.org/TR/UAAG20-Reference/

UAAG 2.0 is complete. It provides specific guidance for browsers and 
other user agents, and reference information for accessibility 
professionals.


The UAWG has identified implementations of the features ("success 
criteria") of UAAG 2.0, demonstrating that it is possible to implement 
the UAAG 2.0 success criteria. The threshold for a specification 
becoming a formal W3C Recommendation ordinarily involves extensive 
formal testing of implementations of each success criteria across 
multiple user agents -- which in the case of UAAG 2.0 would have 
required manual testing of many browser user interfaces. Sufficient 
testing resources were not available for this level of testing. W3C 
does not currently plan to advance UAAG 2.0 to Recommendation status. 
W3C plans to include user agent accessibility considerations in future 
accessibility guidelines work.


UAAG 2.0 is still needed and relevant, and may be increasingly 
relevant in the future. The work of the current task forces for Mobile 
Accessibility and Low Vision Accessibility show the importance of 
combined consideration of content, user interface, extensions, 
applications and user agents. While many of the UAAG 2.0 features are 
supported in individual browsers, there is a need for more consistent 
and reliable support for accessibility features across all browsers 
and user agents. UAAG 2.0 provides specific accessibility guidance for 
user agent developers who want to build a better user experience for all.


Comments:
Comments on the Notes can be sent to public-uaag2-comme...@w3.org 
(Public Archive). Although the UAAG working group is closing and will 
not respond, comments can provide useful input for future work in this 
area.


Background:

UAAG 2.0 defines how browsers, browser extensions, media players, 
readers, and other "user agents" should support accessibility for 
people with disabilities and work with assistive technologies. UAAG 
2.0 Reference provides additional information about the guidelines and 
success criteria, including intent, examples, and resources. For more 
information on UAAG and other standards from the W3C Web Accessibility 
Initiative (WAI), see:


* UAAG Overview <http://www.w3.org/WAI/intro/uaag.php>
* WAI Guidelines and Techniques <http://www.w3.org/WAI/guid-tech.html>
* User Agent Accessibility Guidelines Working Group (UAWG) 
<http://www.w3.org/WAI/UA/>


URI:
The first URI above goes to the latest version of the document. The 
"dated" version of this draft is: 
<http://www.w3.org/TR/2015/NOTE-UAAG20-20151215/> The difference 
between these URIs are explained in Referencing and Linking to WAI 
Guidelines and Technical Documents at: 
<http://www.w3.org/WAI/intro/linking.html>


Please let us know if you have any questions. Thank you in advance for 
your comments.
Feel free to circulate this message to other lists; please avoid 
cross-postings where possible.


Regards,

Jim Allan, UAWG Chair
Jeanne Spellman, UAWG W3C Staff Contact
Judy Brewer, WAI Director



___
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] proposition article accessibilité dans loi numérique

[Aurélien Levy]

Bonjour à tous,

je sais c'est bientôt le week end vous avez hâte de rentrer chez vous 
mais avant de partir je vous invite à aller prendre connaissance de la 
proposition faite par le CFPSAA d'évolution de l'article 47 et surtout 
de voter pour donner votre avis :


https://www.republique-numerique.fr/consultations/projet-de-loi-numerique/consultation/consultation/opinions/section-2-accessibilite-des-personnes-handicapees-aux-sites-internet-publics/article-29-accessibilite-numerique-des-services-publics/versions/nouvelle-version-de-l-article-29-accessibilite-aux-services-et-contenus-numeriques-par-les-personnes-en-situation-de-handicap

Au programme, prise en compte de tout les contenus et services 
numériques, élargissement au secteur privé et au organisme avec mission 
/ délégation de service public, instauration d'un schéma d'accessibilité 
pour planifier la mise en oeuvre et surtout rappel clair des sanctions 
en cas de discrimination (amende, prison, exclusion des marchés publics 
notamment)


Bon week end à vous

--
Aurélien Levy

Temesis


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

Re: [Liste GTA] Exemple pour le critère 13.13 du référentiel v2.2 ?

[Aurélien Levy]

Il s'agit essentiellement de couvrir le cas des homographes hétérophones 
(mot qui s'écrivent pareils mais se prononcent différemment exemple : 
les poules du couvent couvent, il n'y a plus de sucre mais plus de sel


Aurélien


Bonjour,

J’ai trouvé un lien avec des explications et quelques exemples.

http://www.w3.org/Translations/NOTE-UNDERSTANDING-WCAG20-fr/meaning-pronunciation.html

Cordialement,

*Céline ADMIRAT*

Chef de projet AMOA

*UGAP*

*Direction des Systèmes d’Information *

Département Ingéniérie et Nouveaux Projets

Pôle backoffice SAP ERP et BW

255, avenue de la Croix Verte - Parc Euromédecine I

34097 MONTPELLIER CEDEX 5

ugap.fr http://www.ugap.fr/

*De :*liste_gta [mailto:liste_gta-boun...@list.accessiweb.org] *De la 
part de* Valerie

*Envoyé :* jeudi 9 juillet 2015 14:55
*À :* liste_gta@list.accessiweb.org
*Objet :* [Liste GTA] Exemple pour le critère 13.13 du référentiel v2.2 ?

Bonjour à tous,

J'essaie de valider/ invalider ce critère sur un site, mais n'ayant 
pas en tête d'exemple pouvant me guider, je reste baba...


Le critère dit: Dans chaque page Web, pour chaque mot dont le sens ne 
peut être compris sans en connaître la prononciation, celle-ci 
est-elle indiquée ?


Avez-vous des exemples de mots qui obligent à mettre en oeuvre ce critère?

Comment également indique-t-on la prononciation? En phonétique? Je ne 
connais pas beaucoup de monde capable de la lire...


Merci,

Valérie

Imprimer ce mail est-il nécessaire ?



___
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

Re: [Liste GTA] RGAA v3 Critère 6.5

[Aurélien Levy]

Formellement puisque ce cas n'est pas prévu je dirais que non ça serait 
non conforme.


Au mieux tu dois pouvoir dans certains cas faire une dérogation 
justifiée si ton lien est décoratif (un autre lien avec un intitulé 
dans la page fait la même chose). Néanmoins à minima je te conseille :
- d'ajouter un tabindex=-1 sur ton lien décoratif de manière à ce qu'il 
ne puisse pas recevoir le focus clavier

- de vérifier la restitution dans la base de référence

Aurélien

Bonjour à tous

Un lien image avec un alt vide et aria-hidden à true sur le lien 
permet t-il de passer le critère 6.5 ?


Merci

--
Steven Mouret


___
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

Re: [Liste GTA] RGAA v3 Critère 6.5

[Aurélien Levy]

Attention tout de même avec ce genre de chose notamment si il s'agit 
d'image texte.
Une personne utilisant par exemple dragon naturally speaking pour 
naviguer ne pourra pas non plus activer ce lien en annonçant le texte 
sur l'image (c'est hors base de référence mais bon à savoir quand meme)


Aurélien
Salut Aurélien, merci pour la réponse, c'est bien un lien doublon 
purement ergonomique.
J'avais prévu le tabindex=-1, je vais vérifier la restitution dans 
la base de référence.


--
Steven Mouret

Le 4 juin 2015 09:39, Aurélien Levy aurelien.l...@temesis.com 
mailto:aurelien.l...@temesis.com a écrit :


Formellement puisque ce cas n'est pas prévu je dirais que non ça
serait non conforme.

Au mieux tu dois pouvoir dans certains cas faire une dérogation
justifiée si ton lien est décoratif (un autre lien avec un
intitulé dans la page fait la même chose). Néanmoins à minima je
te conseille :
- d'ajouter un tabindex=-1 sur ton lien décoratif de manière à ce
qu'il ne puisse pas recevoir le focus clavier
- de vérifier la restitution dans la base de référence

Aurélien

Bonjour à tous

Un lien image avec un alt vide et aria-hidden à true sur le lien
permet t-il de passer le critère 6.5 ?

Merci

--
Steven Mouret


___
liste_gta mailing list
liste_gta@list.accessiweb.org  mailto: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 mailto: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



--
Aurélien Levy

Temesis

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

Re: [Liste GTA] Déplacement du focus au chargement de la page

[Aurélien Levy]

Dans certains contexte cela peut tout à fait se justifier par exemple 
google.com ou autre type de moteur de recherche, cela peut également 
être le cas sur une application web type formulaire à étape.


Aurélien

Ok, merci Jean-Pierre

*Cyril Lamotte*
Développeur Front-end / Référent accessibilité

clamo...@jouve.fr

02 43 08 39 97

Jouve http://www.jouve.com/fr
1, rue du docteur Sauvé, 53101 Mayenne CEDEX
www.jouve.com http://www.jouve.com

Twitter https://twitter.com/GroupeJouve 	Google + 
https://plus.google.com/103316327091227322721/posts 	LinkedIn 
http://www.linkedin.com/company/groupe-jouve 	Viadeo 
http://www.viadeo.com/v/company/jouve?ga_from=Fu:undefined;Fb%3Amininews%3Bfe%3AMN-pic%0A%0A%3BMNType%3A46 



Jouve http://www.jouve.com/fr/signatureITS

Le 04/06/2015 10:53, Jean-Pierre Villain a écrit :

Bonjour,

Ce n'est pas nécessairement non-conforme, c'est surtout désastreux 
pour l'utilisateur, particulièrement les aveugles pour qui le premier 
contenu de la page est donc un champ de recherche.


Pour ce qui me concerne je me contente de faire une remarque la plus 
pédagogique possible pour tenter d'éradiquer ce genre de mauvais 
pratique.


JPV

Le 04/06/2015 10:38, Cyril Lamotte a écrit :

Bonjour la Liste,

Que pensez-vous de cette situation :
Au chargement de la page le focus est déplacé via JavaScript sur le 
champ de recherche se trouvant sous le menu et les liens 
d'évitement. Sous le champ de recherche, il y a d'autres contenus.


- Est-ce envisageable pour le RGAA ? Si non, quel est le critère 
impacté ? Le 12.13 ?
Critère 12.13 [A] Dans chaque page Web, l'ordre de tabulation 
est-il cohérent ?

Comment justifier la non-validité si elle existe ?

Merci !

--

*Cyril Lamotte*
Développeur Front-end / Référent accessibilité

clamo...@jouve.fr

02 43 08 39 97

Jouve http://www.jouve.com/fr
1, rue du docteur Sauvé, 53101 Mayenne CEDEX
www.jouve.com http://www.jouve.com

Twitter https://twitter.com/GroupeJouve 	Google + 
https://plus.google.com/103316327091227322721/posts 	LinkedIn 
http://www.linkedin.com/company/groupe-jouve 	Viadeo 
http://www.viadeo.com/v/company/jouve?ga_from=Fu:undefined;Fb%3Amininews%3Bfe%3AMN-pic%0A%0A%3BMNType%3A46 



Jouve http://www.jouve.com/fr/signatureITS



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


--
_
Jean-Pierre VILLAIN - @villainjp - +33 (0)6 98 08 50 49
Expert senior, formateur et responsable du pôle RD
Access42 : expertise, conseil et formation en accessibilité numérique
+33 (0)1 78 17 88 55 - access42.net - @access42net


___
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



--
Aurélien Levy

Temesis

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

Re: [Liste GTA] Hierarchisation de titres et référencement

[Aurélien Levy]

Merci oh grand inquisiteur de bien vouloir remettre les infidèles que 
nous sommes sur le droit chemin de la juste morale Villainiene sans toi 
nous serions condamné à bruler dans les flammes de l'enfer.


Il ne faut pas confondre compromis et compromission.

JPV



--
Aurélien Levy

Temesis


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

Re: [Liste GTA] bugs thématique image décoratives et porteuses d'informations RGAA3

[Aurélien Levy]

Bonjour


Salut Aurélien,

En attendant de faire un retour plus complet sur  tes remarques, juste 
un retour rapide :


En ce qui concerne le SVG, le role img n’empêche pas la restitution du 
alt, par contre, le role presentation l’empêche, au moins dans les cas 
que j’ai testé (NVDA +Firefox et VoiceOver/Safari sur OSX). L’absence 
de ce role img empêche justement certains navigateurs d’exposer 
l’alternative.


oui c'est bien pour cela que sur une image de décoration il n'est pas 
utile ;) et le role presentation est lui interdit cf 
https://references.modernisation.gouv.fr/sites/default/files/RGAA3_RC2-1/note_technique.htm#nT1-2


Aurélien


*De :*liste_gta [mailto:liste_gta-boun...@list.accessiweb.org] *De la 
part de* Aurélien Levy

*Envoyé :* mercredi 6 mai 2015 15:28
*À :* liste_gta@list.accessiweb.org
*Objet :* [Liste GTA] bugs thématique image décoratives et porteuses 
d'informations RGAA3


Bonjour,

Suite à ma relecture attentive du RGAA3 j'ai remarqué plusieurs bugs 
sur la thématique image mais j'ai peut être mal compris quelque chose.


*Pour le 1.2*

Il manque un test sur les images embarquées décoratives via balise embed

tests 1.2.1 , 1.2.2 :
- les balises img et area peuvent être porteuses 
d'attribut|aria-label|, |aria-describedby|, |aria-labelledby| il faut 
demander que ce ne soit pas le cas


tests 1.2.3 , 1.2.5 :
- les balises object et canvas peuvent être porteuses 
d'attribut|title, aria-label|, |aria-describedby|, |aria-labelledby| 
il faut demander que ce ne soit pas le cas


test 1.2.4 :
- un élément svg pouvant potentiellement contenir du texte décoratif 
élément text, il faut exiger un aria-hidden=true sur l'élément svg 
ou le text en question pour éviter qu'il ne soit restitué
- le test ne devrait pas demander d'avoir un role=img sur ces 
éléments décoratifs puisque cela risque générer un restitution type 
graphic par les lecteurs d'écran alors que l'élément est décoratif 
et qu'il est donc préférable qu'il soit totalement ignoré comme pour 
une image avec alt=.
- il manque l'attribut title dans la liste des attributs à ne pas 
utiliser sur l'élément svg
- il manque l'indication sans légende dans l'intitulé comme pour les 
autres intitulés de tests


test  1.2.5 :
- la balise canvas peut être porteuse d'attribut |title, aria-label|, 
|aria-describedby|, |aria-labelledby| il faut demander que ce ne soit 
pas le cas
- il manque l'indication sans légende dans l'intitulé comme pour les 
autres intitulés de tests


*Pour le 1.3*

le problème est que le critère 1.1 (à juste titre) ne vérifie pas la 
présence d'alternative aux images object, embed, svg et canvas et que 
par conséquent les tests du critère 1.3 sur ces éléments doivent 
tester présence ET pertinence ce qui est fait correctement sur embed 
et object mais pas sur svg et canvas


test 1.3.1, 1.3.2
- les balises img et area peuvent être porteuses 
d'attribut|aria-label|, |aria-labelledby| il faut demander que ce ne 
soit pas le cas ou que si c'est le cas que ce soit identique au 
contenu du alt


test 1.3.3 :
- la balise input type image peut être porteuse d'attribut|title, 
aria-label|, |aria-labelledby| il faut demander que ce ne soit pas le 
cas ou que si c'est le cas que ce soit identique au contenu du alt


test 1.3.6
- le test ne concernent que les svg possédant une alternative donc 
un svg porteur d'information sans alternative sera donc non applicable 
pour ce test ce qui n'est pas correct pour l'utilisateur et qui n'est 
invalidé par aucun autre critère. Il faut donc supprimer possédant 
une alternative textuelle de l'intitulé.
- le test demande de vérifier une des conditions hors le simple 
ajout de role=img ne devrait pas rendre le test conforme la présence 
du rôle img doit être mis dans chacunes des autres conditions
- rien n'empêche d'utiliser à la fois aria-label, l'attribut title et 
desc (et éventuellement aria-labelledby), les trois devraient être 
identiques ou alors il faut interdire l'usage simultané de aria-label 
et desc et mettre cette précision dans le glossaire via image 
vectorielle porteuse d'information
- il peut tout à fait être mis disposition une alternative via un 
mécanisme de remplacement


La formulation deviendrait donc  :

· Test 1.3.6 : Chaque image vectorielle porteuse d'information (balise 
|svg|) vérifie-t-elle une seule de ces conditions (hors cas 
particuliers 
https://references.modernisation.gouv.fr/sites/default/files/RGAA3_RC2-1/cas_particulier.htm#cpCrit1-3) 
?


  * La balise |svg| possède un attribut |role=img| et un attribut
|aria-label| dont le contenu est pertinent
  * La balise |svg| possède un attribut |role=img| et contient une
balise |desc| dont le contenu est pertinent
  * Un lien adjacent permet d'accéder à une alternative dont le
contenu est pertinent
  * Un mécanisme permet à l'utilisateur de remplacer l'image
vectorielle par un texte alternatif pertinent
  * Un mécanisme permet à l'utilisateur de remplacer l'image
vectorielle par une

[Liste GTA] sortie officielle du RGAA 3.0

[Aurélien Levy]

Bonjour à tous,

pour information :
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT30540064categorieLien=id

Bonne fin de week end à vous

--
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] Différences RGAA 2 / RGAA 3

[Aurélien Levy]

Bonjour à tous,

Pour information nous avons publié aujourd'hui un billet évoquant les 
différences entre RGAA 2 et RGAA 3.

Un fichier détaillé sous licence CC-BY-SA est également mis à disposition.
J'espère que cela pourra vous être utile.

http://blog.temesis.com/post/2015/04/28/Les-differences-entre-RGAA-2-et-RGAA-3 



A bientôt

--
Aurélien Levy

Temesis

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

Re: [Liste GTA] Joomla! et formulaire d'identification

[Aurélien Levy]

Bonjour,

je complète en précisant que dans un cas comme dans l'autre c'est 
effectivement à utiliser sur le input et non sur le label


Aurélien

Bonjour,

l'attribut aria-invalid est utilisé pour savoir si la donnée est 
conforme au format attendu et non pour savoir si le champ est obligatoire.


The |aria-invalid| attribute is used to indicate that the value 
entered into an input field does not conform to the format expected by 
the application.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-invalid_attribute


la notion de champ obligatoire est géré par l'attribut aria-required

The |aria-required| attribute is used to indicate that user input is 
required on an element before a form can be submitted. This attribute 
can be used with any typical HTML form element; it is not limited to 
elements that have an ARIA |role| assigned.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-required_attribute

Cordialement,
Frédéric


Le 26 mars 2015 15:31, Ariane Andurand ariane.andur...@gmail.com 
mailto:ariane.andur...@gmail.com a écrit :



Dans le cas d'un formulaire avec des champs obligatoires,
l'élément aria-invalid=true/false doit-il être présent sur le
label et l'input ou uniquement l'input.

Le CMS que nous utilisons génère un aria-invalid=true/false à la
fois sur le label et sur le champ.

Lorsque le champ username est laissé vide, le label a :
aria-invalid=false , qui disparaît quand on remplie le champ.

Je préfère avoir confirmation avant de poster une issue sur le Git
de la Core Team mais selon moi l'aria-invalid n'a pas lieu d'être
sur le label ?

Merci de votre aide.

Ariane


___
liste_gta mailing list
liste_gta@list.accessiweb.org mailto: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



--
Aurélien Levy

Temesis

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

Re: [Liste GTA] zone cliquable taille minimum

[Aurélien Levy]

à ma connaissance il n'y a jamais eu cela dans accessiweb par contre il 
me semble que c'était à l'époque dans la méthode blindsurfer qui est 
devenu anysurfer


Aurélien
Merci @Aurélien pour cet enrichissement lié aux écrans tactiles et aux 
WCAG 2,

9 mm correspondent donc +/- à 35px.

Je ne retrouve toujours pas la préco Accessiweb lié aux WCAG 1.
elle me semblait être lié aux image-lien et/ou pictogrammes et comme 
annoncé précédemment.
Le site http://www.fiphfp.fr/ label Or n'a pas de soucis avec ces 
pictogrammes/images-lien

de 17x20 + paddings 10x5 (px)
ou de 15x34 + paddings 5x12 (px)

@Marie : Navré que mes années de développement back ne me permettent 
plus de pragmatisme.


Bien cordialement,
Victor Miguens



Le 23/03/2015 10:01, Aurélien Levy a écrit :
oui ça n'est plus dans wcag 2 par contre ça pourrait finir par y 
revenir :

http://w3c.github.io/Mobile-A11y-TF-Note/#touch-target-size-and-spacing

Aurélien


Merci à vous 2, j’avais aussi vu le 44x44 mais effectivement, je 
cherche une référence tourné plus accessibilité sur le sujet.


@Victor, Je ne retrouve pas ce critère dans les WCAG 1.0, peux-tu 
confirmer ?


Quelqu’un sait pourquoi cette notion a été retirée des WCAG 2.0?

*Marie Baudy*

Web  UX Office

LE GOUVERNEMENT DU GRAND-DUCHÉ DE LUXEMBOURG
Centre des technologies de l’information de l’État

11, rue Notre-Dame . L-2240 Luxembourg
Tél. (+352) 247-82030 . Fax (+352) 247-92061
E-mail :_marie.ba...@ctie.etat.lu mailto:marie.ba...@ctie.etat.lu
www.gouvernement.lu http://www.gouvernement.lu/ . 
www.luxembourg.lu http://www.luxembourg.lu/_


Référentiel de normalisation : www.renow.lu http://www.renow.lu/
Support Renow : renow.i...@ctie.etat.lu mailto:renow.i...@ctie.etat.lu

*De :*liste_gta [mailto:liste_gta-boun...@list.accessiweb.org] *De 
la part de* Victor Miguens

*Envoyé :* lundi 23 mars 2015 08:57
*À :* liste_gta@list.accessiweb.org
*Objet :* Re: [Liste GTA] zone cliquable taille minimum

Bonjour,
Je n'ai pas trouvé le pendant WCAG 2.0,
mais si ma mémoire est bonne, au niveau des WCAG 1 la taille 
minimale de ce type de zone était de 30/30px.

Mais je ne vous retrouve pas la source online assez rapidement.

Bien cordialement,
Victor Miguens

Le 23/03/2015 08:54, Jean-Marc Delisle a écrit :

Bonjour,  tu as des specs,  genre chez Apple ou il est précisé
que la taille d'un bouton droit au moins faire 44 px X 44 px un
truc dans le genre,  après c'est du bon sens. Mais tu auras
toujours des petits malins qui vont te coller un script
absolument utile sur une image 1x1.
Cordialement

Le lun. 23 mars 2015 08:47, Marie Gazel Baudy
marie.ba...@ctie.etat.lu mailto:marie.ba...@ctie.etat.lu a
écrit :

Bonjour la liste,

Existe-t-il une taille minimum pour une zone cliquable ?

Une zone de clic ridicule (comme sur les volets de pub) peut
être un calvaire pour des utilisateurs mobile mais aussi sur
desktop pour des personnes qui ont des soucis moteur. N’est-ce pas ?

Connaissez-vous des recommandations, références sur le sujet ou
un critère en cours de discussion (Accessiweb, WCAG ou autre)
permettant de vérifier cela ?

Merci d’avance pour vos réponses,

*Marie Baudy*

Web  UX Office

LE GOUVERNEMENT DU GRAND-DUCHÉ DE LUXEMBOURG
Centre des technologies de l’information de l’État

11, rue Notre-Dame . L-2240 Luxembourg
Tél. (+352) 247-82030 . Fax (+352) 247-92061
E-mail :_marie.ba...@ctie.etat.lu mailto:marie.ba...@ctie.etat.lu
www.gouvernement.lu http://www.gouvernement.lu/ .
www.luxembourg.lu http://www.luxembourg.lu/_

Référentiel de normalisation : www.renow.lu http://www.renow.lu/
Support Renow : renow.i...@ctie.etat.lu
mailto:renow.i...@ctie.etat.lu




  DECHARGE

Les informations contenues dans cet email peuvent être
confidentielles ou protégées par des lois en vigueur. Elles sont
à l'attention des destinataires uniquement. A moins de respecter
les conditions de la loi du 2 août 2002, les données nominatives
éventuelles ne peuvent être communiquées à des tiers par le
récepteur de cet email.

Si vous n'êtes pas le destinataire principal, ni un des
destinataires placés en copie, la divulgation, la copie, la
diffusion ou toute autre utilisation de cet email est prohibée
et peut être illégale.

Dans ce cas, vous devez avertir l'envoyeur immédiatement et
détruire cet email.

L'émetteur de l'email supporte l'entière responsabilité pour le
contenu purement privé non en relation avec les fonctions que ce
dernier exerce auprès du CTIE.

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

Re: [Liste GTA] zone cliquable taille minimum

[Aurélien Levy]

 prohibée et peut être illégale.


Dans ce cas, vous devez avertir l'envoyeur immédiatement et détruire 
cet email.


L'émetteur de l'email supporte l'entière responsabilité pour le 
contenu purement privé non en relation avec les fonctions que ce 
dernier exerce auprès du CTIE.




___
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

Re: [Liste GTA] mise en pratique RGAA v3

[Aurélien Levy]

Au temps pour moi, j'avais compris que Jean Pierre avait créé cet arbre 
de décision suite à ce problème lors de la restitution.


Aurélien
Pour ma part je n'avais pas encore eu l'occasion de manipuler cette 
notion, et l'arbre de décision m'a permis de sécuriser mes choix 
lorsque j'avais un doute (ce qui n'a été le cas que sur quelques 
situations). Précisons en l'occurrence que l'inspecteur reste 
souverain, et peut décider d'utiliser l'arbre de décision, ou pas.


Cordialement,
--
Olivier Nourry
http://about.me/oliviernourry

http://about.me/oliviernourry


Le 6 mars 2015 09:40, Aurélien Levy aurelien.l...@temesis.com 
mailto:aurelien.l...@temesis.com a écrit :


Bonjour,


  * je ne sais pas si les différences RGAA2 et 3 ont posé
problème au candidat. En tous cas il n'en a pas fait état. A
noter que ce site avait été labellisé sur AW2.1, ce n'est
donc pas le formalisme nouveau qui aura posé problème, je suppose


non tout à fait comme cela portait bien sur des points non
documentés qui suite à l'appel à commentaire ont pour la plupart
été éclairci


  * la procédure est loin d'être inflexible, au contraire; elle
prend parfaitement en compte la notion d'aménagement
raisonnable décrite dans le guide d'accompagnement. Ce qui a
pêché, c'est la compréhension de la procédure de part et
d'autre, point. Cela ne devrait pas se reproduire maintenant
que l'on a clarifié les choses.


Si j'ai bien compris à l'époque de l'audit cette notion n'était en
tout pas cas pas suffisamment claire pour permettre à l'auditeur
du label de juger simplement du caractère raisonnable de la
dérogation puisque c'est suite à cela que Jean Pierre a proposé la
grille avec impact utilisateur, cout de mise en oeuvre, etc.

Mais comme dit dans mon précédent message cela a effectivement
permis de faire évoluer la procédure dans le bon sens.

Aurélien

___
liste_gta mailing list
liste_gta@list.accessiweb.org mailto: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



--
Aurélien Levy

Temesis

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

Re: [Liste GTA] mise en pratique RGAA v3

[Aurélien Levy]

Bonjour,


  * je ne sais pas si les différences RGAA2 et 3 ont posé problème au
candidat. En tous cas il n'en a pas fait état. A noter que ce site
avait été labellisé sur AW2.1, ce n'est donc pas le formalisme
nouveau qui aura posé problème, je suppose

non tout à fait comme cela portait bien sur des points non documentés 
qui suite à l'appel à commentaire ont pour la plupart été éclairci


  * la procédure est loin d'être inflexible, au contraire; elle prend
parfaitement en compte la notion d'aménagement raisonnable décrite
dans le guide d'accompagnement. Ce qui a pêché, c'est la
compréhension de la procédure de part et d'autre, point. Cela ne
devrait pas se reproduire maintenant que l'on a clarifié les choses.

Si j'ai bien compris à l'époque de l'audit cette notion n'était en tout 
pas cas pas suffisamment claire pour permettre à l'auditeur du label de 
juger simplement du caractère raisonnable de la dérogation puisque c'est 
suite à cela que Jean Pierre a proposé la grille avec impact 
utilisateur, cout de mise en oeuvre, etc.


Mais comme dit dans mon précédent message cela a effectivement permis de 
faire évoluer la procédure dans le bon sens.


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

Re: [Liste GTA] mise en pratique RGAA v3

[Aurélien Levy]

 test ?

*Je t'ai fournis un lien de téléchargement de notre propre grille Excel.*

Merci pour vos retours

Claire

*Claire Daval*

*Business  Decision Eolas

http://www.businessdecision-eolas.com/401-accueil.htm?utm_source=BasDeMailutm_medium=Emailutm_campaign=BasdemaillabelENR2015*-
tel.: +33 (0)4 76 44 50 50
tel:%2B33%20%280%294%2076%2044%2050%2050 - fax.: +33 (0)4 76 44
00 41 tel:%2B33%20%280%294%2076%2044%2000%2041
Services en ligne managés 24/7 - e-commerce, e-administration,
e-business

Suivez-nous sur Twitter : @BD_eolas https://twitter.com/BD_eolas


http://www.businessdecision-eolas.com/uploads/Image/ca/6772_222_label-ENR-bas-de-mail.jpg

http://www.businessdecision-eolas.com/3697-label-entreprise-numerique-responsable.htm?utm_source=BasDeMailutm_medium=Emailutm_campaign=BasdemaillabelENR2015



*▶**Eolas, labellisée Entreprise Numérique Responsable !*

http://www.businessdecision-eolas.com/3697-label-entreprise-numerique-responsable.htm?utm_source=BasDeMailutm_medium=Emailutm_campaign=BasdemaillabelENR2015


___
liste_gta mailing list
liste_gta@list.accessiweb.org mailto: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



--
Aurélien Levy

Temesis

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

Re: [Liste GTA] Fieldset imbriqués ?

[Aurélien Levy]

Chez moi le title est bien restitué par défaut sur les champs de formulaire

Aurélien

Merci de vos pistes,

- labelledby à pour effet d'annuler la lecture du label déjà présent 
dans la page, donc on ne sait plus quel est le label de la case.

- Le title, n'est pas restitué avec la config par défaut en tout cas.
- avec aria-describedby en revanche, le label par défaut est conservé 
et le texte de description est lu ensuite.


Je vais opter pour /aria-describedby/ qui à la meilleur restitution 
d’après mes tests sur NVDA / Jaws.


Merci

*Cyril Lamotte*
Jouve I.T. Solutions - Développeur Front-end / Expert accessibilité
02 43 08 39 97

Adoptez l'éco-attitude. N'imprimez ce courriel que si c'est vraiment 
nécessaire.


Le présent mail ainsi que toutes les informations qu'il contient ne 
peuvent en aucun cas être considérés comme un engagement juridique de 
quelque nature que ce soit de JOUVE. Tout accord devra être formulé 
par écrit papier ultérieur signé par un représentant légal de JOUVE. 
Par ailleurs, si vous recevez ce mail par erreur, merci de nous le 
signaler et de le détruire ainsi que l'intégralité du document qui 
pourrait y être joint.


Jouve Its http://www.jouve.com/fr/signature
Le 03/03/2015 11:03, Aurélien Levy a écrit :

ou title tout simplement ;)

Aurélien

Bonjour,

Les lecteurs se prennent les pieds dans le tapis avec les fieldsets 
imbriqués d'où le fait de le déconseiller.
Personnellement, je m'appuierai sur aria-labelledby pour implémenter 
ces éléments.


Romain

Le 3 mars 2015 10:55, Cyril Lamotte clamo...@jouve.fr 
mailto:clamo...@jouve.fr a écrit :


Bonjour la liste,

Selon vous,  comment coderiez-vous ce formulaire de filtres au
niveau des fieldset sachant que les checkboxes devraient être
dans des fieldsets d'après le référentiel AW.
J'ai l'impression d'être obligé d'imbriquer des fieldset, or je
lis ici ou là que ce n'est pas conseillé.

Qu'en pensez-vous ?


-- 


*Cyril Lamotte*
Jouve I.T. Solutions - Développeur Front-end / Expert accessibilité
02 43 08 39 97 tel:02%2043%2008%2039%2097

Adoptez l'éco-attitude. N'imprimez ce courriel que si c'est
vraiment nécessaire.

Le présent mail ainsi que toutes les informations qu'il contient
ne peuvent en aucun cas être considérés comme un engagement
juridique de quelque nature que ce soit de JOUVE. Tout accord
devra être formulé par écrit papier ultérieur signé par un
représentant légal de JOUVE. Par ailleurs, si vous recevez ce
mail par erreur, merci de nous le signaler et de le détruire
ainsi que l'intégralité du document qui pourrait y être joint.

Jouve Its http://www.jouve.com/fr/signature

___
liste_gta mailing list
liste_gta@list.accessiweb.org mailto: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



--
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



--
Aurélien Levy

Temesis

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

Re: [Liste GTA] Fieldset imbriqués ?

[Aurélien Levy]

ou title tout simplement ;)

Aurélien

Bonjour,

Les lecteurs se prennent les pieds dans le tapis avec les fieldsets 
imbriqués d'où le fait de le déconseiller.
Personnellement, je m'appuierai sur aria-labelledby pour implémenter 
ces éléments.


Romain

Le 3 mars 2015 10:55, Cyril Lamotte clamo...@jouve.fr 
mailto:clamo...@jouve.fr a écrit :


Bonjour la liste,

Selon vous,  comment coderiez-vous ce formulaire de filtres au
niveau des fieldset sachant que les checkboxes devraient être
dans des fieldsets d'après le référentiel AW.
J'ai l'impression d'être obligé d'imbriquer des fieldset, or je
lis ici ou là que ce n'est pas conseillé.

Qu'en pensez-vous ?


-- 


*Cyril Lamotte*
Jouve I.T. Solutions - Développeur Front-end / Expert accessibilité
02 43 08 39 97 tel:02%2043%2008%2039%2097

Adoptez l'éco-attitude. N'imprimez ce courriel que si c'est
vraiment nécessaire.

Le présent mail ainsi que toutes les informations qu'il contient
ne peuvent en aucun cas être considérés comme un engagement
juridique de quelque nature que ce soit de JOUVE. Tout accord
devra être formulé par écrit papier ultérieur signé par un
représentant légal de JOUVE. Par ailleurs, si vous recevez ce mail
par erreur, merci de nous le signaler et de le détruire ainsi que
l'intégralité du document qui pourrait y être joint.

Jouve Its http://www.jouve.com/fr/signature

___
liste_gta mailing list
liste_gta@list.accessiweb.org mailto: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



--
Aurélien Levy

Temesis

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

Re: [Liste GTA] Jaws vocalise clic

[Aurélien Levy]

Bonjour,

c'est étrange, est tu certain de ne pas avoir de gestionnaire 
d'événement au clic sur les span, le td parent ou le tr parent ?


Aurélien

Bonjour,
petite question sur la restitution par Jaws du code suivant :
td class=date
span class=day04/09/span
span class=hour10h03/span
/td
Jaws vocalise : 24, barre oblique, 09, clic, 16, h, 29, 
clic.

A quoi correspond clic ?
L'afficheur braille de Jaws affiche 04/0910h03.
Ne serait-il pas plus intéressant pour l'utilisateur que le code se 
base sur des balises p ?
En juin 2013, la division Services Numériques du *Groupe D.A.C.P* 
(maison mère d'*Etic*) a créé une nouvelle société de services : 
*Novia Systems* avec 500 nouveaux collaborateurs. Dans notre volonté 
d'apporter à nos clients des réponses adaptées aux dés de demain, 
*Etic* et *Novia Systems* ont fusionné au 1er janvier 2014 pour 
donner naissance à une société de services numériques de 1000 
personnes et de plus de 80 M€ de C.A, qui porte le nom de *Novia 
Systems*.
novia systems 	FRÉDÉRIC BERNIER-MALCOIFFE CHEF DE PROJETS - EXPERT EN 
ACCESSIBILITE

*adresse : *1, rue du Château de l'Eraudière - 44306 - NANTES Cedex 3
*tél : *+33 (0)2.51.89.78.78 - *fax : *+33 (0)2.51.89.78.50
*direct : *+33 (0)2.51.89.78.66 - *poste : 32*.66



___
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

Re: [Liste GTA] Apparence de checkbox customisée via CSS et ARIA

[Aurélien Levy]

Merci pour l'exemple.
En effet, dans le 10.3 du RGAA 3, il n'y a pas de test sur la 
désactivation des images.

La surcharge de rôle du label via ARIA (checkbox)est-elle conforme ?
oui à partir du moment ou tu reproduit bien l'ensemble des comportements 
natifs (prise de focus visible, activable au clavier de la même manière 
que la case à cocher native, etc) et que cela fonctionne quand tu teste 
le rendu dans la base de référence RGAA3 notamment le rendu du 
nom/intitulé, du role et de l'état. (chez moi en tout cas sur safari et 
voiceover ça fonctionne pas)

Et globalement, le code évalué est-il conforme ?

cf point précédant tu dois tester le rendu.

Aurélien


-Original Message-
From: Aurélien Levy aurelien.l...@temesis.com
To: liste_gta@list.accessiweb.org
Date: Thu, 11 Dec 2014 18:34:09 +0100
Subject: Re: [Liste GTA] Apparence de checkbox customisée via CSS
et ARIA

Bonjour,

pour ce genre de chose tu n'as pas besoin de passer par aria,
exemple :

http://blog.temesis.com/post/2014/03/18/cases-a-cocher-personnalisees-accessibles


Le problème ici est que tes cases à cocher sont faites via des
images de fond donc si tu les désactives / mode fort contraste /
css utilisateurs / problème de chargement, elles disparaitront ce
qui perturber les utilisateurs voyants et malvoyants.

A noter, lors de l'appel à commentaire au GTA sur le RGAA 3, la
majorité a demandé le maintient de la prise en compte de ce cas de
figure mais ils semble cf la version béta que la DISIC ce soit
ranger à l'avis contraire.

Aurélien

Bonjour,
voici un nouveau cas lors de mon éval qui me laisse perplexe.
Le code suivant permet d'afficher ses propres images, via CSS,
pour représenter la case à cocher.
input type=checkbox value=Afficher name=TYPE
checked=checked class=checkbox-mobile
id=presentationModeDemarrage
label role=checkbox tabindex=0 aria-checked=true
for=presentationModeDemarrage id=xxxAfficher les astuces au
prochain démarrage/label
La classe checkbox-mobile fait un display:none.
La restitution par Jaws par prise de focus est bonne : Case  à
cocher Afficher les astuces au prochain démarrage Cochée 
Par contre, la sélection/désélection n'est pas notifiée.
Le détournement via ARIA du rôle natif de l'élément label est-il
conforme ? Si non, quel critère permet d'invalider ?
Comment implémenter la notification ?
Merci d'avance pour votre collaboration.
FRÉDÉRIC BERNIER-MALCOIFFE


___
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



--
Aurélien Levy

Temesis

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

Re: [Liste GTA] Apparence de checkbox customisée via CSS et ARIA

[Aurélien Levy]

Bonjour,

pour ce genre de chose tu n'as pas besoin de passer par aria, exemple :
http://blog.temesis.com/post/2014/03/18/cases-a-cocher-personnalisees-accessibles

Le problème ici est que tes cases à cocher sont faites via des images de 
fond donc si tu les désactives / mode fort contraste / css utilisateurs 
/ problème de chargement, elles disparaitront ce qui perturber les 
utilisateurs voyants et malvoyants.


A noter, lors de l'appel à commentaire au GTA sur le RGAA 3, la majorité 
a demandé le maintient de la prise en compte de ce cas de figure mais 
ils semble cf la version béta que la DISIC ce soit ranger à l'avis 
contraire.


Aurélien

Bonjour,
voici un nouveau cas lors de mon éval qui me laisse perplexe.
Le code suivant permet d'afficher ses propres images, via CSS, pour 
représenter la case à cocher.
input type=checkbox value=Afficher name=TYPE checked=checked 
class=checkbox-mobile id=presentationModeDemarrage
label role=checkbox tabindex=0 aria-checked=true 
for=presentationModeDemarrage id=xxxAfficher les astuces au 
prochain démarrage/label

La classe checkbox-mobile fait un display:none.
La restitution par Jaws par prise de focus est bonne : Case  à cocher 
Afficher les astuces au prochain démarrage Cochée 

Par contre, la sélection/désélection n'est pas notifiée.
Le détournement via ARIA du rôle natif de l'élément label est-il 
conforme ? Si non, quel critère permet d'invalider ?

Comment implémenter la notification ?
Merci d'avance pour votre collaboration.
FRÉDÉRIC BERNIER-MALCOIFFE


___
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

Re: [Liste GTA] Canva, légende et alternatives

[Aurélien Levy]

Bonjour,

Pour moi c'est clairement une image décorative vu que toutes les infos 
sont présente textuellement.


Il faut juste s'assurer que le % est bien mis à jour et restitué à 
intervalle régulier :


div aria-live=assertive aria-labelledby=xxx
span10%/span
canvas width=220 height=220/canvas
/div
p id=xxxSynchronisationbrspan style=font-size:xx-smallMise à 
jour de la base locale/span/p


Aurélien

Bonjour,

j'aimerais avoir votre avis sur le cas suivant dans le cadre d'une éval.

Une image bitmap (balise canvas) est utilisée pour illustrer la 
progression d'une synchronisation : un cercle se colore par tranche de 5%.

C'est le seul élément d'une page blanche.
Il s'agit selon moi d'une image porteuse d'information pour laquelle 
il faut évaluer la pertinence de l'alternative.


Le code est le suivant :
span10%/span
canvas width=220 height=220/canvas
spanSynchronisationbrspan style=font-size:xx-smallMise à jour 
de la base locale/span/span


L'image et le texte du pourcentage sont mis à jour par script.

Quel(s) critère(s) invalider ?
Le 1.3.9 est non applicable car le contenu entre canvas et 
/canvas est vide.
Peut-on considérer qu'on est dans le cas d'une image bitmap légendée 
(1.10.5) et que ce critère et non valide ?


Les préconisations de correction suivantes sont-elles correctes ? 
Laquelle est la meilleure ?


Préco 1 :

figure role=group 
canvas width=220 height=220Synchronisation/canvas
figcaption
span id=pourcent10%/spanspanSynchronisationbrspan 
style=font-size:xx-smallMise à jour de la base locale/span/span

/figcaption
/figure

Préco 2 :

canvas width=220 height=220
span id=pourcent10%/spanspanSynchronisationbrspan 
style=font-size:xx-smallMise à jour de la base locale/span/span

/canvas

[Mode troll on]
Préco 3 (solution alternative simplifiée) :
L'image est considérée comme une image de décoration et n'est pas 
restituée aux TA.
Une notification est implémentée de manière accessible : 
Synchronisation (mise à jour de la base locale) en cours.

Elle est répétée régulièrement (toutes les 5 secondes ?).
[Mode troll off]

Merci de votre collaboration !

En juin 2013, la division Services Numériques du *Groupe D.A.C.P* 
(maison mère d'*Etic*) a créé une nouvelle société de services : 
*Novia Systems* avec 500 nouveaux collaborateurs. Dans notre volonté 
d'apporter à nos clients des réponses adaptées aux dés de demain, 
*Etic* et *Novia Systems* ont fusionné au 1er janvier 2014 pour 
donner naissance à une société de services numériques de 1000 
personnes et de plus de 80 M€ de C.A, qui porte le nom de *Novia 
Systems*.
novia systems 	FRÉDÉRIC BERNIER-MALCOIFFE CHEF DE PROJETS - EXPERT EN 
ACCESSIBILITE

*adresse : *1, rue du Château de l'Eraudière - 44306 - NANTES Cedex 3
*tél : *+33 (0)2.51.89.78.78 - *fax : *+33 (0)2.51.89.78.50
*direct : *+33 (0)2.51.89.78.66 - *poste : 32*.66



___
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

Re: [Liste GTA] Menu Accessible Adobe

[Aurélien Levy]

Bonsoir,

ce menu est effectivement très bien par contre il semble me souvenir que 
justement il ne respectait pas le design pattern menu ARIA et cela de 
manière volontaire d'après les développeurs. Par contre comme il n'est 
plus utilisé sur le site adobe, difficile de vérifier cela.


Aurélien

Merci de ce retour !

Le 28 octobre 2014 14:37, san...@free.fr mailto:san...@free.fr a 
écrit :


hello Ariane,
j'ai utilisé ce plug, il fonctionne très bien ;et respecte les
design pattern,
pas de soucis tu peux y aller,
a+

Sanvin

- Mail original -
De: Ariane Andurand ariane.c...@gmail.com
mailto:ariane.c...@gmail.com
À: liste gta liste_gta@list.accessiweb.org
mailto:liste_gta@list.accessiweb.org
Envoyé: Mardi 28 Octobre 2014 14:09:00
Objet: [Liste GTA] Menu Accessible Adobe





Bonjour la liste,

J'ai besoin d'adapter une vue d'un template Joomla! pour rendre un
menu accessible. Pour ce faire je comptais partir du code suivant:
http://adobe-accessibility.github.io/Accessible-Mega-Menu/
https://github.com/adobe-accessibility/Accessible-Mega-Menu/

L'un d'entre vous a-t-il déjà implémenté ce menu ? et si oui, je
résultat a-t-il était

Ariane

___
liste_gta mailing list
liste_gta@list.accessiweb.org mailto: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 mailto: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



--
Aurélien Levy

Temesis

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

Re: [Liste GTA] 10.4.2 -- pourquoi interdire unité PT sur CSS media print ?

[Aurélien Levy]

Il s'agit simplement d'être cohérent si c'est fait dans l'intitulé pour 
le 10.4.1 je ne vois pas pourquoi ce n'est pas le cas dans le 10.4.2 
alors que cela s'applique aussi.


C'est une info utile pour les outils automatiques mais également pour le 
testeur manuel qui n'ayant pas cette précision serait tenter de vérifier 
sur toutes les css peu importe le media.


De même, dans le 10.4.2 il faudrait parler de tailles des caractères et 
non de taille des polices pour être cohérent.


Cela donnerait :
Test 10.4.2 : Pour les feuilles de styles 
http://www.accessiweb.org/index.php/glossaire-du-referentiel-accessiweb-html5aria.html#mFeuilleStyle 
du site Web 
http://www.accessiweb.org/index.php/glossaire-du-referentiel-accessiweb-html5aria.html#mSiteWeb 
de type de média screen, tv, handheld, projection, la tailles des 
caractères 
http://www.accessiweb.org/index.php/glossaire-du-referentiel-accessiweb-html5aria.html#mTailleCaractere 
utilisent-elles uniquement des unités relatives (% ou em) ou des mots 
clés (xx-small, xx-small, x-small, small, medium, large, x-large, 
xx-large, xsmaller, or larger) ?


L'autre solution serait de tout cacher dans le glossaire mais c'est 
clairement pas ma préférence.


Aurélien

salut Aurélien,
dans la mesure où l'objet de ce critère est de préserver la 
possibilité d'agrandissement des caractères par l'utilisateur dans le 
navigateur, j'ai du mal à voir en quoi ça peut être interprété comme 
incluant potentiellement les CSS print.
Mais bon, tu m'as habitué à voir les trucs que je ne vois pas, je suis 
donc curieux de savoir ce que j'ai loupé!! ;-) [clin d'oeil]


Cordialement,
--
Olivier Nourry
http://about.me/oliviernourry

http://about.me/oliviernourry




--
Aurélien Levy

Temesis

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

Re: [Liste GTA] image légendée avec alternative vide

[Aurélien Levy]

Le 06/09/2014 16:05, Romain Gervois a écrit :

Bonjour Aurélien,

aria-labelledby n'étant pas référencé comme implémentation possible 
d'une alternative (ça ne doit pas se conformer à la base de références 
je présume) et le alt étant requis, il ne peut s'agir que d'une simple 
exception.
Certes, il n'est pas référencé mais d'après mes tests c'est bien 
conforme avec la base de référence puisque ça fonctionne avec 
voiceover+safari et ndva (2 dernières version à minima) / Jaws 13/15 + 
Firefox (et aussi à minima sur IE11) que ce soit dans un 
figure+figcaption ou pas. Par contre les tests confirment bien qu'il est 
préférable de ne pas mettre d'attribut alt du tout (ou un attribut alt 
non vide mais dans ce cas aria-describedby serait préférable).


L'usage aria-labelledby devrait être donc être globalement autorisé (en 
tout cas pour ma part présent ou pas dans AW/RGAA3 vu que WCAG 
l'autorise et que ça fonctionne je me l'autoriserais dans certaines 
situation ;) )



--
Aurélien Levy

Temesis


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

Re: [Liste GTA] Label implicite

[Aurélien Levy]

Je confirme que ce n'est pas correcte à cause du support défaillant de 
certaines aides techniques (il n'y a pas que les lecteurs d'écran, par 
exemple dragon naturally speaking ne le gère pas par exemple)


Aurélien

Bonjour,

Ceci est valide HTML (4: je suis sur, 5: je n'ai pas vérifié).
Je crois me souvenir que cette syntaxe était toutefois déconseillée en 
raison du support dans les lecteurs d'écran.


Je ne sais pas si c'est toujours d'actualité

Cordialement,

*Cyril FABBY*
*
*
/Ingénieur d'étude, //Expert Accessiweb 2.0 en Evaluation de page, 
//Ergonomie, Web Design/

/
/
*Key Consulting http://keyconsulting.fr*
41 rue Emile Duclaux
92150 Suresnes
Tél: 01 41 38 90 40
Fax: 01 41 38 90 41
P *Avant d'imprimer cet email, réfléchissez à l'impact sur 
l'environnement, merci*



Le 5 septembre 2014 10:37, Cyril Lamotte clamo...@jouve.fr 
mailto:clamo...@jouve.fr a écrit :


Bonjour la Liste,

Une petite question en 3 parties :)

a/ Un champ contenu dans un label est-il une façon accessible de
coder une étiquette ?


  label
select id=u104 class=u104
  option selected= value=TousTous/option
  option value=Texte Texte /option
/select
  /label


b/ On m'a reporté l'absence d'attribut for ici sur le label
comme une erreur, qu'en pensez-vous ?
Le fait que le champ soit à l'intérieur du label ne rend pas le
code accessible ?

c/ Le critère ne semble pas faire mention de ça et impose un for

http://www.accessiweb.org/index.php/accessiweb-html5aria-liste-deployee.html#crit-11-1


A vous !

Bien cordialement,

-- 


*Cyril Lamotte*
Jouve I.T. Solutions - Développeur Front-end / Expert accessibilité
02 43 08 39 97

Adoptez l'éco-attitude. N'imprimez ce courriel que si c'est
vraiment nécessaire.

Le présent mail ainsi que toutes les informations qu'il contient
ne peuvent en aucun cas être considérés comme un engagement
juridique de quelque nature que ce soit de JOUVE. Tout accord
devra être formulé par écrit papier ultérieur signé par un
représentant légal de JOUVE. Par ailleurs, si vous recevez ce mail
par erreur, merci de nous le signaler et de le détruire ainsi que
l'intégralité du document qui pourrait y être joint.


___
liste_gta mailing list
liste_gta@list.accessiweb.org mailto: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



--
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] role search test 12.10.4

[Aurélien Levy]

Bonjour,

le test 12.10.4 restreint l'usage du role=search sur le champ de 
saisie, y a t il une raison à cela ? Les exemples issu de wcag ou de la 
spec que j'ai trouvé autorise son usage sur le formulaire ou la div qui 
contient le champ.


Il me semble qu'il y avait un temps un bug avec jaws qui est peut être à 
l'origine de cela mais je pense que ce n'est plus d'actualité.


--
Aurélien Levy

Temesis


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

Re: [Liste GTA] role search test 12.10.4

[Aurélien Levy]

ok merci, il semble que le site avec commentaires préliminaires n'est 
plus en ligne :
http://accessibilite-numerique-forum.smile-hosting.fr/ me dit adresse 
introuvable


D'ailleurs, y a t il des nouvelles de l'appel à commentaires publiques ?

Aurélien

Hello,
si je me rappelle bien, cela avait été signalé lors de l'appel à 
commentaires préliminaire du RGAA, et identifié comme une restriction 
qui allait être levée. Donc a priori cela pourra être appliqué à un 
FORM ou autre INPUT ayant ce rôle.


Cordialement,
--
Olivier Nourry
http://about.me/oliviernourry

http://about.me/oliviernourry



Le 4 septembre 2014 10:21, Aurélien Levy aurelien.l...@temesis.com 
mailto:aurelien.l...@temesis.com a écrit :


Bonjour,

le test 12.10.4 restreint l'usage du role=search sur le champ de
saisie, y a t il une raison à cela ? Les exemples issu de wcag ou
de la spec que j'ai trouvé autorise son usage sur le formulaire ou
la div qui contient le champ.

Il me semble qu'il y avait un temps un bug avec jaws qui est peut
être à l'origine de cela mais je pense que ce n'est plus d'actualité.

-- 
Aurélien Levy


Temesis


___
liste_gta mailing list
liste_gta@list.accessiweb.org mailto: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



--
Aurélien Levy

Temesis

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

Re: [Liste GTA] role search test 12.10.4

[Aurélien Levy]

Le site de commentaires préliminaire était voué à être temporaire, 
c'est pour cela qu'il est fermé.
Il semblait me souvenir que le dernier message sur le forum de M. 
Maucorps indiquait le contraire.
Il me semble également qu'il serait utile qu'il soit encore accessible 
pendant la période d'appel à commentaire publique.
Cela éviterait de remonter des choses déjà remontées et qui n'ont pas 
été prise en compte et permettrait à tous d'avoir les explications qui 
ont été données sur certains points lors de la consultation restreinte.


Aurélien

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

Re: [Liste GTA] test 5.1.1

[Aurélien Levy]

Il est obsolète mais au niveau de la conformité AW/RGAA/WCAG à ma 
connaissance rien n'interdit l'usage de balise ou attribut obsolète pas 
plus qu'il n'est interdit d'utiliser des éléments / balise hors de la spec.


Ce qui n'est pas implémenté par les navigateurs c'est l'affichage du 
summary il est parfaitement géré par les lecteurs d'écrans.


Bonjour,

Je me suis posé cette question tout récemment.

Dans mon cas j’ai supprimé summary pour laisser le seul caption qui 
devient par nature deux en un (titre et résumé).


Si j’ai bien compris, il est aussi possible d’écrire un texte juste 
avant le tableau dans le code source en guise de résumé.


L’attribut summary n’est-il pas déprécié en html5 ?
Est-il implémenté dans un navigateur ?

De mon souvenir, seul Opera le gérait, mais mes infos ne sont 
peut-être plus à jour.


Yves

*De :*liste_gta [mailto:liste_gta-boun...@list.accessiweb.org] *De la 
part de* Aurélien Levy

*Envoyé :* lundi 1 septembre 2014 15:52
*À :* liste_gta@list.accessiweb.org
*Objet :* Re: [Liste GTA] test 5.1.1

Ok dans ce cas faudrait le dire dans la note technique sinon on a 
aucune solution quand on se contente de la note technique actuelle.


Si on continue d'utiliser summary est ce que cela invaliderait-il un 
critère ? (à mon avis non)


Aurélien

Bonjour,

Et si on utilise déjà un caption visible pour mettre le titre,
on le met où le résumé ?

À la suite du titre, masqué dans le caption ?

Bel après-midi.
Sébastien.

Le 1 sept. 2014 15:41, jean-pierre villain jpvill...@yahoo.fr
mailto:jpvill...@yahoo.fr a écrit :

 Bonjour,

 Résumé en passage de texte dans l'élément caption,
éventuellement masqué.
 C'est le seul truc qui fonctionne correctement selon ce qui est
attendu.

 
 Jean-Pierre Villain - +33 6 98 08 50 49

 
 De : Aurélien Levy aurelien.l...@temesis.com
mailto:aurelien.l...@temesis.com
 À : gt  liste_gta@list.accessiweb.org
mailto:liste_gta@list.accessiweb.org
liste_gta@list.accessiweb.org
mailto:liste_gta@list.accessiweb.org
 Envoyé le : Lundi 1 septembre 2014 15h34
 Objet : [Liste GTA] test 5.1.1

 Bonjour à tous,

 j'ai une interrogation sur le test 5.1.1
 Pour chaque tableau de données complexe (balise table) un
résumé est-il disponible dans la balise caption ? 

 En AW 2 on utilisait l'attribut summary maintenant la note
technique dit :
 La spécification propose plusieurs méthodes pour lier un résumé
à un tableau (tableau lié à un passage de texte avec
aria-describedby, tableau groupé via figure avec le résumé en
texte adjacent, tableau groupé avec figure avec le résumé dans un
élément figcaption, résumé dans un élément details dans l'élément
caption).
 mais elle dit aussi :
 Ces méthodes n'ont pas un support suffisant pour être utilisées
actuellement.

 Du coup, on est sensé utiliser quoi pour être conforme ? summary
? rien ?

 --
 Aurélien Levy
 
 Temesis


 ___
 liste_gta mailing list
 liste_gta@list.accessiweb.org mailto: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 mailto: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  mailto: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



--
Aurélien Levy

Temesis

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

Re: [Liste GTA] Plateforme multimédia

[Aurélien Levy]

Bonjour Marc Antoine,

Qu'appelez vous une plateformes multimédias ?

Aurélien Levy


Bonjour à tous,

Pouvez-vous me dire quelles sont les plateformes multimédias accessible ?

Titre : Accueil du site Association Valentin Haüy (Logo) 
http://www.avh.asso.fr/




*Marc-Antoine Bonnet*

Webmaster AVH
Expert AccessiWeb en Evaluation

*Email : webmas...@avh.asso.fr mailto:webmas...@avh.asso.fr*

*Tel : 01 44 49 27 27 -- Poste 2219*



Titre : Partagez sur Facebook ! 
http://www.facebook.com/pages/Association-Valentin-Hauy-AVH/162383987105585Titre : 
Partagez sur Twitter ! http://www.twitter.com/ValentinHauyTitre : 
Partagez sur Youtube ! 
http://www.youtube.com/user/AssoValentinHauyTitre : Consultez nos 
E-newsletter ! 
http://www.avh.asso.fr/rubriques/newsletter/dernier_enews.php**




___
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] Slideshow accessible

[Aurélien Levy]

Bonjour Ariane,

aria-expanded ne te servirai à rien, cela sert à signaler si un bloc est 
ouvert ou fermé pas si il est visible ou non.


Par ailleurs, de ce que j'ai compris des discussions du forum RGAA en 
l'état actuelle des choses :
1- tu n'as aucune obligation d'utiliser aria tant que ton composant est 
accessible sinon fournir une alternative accessible
2- si tu utilise aria et que ton composant fait partie des composants 
pour lesquels il existe un modèle de conception 
http://www.w3.org/TR/wai-aria-practices/#aria_ex (c'est libre à toi de 
juger si ça correspond à quelque chose d'existant mais dans le cas des 
carrousel pour moi ce n'est pas le cas) tu dois le respecter ou en 
proposer à minima une version dérivée sinon fournir une alternative 
accessible


Enfin l'exemple que tu donne http://bartdc.anysurfer.be/slideshow/ n'est 
en soit pas conforme AW ou RGAA actuel car les boutons de contrôle 
disparaissent quand css activé et image de fond désactivé (mode fort 
contraste ou css utilisateur). Par ailleurs on peut débattre de la 
logique de l'ordre de navigation clavier car les contrôles se situent 
après le contenu des slides du coup si l'utilisateur active un slide il 
est obligé de revenir en arrière ce qui n'est pas des plus simples à 
utiliser (et que pour ma part je jugerai non conforme).


Aurélien

Bonjour la liste,

En dépit du fait qu'un slideshow, galerie, carrousel (appelons le 
comme on veut) n'est pas très utile, si on doit en mettre un, il se 
doit d'être accessible.


J'ai cherché et j'ai fini par implémenter celui-ci 
http://www.anysurfer.be/fr/blog/detail/un-diaporama-sur-la-home-page-sil-le-faut-vraiment 
pour un projet mais il ne contient pas de balise aria-expanded etc, 
... Le js n'est donc pas accessible ?


Merci pour vos réponses.

Ariane



___
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

Re: [Liste GTA] Slideshow accessible

[Aurélien Levy]

Bonjour Antoine,

avec AW HTML5 tu n'as plus à fournir d'alternative à js si ton composant 
avec js est accessible.


Aurélien

De plus, sans JS, le diaporama n'affiche juste rien du tout...

Donc ca m'étonnerait que tous les critères d'accessibilité soient 
remplis ;)



Cordialement,

Antoine Bouet
Ingénieur Développement
Expert AccessiWeb en Evaluation

CIMEOS
Montbéliard - Besançon - Paris

e-mail : antoine.bo...@cimeos.com mailto:antoine.bo...@cimeos.com
tel. : +33(0)9 72 30 72 42

www.cimeos.com http://www.cimeos.com

COORDONNEES DU SUPPORT :
Hébergement et Nom de Domaine : supp...@cimeos.com 
mailto:supp...@cimeos.com / 0899 49 42 00 (1.34EUR/appel puis 0.34/min)
Maintenance des sites : maintena...@cimeos.com 
mailto:maintena...@cimeos.com

Le 25/07/2014 14:43, Aurélien Levy a écrit :

Bonjour Ariane,

aria-expanded ne te servirai à rien, cela sert à signaler si un bloc 
est ouvert ou fermé pas si il est visible ou non.


Par ailleurs, de ce que j'ai compris des discussions du forum RGAA en 
l'état actuelle des choses :
1- tu n'as aucune obligation d'utiliser aria tant que ton composant 
est accessible sinon fournir une alternative accessible
2- si tu utilise aria et que ton composant fait partie des composants 
pour lesquels il existe un modèle de conception 
http://www.w3.org/TR/wai-aria-practices/#aria_ex (c'est libre à toi 
de juger si ça correspond à quelque chose d'existant mais dans le cas 
des carrousel pour moi ce n'est pas le cas) tu dois le respecter ou 
en proposer à minima une version dérivée sinon fournir une 
alternative accessible


Enfin l'exemple que tu donne http://bartdc.anysurfer.be/slideshow/ 
n'est en soit pas conforme AW ou RGAA actuel car les boutons de 
contrôle disparaissent quand css activé et image de fond désactivé 
(mode fort contraste ou css utilisateur). Par ailleurs on peut 
débattre de la logique de l'ordre de navigation clavier car les 
contrôles se situent après le contenu des slides du coup si 
l'utilisateur active un slide il est obligé de revenir en arrière ce 
qui n'est pas des plus simples à utiliser (et que pour ma part je 
jugerai non conforme).


Aurélien

Bonjour la liste,

En dépit du fait qu'un slideshow, galerie, carrousel (appelons le 
comme on veut) n'est pas très utile, si on doit en mettre un, il se 
doit d'être accessible.


J'ai cherché et j'ai fini par implémenter celui-ci 
http://www.anysurfer.be/fr/blog/detail/un-diaporama-sur-la-home-page-sil-le-faut-vraiment 
pour un projet mais il ne contient pas de balise aria-expanded etc, 
... Le js n'est donc pas accessible ?


Merci pour vos réponses.

Ariane



___
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 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

Re: [Liste GTA] Slideshow accessible

[Aurélien Levy]

non tu peux tout à fait rendre un menu déroulant, un carrousel ou autre 
accessible sans utiliser aria.


Exemple pour un bloc qui se déplie tu peux utiliser du texte masqué pour 
indiquer l'état ouvert /fermé du bloc à la place de aria-expanded et le 
rendre utilisable au clavier.



Aurélien

Ca veut dire si on utilise ARIA je suppose ?

Car si pas d'ARIA, ni d'alternative au JS, ca me parait compliqué non ?


Cordialement,

Antoine Bouet
Ingénieur Développement
Expert AccessiWeb en Evaluation

CIMEOS
Montbéliard - Besançon - Paris

e-mail : antoine.bo...@cimeos.com mailto:antoine.bo...@cimeos.com
tel. : +33(0)9 72 30 72 42

www.cimeos.com http://www.cimeos.com

COORDONNEES DU SUPPORT :
Hébergement et Nom de Domaine : supp...@cimeos.com 
mailto:supp...@cimeos.com / 0899 49 42 00 (1.34EUR/appel puis 0.34/min)
Maintenance des sites : maintena...@cimeos.com 
mailto:maintena...@cimeos.com

Le 25/07/2014 15:26, Aurélien Levy a écrit :

Bonjour Antoine,

avec AW HTML5 tu n'as plus à fournir d'alternative à js si ton 
composant avec js est accessible.


Aurélien

De plus, sans JS, le diaporama n'affiche juste rien du tout...

Donc ca m'étonnerait que tous les critères d'accessibilité soient 
remplis ;)



Cordialement,

Antoine Bouet
Ingénieur Développement
Expert AccessiWeb en Evaluation

CIMEOS
Montbéliard - Besançon - Paris

e-mail : antoine.bo...@cimeos.com mailto:antoine.bo...@cimeos.com
tel. : +33(0)9 72 30 72 42

www.cimeos.com http://www.cimeos.com

COORDONNEES DU SUPPORT :
Hébergement et Nom de Domaine : supp...@cimeos.com 
mailto:supp...@cimeos.com / 0899 49 42 00 (1.34EUR/appel puis 
0.34/min)
Maintenance des sites : maintena...@cimeos.com 
mailto:maintena...@cimeos.com

Le 25/07/2014 14:43, Aurélien Levy a écrit :

Bonjour Ariane,

aria-expanded ne te servirai à rien, cela sert à signaler si un 
bloc est ouvert ou fermé pas si il est visible ou non.


Par ailleurs, de ce que j'ai compris des discussions du forum RGAA 
en l'état actuelle des choses :
1- tu n'as aucune obligation d'utiliser aria tant que ton composant 
est accessible sinon fournir une alternative accessible
2- si tu utilise aria et que ton composant fait partie des 
composants pour lesquels il existe un modèle de conception 
http://www.w3.org/TR/wai-aria-practices/#aria_ex (c'est libre à toi 
de juger si ça correspond à quelque chose d'existant mais dans le 
cas des carrousel pour moi ce n'est pas le cas) tu dois le 
respecter ou en proposer à minima une version dérivée sinon fournir 
une alternative accessible


Enfin l'exemple que tu donne http://bartdc.anysurfer.be/slideshow/ 
n'est en soit pas conforme AW ou RGAA actuel car les boutons de 
contrôle disparaissent quand css activé et image de fond désactivé 
(mode fort contraste ou css utilisateur). Par ailleurs on peut 
débattre de la logique de l'ordre de navigation clavier car les 
contrôles se situent après le contenu des slides du coup si 
l'utilisateur active un slide il est obligé de revenir en arrière 
ce qui n'est pas des plus simples à utiliser (et que pour ma part 
je jugerai non conforme).


Aurélien

Bonjour la liste,

En dépit du fait qu'un slideshow, galerie, carrousel (appelons le 
comme on veut) n'est pas très utile, si on doit en mettre un, il 
se doit d'être accessible.


J'ai cherché et j'ai fini par implémenter celui-ci 
http://www.anysurfer.be/fr/blog/detail/un-diaporama-sur-la-home-page-sil-le-faut-vraiment 
pour un projet mais il ne contient pas de balise aria-expanded 
etc, ... Le js n'est donc pas accessible ?


Merci pour vos réponses.

Ariane



___
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 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 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

Re: [Liste GTA] Accessibilité des plugins et modules

[Aurélien Levy]

, mais le coût de
développement et d'adaptation apres coup n'est pas négligeable.

Sommes nous tenus de mettre à jour ces extensions ? Souvent, au
chiffrage, nous n'avons pas encore sélectionné l'extension que
l'on utilisera, et donc les fonctionnalités accessibles qu'elle
propose.

Peut-on faire valoir le droit de l'extension externe pour
justifier le non  conformité d'une extension ? Souvent, ce sont
les formulaires de contact qui posent le plus de problème, avec
une accessibilité quasi nulle.

Comment faites vous de votre côté? Prévoyez vous une enveloppe
budget dans ce cas là ?

Merci de votre retour d'expérience,

Valérie


___
liste_gta mailing list
liste_gta@list.accessiweb.org mailto: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



--
Aurélien Levy

Temesis

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

Re: [Liste GTA] conformité OR AW HTML5 et RGAA

[Aurélien Levy]

A défaut de réponses sur ces points j'espère qu'on aura la réponse dans 
le RGAA V3 sans devoir faire appel à l'oracle


Aurélien

Bonjour,


le formulaire http://www.fiphfp.fr/Contact :
* ne propose pas d'étape de confirmation de saisie des données
personnelles, considérez vous cela comme non conforme ?

Il n'y à pas besoin d'avoir une étape de confirmation de saisie qui 
n'est utilisé que si des informations ne sont plus modifiables avant 
l'envoi du formulaire.
ok mais tu considèrerai donc comme également conforme un formulaire 
multi étape sans écran récapitulatif mais qui permettrait de revenir 
en arrière ?


 ne présente aucun changement dans le title de la page quand il y a des
erreurs de saisies (peut être est ce lié à un cas particulier non
documenté quand les types de formulaire html5 sont utilisés ?)

Le message d'erreur dans la page est liée au rechargement de la page, 
ici il n'y à pas rechargement de page.
ok, il serait peut être bien d'avoir dans la note du glossaire quelque 
chose d'un peu plus précis genre :
lorsqu'une page se recharge dans sa totalité (ou partiellement pour 
couvrir le cas ajax ?) et qu'elle affiche des erreurs de saisie, le 
titre de la page doit comporter la mention erreur de saisie


 les messages d'erreur restitué automatiquement par les types html5 ne
proposent pas d'exemple de saisie (la note technique du glossaire n'est
pas très claire sur le fait qu'il est nécessaire de les personnaliser ou
pas)

Ces messages sont personnalisables via constraint validation qui 
n'est pas encore universellement supporté, d'où la tolérance.

même question que Romain


 plusieurs pages de l'échantillon affichent des liens mailto type
x...@xxx.com. mailto:x...@xxx.com. Il me semblait que ce type de 
lien était considérer comme

non explicite par AW et qu'il fallait donc le rendre explicite par le
biais du contexte pour être conforme niveau Argent (ce qui est le cas
ici) ou directement par l'intitulé au niveau OR (ce qui n'est pas le cas
ici)

Ce point n'a jamais été formalisé, c'est une vieillerie d'usage AW 
1.1 (comme les url)
Au niveau OR / AAA on considère donc que l'intitulé x...@xxx.com est 
suffisant pour que l'utilisateur comprenne le changement de contexte 
si il s'agit d'un mailto ? idem si c'est un lien type envoyer un mail 
à xxx ?
Dans ce cas pourquoi le signalement d'ouverture dans une nouvelle 
fenêtre est requis et pas le signalement du changement d'agent 
utilisateur ?
___
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org

[Liste GTA] conformité OR AW HTML5 et RGAA

[Aurélien Levy]

Bonjour,

le nouveau site du FIPHFP a été labellisé niveau OR accessiweb selon le 
référentiel HTML5 
http://www.accessiweb.org/index.php/rapport_de_labellisation/items/fiphfp_2014.html 
et se dit également conforme avec le RGAA (cf pied de page du site).


Le site est effectivement particulièrement bien fait mais je me pose 
quelques questions sur certains détails, je suis donc preneur de votre 
avis / retour d'expérience sur le sujet :


- le formulaire http://www.fiphfp.fr/Contact :
* ne propose pas d'étape de confirmation de saisie des données 
personnelles, considérez vous cela comme non conforme ?
* ne présente aucun changement dans le title de la page quand il y a des 
erreurs de saisies (peut être est ce lié à un cas particulier non 
documenté quand les types de formulaire html5 sont utilisés ?)
* les messages d'erreur restitué automatiquement par les types html5 ne 
proposent pas d'exemple de saisie (la note technique du glossaire n'est 
pas très claire sur le fait qu'il est nécessaire de les personnaliser ou 
pas)


- plusieurs pages de l'échantillon affichent des liens mailto type 
x...@xxx.com. Il me semblait que ce type de lien était considérer comme 
non explicite par AW et qu'il fallait donc le rendre explicite par le 
biais du contexte pour être conforme niveau Argent (ce qui est le cas 
ici) ou directement par l'intitulé au niveau OR (ce qui n'est pas le cas 
ici)


- il y a quelques pertes d'infos avec le texte agrandi à 200% (bas de la 
colonne de droite, texte dans le select du formulaire de contact), quel 
est donc votre niveau de tolérance sur ce genre de situation ?


En tout cas félicitations à Kaliop pour le beau travail réalisé sur ce site.

--
Aurélien Levy

Temesis


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

Re: [Liste GTA] conformité OR AW HTML5 et RGAA

[Aurélien Levy]

Merci Jean Pierre pour ces réponses, quelques questions complémentaires 
du coup.

Bonjour,


le formulaire http://www.fiphfp.fr/Contact :
* ne propose pas d'étape de confirmation de saisie des données
personnelles, considérez vous cela comme non conforme ?

Il n'y à pas besoin d'avoir une étape de confirmation de saisie qui 
n'est utilisé que si des informations ne sont plus modifiables avant 
l'envoi du formulaire.
ok mais tu considèrerai donc comme également conforme un formulaire 
multi étape sans écran récapitulatif mais qui permettrait de revenir en 
arrière ?


 ne présente aucun changement dans le title de la page quand il y a des
erreurs de saisies (peut être est ce lié à un cas particulier non
documenté quand les types de formulaire html5 sont utilisés ?)

Le message d'erreur dans la page est liée au rechargement de la page, 
ici il n'y à pas rechargement de page.
ok, il serait peut être bien d'avoir dans la note du glossaire quelque 
chose d'un peu plus précis genre :
lorsqu'une page se recharge dans sa totalité (ou partiellement pour 
couvrir le cas ajax ?) et qu'elle affiche des erreurs de saisie, le 
titre de la page doit comporter la mention erreur de saisie


 les messages d'erreur restitué automatiquement par les types html5 ne
proposent pas d'exemple de saisie (la note technique du glossaire n'est
pas très claire sur le fait qu'il est nécessaire de les personnaliser ou
pas)

Ces messages sont personnalisables via constraint validation qui n'est 
pas encore universellement supporté, d'où la tolérance.

même question que Romain


 plusieurs pages de l'échantillon affichent des liens mailto type
x...@xxx.com. mailto:x...@xxx.com. Il me semblait que ce type de lien 
était considérer comme

non explicite par AW et qu'il fallait donc le rendre explicite par le
biais du contexte pour être conforme niveau Argent (ce qui est le cas
ici) ou directement par l'intitulé au niveau OR (ce qui n'est pas le cas
ici)

Ce point n'a jamais été formalisé, c'est une vieillerie d'usage AW 1.1 
(comme les url)
Au niveau OR on considère donc que l'intitulé x...@xxx.com est suffisant 
pour que l'utilisateur comprenne le changement de contexte si il s'agit 
d'un mailto ? idem si c'est un lien type envoyer un mail à xxx ?
Dans ce cas pourquoi le signalement d'ouverture dans une nouvelle 
fenêtre est requis et pas le signalement du changement d'agent utilisateur ?


--
Aurélien Levy

Temesis

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

Re: [Liste GTA] question sur interaction clavier d'un système d'onglet respectueux du DP ARIA

[Aurélien Levy]

Le comportement que tu décrit est logique puisque l'utilisateur doit 
normalement utiliser :
- les flèches pour accéder aux autres onglets qd il a le focus sur un 
onglet
- controle page up/down pour accéder aux autres onglets quand le focus 
est dans un onglet (il me semble qu'AW ne demande pas de respecter ces 
raccourcis cela dit)


Pour ma part je t'inciterai à ne pas utiliser le design pattern car :
- il me semble que Jaws ne gère pas les roles correspondant à ce design 
pattern (en tout cas la dernière fois que j'ai testé mais cela a peut 
être changé depuis)
- comme il est dit dans le descriptif du DP les comportement ne sont 
clairement pas uniformes dans les différents systèmes d'exploitation
- la solution conforme mais incomplète risque effectivement plus de 
frustrer l'utilisateur qui connait le design pattern plus qu'autre chose



Aurélien


Bonjour à tous,

J'ai beau lire et relire le design pattern ARIA du système d'onglets 
(http://www.w3.org/TR/wai-aria-practices/#tabpanel), j'ai un doute sur 
le comportement attendu pour la touche Tab.
En effet il n'est rien précisé explicitement (ou je n'ai pas trouvé) 
sur le comportement attendu lorsqu'on dépasse le dernier item 
focusable du tabpanel courant.
Apparemment on laisse le focus sortir du système d'onglets, pour 
passer à la suite.
Ok mais à l'usage c'est un peu déroutant: je m'attends à passer à 
l'étiquette d'onglet suivante en continuant à tabuler. D'un autre 
coté, je n'ai pas forcément envie de repasser par les étiquettes 
d'onglets pour sortir du système.


En essayant sur des interfaces d'OS (ex: propriétés d'un fichier sous 
Windows) ou d'application (ex: Options de Thunderbird) je n'ai pas non 
plus une réponse claire, les comportements semblant légèrement 
variables. De plus je suis généralement dans une fenêtre modale qui ne 
réplique pas très bien une page pleine de contenus.


Vos avis?

Cordialement,
*Olivier Nourry*
Twitter: @OlivierNourry http://twitter.com/#%21/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

Re: [Liste GTA] Etiquette de champ de saisie de formulaire

[Aurélien Levy]

Bonjour Giuseppe,

c'est effectivement formellement possible, ça serait donc conforme (mais 
clairement pas la solution la plus accessible).


Il y a deux techniques wcag qui permettent de dire que les titles sont 
une solution utilisables. La technique h33 pour les liens et la 
technique h65 pour les formulaires 
http://www.w3.org/TR/WCAG20-TECHS/H65.html


Dans la technique h33 on peut notamment lire Because of the extensive 
user agent limitations in supporting access to the title attribute, 
authors should use caution in applying this technique
et une bonne partie des problèmes signalés dans notes agents utilisateur 
du h33 s'appliquent également 
http://www.w3.org/WAI/WCAG20/Techniques/ua-notes/html#H33 au cas du h65


Par ailleurs, la technique h65 dit bien to label form controls when the 
visual design cannot accommodate the label, il s'agit donc bien d'un 
choix à faire coté design rattrapable à coup de title niveau technique 
et non de la solution à privilégier.


Tout dépend donc de l'objectif (conformité / accessibilité) et de la 
phase à laquelle tu interviens (conception, création, intégration, 
recette, correction)


Si tu interviens en conception / création d'un nouveau service il faut 
demander à ton designer de justifier pourquoi il ne peut pas mettre un 
label (autrement que par c'est pas beau! ou c'est pas la mode si 
possible)


Aurélien

Bonjour à tous,

Dans l'administration nous avons énormément de formulaire. Je tente 
donc de pousser à l'adoption de bonnes pratiques notamment sur cette 
thématique.

Toutefois j'ai un soucis concernant :


  Critère 11.1 [A] Chaque champ de formulaire
  
http://accessiweb.org/index.php/glossaire-du-referentiel-accessiweb-html5aria.html#mChpSaisie
  a-t-il une étiquette
  
http://accessiweb.org/index.php/glossaire-du-referentiel-accessiweb-html5aria.html#mEtiquette
  ?

Test 11.1.1 : Chaque champ de formulaire 
http://accessiweb.org/index.php/glossaire-du-referentiel-accessiweb-html5aria.html#mChpSaisie 
vérifie-t-il une de ces conditions ?


  * Le champ de formulaire possède un attribut title


Si je m'appuie uniquement sur les critères, sans prendre en compte 
d'autres aspects (design, ergonomie...), il semble possible de 
réaliser un formulaire en ne mettant aucun label sur les champs de 
saisie mais uniquement des title explicite (test de pertinence 11.2.2 
respecté) ?


...
input  id=madame name=genre type=radio title=Madame /input  
id=mademoiselle name=genre type=radio title=Mademoiselle 
/input id=monsieur name=genre type=radio title=Monsieur/br /

input id=nom type=texte title=Saisir le Nom value=/inputbr /
input id=prenom type=texte title=Saisir le Prénom 
value=/inputbr /


...
Si c'est le cas, j'ai des difficulté à comprendre comment des 
utilisateurs exclusifs du clavier (mais voyant) auront accès à 
l'information (si des éléments de type placeholder ou autres ne sont 
pas utilisés).


Dans l'exemple, j'ai poussé un peu loin, notamment avec les boutons 
radio et sans placeholder, mais en fait il s'agit d'une question 
réelle où il s'agissait de remplacer l'ensemble des /label /par des 
/placeholder /et en ajoutant des /title /sur les champs de type /text/.


Merci pour vos lumières.

--

Cordialement,

DGFiP   Giuseppe ROSA
Inspecteur Analyste
Atelier SODA - bureau SI-1A
Site SODA : http://si1a.intranet.dgfip/soda tel : 01.573.36.997
pièce : 2388



*Adoptez l'éco-attitude.*
N'imprimez ce mail que si c'est vraiment nécessaire



___
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

Re: [Liste GTA] [URGENT] J-1 avant fermeture de la consultation RGAA phase 2 !

[Aurélien Levy]

Bonjour,

je relance de 1 pour vous inviter à participer et à prendre le temps de 
lire les discussions qui bien que longues pour certaines vous 
permettrons d'avoir connaissance des différents avis et alimenterons 
peut être vos réflexions.


Bonne journée

Aurélien

Bonjour à toutes et tous,

Il ne vous reste que jusqu'à demain midi pour exprimer votre avis sur 
les sujets ouverts à discussion sur le forum du RGAA 3.


Je rappelle l'adresse : 
http://accessibilite-numerique-forum.smile-hosting.fr/


Si vous n'avez pas le temps de laisser un commentaire, vous pouvez au 
moins donner votre sentiment via un vote.


En tant que professionnels formés, votre avis est important pour 
savoir ce qui vous semble la meilleure option. Je sais que certains 
sujets semblent pointus et qu'il peut vous paraître difficile de faire 
un choix, mais essayez quand même s'il vous plaît.


Plusieurs avis contradictoires sont exprimés, ce qui vous permet 
d'avoir une idée des échanges et des différents arguments en présence.


Pour mémoire, il y a 11 questions offrant un vote :

 1. Faut-il prendre en compte HTML5 ?
 2. Validez-vous la notion de base de référence ?
 3. Validez-vous la base de référence proposée ?
 4. Faut-il intégrer les nouveaux éléments de structure HTML5 ?
 5. Le mécanisme proposé pour prendre en charge les DTD antérieures à
HTML5 vous convient-il ?
 6. Faut-il supprimer l'exigence d'une alternative à JavaScript ?
 7. Faut-il maintenir l'interdiction du pixel comme unité de police ?
 8. Faut-il imposer, si possible, le respect des motifs de conception
(design pattern) WAI-ARIA ?
 9. Faut-il monter le niveau du double A vers triple A du critère
imposant d'informer de l'ouverture de nouvelles fenêtres (13.2) ?
10. Faut-il autoriser la technique du texte caché en alternative aux
images de fond et donc supprimer le test images désactivées avec
CSS activées ?
11. Faut-il définir des profils par critère ?

Voter ne devrait pas vous prendre plus de 15 minutes. Ne laissez pas 
passer cette opportunité de donner votre avis, demain midi il sera 
trop tard.


Il vous restera la possibilité de vous exprimer lors de la 
consultation publique qui suivra, mais le contexte de consultation 
étant plus large, vous n'aurez pas le même type d'échange.


Bonne journée et à bientôt,

Armony
--

Armony ALTINIER
Directrice ACS Horizons
Consultante et formatrice en accessibilité numérique

  * Pro : acs-horizons.fr http://acs-horizons.fr
  * Twitter : @armonyaltinier https://twitter.com/armonyaltinier
  * Livre : accessibiliteweb-lelivre.com
http://accessibiliteweb-lelivre.com



___
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

Re: [Liste GTA] Type d'action permettant de valider le critère 10.13

[Aurélien Levy]

oui.
En fait il n'est même pas nécessaire qu'ils deviennent visibles au 
focus pour valider le test. Mais ce serait alors d'un intérêt limité 
puisque les principaux bénéficiaires de ce dispositif sont les 
utilisateurs voyants au clavier, et non les utilisateurs de lecteur 
d'écran comme on le pense généralement; ces derniers disposant 
d'autres moyens pour naviguer rapidement dans la page.


Cordialement,
*Olivier Nourry*
Twitter: @OlivierNourry http://twitter.com/#%21/OlivierNourry

Bonjour Olivier,

A ce propos, j'ai récemment échangé avec Steve Faulkner sur ce sujet et 
il m'a indiqué que pour lui avoir des éléments atteignables au clavier 
mais non visible à l'écran est une violation directe du critère de 
succès 2.4.7 même si il n'y a pas de failure. 
http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html 



En effet, il est clairement dit :

The purpose of this success criterion is to help a person know which 
element has the keyboard focus.


ce qui est impossible si l'on ne voit as l'élément qui a le focus (il me 
semble d'ailleurs c'est également le position des notices accede-web sur 
le sujet).


Le RGAA3 serait peut être l'occasion de rediscuter de ce genre de chose ;)

Aurélien


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

Re: [Liste GTA] Différences entre WCAG et AW HTML5-ARIA

[Aurélien Levy]

Re bonjour,


Ce qui sera soumis à discussion, ce seront certains points techniques 
liés aux nouveautés de la version HTML5-ARIA, des définitions de 
glossaire, ainsi que la notion de base de référence, essentielle pour 
comprendre ce que fait le référentiel AccessiWeb : en un mot, il trie 
dans WCAG et dans la spécification HTML 5 elle-même les différentes 
techniques pour ne retenir que ce qui fonctionne réellement pour les 
utilisateurs. Bref, ce qui est « compatible avec l'accessibilité » 
(notion WCAG) dans la base de référence retenue.
concernant cette remarque, je vous invite pour ma part à lire ce billet 
qui j'ai écrit hier soir :

http://blog.temesis.com/post/2014/06/30/Le-RGAA-v3-ma-lettre-aux-concepteurs

Il me semble en effet que ce RGAA V3 se doit d'être l'occasion d'aller 
plus loin qu'une simple mise à jour d'une annexe technique dont la 
nécessité ne fait aucun doute.


--
Aurélien Levy

Temesis


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

Re: [Liste GTA] Sensibiliser au RGAA en 2014 ?

[Aurélien Levy]

Bonjour,

je pense également que cela dépend du public de la formation et de 
l'organisation de la structure voir des outils et process de production 
utilisé.
Si cela s'adresse à un public généraliste Il s'agit avant tout de 
sensibiliser à l'accessibilité et d'évoquer le contexte mouvant actuelle 
autour de la référence technique permettant officiellement de vérifier 
la conformité à WCAG.
Si il s'agit de former des développeurs ou des graphiste travailler 
directement avec WCAG / accede-web / HTML5 me parait un meilleur 
matériel pédagogique. Il n'y a par exemple que peu d'intérêt à connaitre 
les critères RGAA / Accessiweb correspondant pour savoir pourquoi et 
quand mesurer un contraste avec les outils existant quand le processus 
de production intègre une phase de recette par une équipe tiers.
Si il s'agit par contre de former ces gens charger de contrôler le 
travail des graphistes / dev effectivement partir sur AW/HTML5 semble 
une sage décision en espérant que nous aurons une changelist entre la 
version existante actuelle et le RGAA3.


Aurélien

Bonjour,

quelle réalité des sites d'aujourd'hui ?
Chaque projet, agence, prestataire, site web, responsable a ses 
particularités : site de contenu ou applicatif, HTML5 IE10+ ou XHTML 
1.0 avec JS en amélioration progressive IE8+. Client ne 
voulant/pouvant pas se permettre de tout changer tant qu'HTML5 n'est 
pas finalisé ou pris en compte par ses propres fournisseurs ou au 
contraire se jetant sur les dernières technos.
Pour un début (présenté à des intégrateurs/développeurs intervenants 
sur des sites publics) et par manque de temps, je ne présente 
qu'AccessiWeb 2.2 et RGAA 2.2 mais en évoquant HTML5/ARIA et en 
expliquant qu'on est en pleine période de transition. Bien cadrer les 
bases pour qu'elles soient respectées. Mettre en place HTML5 au-delà 
du changement de doctype nécessite plus une formation à HTML5 (et sans 
rapport direct mais ça arrive en même temps dans les projets : au 
responsive) qu'à l'accessibilité pour ces équipes à mon avis.

Avec un autre public, j'aurais probablement une autre approche.

Si le RGAA 2.2 est largement obsolète, il en est de même 
d'AccessiWeb 2.2, non ?
Pour des sites de contenu dont l'exigence fonctionnelle n'a pas changé 
en 2014 par rapport à 2009 (mis à part : que ce soit 
responsive/adaptatif et qu'il n'y ait pas de Flash), ça me convient 
très bien mais je peux comprendre les manques pour d'autres types de 
sites.



Ph. Vayssière
PS : merci à Aurélien de nous tenir au courant. C'est utile (et 
évitera les bruits de couloir :) )
PPS : merci à Patrice Bourlon pour avoir produit le seul format 
réellement utilisable du RGAA avec http://rgaa.net (on peut toujours 
lire sur le site de la DGME, Une version en ligne des critères de 
succès et tests de conformité est en cours de réalisation et sera 
prochainement mise à disposition sur le site.. Depuis 2009, /humour/)


Le 24/06/2014 09:00, CONVERT Yves a écrit :


Bonjour,


Comme vous tous, je suis les évolutions du RGAA avec attention.

J'ai découvert l'article d'Aurélien sur le blog de Temesis sur 
l'évolution majeure du RGAA à venir 
(http://blog.temesis.com/post/2014/06/20/Evolution-majeure-du-RGAA).



Étant amené à sensibiliser des équipes aux profils divers 
(fonctionnel, chef de projet, développeur) au RGAA, la première 
question que je me suis posé est : Avec qu'elle version d'AccessiWeb 
vais-je pouvoir faire l'équivalence ?.


Etant donné que le RGAA dans sa version actuelle est largement 
obsolète, un choix aurait pu être le référentiel Accessiweb 2.2 ? 
(Bien que pas totalement en phase avec la version des WCAG).


En tout cas pas la version HTML5/ARIA, bien trop actuelle...


Et c'est là qu'un doute s'est installé.

Compte tenu des travaux à venir sur le RGAA, et de la réalité des 
sites d'aujourd'hui, je me demande s'il ne serait pas opportun 
d'adresser, par anticipation, le référentiel Accessiweb HTML5/ARIA ?



Sachant que mon travail de sensibilisation/formation ne peut attendre 
la sortie officielle du futur RGAA, comment géreriez-vous la transition ?



Yves Convert

Micropole






___
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



--
Aurélien Levy

Temesis

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

Re: [Liste GTA] cas d'autocomplétion

[Aurélien Levy]

Bonjour Tanguy

j'avoue avoir un peu de mal à comprendre le besoin. La liste est 
présente dans la page en permanence ? si oui c'est une fonction de 
filtre de la liste en ajax qui réduit le nombre de résultats ? Ce que tu 
cherche à éviter c'est que si l'utilisateur qui fait une faute dans sa 
saisie par exemple voitures au pluriel alors que dans la liste il y a 
voiture au singulier puisse tout de même savoir qu'il y a voiture au 
singulier dans la liste ?


Su oui, le mieux serait sans doute d'avoir une zone de texte masquée 
avec un aria-live polite ou assertive qui annonce le nombre d'élément en 
surbrillance et les listes. Exemple quand tu tapes les lettres v,o,i il 
t'annonce 2 résultats : voiture, voisin. Si tu tape alors les lettres 
v,o,i,t il t'annonce 1 résultat : voiture. Tu peux alors descendre 
dans la liste et choisir cet élément.


Aurélien


Bonjour,

Je travaille depuis quelques temps en admin SharePoint 2010. Je rédige 
un doc relevant des points d'inaccessibilité des écrans 
d'administration et proposant des solutions ou au moins des pistes.


A ce titre, j'ai un cas de zones d'édition avec autocomplétion pour 
lequel je présume que l'utilisation d'ARIA serait le plus approprié. 
Mais j'aimerais pouvoir orienter plus précisément les développeur sur 
le design pattern et surtout les états et propriétés à adopter.


Si vous pouviez m'aider, je vous en serai reconnaissant.

Voici la situation :

Ce sont des zones d'éditions dans lesquelles on peut écrire les 
premières lettres, mais pour lesquelles l'élément alors en 
surbrillance n'est pas annoncé par le lecteur d'écran. La liste des 
éléments proposés est heureusement détectée par le lecteur d'écran 
sans même entrer dans la zone d'édition. La difficulté réside dans le 
fait de savoir quel élément est en surbrillance à mesure que l'on 
tape. L'utilisateur doit donc préalablement


1.parcourir la liste des items

2.Mémoriser à quel rang se trouve celui qu'il recherche

3.Se positionner dans la zone d'édition

4.Taper les premières lettres correspondant à l'item souhaité

5.Si plusieurs items commencent par les mêmes caractères, descendre 
jusqu'au rang précédemment noté


6.Ressortir de la zone d'édition

7.Aller jusqu'à l'item présumé en surbrillance

8.Vérifier la couleur de texte et de fond en interrogeant le lecteur 
d'écran


9.Si l'item souhaité n'est pas en surbrillance, réitérer le tout 
depuis l'étape 5.


La solution consiste à permettre au lecteur d'écran d'annoncer 
l'élément en surbrillance sans avoir à accomplir toutes ces étapes.


Par avance, merci pour vos réponses.

Tanguy



___
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

Re: [Liste GTA] Technique WCAG H2 sur les liens composites non implémentée dans AccessiWeb

[Aurélien Levy]

Bonjour,

c'est effectivement une bonne pratique c'est pour cela que H2 est une 
technique suffisante et non une erreur.
Une technique suffisante est un des moyens possibles de se conformer à 
un critère de succès mais n'est pas le seul et unique moyen. En soit, 
cela ne peut donc pas constituer une erreur RGAA ou Accessiweb, par 
contre à titre d'experte tu peux effectivement fortement le recommander.


Aurélien

Bonjour à tous,

J'ai fait un audit récemment où tous les liens étaient 
systématiquement doublés : un lien image suivi d'un lien texte identique.


Or, il tombe sous le sens qu'il faut dans ce genre de cas faire un 
lien composite pour éviter les redites et tabulations inutiles, avec 
un seul lien englobant image et texte (lien composite)  et un alt vide 
sur l'image.


Or, rien ne permet d'invalider cette très mauvaise pratique dans le 
référentiel AccessiWeb. Rien non plus dans le RGAA.


Pourtant, la technique H2 de WCAG 
http://www.w3.org/TR/WCAG20-TECHS/H2 est très claire à ce sujet, 
documentant la présence de 2 liens identiques qui se suivent (un lien 
image + un lien texte) comme une erreur (failure).


*Serait-il possible d'implémenter cette technique ?*

Par ailleurs, si le référentiel utilisait un système de gestion de 
version comme Git et était mis à disposition sur un dépôt de code 
comme Github, cela permettrait de remonter ce genre de bug, de 
versionner plus facilement et encouragerait la contribution...


Mes deux centimes comme on dit,
Armony

--

*Armony ALTINIER ???*
Directrice d'ACS Horizons
Consultante, formatrice et développeuse web
Accessibilité du Web et logiciels libres

*Découvrez le livre, /Accessibilité web/ aux éditions Eyrolles !
accessibiliteweb-lelivre.com http://accessibiliteweb-lelivre.com*

*Bureau :* +33 (0) 178 178 855
*Mobile :* +33 (0) 668 897 751
*Fax :* +33 (0) 170 248 941



*Email :* arm...@acs-horizons.fr mailto:arm...@acs-horizons.fr

*Site pro. :* acs-horizons.fr http://www.acs-horizons.fr/
*Blog perso :* armonyaltinier.fr http://www.armonyaltinier.fr/
*Twitter perso : *@armonyaltinier https://twitter.com/armonyaltinier




*ACS Horizons* http://www.acs-horizons.fr/
BP 60015
95121 Ermont Cedex, France ? ?



___
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

Re: [Liste GTA] Technique WCAG H2 sur les liens composites non implémentée dans AccessiWeb

[Aurélien Levy]

RGAA n'interdit pas le title redondant ;)

Aurélien

Merci Aurélien de ta réponse.

Si je ne m'abuse, le critère AccessiWeb 6.2 /Critère 6.2 [Bronze] 
Pour chaque lien ayant un titre de lien, celui-ci est-il pertinent 
?/, qui correspond au test RGAA 6.13 /[Navigation] Possibilité 
d'identifier la destination ou l'action des liens et des boutons/ 
interdisent tous deux les attributs title redondants.


Or, ces deux critère/test se basent en l'espèce sur une technique 
suffisante, la H33. Il n'y a pas plus de failure que pour H2 et cela 
n'empêche pas d'invalider un title redondant. Notons que dans H2 il y 
a des exemples de failure à H2, qui n'existent pas pour H33.


Pourquoi en serait-il autrement avec un lien redondant, ce qui est 
encore pire qu'un title redondant ? (c'est une vraie question, hein, 
j'imagine qu'il y a une explication mais je n'arrive pas à voir 
laquelle... ^^)


Armony




Le 10 février 2014 17:52, Aurélien Levy aurelien.l...@temesis.com 
mailto:aurelien.l...@temesis.com a écrit :


Bonjour,

c'est effectivement une bonne pratique c'est pour cela que H2 est
une technique suffisante et non une erreur.
Une technique suffisante est un des moyens possibles de se
conformer à un critère de succès mais n'est pas le seul et unique
moyen. En soit, cela ne peut donc pas constituer une erreur RGAA
ou Accessiweb, par contre à titre d'experte tu peux effectivement
fortement le recommander.

Aurélien

Bonjour à tous,

J'ai fait un audit récemment où tous les liens étaient
systématiquement doublés : un lien image suivi d'un lien texte
identique.

Or, il tombe sous le sens qu'il faut dans ce genre de cas faire
un lien composite pour éviter les redites et tabulations
inutiles, avec un seul lien englobant image et texte (lien
composite)  et un alt vide sur l'image.

Or, rien ne permet d'invalider cette très mauvaise pratique dans
le référentiel AccessiWeb. Rien non plus dans le RGAA.

Pourtant, la technique H2 de WCAG
http://www.w3.org/TR/WCAG20-TECHS/H2 est très claire à ce
sujet, documentant la présence de 2 liens identiques qui se
suivent (un lien image + un lien texte) comme une erreur (failure).

*Serait-il possible d'implémenter cette technique ?*

Par ailleurs, si le référentiel utilisait un système de gestion
de version comme Git et était mis à disposition sur un dépôt de
code comme Github, cela permettrait de remonter ce genre de bug,
de versionner plus facilement et encouragerait la contribution...

Mes deux centimes comme on dit,
Armony

-- 


*Armony ALTINIER ???*
Directrice d'ACS Horizons
Consultante, formatrice et développeuse web
Accessibilité du Web et logiciels libres

*Découvrez le livre, /Accessibilité web/ aux éditions Eyrolles !
accessibiliteweb-lelivre.com http://accessibiliteweb-lelivre.com*

*Bureau :* +33 (0) 178 178 855
*Mobile :* +33 (0) 668 897 751
*Fax :* +33 (0) 170 248 941



*Email :* arm...@acs-horizons.fr mailto:arm...@acs-horizons.fr

*Site pro. :* acs-horizons.fr http://www.acs-horizons.fr/
*Blog perso :* armonyaltinier.fr http://www.armonyaltinier.fr/
*Twitter perso : *@armonyaltinier
https://twitter.com/armonyaltinier




*ACS Horizons* http://www.acs-horizons.fr/
BP 60015
95121 Ermont Cedex, France ? ?



___
liste_gta mailing list
liste_gta@list.accessiweb.org  mailto: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 mailto:liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org




--

*Armony ALTINIER ???*
Directrice d'ACS Horizons
Consultante, formatrice et développeuse web
Accessibilité du Web et logiciels libres

*Découvrez le livre, /Accessibilité web/ aux éditions Eyrolles !
accessibiliteweb-lelivre.com http://accessibiliteweb-lelivre.com*

*Bureau :* +33 (0) 178 178 855
*Mobile :* +33 (0) 668 897 751
*Fax :* +33 (0) 170 248 941



*Email :* arm...@acs-horizons.fr mailto:arm...@acs-horizons.fr

*Site pro. :* acs-horizons.fr http://www.acs-horizons.fr/
*Blog perso :* armonyaltinier.fr http://www.armonyaltinier.fr/
*Twitter perso : *@armonyaltinier https://twitter.com/armonyaltinier




*ACS Horizons* http://www.acs-horizons.fr/
BP 60015
95121 Ermont Cedex, France ??



___
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

Re: [Liste GTA] Observatoire de l’Accessibilité du Web – Appel aux experts volontaires

[Aurélien Levy]

Bonjour Sylvie,

serait-il possible d'avoir la liste exacte des 20 sites en question ?
Les responsables de ses différents sites seront-ils mis au courant au 
préalable ? Cela peut être utile ne serait ce que pour vérifier que le 
site ne va pas être remplacé par un nouveau entre la date de 
l'évaluation et le jour de la publication des résultats. Vu que Tanaguru 
va sans doute être utilisé je me doute qu'une copie de sites le jour de 
l'évaluation serait faite mais je trouve que ça perdrait quand même en 
impact en terme de communication. En fait tout cela dépend aussi 
grandement de l'objectif recherché par cet observatoire, point qui 
n'avait pas été tranché collectivement lors du séminaire il me semble.


Aurélien


Bonjour à toutes et tous,
Comme cela a été annoncé lors du séminaire GTA du 19 décembre 2013, 
BrailleNet lance un observatoire de l'accessibilité des sites Web en 
France, auquel seront associés des volontaires du GTA. L’objectif de 
ce projet est de communiquer sur l'évolution de l'accessibilité d’un 
échantillon de sites d'intérêt général.
Les premiers résultats de cet observatoire seront dévoilés lors du 8e 
forum de l'accessibilité numérique à la cité des sciences le 31 mars 
prochain sur un stand BrailleNet-GTA.


Nous avons sélectionné 20 sites dont nous proposons d'évaluer la page 
d'accueil et un scénario d’utilisation représentatif selon 90 critères 
AccessiWeb (bronze + critères MIPAW argent et or).


Nous faisons appel aux volontaires pour évaluer chacun un ou deux 
sites durant le mois de février. L’évaluation d’un site devrait 
représenter une demi-journée de travail environ. Chaque expert se 
verra assigner un ou deux sites selon sa disponibilité et recevra des 
instructions précises sur le travail à effectuer sur chacun de ces 
sites. Un outil pour la gestion d'audit et un wiki seront utilisés 
pour faciliter l'enregistrement et les échanges sur les résultats. En 
outre, une permanence téléphonique hebdomadaire sera mise en place 
pour répondre aux interrogations/demandes des experts volontaires.


Le rapport de cette première évaluation sera publié par BrailleNet et 
présenté lors du 8e forum de l'accessibilité numérique le 31 mars. Sur 
la base des résultats, il sera également proposé une suite au projet, 
afin de pérenniser cet observatoire et d’en faire un instrument 
opérationnel au service de l’accessibilité numérique, en phase avec 
les travaux méthodologiques menés par W3C/WAI.


Les experts volontaires et leurs organismes seront cités dans le 
rapport d’étude publié sur le site AccessiWeb et leur participation 
valorisée lors de la communication du 31 mars.


Si vous êtes volontaire, veuillez me répondre à 
sylvie.duchat...@snv.jussieu.fr d'ici au mercredi 5 février au soir. 
en m’indiquant le temps que vous pouvez consacrer au projet durant ce 
mois de février.


Je vous remercie pour vos réponses et reste à votre disposition pour 
tous commentaires et /ou questions.


Amicalement

Sylvie




--
Aurélien Levy

Temesis


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

Re: [Liste GTA] Titre de lien d'un document téléchargeable généré par SPIP

[Aurélien Levy]

Bonjour,

il y a quelques temps déjà j'avais proposé des jeux de modèles pour img 
et doc qui corrigeaient leur faille d'accessibilité notamment l'ajout 
des titre dans les title/alt ainsi que la possibilité de préciser la 
langue si nécessaire malheureusement cela n'a jamais été intégré au core.

http://contrib.spip.net/Accessibilite-pour-les-redacteurs
http://zone.spip.org/trac/spip-zone/browser/_plugins_/accessibilite

Aurélien


Bonjour à tous,

Je suis en train d'évaluer la prise en compte de l'accessibilité par 
le CMS SPIP.


Il est possible d'insérer des documents PDF via le back-office et de 
renseigner un titre pour ce document (« Titre de mon PDF » dans 
l'exemple suivant).


Que pensez-vous du code généré ?

dl class=spip_document_9 spip_documents

dta href=monpdf.pdf title=PDF - 505.6nbsp;ko 
type=application/pdfimg 
src=local/cache-vignettes/L52xH52/pdf-39070.png alt=PDF - 
505.6nbsp;ko height=52 width=52/a/dt


dt class=spip_doc_titre style=width:120px;strongTitre de mon 
PDF/strong/dt


/dl

Le titre du lien n'est clairement pas explicite. Il informe certes du 
format et du poids du document... mais pas de ce qu'est le document.


Cette information étant située juste après le lien, peut-on considérer 
cette implémentation par texte adjacent acceptable ? (je ne pense pas 
mais j'essaie de comprendre pourquoi cela a été fait comme ça) .


De plus, l'utilisation de balises dl/dt ne me semble pas 
sémantiquement adaptée.


Merci de votre aide.

FRÉDÉRIC BERNIER-MALCOIFFE



___
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] Nom et évolution du référentiel AccessiWeb

[Aurélien Levy]

Bonjour,


Le 20/01/2014 21:48, jean-pierre villain a écrit :

En revanche les cas d'utilisation d'éléments ou de dispositifs fondés 
sur ARIA ou les nouveaux éléments HTML5 existent bel et bien et 
provoquent, naturellement, des cas impossibles à respecter sur un 
contenu typé HTML4 comme l'utilisation des éléments header, nav, main 
ou footer pour structurer le document (critère 9.2) par exemple.
en soit rien ne t'empêche d'utiliser les nouveaux éléments html5 dans du 
html4 et c'est même déjà le cas bien souvent via des javascript qui 
inclus des éléments vidéo / canvas / svg ou de l'aria. Tu serais non 
conforme html mais les erreurs ne serait pas invalidante du point de vue 
accessibilité, idem et encore plus valable pour ARIA.


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

Re: [Liste GTA] Outil de sondage

[Aurélien Levy]

Mon dieu une solution qui n'est pas libre !

maintenant tu as deux solutions :
- soit tu utilises un logiciel libre qui n'est pas accessible et tu 
rejoint la communauté pour l'améliorer parce que sinon tu seras vraiment 
un rebut de la société capitaliste qui ne pense qu'à lui et ne fait rien 
d'utile
- soit tu utilises le logiciel propriétaire qui fonctionne dans ton 
coin, tout seul, loin de la grande et gentille famille libriste qui va 
changer le monde


Aurélien

PS: toute ressemblance avec un des précédents mail publiés sur cette 
liste est bien évidemment humoristique et sarcastique

Bonjour Armony, Tanguy et tous,
J'ai changé volontairement l'objet juste pour répondre à la première 
question, l'accessibilité du sondage.

J'ai moi aussi constaté ces problèmes d'accessibilité.
Quand je fais un sondage, j'utilise doodle qui s'est bien amélioré au 
fil des ans : chaque réponse est une image commentée, on peut afficher 
le sondage sous forme de tableau ou sous forme accessible. Il est 
multilingue et la version française parle bien français.

Adresse :
www.doodle.com
Je ne sais pas s'il est libre ou pas mais il fonctionne bien.
Bonne journée
Sylvie 



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

Re: [Liste GTA] Nom et évolution du référentiel AccessiWeb

[Aurélien Levy]

 la 
seule façon d'aider les développeurs à s'y retrouver. Car leur 
demander, comme fait WCAG, de vérifier si c'est compatible avec les 
technos d'assistance, c'est l'impasse assurée. Ni AccessiWeb 
jusqu'ici, ni RGAA ne font ça. Sinon, autant utiliser WCAG directement.


Si l'idée est de maintenir la différence de traitement entre les 
versions 4 et 5 de HTML, il va bien falloir conserver deux versions, 
non ? Comment pourrions-nous concilier deux approches aussi 
différentes entre d'un côté version HTML 4 où on exige une alternative 
accessible sans JS pour tous les scripts (compatibilité RGAA) ; et 
côté HTML5 pas d'alternative exigée si script accessible, et un 
certain nombre de tests à effectuer sur une base de référence ?


Bref, une version renommée version 3, pourquoi pas. Qu'elle serve de 
base aux formations, à vous de voir. Mais certainement pas un seul 
référentiel mélangeant les paradigmes HTML4 et 5. Une version unique a 
l'air plus simple sur papier, mais je pense que c'est une erreur. On 
est dans une période de transition, il est important de garder à 
l'esprit que lorsqu'on rend un site ou une application accessible, il 
faut réfléchir aux conséquences de ses choix techniques. Et HTML5 
n'est pas toujours possible/recommandé.


Par ailleurs, tant que RGAA n'a pas évolué, il faut bien conservé une 
version compatible. Donc la branche 2 reste cohérente.


Mon avis est donc *défavorable*. Je ne le mets pas en majuscules et en 
rouge pour ne pas paraître agressive ou grossière, mais le coeur y est 
[clin d'oeil]


Une contre-proposition : faire une page d'accueil commune aux deux 
référentiels AccessiWeb avec un message d'avertissement disant :


Si votre site est en HTML 5, utilisez la version 3 [lien]. Mais
attention : elle n'est pas compatible RGAA et ne peut fonctionner
avec de vieux navigateurs. Voir la base de référence pour pouvoir
utiliser HTML 5 de façon accessible [lien]
Si votre site n'est pas en HTML 5, utilisez la version 2.2,
compatible RGAA [lien]


Et vous, qu'en pensez-vous ?

Armony


--

*Armony ALTINIER ???*
Directrice d'ACS Horizons
Consultante, formatrice et développeuse web
Accessibilité du Web et logiciels libres

*Découvrez le livre, /Accessibilité web/ aux éditions Eyrolles !
accessibiliteweb-lelivre.com http://accessibiliteweb-lelivre.com*

*Bureau :* +33 (0) 178 178 855
*Mobile :* +33 (0) 668 897 751
*Fax :* +33 (0) 170 248 941



*Email :* arm...@acs-horizons.fr mailto:arm...@acs-horizons.fr

*Site pro. :* acs-horizons.fr http://www.acs-horizons.fr/
*Blog perso :* armonyaltinier.fr http://www.armonyaltinier.fr/
*Twitter perso : *@armonyaltinier https://twitter.com/armonyaltinier




*ACS Horizons* http://www.acs-horizons.fr/
BP 60015
95121 Ermont Cedex, France ??



___
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

Re: [Liste GTA] Nom et évolution du référentiel AccessiWeb

[Aurélien Levy]

Rebonjour,


*1. Cadre légal et compatibilité du RGAA avec HTML 5*
Le cadre légal est clair : l'article 47 impose le respect des WCAG 
(comme le dit Olivier). Mais il impose également, via décret et 
arrêté, de vérifier cette conformité WCAG via le RGAA, même s'il est 
possible de le faire avec tout référentiel.

En réalité il y a 2 obligations:
- d'un coté la mise en conformité ou la conformité dès le départ à WCAG 
A+AA puisque le RGAA en soit n'est que la traduction des WCAG
- la publication d'une attestation de conformité résultant des tests 
ayant été effectué pour vérifier la conformité au RGAA/WCAG la liste des 
tests étant regroupés dans l'annexe 2 du RGAA.


Ni l'article de loi, ni le décret, ni l'arrêté, ni le document 
d'accompagnement n'indique clairement si l'annexe des tests est le seul 
moyen de vérifier la conformité. Si Accessiweb a bien effectivement 
effectué un travail de tableau de correspondance, ce tableau n'a 
aucunement été validé officiellement.
En l'absence de jugements, d'évolutions législatives ou documentaires 
sur ces points il n'y a pour l'instant que la conviction de chacun qui 
prime.


Le cadre légal fixe précisément trois cas d'exception de conformité. 
Je me souviens d'un avis transmis par Magali Oualid lorsqu'elle était 
au ministère de l'Éducation et qu'elle avait fait faire par le service 
juridique du ministère. Il me semble me souvenir que l'avis des 
juristes n'autorisait pas de dérogation en dehors de ceux décrits dans 
le guide d'accompagnement du RGAA (p.26), à savoir :


 1. volume important (valable seulement jusqu'en 2012)
 2. contenus obsolètes
 3. contenus tierce partie.

Maintenant, Aurélien étant l'un des principaux rédacteurs du RGAA, son 
avis est important. Et je sais que la conformité RGAA selon toi 
Aurélien est facilement gérée via des dérogations pouvant aller 
au-delà de ce cadre.


Personnellement, je reste persuadée qu'un juge ne serait pas de cet 
avis et se baserait uniquement sur les écrits officiels. Peut-être 
serons-nous fixé un jour, libre à chacun d'en faire son interprétation 
entre temps.




Tout comme le tien, mon avis ne vaut pas plus que celui des autres 
puisque je n'ai aucunement plus le droit qu'un autre de me substituer à 
la loi ;). Par ailleurs pour être précis je n'ai pris part qu'à la 
rédaction des différentes annexes et non à son contexte législatif ou au 
document d'accompagnement.
Je note tout de même que le document d'accompagnement dit bien Les 
*principales* raisons pouvant conduire à déroger et non pas les seules 
et uniques raisons. Mais encore une fois en l'absence de jugement ou 
d'éclaircissement chacun est libre de se faire sa propre opinion.



*2. C'est trop compliqué, les gens n'ont pas à connaître la technique 
pour faire de l'accessibilité*


Est-ce compliqué ? Oui.

Est-ce que ça mérite de faire des efforts de pédagogie ? Certainement.

Cela doit-il exonérer les chefs de projets de se poser des questions 
techniques quand ils cherchent à faire accessible ? Non, bien sur que 
non. Un client veut faire accessible sans connaître la technique ? Je 
ne connais que deux possibilités pour le faire sérieusement (même hors 
du cadre HTML5) : se former ou se faire accompagner. Et c'est d'autant 
plus vrai à mesure que le Web lui-même se complexifie.


Même quand je fais de la formation contributeur (très peu technique, 
donc sans parler de HTML), je leur explique que ce qu'ils écrivent 
produit du code qui interagit sur les technologies d'assistance. Et 
que donc la façon de contribuer a un impact. Il est de la 
responsabilité de chacun de prendre en compte l'accessibilité à son 
niveau. Et il n'est pas concevable au niveau chef de projets de ne pas 
se poser ces questions techniques (quand on est sérieux s'entend). 
Donc si quelqu'un décide d'utiliser le référentiel AccessiWeb, il sera 
en mesure de comprendre car il se sera formé ou se sera fait 
accompagné. Il suffit de faire une page pédagogique expliquant dans 
quel cadre utiliser l'un ou l'autre référentiel.
Oui oui bien sûr dans le pays des bisounours tous les chefs de projets 
se forme à l'accessibilité et tous les projets sont accessibles.
Soyons réaliste, l'immense majorité fait un copié collé du cahier des 
charges d'à coté, ne se forme pas à l'accessibilité et ne vérifie pas 
une virgule de ce que lui vend son agence coté accessibilité. Attention 
je ne suis pas entrain de dire qu'il faut considérer cela comme un état 
de fait et ne rien faire pour le faire changer bien au contraire. 
Néanmoins, rajouter une couche de complexité qui va ralentir le 
processus d'appropriation de ceux qui voudrait s'y mettre ne me semble 
pas aller dans le bon sens. On a déjà suffisamment à faire avec WCAG, 
RGAA, Accessiweb, A, AA, AAA, Bronze, Argent, Or qui occasionne 
régulièrement des demandes types : Notre application cartographique en 
Flash devra être conforme RGAA Argent AAA Wcag


Aurélien
___
liste_gta mailing list

Re: [Liste GTA] Nom et évolution du référentiel AccessiWeb

[Aurélien Levy]

Je fais de même

Je réponds directement dans le mail d'Aurélien.


 JPV


Réponse de JPV :

Techniquement tu à raison donc :

1. On versionne AW 2.2 en AW 2.3
2. Dans AW 2.3 on redresse les alternatives à Javascript
3. Dans AW 2.3 on implémente ARIA (ce qui oblige à l'utilisation des 
Designs Pattern et des tests de restitution)

4. Dans AW 2.3 on implémente les nouveaux éléments

Et on dit : voilà la nouvelle version d'AccessiWeb.

Résultat : tous les sites qui sont en cours d'implémentation de 
l'accessibilité à l'ancienne se retrouvent ipso facto 
systématiquement non-conformes par rapport à la dernière version 
d'AccessiWeb à moins de tout refaire.
Et tout les sites dont la refonte n'est pas prévue avant un certain 
temps n'ont plus de référentiel de référence.
Je ne vois pas pourquoi les sites qui en cours d'implémentation à 
l'ancienne deviendraient non conforme à ce que je sache la nouvelle 
version ne va pas interdire de faire des alternatives à js et n'oblige 
pas à utiliser aria (ou alors j'ai raté un bout, ce qui est possible)


Sur le fond ce qui me gène n'est pas d'avoir 2 référentiels ce qui me 
gène c'est de lier le cas alternative à js et le cas aria à Html5 au 
niveau du nommage du référentiel et de ne dire que l'un ou l'autre 
s'applique uniquement en fonction du choix de la version d'html ce que 
laisserait à penser un nommage accessiweb x.x HTML5


L'association BrailleNet est naturellement libre de faire ce qu'elle 
veut, je rappelle néanmoins que ces décisions (deux référentiels, 
changement de nomenclature des niveaux, nouveau nom) ont été proposées 
préalablement à BrailleNet qui à accepté de s'en remettre à l'avis du 
groupe d'experts référents en 2011/2012 lors des travaux 
préliminaires. Ce qui correspond au cadre du processus de pilotage du 
référentiel mis en place en 2010.
Cette initiative de consultation est la bienvenue : elle semble 
démontrer une très forte adéquation entre ce qui est proposé et ce qui 
est attendu par les professionnels.
Cela montre également une bonne maitrise technique du référentiel et 
une bonne compréhension des enjeux opérationnels d'un outil comme 
AccessiWeb.
Pour moi c'est le signe d'une grande maturité du GTA, il serait 
vraiment dommage de ne pas en profiter.


sur cela nous sommes d'accord ma précision n'avait pas pour but de 
minimiser l'intérêt de ce sondage mais simplement de rappeler une 
réalité pouvant parfois expliquer certaines décisions.


--
Aurélien Levy

Temesis

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

Re: [Liste GTA] Exemple de site réel avec descriptions longues d'images

[Aurélien Levy]

Voilà :
http://www.dondorganes.fr/016-les-chiffres-cles


bonjour à toutes et tous,
J'aurais besoin pour une démo d'un exemple de site qui a des images 
complexes et propose des longues descriptions de ces images.
J'en avais référencé un sur kb-access mais le problème est que les 
fichiers de longue description ont un souci d'encodage ce qui entraîne 
un mauvais affichage des accents, donc inaudible avec une synthèse 
vocale.

Merci pour vos suggestions et bon week-end!
Amicalement
Sylvie

___
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

Re: [Liste GTA] Erreur AccessiWeb sur critère 8.5 ?

[Aurélien Levy]

Salut,

à priori si tu met un title en dehors du head cela sera non conforme 
html et donc tu peux invalider le critère correspondant à la bonne 
arborescence du DOM. Je ne vois donc pas trop l'utilité de la précision 
sur le 8.5


Aurélien

Salut,

On vient de tomber sur un os à rogner. Il semble y avoir une erreur 
sur le critère AW 8.5 
http://www.accessiweb.org/index.php/accessiweb_2.2_liste_deployee.html#crit-8-5.


AccessiWeb demande de tester la balise title, sans plus de précision. 
Or WCAG, avec la technique H25 
http://www.w3.org/TR/WCAG-TECHS/H25.html (section procedure) 
demande de tester la balise title /qui se trouve dans la balise 
//head/ (check that a non-empty |title| element appears in the |head| 
section).


Cas problématique: si j'ai un title hors du head, comme c'est le cas 
sur http://accor.com/fr.html que faire ?


Au passage, les navigateurs (du moins Firefox, Opera, Chromium) 
récupèrent bien le title.


Vu tout le travail qui a été fait pour rendre AccessiWeb conforme à 
WCAG, il me semble dommage de laisser passer ça.


Vous en pensez quoi ? (cc @dbo75 @villainjp)

Matthieu

PS: Je me permets d'ajouter quelques sous-titres: la réponse à cette 
question n'est pas anodine, elle fera foi dans l'implémentation 
Tanaguru, donc sur plusieurs millions pages testées.





--
Phone: +33 9 72 11 26 06
Mobile: +33 6 73 96 79 59
Twitter: @mfaure http://twitter.com/mfaure

Tanaguru free-libre software for accessibility assessment 
http://www.Tanaguru.org/
KBAccess collaborative database of good and bad examples of Web 
Accessibility http://www.kbaccess.org/




___
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] Erreur AccessiWeb sur critère 8.5 ?

[Aurélien Levy]

Oui et donc title présent dans le head ou ailleurs - 8.5 conforme
pas de title dans le head ou ailleurs - 8.5 non conforme
sinon tu invalides 2 fois pour les mêmes raisons (title pas à la bonne 
place)


Aurélien

Salut,

OK pour éventuellement invalider le 8.2. Mais les critères sont 
indépendants. Il faut quand même statuer sur le 8.5.


Matthieu

Le 29/10/2013 18:36, Aurélien Levy a écrit :

Salut,

à priori si tu met un title en dehors du head cela sera non conforme 
html et donc tu peux invalider le critère correspondant à la bonne 
arborescence du DOM. Je ne vois donc pas trop l'utilité de la 
précision sur le 8.5


Aurélien

Salut,

On vient de tomber sur un os à rogner. Il semble y avoir une erreur 
sur le critère AW 8.5 
http://www.accessiweb.org/index.php/accessiweb_2.2_liste_deployee.html#crit-8-5.


AccessiWeb demande de tester la balise title, sans plus de 
précision. Or WCAG, avec la technique H25 
http://www.w3.org/TR/WCAG-TECHS/H25.html (section procedure) 
demande de tester la balise title /qui se trouve dans la balise 
//head/ (check that a non-empty |title| element appears in the 
|head| section).


Cas problématique: si j'ai un title hors du head, comme c'est le cas 
sur http://accor.com/fr.html que faire ?


Au passage, les navigateurs (du moins Firefox, Opera, Chromium) 
récupèrent bien le title.


Vu tout le travail qui a été fait pour rendre AccessiWeb conforme à 
WCAG, il me semble dommage de laisser passer ça.


Vous en pensez quoi ? (cc @dbo75 @villainjp)

Matthieu

PS: Je me permets d'ajouter quelques sous-titres: la réponse à cette 
question n'est pas anodine, elle fera foi dans l'implémentation 
Tanaguru, donc sur plusieurs millions pages testées.





--
Phone: +33 9 72 11 26 06
Mobile: +33 6 73 96 79 59
Twitter: @mfaure http://twitter.com/mfaure

Tanaguru free-libre software for accessibility assessment 
http://www.Tanaguru.org/
KBAccess collaborative database of good and bad examples of Web 
Accessibility http://www.kbaccess.org/




___
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



--
Phone: +33 9 72 11 26 06
Mobile: +33 6 73 96 79 59
Twitter: @mfaure http://twitter.com/mfaure

Tanaguru free-libre software for accessibility assessment 
http://www.Tanaguru.org/
KBAccess collaborative database of good and bad examples of Web 
Accessibility http://www.kbaccess.org/




___
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] Mécanisme de mise en pause

[Aurélien Levy]

Bonjour,

si je me range à l'avis général militant pour le bouton pause 
contrairement à ce que dit Romain il n'est nullement indiqué dans les 
WCAG que le seul moyen de mettre en pause doit être via un bouton pause. 
Il parle même de le faire via un raccourci clavier cf 
http://www.w3.org/TR/2013/NOTE-WCAG20-TECHS-20130905/G4. On pourrait 
également une mise ne pause automatique lors du survol de la zone à la 
souris et lors de la prise de focus dans la zone (tout aussi bancale 
comme solution mais tout autant autorisée)
En bref si tu veux etre conforme tu fais comme tu veux du moment que 
l'utilisateur à un quelconque moyen de mettre en pause et reprendre, si 
tu veux etre accessible le mieux reste effectivement le bouton pause


Aurélien

Bonjour,

Il faut impérativement un mécanisme dédié d'arrêt et de relance du 
contenu en mouvement pour assurer la conformité. Même si le 
comportement que tu décris permet l'arrêt du contenu en mouvement cela 
n'est pas satisfaisant : l'utilisateur ayant besoin de ce mécanisme 
n'aura probablement pas l'idée (à juste titre) d'aller activer des 
éléments qui n'ont rien à voir avec ce qu'il cherche à faire (arrêter 
le contenu).


Romain


Le 17 octobre 2013 14:07, Olivier Keul olivier.k...@gmail.com 
mailto:olivier.k...@gmail.com a écrit :


Bonjour la liste,

J'ai un carrousel (outch) en défilement automatique (outch bis) du
coup je suis entrain de décortiquer le critère 13.17

http://www.accessiweb.org/index.php/accessiweb_2.2_liste_deployee.html#crit-13-17
 qui
indique Dans chaque page Web, chaque contenu en mouvement ou
clignotant est-il contrôlable par l'utilisateur ?.

Par contrôlable par l'utilisateur on entend un mécanisme de mise
en pause. La solution qui me vient à l'esprit est l'utilisation
d'un bouton pause. Malheureusement les designers grincent un peu
des dents.

Le carrousel possède un bouton précédent, un bouton suivant, et
une pagination. Si on clique sur l'un de ces 3 boutons alors le
défilement automatique sera bloqué. Est-ce qu'il peut s'agir d'un
mécanisme de mise en pause ?

Merci d'avance,

Olivier Keul

___
liste_gta mailing list
liste_gta@list.accessiweb.org mailto: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 mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org

Re: [Liste GTA] Mécanisme de mise en pause

[Aurélien Levy]

Tout à fait mais il est bien indiqué :
If this is a sufficient technique for a success criterion, failing this 
test procedure does not necessarily mean that the success criterion has 
not been satisfied in some other way, only that this technique has not 
been successfully implemented and can not be used to claim conformance.


Tu peux choisir ou pas d'utiliser cette technique voir aucune des 
techniques et être conforme quand même


PS: attention ce mail peut contenir de graves causes de troll sans fin

Bonjour Aurélien,

La G186 (http://www.w3.org/TR/2013/NOTE-WCAG20-TECHS-20130905/G186) 
demande bien un contrôle dédié. D'où ma réponse.


Romain


Le 17 octobre 2013 14:52, Aurélien Levy aurelien.l...@temesis.com 
mailto:aurelien.l...@temesis.com a écrit :


Bonjour,

si je me range à l'avis général militant pour le bouton pause
contrairement à ce que dit Romain il n'est nullement indiqué dans
les WCAG que le seul moyen de mettre en pause doit être via un
bouton pause. Il parle même de le faire via un raccourci clavier
cf http://www.w3.org/TR/2013/NOTE-WCAG20-TECHS-20130905/G4. On
pourrait également une mise ne pause automatique lors du survol de
la zone à la souris et lors de la prise de focus dans la zone
(tout aussi bancale comme solution mais tout autant autorisée)
En bref si tu veux etre conforme tu fais comme tu veux du moment
que l'utilisateur à un quelconque moyen de mettre en pause et
reprendre, si tu veux etre accessible le mieux reste effectivement
le bouton pause

Aurélien

Bonjour,

Il faut impérativement un mécanisme dédié d'arrêt et de relance
du contenu en mouvement pour assurer la conformité. Même si le
comportement que tu décris permet l'arrêt du contenu en mouvement
cela n'est pas satisfaisant : l'utilisateur ayant besoin de ce
mécanisme n'aura probablement pas l'idée (à juste titre) d'aller
activer des éléments qui n'ont rien à voir avec ce qu'il cherche
à faire (arrêter le contenu).

Romain


Le 17 octobre 2013 14:07, Olivier Keul olivier.k...@gmail.com
mailto:olivier.k...@gmail.com a écrit :

Bonjour la liste,

J'ai un carrousel (outch) en défilement automatique (outch
bis) du coup je suis entrain de décortiquer le critère 13.17

http://www.accessiweb.org/index.php/accessiweb_2.2_liste_deployee.html#crit-13-17
 qui
indique Dans chaque page Web, chaque contenu en mouvement ou
clignotant est-il contrôlable par l'utilisateur ?.

Par contrôlable par l'utilisateur on entend un mécanisme de
mise en pause. La solution qui me vient à l'esprit est
l'utilisation d'un bouton pause. Malheureusement les
designers grincent un peu des dents.

Le carrousel possède un bouton précédent, un bouton suivant,
et une pagination. Si on clique sur l'un de ces 3 boutons
alors le défilement automatique sera bloqué. Est-ce qu'il
peut s'agir d'un mécanisme de mise en pause ?

Merci d'avance,

Olivier Keul

___
liste_gta mailing list
liste_gta@list.accessiweb.org
mailto: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  mailto: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 mailto: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 mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org

Re: [Liste GTA] Message de demande de confirmation

[Aurélien Levy]

  
  
Sauf erreur de ma part l'obligation ne
  porte que sur les informations  caractres personnelles,
  financiers ou juridiques.
  Par ailleurs si l'utilisateur  la possibilit de recrer
  l'information qu'il a supprim il me semble pas non plus avoir
  obligation de demande de confirmation (aprs tout dpend de la
  complexit d'ajout de l'info)
  
  Aurlien


  
  
  
  
  
Bonjour,

Je
remonte ce vieux sujet.

La
position de Romain tait la suivante:
Une demande de confirmation (de toute
  action) ralise sur le client est soumise  alternative pour
  se conformer et  RGAA et  AccessiWeb.
Cette
position fait-elle lunanimit?
Ne
peut-on pas considrer que cette fonctionnalit relve du
confort dutilisation? En particulier, si le libell/titre
associ  laction (lien ou bouton) est suffisamment
explicite.

Frdric
  BERNIER-MALCOIFFE


  De:
  liste_gta [mailto:liste_gta-boun...@list.accessiweb.org] De
la part de Romain Gervois
  Envoy: vendredi 8 fvrier 2013 13:40
  : GTA
  Objet: Re: [Liste GTA] Message de demande de
  confirmation



  Bonjour,

Une demande de confirmation (de toute action) ralise sur
le client est soumise  alternative pour se conformer et 
RGAA et  AccessiWeb.

La solution 1 voque est le point de dpart (ce qui fait
office d'alternative) : un bouton ou un lien selon la
conception amne soit sur une nouvelle page soit sur la mme
page aprs rechargement. Les questions de l'emplacement du
message et de la discrimination des donnes se posent en
effet.

La solution 2 voque correspond au script qui se
substituera  la solution 1. Deux possibilits pour cette
demande de confirmation : confirm ou fentre modale. confirm
est gr nativement et est trs bien support (lecteurs
d'cran compris). Pour la fentre modale, c'est plus dlicat
puisque cela entrane un dveloppement assez consquent par
rapport  confirm :
- sauvegarder l'lment  l'origine de l'ouverture de la
fentre modale ;
- donner le focus  la fentre modale (tabindex  0 en plus
du role dialog et du aria-labelledby ; on peut imaginer du
aria-hidden sur l'arrire-plan) ;
- conserver le focus dans la fentre modale tant qu'aucune
rponse n'a t fournie (manipulation des tabindex
(attention au contexte) et du focus) ;
- redonner le focus  l'lment  l'origine de l'ouverture
de la fentre modale  la fermeture.

Cela dpendra donc du choix entre "Vieux Web" et "Nouveau
Web (?)" sans parler des autres contraintes inhrentes.

Enfin, le point n'est pas abord dans le sujet mais la faon
dont le traitement s'effectue aprs confirmation dans un
contexte client ncessitera attention.
Si  la confirmation, la suppression est porte sur le
client (suppression de l'lment sans rafraichissement et
communication vers le serveur via AJAX), une zone de
notification ne sera pas un luxe (role alert et gestion du
focus  prvoir) - c'est galement vrai ct serveur.


  
Esprant que a aide.
Romain
  
Le 8 fvrier 2013 12:26, Frdric
  BERNIER-MALCOIFFE frederic.bernier-malcoi...@effitic.com
  a crit :

  
Bonjour
   tous,

Je
  souhaite vous solliciter pour avoir votre avis sur le
  sujet suivant.
Comment
  mettre en uvre un mcanisme de demande de
  confirmation suite, par exemple,  une action de
  suppression dun itemdans une liste prsente dans un
  tableau de donnes ?

La
  solution qui vient tout de suite  lesprit est
  lutilisation de la fonction confirm de _javascript_.
  Mais:
 Fait-elle
  partie du champ dapplication du test RGAA 8.12 :
  Prsence d'une alternative au code _javascript_? En
  dautres termes, cela ncessite-t-il de mettre en
  uvre une alternative ct serveur?
 Est-elle
  correctement prise en charge par tous les agents
  

Re: [Liste GTA] Outils de e-learning accessibles

[Aurélien Levy]

Bonjour

Voilà qui devrait t être utile :
https://dl.dropboxusercontent.com/u/3486333/csun2013/lms_compared_paper_2013.html
C est ce que j ai de plus récent en stock.

Aurélien 

Le 1 juil. 2013 à 12:04, CHAMSSEDDINE Frederic 
frederic.chamssedd...@regioncentre.fr a écrit :

 Bonjour à tous
 Je suis à la recherche d’informations sur des outils de e-learning 
 accessibles (pas forcément franco-français).
 Auriez-vous des informations sur ce sujet ?
  
 Cordialement
 Frédéric CHAMSSEDDINE
 Région Centre
 Chargé de mission « Internet »
 Direction de la Communication
 Expert accessibilité AccessiWeb en Evaluation
 02 38 70 35 86
 frederic.chamssedd...@regioncentre.fr
 Retrouvez l'actu de la région Centre sur Facebook :
 http://www.facebook.fr/RegionCentre.fr
  
 Suivez l'actu de la région Centre sur Twitter
 http://twitter.com/Region_Centre
 image001.jpg
 P afin de contribuer au respect de l'environnement, merci de n'imprimer ce 
 mail qu'en cas de nécessité.
  
 ___
 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] Environnement maîtrisé

[Aurélien Levy]

Bonjour,

tout dépend en effet du matériel et du bridage du matériel en question.
Exemple si il s'agit d'ipad mais que l'utilisateur ne peut activer 
voiceover ou brancher un casque ou gérer le volume effectivement il y a 
un souci.
Si il s'agit de tablette android idem avec ceci en plus que cela 
nécessite d'avoir la toute dernière version de l'OS et toutes les 
préférences d'accessibilité activée/installée par défaut.


Cordialement,

Aurélien Levy

Bonjour,

La notion d'environnement maîtrisé suppose deux choses :
* le parc matériel et logiciel est entièrement connu (une liste finie
de matériels, de navigateurs et d'aides techniques)
* il est assuré que les utilisateurs disposent, dans ce cadre, de la
combinaison de matériel, navigateurs et aide technique leur permettant
d'utiliser le service, ou qu'une solution alternative est gérée.

Le cas soulevé me semble donc très limite, pour le second point ;-)

Cordialement,
Laurent Denis
--
Temesis
http://temesis.com



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

Re: [Liste GTA] souci avec un lien

[Aurélien Levy]

  
  
Bonjour,
  
  du point de vue de la conformit il est tout  fait conforme.
  Si on va mme dans le dtails il est mme non applicable si on en
  croit WCAG dans le mesure o l'intitul est non comprhensible par
  personne il n'y a rien  faire de spciale pour le rendre
  comprhensible (une des joyeuset wcagienne).
  Par contre effectivement si on veut qu'il soit accessible il faut
  utiliser une image lien avec alt="aide sur " ou texte cach
  via css ou autre .
  
  Aurlien

Bonjour,
  
  Non, il n'est pas explicite (le contexte apport par le titre de
  lien c'est autre chose). A dfaut d'acceptation du prestataire du
  picto qui va bien, on peut imaginer l'utilisation d'un lment
  abbr ou d'un patch via ARIA (role img + aria-label) avec tous les
  soucis que cela comporte et a n'assurera pas la conformit.
  
  Romain
  

Le 19 novembre 2012 17:12, FORTIN
  Nicolas nicolas.for...@culture.gouv.fr
  a crit :
  

  Oui, en effet, l'attribut alt
  serait la meilleure solution mais je ne suis pas sr
  que le prestataire du site accepte...
  Dans le cas ou il n'accepte pas
  puis-je considrer le lien comme pertinent grce  son
  title ?
  
  
  Bonne soire,
  Nicolas
  
  
  

  
- Original Message
  - 
From:
  Sylvain Bousselier 
To: liste_gta@list.accessiweb.org

Sent: Monday,
  November 19, 2012 4:06 PM
Subject: Re:
  [Liste GTA] souci avec un lien



  Dune
  manire gnral si le lien nest quun point
  dinterrogation il faut que ce soit une image
  img /, car si il y a un problme
  serveur qui empche le chargement de cette
  image on peut quand mme avoir un intitul du
  lien grce  la balise alt de limage.
  
  Je
  pense que par la mme occasion cela rend le
  lien plus explicite (Image-lien).
  
  
Sylvain 
  
Sylvain Bousselier 
Intgrateur
Bureau : 01 58
  17 51 30 
Fax :  01
58 17 59 01 
  sylvain.boussel...@nurun.com 
  

  

  Nurun Inc., une socit de
Qubecor Mdia 
57 boulevard de la Villette 
75010 Paris
Rendez nous visite @ www.nurun.com et participez  la
conversation avec les experts du rseau
Nurun
@
www.digitalforreallife.com

http://5775.nurun.com/

  
  
  

  De: liste_gta
  [mailto:liste_gta-boun...@list.accessiweb.org]
  De la part de FORTIN Nicolas
  Envoy: lundi 19 novembre 2012
  15:48
  : groupe accessiweb
  Objet: [Liste GTA] souci avec un
  lien

  
  
  
Bonjour,
  
  

  
  
Un
lien dont l'intitul est simplement un point
d'interrogation pour symboliser l'aide pour
des raisons graphiques avec un title
bien renseign peut-t'il tre considr
comme explicite ?
  
  

  
  
Personnellement
je pense que non car le point
   

Re: [Liste GTA] Vidéo et HTML5 et multisupport

[Aurélien Levy]

Bonjour,

quand il n'y a pas de javascript vous pouvez proposer un lien vers la 
vidéo, le fichier de soustitre et le fichier d'audiodescription.
Attention cependant car à ma connaissance hormis quelques 
expérimentations dans des labos aucun player html5 à base d'élément 
video ne gère l'audiodescription (seule solution, l'inclure dans la 
vidéo).
En l'état vous pourrez donc avoir une solution accessible mais qui ne 
passera pas la labellisation.


Aurélien


Bonjour,

Nous devons mettre en place un lecteur vidéo multi-support accessible.

C'est-à-dire qu'il doit fonctionner sur tout navigateur sur PC, mais 
aussi sur mobile et sur tablette.


Nous avons fait le choix d'utiliser un lecteur flash avec en 
alternative un lecteur HTML5 quand le flash n'est pas lu.


Nous rencontrons un problème avec les sous-titres : pas moyen de les 
faire fonctionner sans javascript en HTML5... Donc du coup pas 
d'alternative au javascript, donc pas accessible...


Comment traiter cette problématique, nous tournons en rond...

Merci

*Aude JOLY*



___
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

Re: [Liste GTA] Vidéo et HTML5 et multisupport

[Aurélien Levy]

Re salut,

à première vue (et sauf changement depuis les temps anciens où j'avais 
fait labelliser un site) les critères sont applicables aux éléments 
vidéos externes. Le critère
4.20 [Bronze] La consultation de chaque média temporel est-elle 
contrôlable par le clavier et la souris ? s'applique donc. Idem si ce 
contenu vidéo natif est intégré via object. Hors ici l'audiodescription 
ne sera pas contrôlable au clavier sauf à utiliser du SMIL via real 
player (que plus personnes n'utilisent)


Aurélien


salut Aurélien,

pas sûr de comprendre ta remarque:
 En l'état vous pourrez donc avoir une solution accessible mais qui 
ne passera pas la labellisation. 
Sauf erreur le fait d'avoir une version sous-titrée, et une version 
audio-décrite, atteignables avec un lien correctement placé, permet de 
satisfaire les critères de présence dans AW; et donc de labelliser 
potentiellement.


Mais comme je sais que tu le sais, je me dis que j'ai loupé un truc 
;o) [clin d'oeil].

Tu peux préciser stp ?

Sinon, pour Aude: d'instinct j'aurais fait l'inverse: dégrader le 
HTML5 en Flash, mais j'avoue ne pas y avoir réfléchi plus que ça. 
Qu'est-ce qui vous a amené à faire ce choix du Flash d'abord, puis du 
HTML5? A cause des soucis de dépendance à JS?



Cordialement,
*Olivier Nourry*
Twitter: @OlivierNourry http://twitter.com/#%21/OlivierNourry



Le 10 juillet 2012 16:20, Aurélien Levy aurelien.l...@temesis.com 
mailto:aurelien.l...@temesis.com a écrit :


Bonjour,

quand il n'y a pas de javascript vous pouvez proposer un lien vers
la vidéo, le fichier de soustitre et le fichier d'audiodescription.
Attention cependant car à ma connaissance hormis quelques
expérimentations dans des labos aucun player html5 à base
d'élément video ne gère l'audiodescription (seule solution,
l'inclure dans la vidéo).
En l'état vous pourrez donc avoir une solution accessible mais qui
ne passera pas la labellisation.

Aurélien


Bonjour,

Nous devons mettre en place un lecteur vidéo multi-support
accessible.

C'est-à-dire qu'il doit fonctionner sur tout navigateur sur PC,
mais aussi sur mobile et sur tablette.

Nous avons fait le choix d'utiliser un lecteur flash avec en
alternative un lecteur HTML5 quand le flash n'est pas lu.

Nous rencontrons un problème avec les sous-titres : pas moyen de
les faire fonctionner sans javascript en HTML5... Donc du coup
pas d'alternative au javascript, donc pas accessible...

Comment traiter cette problématique, nous tournons en rond...

Merci

*Aude JOLY*



___
liste_gta mailing list
liste_gta@list.accessiweb.org  mailto: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 mailto: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



--
Aurélien Levy

Temesis

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