Re: [Liste GTA] accessibilité des documents bureautiques

[Olivier Nourry]

Bonjour Isabelle,Tu peux le trouver ici: https://drive.google.com/file/d/1f25YbP0f2QSokI50uqo-kdnae8QTcWIC/view?usp=sharing Il s’agit de la version que je conserve sur mon Google Drive.Je le mets également en PJ.J’ai signalé ce problème à la DINUM via la liste RGAA; mais sans effet à ce jour. 

liste-criteres-documents-bureautiques-telechargement-RGAA.odt
Description: application/vnd.oasis.opendocument.text
Bien à toi,OlivierLe 26 janv. 2021 à 12:01, Isabelle Moretti  a écrit :Bonjour à tous,Sur https://numerique.gouv.fr dans le glossaire du référentiel, le lien vers les critères d'accessibilité des documents bureautique renvoie vers une page vide.Où peut-on trouver ce précieux document ?Merci pour votre aide !Bonne journéeIsabelle Moretti06 99 40 02 06www.lesdiodes.fr
___liste_gta mailing listliste_gta@list.accessiweb.orghttp://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] Législation belge

[Olivier Nourry]

Bonjour Marek,

Je ne connais pas d’équivalent du RGAA dans d’autres états membres. Le 
Luxembourg l’a adopté également, cependant. 
Sur le plan technique, hormis le fait que la version 4 ne soit disponible qu’en 
français, rien ne s’oppose à son utilisation dans n’importe quel contexte de 
vérification de conformité WCAG (dont la directive européenne). Le RGAA est en 
effet une méthode compatible, c’est-à-dire qu’un site conforme RGAA 4 est 
conforme WCAG niveau AA. C’est en tout cas l’objectif assigné lors de sa 
rédaction.

Pour ma part, je l’utilise donc systématiquement ou presque, y compris pour des 
clients US par exemple.

J’espère que cela répond à ta question.


Bonne journée,
Olivier Nourry
Access First / Be Player One

> Le 20 janv. 2021 à 09:19, Marek ALGOUD  a écrit :
> 
> Bonjour David,
> 
> Merci pour ta réponse rapide. Pour être sûr de bien comprendre, l'European 
> Accessibility Act est le texte de loi européen auquel tous les pays membres 
> doivent se soumettre et pour le moment, la seule "méthode technique" 
> disponible pour le mettre en place c'est le RGAA (il n'y a pas d'équivalent 
> européen ou belge). C'est bien ça ? Est-ce qu'il y aura un jour un équivalent 
> européen au RGAA ? 
> 
> 
> 
> Le mer. 20 janv. 2021 à 08:54, CAILLAUD DAVID (CNAM / Nantes) 
>  <mailto:david.caill...@assurance-maladie.fr>> a écrit :
> Bonjour Marek,
> 
>  
> 
> La loi européenne est applicable pour tous ses membres :
> 
> European Accessibility Act : https://ec.europa.eu/social/main.jsp?catId=1202 
> <https://ec.europa.eu/social/main.jsp?catId=1202>
> EN 301 549 V2.1.2 
> https://www.etsi.org/deliver/etsi_en/301500_301599/301549/02.01.02_60/en_301549v020102p.pdf
>  
> <https://www.etsi.org/deliver/etsi_en/301500_301599/301549/02.01.02_60/en_301549v020102p.pdf>
>  
> 
> Le RGAA 4 est une première étape dans la prise en compte du texte européen.
> 
>  
> 
> Cordialement,
> 
> David CAILLAUD
> 
>  
> 
> De : liste_gta [mailto:liste_gta-boun...@list.accessiweb.org 
> <mailto:liste_gta-boun...@list.accessiweb.org>] De la part de Marek ALGOUD
> Envoyé : mercredi 20 janvier 2021 08:27
> À : liste_gta@list.accessiweb.org <mailto:liste_gta@list.accessiweb.org>
> Objet : [Liste GTA] Législation belge
> 
>  
> 
> Bonjour la liste,
> 
>  
> 
> J'ai une demande un peu particulière : est-ce que quelqu'un connait la 
> législation en vigueur en Belgique sur l'accessibilité ?
> 
> J'ai trouvé ce texte de lois : 
> http://www.ejustice.just.fgov.be/cgi_loi/change_lg.pl?language=fr=F=2018100412_name=loi
>  
> <http://www.ejustice.just.fgov.be/cgi_loi/change_lg.pl?language=fr=F=2018100412_name=loi>.
>  Il mentionne les "normes harmonisées dont les références ont été publiées 
> par la Commission européenne". 
> 
> Je suis donc allé rur le site de la commission européenne et j'ai trouvé 
> cette page : 
> https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32019L0882=1611126841729=FR#d1e2404-70-1
>  
> <https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32019L0882=1611126841729=FR#d1e2404-70-1>
> Il est écrit : "2.   Conformément à l’article 10 du règlement (UE) no 
> 1025/2012, la Commission demande à une ou plusieurs organisations européennes 
> de normalisation d’élaborer des normes harmonisées pour les exigences en 
> matière d’accessibilité des produits énoncées à l’annexe I. La Commission 
> présente le premier projet de demande au comité concerné au plus tard 28 juin 
> 2021."
> 
>  
> 
> Est-ce que cela signifie qu'une norme européenne équivalente est en cours 
> d'écriture ? Est-ce qu'il existe déjà aujourd'hui un référentiel pour la 
> Belgique reconnu par l'État ?
> 
>  
> 
> D'avance merci pour votre aide !
> 
>  
> 
> Marek
> 
>  
> 
> --
> 
> <~WRD000.jpg>  <http://www.smile.eu/>
> 107 boulevard de Stalingrad
> 69 100 Lyon Villeurbanne
> 
> Marek ALGOUD
> 
> Lead Creative dev
> 
>  
> 
>  marek.alg...@smile.fr <mailto:marek.alg...@smile.fr> 
>  +334 37 23 56 58 
>  http://www.smile.eu <http://www.smile.eu/>
>  
> 
> <~WRD000.jpg> <https://twitter.com/GroupeSmile> <~WRD000.jpg> 
> <https://www.facebook.com/smileopensource> <~WRD000.jpg> 
> <https://www.linkedin.com/company/smile> <~WRD000.jpg> 
> <https://github.com/Smile-SA>
>  
> 
> <~WRD000.jpg> 
> <http://smile.eu/?utm_source=signature_medium=email_campaign=signature>
>  
> 
>  Pour la planète, n'imprimez ce mail que si c'est nécessaire
> 
> 
> • Désormais notre adresse

[Liste GTA] attestation de déplacement dérogatoire au format HTML accessible

[Olivier Nourry]

Re-bonjour,

En version HTML cette fois (ouf, je me sens moins sale): 
https://oliviernourry.github.io/att/ <https://oliviernourry.github.io/att/>

Et le repo Github pour les remarques et correctifs: 
https://github.com/OlivierNourry/att/ <https://github.com/OlivierNourry/att/>

À faire tourner également!
Bonne journée
Olivier Nourry

> Le 17 mars 2020 à 08:59, Olivier Nourry  a écrit :
> 
> Bonjour,
> 
> Le PDF fourni par le document n’étant pas utilisable par tout le monde, j’en 
> ai réalisé une version DOCX: 
> https://drive.google.com/file/d/1eOYKPTHJJ6z7XpSPcid0tvxAu-Gl1PDf/view?usp=sharing
>  
> <https://drive.google.com/file/d/1eOYKPTHJJ6z7XpSPcid0tvxAu-Gl1PDf/view?usp=sharing>
>  
> N’hésitez pas à me faire vos retours sur son accessibilité effective, c’est 
> loin d’être ma spécialité!
> 
> Vous pouvez bien sûr diffuser, dupliquer, et adapter à volonté.
> 
> Bon courage à toutes et à tous,
> Olivier Nourry

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

Re: [Liste GTA] attestation de déplacement dérogatoire au format DOCX accessible

[Olivier Nourry]

Avec plaisir!
On m’a fait un retour sur l’accessibilité avec JAWS 2020 et NVDA dernière 
version, selon lequel il est « très partiellement accessible ». Le document a 
été réalisé sous Mac, qui n’offre pas autant de possibilités que la version 
Windows (COMME PAR HASARD). Manuel Pereira de l’AVH m’a indiqué qu’ils allaient 
s’en occuper dans la journée.

> Le 17 mars 2020 à 09:16, Bulle Cube  a écrit :
> 
> Merci Olivier, je partage sur mes listes ❤️
> 
> -- 
> Bulle Cube
> Le 17 mars 2020 à 08:59:58, Olivier Nourry (olv.nou...@gmail.com 
> <mailto:olv.nou...@gmail.com>) a écrit:
> 
>> Bonjour,
>> 
>> Le PDF fourni par le document n’étant pas utilisable par tout le monde, j’en 
>> ai réalisé une version DOCX: 
>> https://drive.google.com/file/d/1eOYKPTHJJ6z7XpSPcid0tvxAu-Gl1PDf/view?usp=sharing
>>  
>> <https://drive.google.com/file/d/1eOYKPTHJJ6z7XpSPcid0tvxAu-Gl1PDf/view?usp=sharing>
>>  
>> N’hésitez pas à me faire vos retours sur son accessibilité effective, c’est 
>> loin d’être ma spécialité!
>> 
>> Vous pouvez bien sûr diffuser, dupliquer, et adapter à volonté.
>> 
>> Bon courage à toutes et à tous,
>> Olivier Nourry
>> ___ 
>> 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 
>> <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] attestation de déplacement dérogatoire au format DOCX accessible

[Olivier Nourry]

Bonjour,

Le PDF fourni par le document n’étant pas utilisable par tout le monde, j’en ai 
réalisé une version DOCX: 
https://drive.google.com/file/d/1eOYKPTHJJ6z7XpSPcid0tvxAu-Gl1PDf/view?usp=sharing
 

 
N’hésitez pas à me faire vos retours sur son accessibilité effective, c’est 
loin d’être ma spécialité!

Vous pouvez bien sûr diffuser, dupliquer, et adapter à volonté.

Bon courage à toutes et à tous,
Olivier Nourry___
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

[Olivier Nourry]

Bonjour Aurélien,

Merci pour ta réponse.

Le cas d’usage que tu évoques (l’outil qui reconnaît les champs pour ajouter 
des icônes) ne me paraît pas différent du cas de l’autocomplétion. Sur un champ 
de saisie de prénom, avec comme étiquette « Prénom », et autocomplete=on, je 
pense qu’un outil a autant de chances de comprendre la fonction du champ qu’un 
navigateur. Pour moi c’est côté outil que se trouve le problème, si ça ne 
fonctionne pas. 

L’amélioration est souhaitable, et dans la plupart des cas, probablement pas 
difficile à implémenter. Mais s’il y a blocage, et que l’étiquette n’est pas 
ambigüe, perso je laisserais passer.

Bonne journée,
Olivier


> Le 25 janv. 2020 à 08:40, Aurélien Levy  a écrit :
> 
> 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  <mailto:olv.nou...@gmail.com>> 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 <mailto: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>
> ___
> 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] critère 11.13 (RGAA 4) et autocomplete=on

[Olivier Nourry]

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

Re: [Liste GTA] - RGAA, le JS et les inline CSS

[Olivier Nourry]

Bonjour,

oui, le JS est considéré comme une technologie compatible avec l’accessibilité 
depuis la version 3 du RGAA
oui, aucun souci avec ça, la façon dont on affecte les propriétés CSS n’a 
aucune importance

J’espère t’avoir aidé :)

Olivier Nourry
Access First

> Le 13 janv. 2020 à 16:08, Damien ALLIOD  a écrit :
> 
> Bonjour à tous,
> 
> Etant un peu rouillé, je n'ai pas fait de RGAA depuis quelques années...  et 
> j'aimerai des confirmations sur 2 points :
> 
> - Concernant le JS :
> Pouvez-vous me confirmer qu'il n'est pas nécessaire de faire une version "JS 
> désactivé" d'un formulaire tant que le JS est compatible avec les critères 
> RGAA.
> 
> - Concernant les balises et attributs "style" des CSS, est-il bien autorisé 
> de les utiliser ?
> 
> Merci d'avance pour votre retour,
> 
> Cordialement,
> 
> Damien
> 
> 
> ___
> 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)

[Olivier Nourry]

Bonjour,

@Maud: merci pour la citation! C’était un travail d’équipe, avec les 
participations indispensables et expertes de (dans l’ordre de citation dans le 
livre blanc) Alex Bernier et Katie Durand (Braillenet), Jean-Pierre Villain 
(Access 42), Jérôme  Botineau (Empreinte Digitale, anciennement 
V-Technologies), Olivier Ducruix (Orange), et Romain Rouyer (Smile).

Je tiens également à rappeler l’existence d’un ensemble de ressources que nous 
avions produites pour l’écosystème du RGAA 3, directement destinées à la 
conception, au test et au développement d’applis mobiles accessibles:
Conception d’applications mobiles 
<https://github.com/DISIC/guide-mobile_app_conception>
 Développement d’applications mobiles accessibles avec les API Android et iOS 
<https://github.com/DISIC/guide-mobile_app_dev_natif>
Développement d’applications mobiles hybrides accessibles avec Ionic et OnsenUI 
<https://github.com/DISIC/guide-mobile_app_dev_hybride>
Référentiel spécifique aux plateformes mobiles/tactiles 
<https://github.com/DISIC/referentiel-mobile-tactile>
Audit d’applications mobiles <https://github.com/DISIC/guide-mobile_app_audit>

À noter: ces ressources ont été traduites en anglais, et sont donc utilisables 
avec des partenaires internationaux, le cas échéant.

(liste complète des ressources du RGAA: 
https://gta2017.access42.net/2/ressources/ 
<https://gta2017.access42.net/2/ressources/>).

Ces ressources ont été réalisées avant la sortie de WCAG 2.1, néanmoins elles 
ne devraient pas avoir trop vieilli, hormis celles sur les frameworks, qui ont 
beaucoup évolué depuis. La méthodologie, les observations et conclusions 
restent intéressantes pour comprendre certaines notions propres au 
développement d’applis mobiles.


Bonne fin de journée
Olivier Nourry
Access First
 




> Le 22 nov. 2019 à 10:49, 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 
> <https://facebook.github.io/react-native/docs/accessibility>
> 
> Deux autres articles intéressant 
> https://callstack.com/blog/react-native-android-accessibility-tips/ 
> <https://callstack.com/blog/react-native-android-accessibility-tips/>
> https://medium.com/substantial/accessibility-in-react-native-5b47047ca346 
> <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 
> mailto:mdup...@polymorphe-design.fr>> a écrit :
> Il y a celle de 2016 :  
> http://www.braillenet.org/wp-content/uploads/GTA22_LivreBlanc_Mobile.pdf 
> <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 <mailto:mdup...@polymorphe-design.fr> 
> www.polymorphe-design.fr <http://www.polymorphe-design.fr/>
> 
> 
> 
> 
> 
>> Le 22 nov. 2019 à 10:03, Audrey Williamson > <mailto:audw...@gmail.com>> 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 <mailto: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>
> 
> ___
> 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 
> <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] Pour information

[Olivier Nourry]

Bonjour Anthony,

> Le 12 oct. 2019 à 13:52, Anthony Ladeuil  a écrit :
> 
> La fonctionnalité restera une option activable par les utilisateurs 
> concernés. Pour voir le côté positif, on peut se dire que le texte « aucune 
> description disponible" pourra correspondre à un alt vide. :-) Mais ça va 
> devenir verbeux tout ça… Tant que l'information ajoutée par Chrome est 
> spécifiée comme étant de l'IA, les choses seront claires et les utilisateurs 
> sauront sûrement faire la part des choses puisqu'ils n'ont pas le "A" de l'IA.
Sauf que c’est un faux choix: on propose soit un truc qui marche mal, soit rien 
du tout.
Est-ce qu’il aurait été difficile de proposer une option de configuration pour 
que les utilisateurs choisissent le texte (ou l’absence de texte) à restituer?
Evidemment non, d’où ma suspicion que les utilisateurs n’ont pas été associés 
au développement, et donc mon accusation de handi-washing. Parce que sinon on 
n’aboutirait pas à cette pseudo-solution, qui va à l’encontre même des 
recommandations d’accessibilité de base.
> 
> Quant aux moyens déployés par les géants du net dans une techno plutôt qu’une 
> autre, c'est toujours mieux que d'investir dans rien du tout, à mon sens.
Si c’est juste pour faire de la comm sur le dos des personnes handicapées, 
j’estime que c’est pire que rien du tout, pour ma part.

> Le jour où Google va décider de miser sur un lecteur d'écran compatible avec 
> les OS du marché, on va vite les soupçonner de collecter des informations à 
> l'insu des gens et ça va râler. 
> 
Chiche?
Les éditeurs de lecteurs d’écran ne subissent pas cette critique il me semble. 
Il existe un moyen simple de se prémunir de cela. Ça s’appelle l’open source, 
et au pire, ce sont des engagements et un discours clairs concernant le respect 
de la confidentialité. Google pourrait très bien le faire, pour une fraction de 
leur budget R, mais ce n’est apparemment pas le sens de leur politique 
d’investissement.


Cordialement,
Olivier Nourry___
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org

Re: [Liste GTA] Pour information

[Olivier Nourry]

« Balise alt »… sic.

Personnellement j’ai toujours pensé que ce type de technologie était un gadget 
bien trop coûteux pour l’intérêt qu’il présente dans cette application.

D’abord parce que j’ai du mal à percevoir l’intérêt d’avoir des descriptions 
pour des images qui ont essentiellement vocation à être vues (et non décrites - 
je sais pas si vous voyez la nuance?). Ensuite parce que sauf à avoir la 
capacité de compréhension et d’abstraction d’un être humain, une IA ne peut 
pas, de manière fiable, traduire l’intention de l’auteur ou l’autrice du 
contenu. L’image sert un propos qui n’est pas forcément exprimé en la 
décrivant, mais en faisant référence à ce que cette image évoque. Cela implique 
de disposer du bagage culturel (au sens premier du terme) qui permet de faire 
cette association d’idées. Ce que font les IA à l’heure actuelle, c’est de la 
reconnaissance d’images, et c’est très différent. Si j’illustre un site web 
corporate avec une photo de personnes assises autour d’une table de bureau, 
souriantes, bien habillées, représentant divers groupes ethniques, je fais 
passer un message plus ou moins subtil concernant cette entreprise. Les mots 
que j’utiliserais pour faire passer ce message ne seront probablement pas ceux 
qui décrivent l’image de manière factuelle.

Alors ok la reconnaissance d’images c’est très utile pour les voitures 
autonomes, la surveillance, le médical, et des tas d’autres applications. Mais 
pour l’accessibilité, le problème c’est que c’est aussi coûteux qu’inefficace. 
Pour moi ça ressemble à du handi-washing. J’aurais nettement préféré voir les 
milliardaires du numérique investir par exemple sur les lecteurs d’écran, la 
compréhension des besoins utilisateurs, et sur la sensibilisation et la 
formation des professionnels. Ce serait à mon humble avis bien plus profitable 
à tous — mais bon, je dois être utopiste.

Mais si des personnes concernées par le handicap visuel trouvent, au contraire, 
que c’est utile pour elles, alors je veux bien l’entendre. Ça m’intéresse 
réellement d’avoir vos opinions à ce sujet.

Quant à ce qui est indiqué dans l’article: si je comprends bien, quand l'IA ne 
trouvera pas de description satisfaisante pour ses critères de confiance, 
ajoutera « aucune description disponible » là où un alt vide aurait été 
nettement préférable. Preuve selon moi que les personnes concernées ne sont pas 
impliquées dans le développement, une fois de plus. Déçu, mais pas surpris. 


PS: « personnes souffrant d’un handicap visuel » - re sic.

Bonne journée
Olivier Nourry


> Le 11 oct. 2019 à 10:33, fortin.nicolas  a écrit :
> 
> Grâce à l’IA, Google Chrome remplira automatiquement les balises alt pour 
> faciliter le quotidien des malvoyants
> Grâce à la reconnaissance d'images et l'apprentissage automatique, Google va 
> générer automatiquement des balises alt. 
> (le siècle digital, @cecitroc-infos, Vincent Hoefman)
> PAR ÉLÉONORE LEFAIX - TWITTER@ELEFAIX - 11 OCTOBRE 2019
> image d'un panneau de signalisation avec le mot alt
> 
> Naviguer sur le web quand on a un problème de vue, n’est pas une tâche aisée. 
> Pour faciliter le quotidien des malvoyants et des aveugles, Google va 
> utiliser l’IA afin de générer des descriptions automatiques pour plusieurs 
> milliers d’images.
> Des descriptions remplies automatiquement
> Sur Internet et particulièrement les réseaux sociaux, les images sont 
> utilisées pour illustrer des faits ou tout simplement remplacer des mots. Les 
> personnes malvoyantes utilisent pour naviguer sur le web un lecteur d’écran 
> ou une plage braille.
> Pour lire une image cependant, il faut que les balises alt, plus communément 
> appelées texte alternatif soient remplies. Ces dernières servent à décrire ce 
> qu’une image contient.
> Nombreuses sont les entreprises qui ne remplissent pas ces balises et ne 
> permettent donc pas aux personnes souffrant d’un handicap visuel de savoir ce 
> que l’image représente. Google a donc décidé de prendre les devants en 
> utilisant la reconnaissance d’images. De cette manière, la balise alt sera 
> automatiquement remplie sur Chrome avec une description générée 
> automatiquement. Plus de 10 millions d’images ont déjà été décrites, durant 
> les tests menés par Google.
> Il y a quelques mois, Instagram a annoncé utiliser la reconnaissance d’objets 
> pour insérer automatiquement un texte alternatif. Les utilisateurs ont 
> également la possibilité de remplir manuellement ce champs. Facebook propose 
> également une fonctionnalité similaire afin de faciliter la navigation des 
> personnes avec un handicap visuel sur la plateforme.
> Des descriptions approximatives pour ne pas tromper l’utilisateur
> L’équipe « accessibilité » travaillant pour Google Chrome utilise la même 
> technologie qui permet aux utilisateurs de rechercher une image sur Google 
> Photos. Au moment de la lec

Re: [Liste GTA] Un aveugle poursuit Domino's Pizza pour non accessibilité de son site Web (article)

[Olivier Nourry]

Bonjour,

Il n’y a eu aucune amende à ce jour car seul le dernier décret, daté du 
24/07/2019, établit les contours précis de cette sanction (éléments 
déclenchants, montant, délais…). Donc c’est un peu trop récent pour en voir les 
effets. Du reste, même si une procédure avait été lancée, on serait encore dans 
les délais de réaction, puisque l’entité menacée d’une sanction dispose au 
total de 8 mois pour soit régler le problème, soit présenter les preuves de son 
incapacité à le faire. Donc au mieux on verrait les effets fin février 2020, et 
je suis pratiquement certain qu’en réalité rien n’a encore été fait à ce 
propos. 

Rappelons par ailleurs que ce qui est sanctionné c’est le défaut d’affichage 
(de l’état de conformité, qui sera généralement appuyé sur une déclaration de 
conformité, et du schéma pluriannuel). Le site peut donc être ridiculement 
inaccessible tout en étant à l’abri de cette sanction.
Et d’autre part ce ne sont pas les particuliers qui pourront se saisir de la 
justice pour faire appliquer les sanctions, mais le ministère en charge des 
personnes handicapées qui pourra prononcer cette sanction, tant pour le 
contrôle que pour le suivi.

Les particuliers peuvent se saisir de la justice mais sur d’autres 
considérations, notamment celle de la discrimination liée au handicap. Mais 
pour cela il faudra parvenir à prouver qu’il y a effectivement volonté 
manifeste de discriminer, ce qui à mon humble avis sera très difficile dans la 
très grande majorité des cas. Avant d’en arriver là, il est conseillé de saisir 
le Défenseur des Droits. Je ne crois pas que cela ait un effet direct 
quelconque, mais s'ajoute une goutte dans le vase des plaintes, et permet de 
faire constater que le handicap est aujourd’hui la principale source de 
discrimination en France.
 
Les fonctionnaires disposent également, dans le droit qui régit leur activité, 
de la possibilité de se retourner contre leur employeur si leur environnement 
de travail n’est pas accessible, y compris au niveau des logiciels. Je ne sais 
pas si ce dispositif a déjà été utilisé.

Sinon, côté accessibilité physique, un client de la SNCF les attaqués parce que 
les toilettes du train qu’il prend ne lui sont pas accessibles. Il a été 
débouté, je ne sais pas sur quel motif.

J’espère que ces infos vous seront utiles.

Olivier Nourry
Access First




> Le 11 oct. 2019 à 08:50, CAILLAUD DAVID (CNAM / Nantes) 
>  a écrit :
> 
> Bonjour La liste,
>  
> Les décrets de 2016, 2018 et le dernier de 2019 qui abroge le décret initial 
> de 2009  se réfèrent à une amende administrative pour les sites publics et 
> pour les entreprises privés ayant un chiffre d’affaire de plus de 250 
> millions d’euros.
> Il serait intéressant de savoir le nombre d’amendes administratives qui ont 
> été infligés à des sites publics ces dernières années, ne pensez-vous pas ?
>  
> Je suis sceptique sur le fait qu’une amende administrative puisse inciter les 
> français à porter plainte contre l’administration.
>  
>  
> De : liste_gta [mailto:liste_gta-boun...@list.accessiweb.org 
> <mailto:liste_gta-boun...@list.accessiweb.org>] De la part de Anthony Ladeuil
> Envoyé : jeudi 10 octobre 2019 16:33
> À : liste_gta@list.accessiweb.org <mailto:liste_gta@list.accessiweb.org>
> Objet : Re: [Liste GTA] Un aveugle poursuit Domino's Pizza pour non 
> accessibilité de son site Web (article)
>  
> Bonjour David et la liste.
>  
> Si la question est de cas de poursuites d'un plaignant français contre une 
> entité française, je ne pense pas (ou pas encore…). Par contre, des 
> négociations contre menues monnaies (sic) avant procès éventuel engagées par 
> des cabinet américains contre des sociétés françaises diffusant sur le sol 
> américain, la réponse est oui. En même temps ça tire à tout va, là bas.
>  
> Et ça nous pend au nez en France.
>  
> pour avoir un ordre d'idée : 
> https://www.adatitleiii.com/2019/01/number-of-federal-website-accessibility-lawsuits-nearly-triple-exceeding-2250-in-2018/
>  
> <https://www.adatitleiii.com/2019/01/number-of-federal-website-accessibility-lawsuits-nearly-triple-exceeding-2250-in-2018/>
> 
> 
> Le 10 oct. 2019 à 16:12, CAILLAUD DAVID (CNAM / Nantes) 
>  <mailto:david.caill...@assurance-maladie.fr>> a écrit :
>  
> Bonjour la liste,
>  
> Connaissez-vous des cas de poursuite en France ?
>  
> Cordialement,
>  
> David CAILLAUD
>  
> De : liste_gta [mailto:liste_gta-boun...@list.accessiweb.org 
> <mailto:liste_gta-boun...@list.accessiweb.org>] De la part de CHUZEVILLE Hervé
> Envoyé : mercredi 9 octobre 2019 14:22
> À : liste_gta@list.accessiweb.org <mailto:liste_gta@list.accessiweb.org>
> Objet : [Liste GTA] Un aveugle poursuit Domino's Pizza pour non accessibilité 
> de son site Web (article)
>  
> Bonjour,
> Je vous fai

Re: [Liste GTA] Balise et accessibilité

[Olivier Nourry]

Bonjour Isabelle,

Point 1: en fait s’agissant d’une interface générée par le navigateur, ça sort 
du champ de l’accessibilité des contenus, donc du RGAA. Charge à l’utilisateur 
de sélectionner un navigateur qui fait son job correctement. 
Ceci dit, ce choix est parfois purement théorique, puisque ce n’est pas parce 
qu’un lecteur audio natif est accessible que le navigateur qui l’embarque est 
utilisable pour tous les autres contenus… donc pour atténuer ça, une 
possibilité serait de proposer le fichier audio en téléchargement, auquel cas 
les utilisateurs pourront exploiter leur lecteur audio local, celui qu’ils 
utilisent pour tous leurs fichiers audio.

Point 2: dérogation possible, sans équivoque, en tant que contenu tiers. En 
plus, les contenus en direct vont sortir du champ du RGAA4, le décret 
d’application du 24/07/19 en faisant des exemptions.
Je ne dis pas qu’il ne faut pas le faire, mais on ne peut plus invoquer 
l’obligation légale pour y contraindre l’administration concernée.

Point 3: ça doit sûrement exister, mais je ne saurais pas te renseigner. Il 
faut néanmoins savoir que la fiabilité des procédés purement automatiques est 
encore trop faible pour être utilisables. En général il y a une transcription 
humaine, éventuellement aidée par un logiciel. Dit autrement: pas de solution à 
coût 0…


J’espère que ça t’aidera
Olivier Nourry
Access First 

> Le 20 sept. 2019 à 12:33, Isabelle Moretti  a 
> écrit :
> 
> Bonjour à tous,
> 
> j'aimerais savoir comment se gère la présence d'une balise  dans une 
> page, qui permettrait à l'internaute l'écoute en direct d'une radio. J'ai 
> essayé d'éclaircir les questions que je me pose, il en ressort 3... 
> 
> Merci pour votre patience et vos avis éclairés !
> 
> 1 - Cette balise implique un contenu embarqué, qui fonctionne en utilisant à 
> l'écran les fonctionnalités audio du navigateur de l'internaute (s'il a 
> l'attribut "controls"). Cela semble lui garantir (au vu des tests que je 
> viens de faire... mais peut-être me trompe-je ?) un certain niveau 
> d'accessibilité. 
> Peut-on considérer qu'un lecteur qui utilise  est 
> "raisonnablement" accessible (à l'exception de la transcription textuelle qui 
> n'est pas prise en charge) ?
> 
> 2 - Le critère 4.5 concernant la transcription textuelle peut-il faire 
> l'objet d'une dérogation si le lecteur permet l'écoute en direct d'une radio 
> qui n'est pas celle de l'organisme propriétaire du site, mais d'une structure 
> indépendante ? 
> 
> 3 - Existe-t-il des ressources libres ou des indications de méthode 
> informatique pour permettre la génération de sous-titres automatiques sur un 
> contenu audio en direct, via la balise  ou via une autre méthode ?
> 
> Encore merci pour réponses !
> Bonne journée
> 
> 
> Isabelle Moretti
> 
> 06 99 40 02 06
> www.lesdiodes.fr <http://www.lesdiodes.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] Références récentes ?

[Olivier Nourry]

Bonjour Frédéric,

Si tu cherches des sites récemment labellisés, je crains que tu ne trouves rien 
de plus que ce qui est dans la galerie Accessiweb.
Il y aura une vague de labellisations e-accessible RGAA en fin d’année, mais 
tous ne sont pas forcément prêts à l’heure qu’il est.

Néanmoins je peux te communiquer l’adresse de 2 sites que j’ai accompagnés, et 
qui sont (ou seront dans un court délai) conformes AA:
https://www.communaute-paysbasque.fr/  
https://fresques.ina.fr/jalons/  

Bonne fin de journée
Olivier


> Le 19 sept. 2019 à 12:30, Frédéric Lecourbe  a écrit :
> 
> Bonjour la liste !
> Dans le cadre d'un appel d'offre pour un groupe mutualiste français, 
> j'aimerais leur montrer de belles références de sites accessibles récemment 
> labellisés (comme celui ci par exemple : https://www.sncf.com/fr 
> ). J'ai regardé sur le site Accessiweb (premier 
> réflexe), il y a effectivement quelques références, mais assez peu sont 
> récentes.
> 
> Alors ma question : quelles sont vos meilleures références du moment, en 
> France ou ailleurs ?
> Idéalement Argent et Or, mais sinon Bronze ça irait aussi. 
> 
> Merci d'avance, et une très bonne journée,
> 
> Frédéric Lecourbe
> Designer / Publicis Sapient
> 
> 
> ___
> 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] Audit RGAA - input de recherche sans bouton submit

[Olivier Nourry]

> Le 14 août 2019 à 15:45, Julie BARATCHART  a écrit :
> 
> Est-ce qu'ajouter, dans le aria-label du champ "saisissez votre recherche, 
> puis cliquer sur entrer pour lancer la recherche" rendrait ce composant 
> accessible?

Pour moi ce composant est accessible en l’état. Un excès d’information crée 
plus de problèmes qu’il n’en résout… donc si l’étiquette est déjà pertinente (« 
Recherche » suffit amplement), rien besoin d’ajouter à cela :)
Si tu penses que le fait d’appuyer sur Entrée doit être communiqué aux 
utilisateurs, alors il serait plus pertinent de le faire via l’attribut title, 
qui a au moins une chance d’être perçu par des utilisateurs qui naviguent sans 
une techno d’assistance qui restitue aria-label.

Bon courage pour la suite de l’audit!
Olivier___
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org

Re: [Liste GTA] Audit RGAA - input de recherche sans bouton submit

[Olivier Nourry]

Bonjour,
Pour ma part il me semble que c’est Conforme pour le 7.4 ici, puisqu’il n’y a 
pas de changement de contexte sans action de l’utilisateur. Si le champ est 
correctement identifiable (étiquette visible, ou fonction visuellement 
reconnaissable si l’étiquette est invisible), ce qui se passe à la validation 
avec la touche Entrée est parfaitement prévisible pour les utilisateurs.

Note: la technique H32 est suffisante pour le critère WCAG 3.2.2, mais cela ne 
signifie pas qu’elle soit obligatoire pour qu’il soit satisfait, comme précisé 
dans les WCAG: d’autres techniques peuvent permettre de le satisfaire 
également. Pour moi c’est le cas ici puisqu’on doit valider avec la touche 
Entrée pour changer de contexte.

On pourrait objecter que la validation devrait pouvoir se faire à la souris, 
mais si on considère qu’il s’agit d’un champ de saisie, alors, pour utiliser ce 
champ, l’utilisateur aura forcément utilisé un dispositif de saisie de 
caractères comme un clavier (physique ou virtuel), un logiciel de saisie 
vocale, ou autre, qui permettent aussi de déclencher la soumission y compris 
avec un pointeur type souris ou tactile ou vocal.

En soi je ne vois pas de raison d’invalider cette pratique pour des raisons 
d’accessibilité — même si on est d’accord que sur le plan ergonomique c’est pas 
idéal.

J’espère avoir apporté des infos utiles.

Bonne journée,
Olivier Nourry
Access First <https://access-first.fr/>

> Le 14 août 2019 à 14:12, Alex Bernier  a écrit :
> 
> Bonjour Julie,
> 
> Oui c'est bien le 7.4 sur les changements de contexte qui est NC dans ce cas. 
> Tu fais référence à la bonne technique, H32 "Providing submit buttons", qui 
> est bien listée dans celles associées à ce critère 7.4 dans le RGAA.
> 
> (Et effectivement, pas le 11.9 parce que comme tu le dis, le bouton n'existe 
> pas, donc impossible d'évaluer sa pertinence)
> 
> Alex
> 
> On Wed, Aug 14, 2019 at 11:06:35AM +, Julie BARATCHART wrote:
>>   Bonjour la liste,
>> 
>> 
>>   Je suis en train d’auditer un site qui propose dans le bandeau
>>   d’entête, un input de recherche mais sans bouton d’envoi..
>> 
>>   La recherche se lance avec la touche « enter » du clavier..
>> 
>> 
>>   Que je sache, il n’y a pas de critères RGAA qui rend obligatoire
>>   explicitement la présence d’un bouton input ?
>> 
>>   Seul le W3C indique de fournir des boutons d’envoi..
>>   [1]https://www.w3.org/TR/WCAG-TECHS/H32
>> 
>>   Et surtout, je ne sais pas quel critère invalider :
>> * le critères 11.9 sur l’intitulé du bouton qui n’existe pas?
>> * le critère 7.4 sur le changement de contexte ?
>> 
>> 
>>   Je vous remercie par avance pour vos lumières !
>> 
>> 
>>   Cordialement,
>> 
>> 
>>   Julie BARATCHART
>> 
>>   UCANSS - DSI
>> 
>> Références
>> 
>>   1. https://www.w3.org/TR/WCAG-TECHS/H32
> 
>> ___
>> 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] Audit RGAA - Critères 7.4 et 12.13

[Olivier Nourry]

Bonjour Corinne,

Tes questions ne sont pas du tout « bas niveau » :) [sourire].

La modale pourrait être considérée  comme un changement de contexte, mais
ça n’a pas d’autre conséquences  que d’imposer un nom pertinent pour le
contrôle qui permet de l’ouvrir, et d’empêcher de l’ ouvrir sans action
utilisateur, sauf cas particulier tel qu’une alerte de sécurité.
Normalement au niveau du critère 7.1 tu auras déjà traité cette modale en
termes de respect du design pattern Dialog, donc si la modale est conforme,
les utilisateurs ont les moyens de comprendre le changement et la raison
pour laquelle le focus en est prisonnier.

Pour le menu déroulant: tu peux laisser le menu en fin de code si le focus
est contrôlé en JS de manière à ce que la tabulation permette d’y circuler
comme s’il était à la suite. Pour les utilisateurs c’est transparent. À
voir si c’est avantageux par rapport à une modification du HTML. Et éviter
de jouer sur tabindex > 0, c’est la porte ouverte aux problèmes...
Pour ce type de widget ça peut être intéressant de regarder le design
pattern Menu Button (qui est assez simple si on évacue tout ce qui ne le
concerne pas dans le DP Menu). Par contre la navigation clavier repose sur
les flèches, ce qui n’est pas forcément intuitif pour les utilisateurs sans
technologies d’assistance prenant en charge ce pattern.

J’espère t’avoir aidée. Et bon courage pour l’audit !
Olivier

Le lun. 27 mai 2019 à 22:48, Corinne Schillinger  a
écrit :

> Bonsoir à tous,
>
> Je me suis en train de réaliser un audit et je m’interroge sur 2 critères
> et les correctifs à appliquer.
> (voilà quelques temps que je n’ai pas réalisé d’audit, aussi je m’excuse
> d’avance si mes questions vous semblent « bas niveau » : je suis un peu
> rouillée).
>
> Critère 7.4 [A] Pour chaque script
> <http://references.modernisation.gouv.fr/rgaa/glossaire.html#script> qui
> initie un changement de contexte
> <http://references.modernisation.gouv.fr/rgaa/glossaire.html#changement-de-contexte>,
> l'utilisateur est-il averti ou en a-t-il le contrôle ?
> J’avoue que j’ai un peu de mal à voir si l’ouverture d’une modale
> correspond à un changement de contexte ou pas. :o'
> J’aurais tendance à penser que oui, car lorsque je tabule j’accède bien
> aux éléments de la modale, mais j’ai comme un doute.
>
> Critère 12.13 [A] Dans chaque page web, l'ordre de tabulation
> <http://references.modernisation.gouv.fr/rgaa/glossaire.html#ordre-de-tabulation>
> est-il cohérent
> <http://references.modernisation.gouv.fr/rgaa/glossaire.html#comprhensible-ordre-de-lecture>
>  ?
> Sur la page auditée, j’ai un menu drop-down qui permet de changer la
> langue de la page (FR / EN / DE).
> Or dans le code HTML, le contenu de la liste ne se trouve pas
> immédiatement après le bouton qui permet de l’afficher : elle est reléguée
> en fin de contenu avec les fenêtres modales.
> De fait, l’ordre de tabulation n’est pas respecté. De prime abord,
> j’aurais tendance à recommander de déplacer la liste juste après le bouton
> d’action, mais je voulais juste vérifier un point avec vous : existe-t-il
> un autre correctif qui permettrait de valider ce critère simplement ?
>
> Je vous remercie d’avance pour vos réponses et vous souhaite une
> excellente journée,
> Corinne
>
>
> —
> Mail : cori...@inseo.fr
> Téléphone : 03 88 74 72 37
> Site internet : http://www.inseo.fr
>
>
>
> _______
> liste_gta mailing list
> liste_gta@list.accessiweb.org
> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>
-- 



[image: --]
Olivier Nourry
[image: 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

Re: [Liste GTA] astérisque et formulaire, cas particulier

[Olivier Nourry]

Si j’ai pu t’aider par ce message ET avec l’article alors je suis doublement 
ravi! 

> Le 18 janv. 2019 à 14:24, Bulle Cube  a écrit :
> 
> Merci Olivier, ça me donne pas mal de billes et je pense que l'équipe design 
> sera satisfaite avec ces compromis.
> 
> C'est marrant que ce soit toi qui réponde, je venais juste de (re)lire ton 
> article sur le validisme chez 24jours, histoire d'appuyer mon argumentaire =)
> 
> Le ven. 18 janv. 2019 à 12:32, Olivier Nourry  <mailto:olv.nou...@gmail.com>> a écrit :
> Bonjour,
> Du moment que pour tout utilisateur les champs obligatoires sont 
> identifiables sans ambiguïté, pour moi l’exigence est satisfaite.
> Il faudra s’assurer que la mention est bien associée programmatiquement aux 
> fieldsets concernés, et aux champs quand certains ne sont pas obligatoires.
> 
> Ça peut être fait via l’élément LEGEND (il comporte une mention de type « 
> tous les champs sont obligatoires » quand c’est le cas) combiné avec des 
> mentions similaires pour les labels des champs concernés pour les autres. Ce 
> n’est pas idéal en termes de confort car la mention sera répétée à chaque 
> fois, mais au moins l’info est disponible et correctement associée.
> 
> On peut aussi étudier l’option aria-describedby qui a vocation à faire cela, 
> mais il faudrait tester la restitution sur la base de référence dans le cas 
> de fieldset, notamment pour vérifier que c’est bien compréhensible, et s’il 
> vaut mieux l’affecter au fieldset ou au legend. Par ailleurs il faudra 
> conserver une indication visuelle, qui peut être une astérisque sur les 
> legend et les champs ad hoc, avec un paragraphe explicatif en tête de 
> formulaire.
> 
> Autre possibilité: un paragraphe en tête de formulaire avec « Tous les champs 
> sont obligatoires sauf… » en reprenant bien l’étiquette des champs concernés.
> 
> J’espère avoir aidé!
> 
> Cordialement,
> Olivier Nourry
> Access First
> 
> > Le 18 janv. 2019 à 12:15, Bulle Cube  > <mailto:bullec...@gmail.com>> a écrit :
> > 
> > Bonjour tout le monde,
> > 
> > J'ai le cas d'un gros formulaire qui contient plusieurs fieldset où tous 
> > les champs sont obligatoires… sauf 1 ou 2
> > 
> > L'équipe en charge du design rechigne à mettre des * rouge partout, alors 
> > je me demande s'il existe une alternative viable ?
> > Eux proposent de mettre une mention à coté de chaque fieldset qui ne 
> > contiennent que des champs obligatoire ce qui diminuerait l'effet varicelle.
> > 
> > Est-ce que cette solution semble opérable ?
> > ___
> > 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 
> > <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 
> <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] astérisque et formulaire, cas particulier

[Olivier Nourry]

Bonjour,
Du moment que pour tout utilisateur les champs obligatoires sont identifiables 
sans ambiguïté, pour moi l’exigence est satisfaite.
Il faudra s’assurer que la mention est bien associée programmatiquement aux 
fieldsets concernés, et aux champs quand certains ne sont pas obligatoires.

Ça peut être fait via l’élément LEGEND (il comporte une mention de type « tous 
les champs sont obligatoires » quand c’est le cas) combiné avec des mentions 
similaires pour les labels des champs concernés pour les autres. Ce n’est pas 
idéal en termes de confort car la mention sera répétée à chaque fois, mais au 
moins l’info est disponible et correctement associée.

On peut aussi étudier l’option aria-describedby qui a vocation à faire cela, 
mais il faudrait tester la restitution sur la base de référence dans le cas de 
fieldset, notamment pour vérifier que c’est bien compréhensible, et s’il vaut 
mieux l’affecter au fieldset ou au legend. Par ailleurs il faudra conserver une 
indication visuelle, qui peut être une astérisque sur les legend et les champs 
ad hoc, avec un paragraphe explicatif en tête de formulaire.

Autre possibilité: un paragraphe en tête de formulaire avec « Tous les champs 
sont obligatoires sauf… » en reprenant bien l’étiquette des champs concernés.

J’espère avoir aidé!

Cordialement,
Olivier Nourry
Access First

> Le 18 janv. 2019 à 12:15, Bulle Cube  a écrit :
> 
> Bonjour tout le monde,
> 
> J'ai le cas d'un gros formulaire qui contient plusieurs fieldset où tous les 
> champs sont obligatoires… sauf 1 ou 2
> 
> L'équipe en charge du design rechigne à mettre des * rouge partout, alors je 
> me demande s'il existe une alternative viable ?
> Eux proposent de mettre une mention à coté de chaque fieldset qui ne 
> contiennent que des champs obligatoire ce qui diminuerait l'effet varicelle.
> 
> Est-ce que cette solution semble opérable ?
> ___
> 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] liste non ordonnée vs liste de définition

[Olivier Nourry]

Je ne crois pas, personnellement, que nous soyons des emmerdeurs (c’est pas mon 
kiff de jouer ce rôle, hein). Mais c’est bien souvent comme ça qu’on nous 
perçoit ou qu’on nous présente. Ici, par contre, pas besoin de connaître le 
contexte de restitution pour comprendre que la personne qui a fait cette 
demande crée des problèmes là où il n’y en a pas.
Désolé si je ne prends pas ça à la légère… Mais ce qui s’est passé lors de cet 
audit est très alarmant, en fait. Il accrédite l’idée que l’access c’est 
compliqué, que ça sert à rien, que c’est fait pour emmerder le monde… et sur ce 
coup-là je dois donner raison à ces critiques. Sauf que ce n’est pas 
l’accessibilité le problème, mais bien une interprétation des exigences 
totalement  à l’ouest. 

C’est très compliqué quand on passe derrière des gens comme ça, car on est 
obligé d’expliquer que les gens ont bossé pour rien. Tu réalises le niveau de 
frustration que cela peut engendrer? Il y a déjà bien assez à faire comme ça. 
Et peu importe le niveau du reste. Je dirais même que plus le niveau général 
est bas, moins il faut se montrer pointilleux, et concentrer les efforts sur 
les points réellement problématiques.
Faire les tests d’un audit c’est franchement pas le plus compliqué. C’est bien 
ce qu’on en fait qui l’est. Elle est là, la véritable valeur ajoutée (et la 
responsabilité) de l’expert.
A ce sujet je recommande chaudement à tous la lecture de ce guide de l’auditeur 
<https://disic.github.io/guide-auditeur/>, c’est bourré de choses que l’on 
n’apprend pas en formation EAE, mais qui sont essentielles pour faire ce 
métier. 

Olivier



> Le 11 déc. 2018 à 20:13, Anthony Ladeuil  a écrit :
> 
> Bonsoir Olivier,
> 
> Sur le fond, nous sommes d'accord. Coûts, temps, nécessité ou pas.
> Et non, nous ne sommes pas des emmerdeurs (quoi que, des fois...). Au delà de 
> l'audit en lui-même, dont nous n'avons pas de restitution quand à sa 
> formulation sur ce point précis, quelles ont été les mesures prises en amont 
> du développement ? Je pense sincèrement que si lors d'un audit on sent que 
> l'accessibilité a été le parent pauvre, n'importe qui peut devenir 
> pointilleux à outrance, quitte à commettre des impairs (sans supposer que ce 
> soit le cas pour les sites de Giuseppe ni pour l'auditeur). 
> Mon précédent message avait pour but de mettre un peu de légèreté...
> 
>> Le 11 déc. 2018 à 19:51, Olivier Nourry > <mailto:olv.nou...@gmail.com>> a écrit :
>> 
>> Bonjour Anthony,
>> L’enjeu d’un audit accessibilité, AMHA, n’est pas de viser un code optimal, 
>> mais de vérifier que tout fonctionne. Faire modifier du code qui fonctionne 
>> pour le remplacer par de code qui fait exactement la même chose pour 
>> l’utilisateur, c’est de la surqualité. Peu importe la pertinence visuelle ou 
>> le caractère sympa à mettre en forme, ce n’est pas notre mission sur un 
>> audit. Celui qui a fait cette demande a outrepassé ici sa responsabilité 
>> pour s’aventurer sur des terrains hasardeux, faisant abstraction des 
>> contraintes d’implémentation, qui sont pourtant un aspect essentiel du 
>> dialogue auditeur/équipe. Les conséquences pour le projet ne sont pas 
>> neutres: on va dépenser du temps de dév, de tests, de modification des 
>> règles de codage, voire parfois des gabarits, des contenus et du CMS pour… 
>> rien, en fait. C’est là le problème. Pendant ce temps on ne corrige pas des 
>> anomalies réelles et impactantes.
>> 
>> Qu’on s’entende bien: en phase de specs j’aurais pu proposer cette structure 
>> parce qu’elle peut effectivement avoir des avantages, et qu’à ce stade ça ne 
>> coûte rien de plus (pour ça sans doute que sur l’exemple du WAI ils se sont 
>> fait plaisir, sur du code statique. Note cependant que ça n’a pas grand 
>> chose à voir avec le cas décrit par Giuseppe). Et j’aurais allègrement 
>> laissé filer si on m’avait signalé la moindre difficulté d'implémentation. 
>> Mais on ne doit pas demander de corriger (et même on s’abstient de relever) 
>> un point qui ne pose pas de problème. C’est une faute, sur un audit.
>> 
>> On nous (les experts accessibilité) reproche suffisamment d’emmerder le 
>> monde avec nos règles auxquels personne ne comprend rien, pour que nous ne 
>> chargions pas la barque davantage. C’est à cause de ce type de comportement 
>> que nous nous faisons traiter de dogmatiques (et de menteurs) dans des 
>> articles de vulgarisation destinés aux professionnels du Web. Et 
>> franchement, y a pas besoin.
>> 
>> Olivier Nourry
>> 
>>> Le 11 déc. 2018 à 19:28, Anthony Ladeuil >> <mailto:anth...@ladeuil.com>> a écrit :
>>> 
>>> Bonjour Giuseppe et la liste,
>>> 
>>> Le grand déb

Re: [Liste GTA] liste non ordonnée vs liste de définition

[Olivier Nourry]

Bonjour Anthony,
L’enjeu d’un audit accessibilité, AMHA, n’est pas de viser un code optimal, 
mais de vérifier que tout fonctionne. Faire modifier du code qui fonctionne 
pour le remplacer par de code qui fait exactement la même chose pour 
l’utilisateur, c’est de la surqualité. Peu importe la pertinence visuelle ou le 
caractère sympa à mettre en forme, ce n’est pas notre mission sur un audit. 
Celui qui a fait cette demande a outrepassé ici sa responsabilité pour 
s’aventurer sur des terrains hasardeux, faisant abstraction des contraintes 
d’implémentation, qui sont pourtant un aspect essentiel du dialogue 
auditeur/équipe. Les conséquences pour le projet ne sont pas neutres: on va 
dépenser du temps de dév, de tests, de modification des règles de codage, voire 
parfois des gabarits, des contenus et du CMS pour… rien, en fait. C’est là le 
problème. Pendant ce temps on ne corrige pas des anomalies réelles et 
impactantes.

Qu’on s’entende bien: en phase de specs j’aurais pu proposer cette structure 
parce qu’elle peut effectivement avoir des avantages, et qu’à ce stade ça ne 
coûte rien de plus (pour ça sans doute que sur l’exemple du WAI ils se sont 
fait plaisir, sur du code statique. Note cependant que ça n’a pas grand chose à 
voir avec le cas décrit par Giuseppe). Et j’aurais allègrement laissé filer si 
on m’avait signalé la moindre difficulté d'implémentation. Mais on ne doit pas 
demander de corriger (et même on s’abstient de relever) un point qui ne pose 
pas de problème. C’est une faute, sur un audit.

On nous (les experts accessibilité) reproche suffisamment d’emmerder le monde 
avec nos règles auxquels personne ne comprend rien, pour que nous ne chargions 
pas la barque davantage. C’est à cause de ce type de comportement que nous nous 
faisons traiter de dogmatiques (et de menteurs) dans des articles de 
vulgarisation destinés aux professionnels du Web. Et franchement, y a pas 
besoin.

Olivier Nourry

> Le 11 déc. 2018 à 19:28, Anthony Ladeuil  a écrit :
> 
> Bonjour Giuseppe et la liste,
> 
> Le grand débat sur les ... :-)
> 
> Pour ma part, je suis en accord avec le propos modéré de Sébastien.
> Ce type de liste me parait appropriée dans ce contexte, c'est d'ailleurs ce 
> que j'aurais implémenté avant un . En premier lieu, pour l'association 
> 'titre' > 'description', en second lieu parce que côté design c'est assez 
> sympa à mettre en forme. Mais c'est un détail. Ou pas.
> On peut voir une utilisation des 'dl' sur 
> https://www.w3.org/TR/wai-aria-practices-1.1/examples/accordion/accordion.html
>  
> <https://www.w3.org/TR/wai-aria-practices-1.1/examples/accordion/accordion.html>,
>  site qui, a priori, maîtrise son sujet. Au même titre que l'auditeur, 
> apparemment.
> 
> La notion d'inutilité levée par Jean-Pierre me trouble : tout dépend des 
> moyens (financiers, ressources, temps) disponibles pour prendre en compte le 
> conseil de l'auditeur et du niveau de qualité que l'on souhaite atteindre. 
> Même si, en l'occurence, un 'ul' fait le job bien sur. Tout comme un semi 
> remorque fait le job pour aller à la plage, mais en voiture c'est sympa 
> aussi. ^^ Et est-ce que l'auditeur a clairement exprimé qu'à défaut de liste 
> de description les utilisateurs seraient dans l'incapacité de comprendre le 
> récapitulatif ? Il ne s'agit peut être que d'un conseil.
> 
> Pour ce qui est de l'apport à l'utilisateur, visuellement il peut y en avoir 
> un, ne serait-ce que par la mise en forme visuelle. 
> A priori, le temps de mise en oeuvre ne serait pas non plus rédhibitoire.
> 
> Bien à vous.
> 
> 
>   Prénom
>   Anthony
>   NOM
>   Ladeuil
> 
> 
> 
>> Le 11 déc. 2018 à 17:57, Jean-Pierre Villain > <mailto:jpvill...@access42.net>> a écrit :
>> 
>> Bonjour,
>> 
>> De mon point de vue la recommandation est inutile et abusive.
>> 
>> Inutile parce que la liste UL fait très bien le job.
>> 
>> Abusive parce qu'elle demande un surcroit de travail qui ne sert strictement 
>> à rien.
>> 
>> Mon conseil :
>> 
>> Exiger de l'auditeur qu'il apporte la preuve que, faute d'utiliser des DL, 
>> des utilisateurs seraient dans l'incapacité de comprendre le récapitulatif.
>> Comme l'auditeur sera incapable d'apporter cette preuve, refuser la Non 
>> conformité
>> Ne rien changer à l'implémentation a actuelle
>> Envisager sérieusement de changer d'auditeur qui, à l'évidence, ne maitrise 
>> pas son sujet.
>> Néanmoins si vous le faite ça n'aura aucune conséquence sur l'utilisateur ça 
>> vous aura juste fait perdre du temps.
>> Et je ne suis pas d'accord que dans l'idéal la liste de description serait 
>> appropriée dans un contexte de cette nature.
>> 
>> L'apport pour l'ut

Re: [Liste GTA] Vue js

[Olivier Nourry]

Bonjour Claire,

Pour la Web Developer toolbar, spécifiquement, il faudrait vérifier pour chaque 
fonctionnalité ce qui est analysé, notamment lorsque le DOM est mis à jour par 
un script durant l’inspection. Mais pour les « developer tools » intégrés aux 
navigateurs (que ce soit Firefox, Chrome, Safari, ou Edge), le code inspecté 
est celui qui est généré en temps réel, par défaut. Avec les outils actuels je 
pense même qu’il est plus difficile d’accéder au code source qu’au code généré 
;-) [clin d’oeil]
Donc aucun souci pour auditer du contenu généré en JS.
Ton interrogation tient peut-être au fait que par le passé les outils 
d’inspection (automatiques notamment) analysaient le code source, et non le 
code vu du client après application des transformations par CSS et JS. Or les 
technologies d’assistance d’aujourd’hui s’appuient sur le code généré et 
détectent les modifications du DOM qui sont répercutées sur l’accessibility 
tree. Les outils d’inspection du code source n’ont donc quasiment plus aucun 
intérêt pour auditer l’accessibilité.


J'espère avoir répondu à ta question.
J’en profite aussi pour signaler l’étude de l’accessibilité de bibliothèques JS 
publiée par la DINSIC: 
https://disic.github.io/rgaa_bibliotheques-javascript/tutoriels/index.html  
<https://disic.github.io/rgaa_bibliotheques-javascript/tutoriels/index.html>

Bonne fin de journée
Olivier Nourry
Access First

> Le 25 sept. 2018 à 11:05, DAVAL Claire  a 
> écrit :
> 
> Re bonjour à tous,
>  
> Merci pour vos réponses
> Alors, après avoir un peu exploré la bibliothèque, il semble que l’on soit 
> libre de mettre n’importe quelle structure HTML.
> Donc si je résume, cela signifie que c’est grosso modo la même problématique 
> que pour un site « classique », mais c’est plus compliqué à analyser parce 
> qu’il faut se baser sur le code généré et donc on ne bénéficie pas de l’aide 
> des outils de type web developper toolbar.
> Vous êtes d’accord avec ça ?
>  
> Claire DAVAL
> Tel : +33 (0)4 76 44 50 50
> EOLAS, groupe Business & Decision 
> <https://www.eolas.fr/?utm_source=BasDeMail_campaign=BasDeMail_medium=email>
>  
> Services en ligne managés 24/7 - e-commerce, e-administration, e-business
> 
>  
> <https://www.eolas.fr/?utm_source=BasDeMail_campaign=BasDeMail2017_medium=email>
>   <https://twitter.com/BD_eolas>  
> <https://www.linkedin.com/company/business-&-decision-eolas/> 
> 
> 
>  <https://www.facebook.com/BDEolas/>
>  
> De : liste_gta [mailto:liste_gta-boun...@list.accessiweb.org 
> <mailto:liste_gta-boun...@list.accessiweb.org>] De la part de Nicolas Bocquet
> Envoyé : lundi 24 septembre 2018 16:45
> À : liste_gta@list.accessiweb.org <mailto:liste_gta@list.accessiweb.org>
> Objet : Re: [Liste GTA] Vue js
>  
> Bonjour Claire,
>  
> Un développement Javascript utilisant des bibliothèques de type ReactJS, 
> Angular et VueJS, peut tout à fait être compatible RGAA à condition de 
> respecter le référentiel ainsi que les recommandations des experts en 
> accessibilité. Cela nécessite parfois de ne pas suivre certaines 
> recommandations officielles de ces bibliothèques et d’adopter une approche de 
> développement plus orientée en faveur de l’accessibilité, mais ce dernier 
> point vaut aussi pour du Javascript natif.
> 
> A noter que reactJS proposait l’année dernière des composants dont certains 
> présentaient des lacunes en matière d’accessibilité. J’avoue ne pas avoir 
> vérifié depuis un moment, peut-être que certains collègues pourront être plus 
> précis que moi, mais dans tous les cas de figure je vous recommande 
> chaudement de procéder à une vérification avant d’utiliser tout composant 
> pré-développé.
>  
> cdt
>  
> ---
> Nicolas Bocquet
> Intégrateur web, Expert accessibilité et Web ergonome
> Web : http://www.nicolasbocquet.fr <http://www.nicolasbocquet.fr/>
> Tel : 09 52 68 90 03
>  
> De : DAVAL Claire <mailto:claire.da...@businessdecision.com>
> Envoyé le :lundi 24 septembre 2018 14:50
> À : liste_gta@list.accessiweb.org <mailto:liste_gta@list.accessiweb.org>
> Objet :[Liste GTA] Vue js
>  
> Bonjour la liste,
>  
> Que pensez-vous de l'usage des technologies FrontEnd en full JS type Vue.js 
> et leurs comptabilité avec le RGAA.
> Nous posons la question de l’utiliser pour mettre en place un espace client 
> pour un service public.
> Nous avons fait quelques tests avec des lecteurs d’écran, la restitution 
> semble correcte à première vue.
>  
> Mais dans la mesure ou le code source n’est pas visible directement sur le 
> navigateur, je me demande dans quelle mesure il est possible d’évaluer une 
> compatibilité RGAA ?
> Faut-il forcément bannir ce type de technologie comme flash à une époque un 

Re: [Liste GTA] WCAG 2.1 et mise à jour du RGAA

[Olivier Nourry]

Bonjour Steven,

Pas d’info officielle à fournir, mais plutôt mon opinion sur la question.

Les mises à jour du RGAA sont pilotées par la DINSIC qui jusqu’à présent s’est 
appuyée sur un groupement de prestataires, dont j’ai fait partie. Le marché 
permettant à la DINSIC de sous-traiter cette tâche a pris fin il y a un an. Un 
appel d’offres a été émis pour renouvellement, et cloturé en avril. On attend 
la notification d’attribution.
Donc 0 chance qu’il y ait une maj du RGAA en juin. En revanche, en prévision de 
la transposition de la directive européenne sur l’accessibilité, via décret 
et/ou arrêté, il pourrait y avoir une évolution à la rentrée. Mais pas 
nécessairement sur la partie technique, plutôt sur le guide d’accompagnement, 
afin d’y intégrer ces nouvelles dispositions (info obtenue suite à une réunion 
de présentation à la DINSIC avec des professionnels représentatifs du marché 
des prestations a11y).

Concernant l’adoption de WCAG 2.1: en fait, l’un des aspects nouveaux de la 
directive européenne est qu’on ne se réfèrera plus aux « normes internationales 
» mais à des normes européennes. Pour le moment elles sont un copié-collé des 
WCAG 2.0. Rien ne permet de prédire si WCAG 2.1 sera un jour intégré à ces 
normes européennes, ou si la CE prendra une autre orientation: création d’une 
norme ex nihilo (très peu probable), maintien de WCAG 2.0, évolution de WCAG 
2.0,  attente de WCAG 3.0…. tout est ouvert à ce stade.

J’espère avoir répondu à ta question.
Olivier Nourry


> Le 11 juin 2018 à 16:13, Steven Mouret  a écrit :
> 
> 
> Bonjour à tous,
> 
> Quelqu'un a t-il des infos sur la date de la mise à jour du RGAA par rapport 
> à WCAG 2.1. Généralement il y a une mise à jour annuelle en juin pour le 
> RGAA, j'imagine qu'elle va être décalée.
> 
> Merci pour vos infos.
> 
> --
> Steven Mouret
> ___
> 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] Burger Menu et accessibilité

[Olivier Nourry]

Ah ok, je n’avais pas compris ta demande.
Mieux vaut avoir du texte dans le HTML, c’est le plus robuste; quitte à le 
rajouter à la volée en JS (bien s’assurer de réduire au minimum le délai entre 
le moment où le DOM est dispo et celui où le texte est inséré).
Les contenus générés en CSS, via par exemple :before et :after, commencent à 
être lus par les lecteurs d’écran, mais ce n’est pas une généralité. Maintenant 
si tu as un aria-label ou équivalent, il y aura quoiqu’il arrive un libellé de 
bouton disponible pour les lecteurs d’écran, donc ça peut se tenter. Ma crainte 
étant qu’il y ait une possible double restitution: normalement le aria-label 
est restitué à la place du contenu textuel ou du title du bouton, mais je ne 
sais pas si ça inclut les éventuels contenus de :after et :before… c’est à 
tester en tous cas!

> Le 25 janv. 2018 à 14:08, Antoine Bouet Access 
> <antoine.bouet.acc...@gmail.com> a écrit :
> 
> Merci Olivier pour les liens.
> 
> Si j'ai bien compris, le "cache cache css" sert à masquer le libellé du lien.
> Personnellement, je connais beaucoup de personnes qui ne comprennent pas cet 
> icône aux trois traits de menu burger (et certains articles sur le web 
> confirment cela).
> Donc je voulais le mot "MENU" y soit accolé, afin que tout le monde le voit 
> et comprenne à quoi cela sert.
> Mais ma question était de savoir si du CSS ou un ajout en JS restait tout de 
> même accessible (même si je ne suis pas fan du remplacement JS).
> 
> Vu ta réponse, ca a l'air d'être quand même le cas :)
> 
> 
>  
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> Garanti sans virus. www.avast.com 
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>  
> 
> Le 25 janvier 2018 à 12:27, Olivier Nourry <olv.nou...@gmail.com 
> <mailto:olv.nou...@gmail.com>> a écrit :
> Bonjour Antoine,
> 
> J’aurais tendance à dire que dans l’absolu, le mieux est de partir d’un 
> véritable bouton (Menu), dont tu peux masquer le 
> libellé de manière à ce qu’il soit perceptible par les lecteurs d’écran. Pour 
> cela tu peux utiliser la classe CSS détaillée ici: 
> www.ffoodd.fr/cache-cache-css/ <http://www.ffoodd.fr/cache-cache-css/> 
> Ça donnerait Menu
> 
> Si c’est difficile de modifier le code HTML directement, tu as toujours la 
> possibilité de faire un remplacement à la volée en JS.
> 
> Un article très intéressant et très complet sur les différents types de 
> boutons menus (en anglais): 
> https://inclusive-components.design/menus-menu-buttons/ 
> <https://inclusive-components.design/menus-menu-buttons/>
> 
> Je ne sais pas si j’ai répondu à ta demande?
> 
> 
>> Le 24 janv. 2018 à 12:22, Antoine Bouet Access 
>> <antoine.bouet.acc...@gmail.com <mailto:antoine.bouet.acc...@gmail.com>> a 
>> écrit :
>> 
>> Bonjour la liste
>> 
>> Je m'attaque à un sujet qui fâche, le Burger Menu (de la Mort).
>> Déjà pas convaincu à la base par le concept, je dois néanmoins faire avec 
>> sur un site et je souhaiterai le rendre accessible.
>> 
>> Pour le moment, c'est juste un lien vide (!) avec une classe CSS et un 
>> aria-label, sûrement là comme cache misère...
>> Je souhaiterai ajouter (au minimum) un libellé ("MENU" irait bien), ce qui 
>> rendrait service à tout le monde.
>> 
>> Mais d'un point de vue technique, quel est la meilleure manière de procéder ?
>> 
>> - Javascript qui ajoute le texte avec un CSS le rendant "joli" ?
>> - Solution Full CSS en jouant sur les "after" ou "before" ?
>> - Directement modifier la génération du code HTML (mais là, ce sera plus 
>> compliqué malheureusement...)
>> 
>> Est-ce que quelqu'un a déjà planché sur le sujet ?
>> 
>> Merci d'avance et bon appétit pour cette pause de midi !
>> 
>>  
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>>Garanti sans virus. www.avast.com 
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>>  <>___
>> 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 
>> <http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org>
> 
> 
> ___
> liste_gta mailing list
> liste_gta@list.accessiweb.org <mailto:liste_gta@lis

Re: [Liste GTA] Burger Menu et accessibilité

[Olivier Nourry]

Bonjour Antoine,

J’aurais tendance à dire que dans l’absolu, le mieux est de partir d’un 
véritable bouton (Menu), dont tu peux masquer le 
libellé de manière à ce qu’il soit perceptible par les lecteurs d’écran. Pour 
cela tu peux utiliser la classe CSS détaillée ici: 
www.ffoodd.fr/cache-cache-css/  
Ça donnerait Menu

Si c’est difficile de modifier le code HTML directement, tu as toujours la 
possibilité de faire un remplacement à la volée en JS.

Un article très intéressant et très complet sur les différents types de boutons 
menus (en anglais): https://inclusive-components.design/menus-menu-buttons/ 


Je ne sais pas si j’ai répondu à ta demande?


> Le 24 janv. 2018 à 12:22, Antoine Bouet Access 
>  a écrit :
> 
> Bonjour la liste
> 
> Je m'attaque à un sujet qui fâche, le Burger Menu (de la Mort).
> Déjà pas convaincu à la base par le concept, je dois néanmoins faire avec sur 
> un site et je souhaiterai le rendre accessible.
> 
> Pour le moment, c'est juste un lien vide (!) avec une classe CSS et un 
> aria-label, sûrement là comme cache misère...
> Je souhaiterai ajouter (au minimum) un libellé ("MENU" irait bien), ce qui 
> rendrait service à tout le monde.
> 
> Mais d'un point de vue technique, quel est la meilleure manière de procéder ?
> 
> - Javascript qui ajoute le texte avec un CSS le rendant "joli" ?
> - Solution Full CSS en jouant sur les "after" ou "before" ?
> - Directement modifier la génération du code HTML (mais là, ce sera plus 
> compliqué malheureusement...)
> 
> Est-ce que quelqu'un a déjà planché sur le sujet ?
> 
> Merci d'avance et bon appétit pour cette pause de midi !
> 
>  
> 
> Garanti sans virus. www.avast.com 
> 
>  
> ___
> 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] H1 multiples

[Olivier Nourry]

Bonjour Antoine,
Il n’est pas interdit d’avoir plusieurs H1 dans la même page, du moment que 
c’est justifié.
En effet, un H1 est sensé titrer un document. Si tu as plusieurs documents dans 
la même page (par exemple: une page portail qui affiche différents contenus 
provenant de différents sites), tu devras normalement avoir un H1 par document.
Dans le cas que tu indiques, ça ne paraît pas justifié d’un point de vue 
accessibilité. D’ailleurs, quel est le alt du logo? Je doute qu’il y ait un 
bénéfice utilisateur à en faire un H1.
Pour le SEO: je ne suis pas un spécialiste, loin de là. Mais la logique me fait 
dire que plus on a de termes en H1, plus on « dilue » leur importance relative. 
Les contenus du H1 sur le logo ont-ils réellement besoin d’être indexés avec un 
poids élevé? Est-ce qu’on ne les retrouve pas déjà dans la balise title ou 
l’URL?
J’avais eu un échange avec un spécialiste SEO, il y a quelques années, qui 
disait que le SEO in-page n’était pas aussi important que les liens entrants et 
autres techniques pour conduire le trafic vers le site, et qu’il valait mieux 
laisser faire les gens de l’access pour ce qui concerne les contenus. Venant de 
quelqu’un dont c’est la spécialité, j’aurais tendance à penser que c’est la 
bonne approche…

Cordialement,
Olivier Nourry

> Le 6 déc. 2017 à 18:09, Antoine Bouet Access <antoine.bouet.acc...@gmail.com> 
> a écrit :
> 
> Bonjour la liste !
> 
> J'ai une question qui va peut-être relancer le débat entre "pro-access" et 
> "pro-seo" (même si je pense savoir de quel côté vous êtes).
> 
> Je dois intervenir sur un site qui possède deux , sur la page d’accueil 
> comme sur les autres pages.
> 
> On trouve en effet le premier H1 pour le logo, puis un autre H1 pour le titre 
> de la page et ensuite tous les autres Hn.
> 
> Cela pose-t-il un problème d'accessibilité ? Et de SEO ?
> 
> J'avoue être plutôt partisan du H1 unique mais certaines personnes me font 
> douter donc j'aimerai avoir d'autres avis.
> 
> Merci et bonne fin de journée à tous !
> 
> Antoine Bouet.
> 
>  
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> Garanti sans virus. www.avast.com 
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>  
> ___
> 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] titres d'articles et méta-données associées - des suggestions?

[Olivier Nourry]

Bonjour,

Merci Frédéric, Alex et Aurélien pour vos suggestions.


Bonne journée,
Olivier Nourry


> Le 24 nov. 2017 à 09:52, Aurelien Levy <aurelien.l...@gmail.com> a écrit :
> 
> Hello, 
> 
> solution imparfaite à base de titre masqué à utiliser en dernier recours   :
> [titre d’article 1]
> [date 1]
>  [catégories 1]
> [titre d’article 1]
> 
> Aurélien
> 
> Le 23 novembre 2017 à 16:35, Alex Bernier <alex.bern...@braillenet.org 
> <mailto:alex.bern...@braillenet.org>> a écrit :
> Une structure de code comme celle-ci devrait marcher :
> 
> 
> [date 1]
> [catégories 1]
> [titre d’article 1]
> 
> [le contenu de l’article 1]
> 
> 
>  est un élément sectionnant, donc si le lecteur d'écran fait son 
> job, pas d'ambiguïté entre le contenu de deux "" différents...
> 
> Alex
> 
> 
> On Thu, Nov 23, 2017 at 04:06:03PM +0100, Olivier Nourry wrote:
> >Bonjour,
> >
> >Je rencontre souvent ce genre de structures sur des sites de contenus:
> >
> >[une date]
> >
> >[une ou plusieurs catégories]
> >
> >[un titre d’article]
> >
> >[le contenu de l’article]
> >
> >répété plusieurs fois dans la page. Ce qui donne:
> >
> >[date 1]
> >[catégories 1]
> >[titre d’article 1]
> >[le contenu de l’article 1]
> >
> >[date 2]
> >[catégories 2]
> >[titre d’article 2]
> >[le contenu de l’article 2]
> >
> >etc.
> >
> >Bien sûr, les [Titre n] sont des éléments H2, ou H3, etc.
> >
> >Le problème avec cette structure, c’est de signifier que « Titre 1 »
> >est le titre associé aux méta-données « date 1 » et « catégories 1 »,
> >et non de « date 2 » et « catégories 2 » qui viennent juste après.
> >
> >Je me bats toujours avec cette situation, en incitant à remettre les
> >méta sous le titre, visuellement, ce qui facilitera la structuration,
> >mais j’obtiens rarement gain de cause.
> >
> >J’ai cherché sur différents sites de référence, espérant trouver une
> >intégration intelligente de cette contrainte, mais ils positionnent
> >tous les méta après les titres.
> >
> >Les 2 solutions que je propose généralement:
> >
> >  * soit intégrer la méta dans le heading (mais ça n’est réellement
> >faisable que si on n’a juste qu’une date par exemple)
> >  * soit positionner les méta après le heading dans le code, et les
> >repositionner au-dessus en CSS. Sauf que c’est pas toujours évident
> >à réaliser, notamment pour garder ça propre à tous les niveaux de
> >zoom et pour toutes les largeurs de fenêtres
> >
> >J’ai déjà vu également des implémentations où le bloc « méta + titre +
> >corps d’article » est labellisé (via aria-labelledby) par le titre à
> >l’intérieur. Mais ça ne me paraît pas efficace pour résoudre le
> >problème.
> >
> >D’autres propositions?
> 
> > ___
> > 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 
> > <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 
> <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] titres d'articles et méta-données associées - des suggestions?

[Olivier Nourry]

Bonjour,

Je rencontre souvent ce genre de structures sur des sites de contenus:

[une date]
[une ou plusieurs catégories]
[un titre d’article]
[le contenu de l’article]

répété plusieurs fois dans la page. Ce qui donne:

[date 1]
[catégories 1]
[titre d’article 1]
[le contenu de l’article 1]

[date 2]
[catégories 2]
[titre d’article 2]
[le contenu de l’article 2]

etc.
Bien sûr, les [Titre n] sont des éléments H2, ou H3, etc.

Le problème avec cette structure, c’est de signifier que « Titre 1 » est le 
titre associé aux méta-données « date 1 » et « catégories 1 », et non de « date 
2 » et « catégories 2 » qui viennent juste après. 
Je me bats toujours avec cette situation, en incitant à remettre les méta sous 
le titre, visuellement, ce qui facilitera la structuration, mais j’obtiens 
rarement gain de cause. 
J’ai cherché sur différents sites de référence, espérant trouver une 
intégration intelligente de cette contrainte, mais ils positionnent tous les 
méta après les titres.
Les 2 solutions que je propose généralement:
soit intégrer la méta dans le heading (mais ça n’est réellement faisable que si 
on n’a juste qu’une date par exemple)
soit positionner les méta après le heading dans le code, et les repositionner 
au-dessus en CSS. Sauf que c’est pas toujours évident à réaliser, notamment 
pour garder ça propre à tous les niveaux de zoom et pour toutes les largeurs de 
fenêtres

J’ai déjà vu également des implémentations où le bloc « méta + titre + corps 
d’article » est labellisé (via aria-labelledby) par le titre à l’intérieur. 
Mais ça ne me paraît pas efficace pour résoudre le problème.

D’autres propositions?

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

Re: [Liste GTA] Vocalisation PDF

[Olivier Nourry]

Bonjour Eric,

Je ne fais pas d’inspection de labellisation AccessiWeb, je ne vais donc pas 
répondre à la place de Braillenet à ce propos.
Mais voici ce que je ferais dans le cas d’une vérification de conformité RGAA, 
indépendamment du contexte d’une labellisation:
d’abord vérifier que le document nécessite bien une version alternative. Deux 
cas:
soit le PDF lui-même est accessible (tout-à-fait envisageable pour du simple 
texte, bien balisé)
soit le doc n'a aucune valeur ajoutée, comme par exemple les plaquettes 
commerciales qui se contentent de reprendre l’information du site dans un 
format imprimable. J’aurais aussi  tendance à dire que s’il y a un lien 
explicite vers la même information, même disponible ailleurs, dans un format 
accessible (ce que n’est pas un format audio pur), le critère pourrait être 
considéré comme N/A - à évaluer au cas par cas.
ensuite vérifier que le contenu n’est pas l’objet d’une dérogation, en 
m’appuyant sur le guide des dérogations: 
https://github.com/DISIC/guide-derogations 
<https://github.com/DISIC/guide-derogations>. Si  c’est le cas, le critère 13.7 
est conforme pour ce contenu (ce qui implique aussi de mettre en place le 
mécanisme de compensation prévu en pareil cas).

Dans tous les autres cas, le site doit fournir une version alternative. Si 
c’est du simple texte, ça va être dur de trouver une justification recevable 
pour ne pas le fournir sous forme de HTML, ou sous forme de document au format 
traitement de texte.

Mes deux centimes :)

Olivier Nourry

> Le 2 nov. 2017 à 10:40, liste_...@federici.fr a écrit :
> 
> Bonjour Frédéric,
> 
> Merci pour cette réponse.
> 
> Je suis d'accord avec toi, sur les fichiers graphiques, il n'y a aucune 
> accessibilité. Mais sur un PDF ne comportant que du texte et bien balisé, 
> qu'en est-il ?
> Le fait que la solution Read Speaker soit à une autre URL n'est-il pas gênant 
> ?
> 
> Eric Federici 
> 
> Le 02.11.2017 00:10, Frédéric Halna a écrit :
> 
>> Bonsoir,
>>  
>> suffisant pour une labellisation surement pas, et suffisant pour 
>> l'utilisateur non plus.
>> Si on prend ce document: 4ème étude "Economie des Telecoms" de Arthur D. 
>> Little 
>> <http://docreader.readspeaker.com/docreader/?cid=brtoc=fr_fr=http://www.fftelecoms.org/sites/fftelecoms.org/files/contenus_lies/1411.27_etude_economie_des_telecoms_arthur_d._little_pour_fftelecoms_0.pdf>
>>  
>> et spécifiquement la 12ème  page.
>> On aperçois rapidement que l'ordre de lecture n'est pas corrigé, qu'il 
>> n'existe aucune sémantique et que l'information portée par le graphique est 
>> tout simplement non restitué par la synthèse.
>> 
>> Sur la page d'accueil, le logo ne possède pas d'alternative donc c'est URL 
>> de l'image qui est restituée par la synthèse.
>>  
>> Donc sur une document non accessible Read Speaker n'apporte aucun bénéfice à 
>> l'accessibilité et n'est donc pas une alternative valable à un PDF.
>>  
>> Frédéric Halna.
>>  
>> 
>> 
>> Le 1 novembre 2017 à 18:57, <liste_...@federici.fr 
>> <mailto:liste_...@federici.fr>> a écrit :
>> Bonjour à tous,
>> 
>> La vocalisation de fichiers PDF à l'aide de Read Speaker permet-elle une 
>> validation Accessiweb, dans le cas de PDF non accessibles à cause d'un 
>> mauvais balisage par exemple, ou de contrastes de couleurs insuffisants  ?
>> 
>> Voici un exemple précis pour illustrer mon propos : 
>> http://www.fftelecoms.org/articles/l-economie-du-secteur-des-telecoms-en-france-4eme-etude-arthur-d-little-pour-la-federation
>>  
>> <http://www.fftelecoms.org/articles/l-economie-du-secteur-des-telecoms-en-france-4eme-etude-arthur-d-little-pour-la-federation>
>> Tout en bas de la page, on trouve un PDF avec un lien vers Read Speaker.
>> Est-ce suffisant pour une labellisation ?
>> 
>> Merci d'avance pour vos avis.
>> 
>> Cordialement,
>> Eric Federici
>> 
>> ___
>> 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 
>> <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 
>> <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] critère 9.2 - footer et header en contexte responsive

[Olivier Nourry]

Bonjour,

En fait il suffisait de prendre du recul, j’étais trop dedans pour y voir clair…
Merci JP et Romain pour m’avoir éclairé dans ce tunnel!

Olivier

> Le 25 oct. 2017 à 17:49, Jean-Pierre Villain <jpvill...@access42.net> a écrit 
> :
> 
> Bonjour,
> 
> Il n'y a aucune obligation d'avoir un header et un footer ni de nav 
> d'ailleurs.
> 
> Le test n'oblige pas à utiliser ces éléments mais vérifie simplement que dans 
> le cas où il y a une zone d'en-tête elle est structurée par une balise header.
> 
> Il n'y a pas un logo ?
> 
> Auquel cas le header est réduit au seul logo.
> 
> Pour le footer s'il n'y en a pas ben il n'y en a pas.
> 
> JPV
> 
> Le 25/10/2017 à 17:22, Olivier Nourry a écrit :
>> Hello tous,
>> Je suis en train d’auditer un site (en cours de dev, donc pas possible de 
>> montrer des écrans), sur lequel il n’y a aucune balise de landmark, donc le 
>> critère 9.2 est NC. Par contre je suis embêté pour préconiser où mettre le 
>> header et accessoirement le footer, surtout que le site est codé en 
>> responsive design, et certains éléments qui étaient en haut passent en bas. 
>> Je précise:
>> en vue large, il y a une bande horizontale en haut de page, avec dedans un 
>> lien vers la home, des icones-boutons d’action, un champ de recherche
>> en vue large en colonne de gauche on a le menu de navigation principal
>> en vue étroite, la bande du haut devient: un bouton burger qui permet 
>> d’afficher le menu de nav principal, le lien home qui prend toute la 
>> largeur, et un bouton qui permet d’ouvrir le formulaire de recherche. Les 
>> icones-boutons passent tout en bas de la page
>> il n’y a rien, mais alors rien, en pied de page (pas même un lien vers un 
>> plan de site, une aide, des crédits ou quoi…). Je ne sais pas si c’est prévu 
>> à terme, mais en l’état je ne saurais quoi mettre dans ma balise footer.
>> 
>> La bande du haut ne me paraît pas vraiment être un header, sachant qu’elle 
>> n’a rien à voir d’une version à l’autre, et ça me paraît compliqué de forcer 
>> un conteneur sur un truc qui est coupé en deux en largeur étroite. Et 
>> d’autre part, je ne crois pas que le test prévoie le cas où un footer n’a 
>> pas de contenu.
>> 
>> Qu’en pensez-vous? Vous mettriez quoi dans header? et footer?
>> 
>> 
>> Merci d’avance
>> Olivier Nourry
>> 
>> 
>> ___
>> 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 
>> <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] critère 9.2 - footer et header en contexte responsive

[Olivier Nourry]

Hello tous,
Je suis en train d’auditer un site (en cours de dev, donc pas possible de 
montrer des écrans), sur lequel il n’y a aucune balise de landmark, donc le 
critère 9.2 est NC. Par contre je suis embêté pour préconiser où mettre le 
header et accessoirement le footer, surtout que le site est codé en responsive 
design, et certains éléments qui étaient en haut passent en bas. Je précise:
en vue large, il y a une bande horizontale en haut de page, avec dedans un lien 
vers la home, des icones-boutons d’action, un champ de recherche
en vue large en colonne de gauche on a le menu de navigation principal
en vue étroite, la bande du haut devient: un bouton burger qui permet 
d’afficher le menu de nav principal, le lien home qui prend toute la largeur, 
et un bouton qui permet d’ouvrir le formulaire de recherche. Les icones-boutons 
passent tout en bas de la page
il n’y a rien, mais alors rien, en pied de page (pas même un lien vers un plan 
de site, une aide, des crédits ou quoi…). Je ne sais pas si c’est prévu à 
terme, mais en l’état je ne saurais quoi mettre dans ma balise footer.

La bande du haut ne me paraît pas vraiment être un header, sachant qu’elle n’a 
rien à voir d’une version à l’autre, et ça me paraît compliqué de forcer un 
conteneur sur un truc qui est coupé en deux en largeur étroite. Et d’autre 
part, je ne crois pas que le test prévoie le cas où un footer n’a pas de 
contenu.

Qu’en pensez-vous? Vous mettriez quoi dans header? et footer?


Merci d’avance
Olivier Nourry___
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org

Re: [Liste GTA] Bouton-icône avec texte hors-écran

[Olivier Nourry]

Bonjour Cyril,
dans AccessiWeb, cette pratique était évaluée non conforme,  via le critère 
10.2, qui vérifiait que la suppression des images de fond ne supprimait pas 
d’information.
Lors des débats préparatoires à l’écriture du RGAA 3.0, ce test a été supprimé 
pour les raisons suivantes:
WCAG 2 l’autorise
une grande quantité de frameworks et de CSS ont recours à cette pratique, ce 
qui rendrait problématique l’application de cette exigence, en particulier pour 
les fontes-icones.
Il a donc été décidé, tant au niveau de la consultation du GTA, que d’un groupe 
d’experts consultés par la DINSIC (ex-DISIC), de lever cette contrainte.

Donc pour répondre à ta question: c’est conforme, avec les inconvénients que tu 
mentionnes. On peut atténuer en plaçant un attribut title sur le bouton, avec 
un contenu identique, mais ça ne s’affichera pas à la prise de focus clavier 
(sauf si on a prévu un script pour ça).
En revanche, en utilisant une image IMG avec un attribut alt approprié, on n’a 
plus besoin du texte caché, et le alt est affiché si l’image n’est pas 
disponible.

J’espère avoir répondu à ta demande.
Olivier Nourry
Access First

> Le 19 oct. 2017 à 13:37, Cyril Lamotte <lamotte.cy...@gmail.com> a écrit :
> 
> Bonjour !
> 
> Sur le balisage ci-dessous : Je n'arrive pas définir si cette implémentation 
> est correcte :
> 
> Ma 
> fonction
> 
> - Visuellement, une icone simple est visible (via CSS)
> - Le span est "hors-ecran", il est donc lisible par les TA.
> 
> > En cas de d'erreur réseau, ou pendant le chargement (l'image de fond n'est 
> > pas -encore- téléchargée), il n'y a visuellement plus rien dans le bouton.
> 
> L'implémentation est-elle correcte tout de même à votre avis ? ou 
> l'invalideriez-vous (pour quel critère ?)
> 
> Merci !
> 
> -- 
> Cyril
> ___
> 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] Input entre balises label

[Olivier Nourry]

Salut Audrey,
la partie de la spec aus tu cites dit bien qu’un label fournit un accessible 
name, mais ne précise pas si le fait d’associer le label au champ en entourant 
le champ avec le label, est une méthode conforme. Or elle l’est de par la spec 
HTML il semble.
Et en fait si ça ne marche pas pour certaines AT, ce serait plus de l’ordre du 
bug que de la non-conformité aux specs. Ce qui revient au même pour 
l’utilisateur (ça marche pô), mais déplace la responsabilité.
Perso je demande toujours la correction. Mais si on me répond que c’est trop 
compliqué je serais bien en peine de contre-argumenter…

> Le 3 oct. 2017 à 16:08, Audrey Maniez  a écrit :
> 
> Bonjour, 
> 
> Effectivement, la spec HTML reconnaît le label implicite comme une 
> implémentation conforme pour nommer le champ. Mais certaines combinaisons de 
> navigateur/lecteur d'écran peuvent ignorer cette implémentation.
> 
> La spécification définit ce qu'est le nom accessible pour un champ de 
> formulaire : 
> https://www.w3.org/TR/html-aam-1.0/#accessible-name-and-description-computation
>  
> 
>  
> Il est bien noté que si aucun des attributs ou balises mentionnées (aria-*, 
> title ou label) n'est présent, alors il n'y a pas de nom accessible, i.e que 
> les lecteurs d'écrans ne devraient pas restituer d'étiquette. 
> 
> Le fait que les technologies restituent correctement n'est pas une raison 
> valable pour valider une implémentation. Implémenter selon une méthode 
> explicite (label id/for par exemple) assure la transmission aux API d'access 
> et aux AT de manière uniforme, sans avoir à tester sur toutes les AT du 
> marché justement. 
> 
> Audrey MANIEZ - @audreyblabla - +33 (0)6 22 11 29 62
> Experte senior et formatrice 
> Access42 : expertise, conseil et formation en accessibilité numérique
> +33 (0)9 72 45 06 14 - http://access42.net  - 
> @access42net
> Le 03/10/2017 15:35, ROSA Giuseppe (93) a écrit :
>> Bonjour la liste,
>> 
>> Je ne sais plus si la question a déjà été posé :
>> 
>> Lorsqu'un champ input est entre balise label, sans autre moyen préconisé par 
>> le test 11.1.1 (ni title, ni aria-label ou aria-labelledby) et sans 
>> respecter le test 11.1.2 (pas de id / for) :
>> 
>> Prénom : 
>> 
>> Je dois le considérer comme 'Non Conforme'.
>> 
>> Pourtant : 
>> Au moins NVDA (et a priori JAWS) m'indique bien "Prénom" lorsque je tabule 
>> dans le champ (NVDA donne "Prénom :  édition  avec auto-complétion vide", 
>> soit exactement la même chose que si j'avais Prénom 
>> : )
>> Ce label se comporte comme un label rattaché au champ, c'est à dire en 
>> cliquant sur Prénom , le focus est mis dans le champ
>> le validateur W3C n'indique pas d'erreur
>> Par conséquent, il est difficile demander à un développeur de "revoir sa 
>> copie" avec pour unique argument que ce n'est pas RGAA.
>> 
>> Auriez-vous des arguments pour inciter à mettre le code en conformité (cas 
>> où l'input dans le label ne fonctionnerait pas correctement...) ?
>> 
>> Merci la liste
>> 
>> PS : pour cause de déplacement professionnel prévu de longue date, je ne 
>> pourrai pas être des vôtres le 17.10.
>> 
>> Cordialement,
>> DGFiPGiuseppe 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
>> 
>> 
>> 
>> 
>> ___
>> 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] Input entre balises label

[Olivier Nourry]

Bonjour Giuseppe,

Je suis resté sur l’idée que le label implicite est moins robuste car posant 
problème dans certaines configurations navigateurs/TA — qui me vient sans doute 
de la note technique mentionnée par Alex, ou par quiconque l’a mentionnée. 
J’avoue ne pas avoir creusé plus loin.

Steve Faulkner l’avait fait (en 2011…), voici l’article présentant ses tests: 
https://developer.paciellogroup.com/blog/2011/07/html5-accessibility-chops-form-control-labeling/
 

 Il y indique que la méthode avec for/id (label explicite) est la plus robuste, 
et qu’il faut éviter les 2 autres (label implicite, et combinaison de implicite 
ET for/id). Seulement les tableaux de tests ne me paraissent pas révéler de 
différence perceptible entre les 3 méthodes, pour aucune des combinaisons 
testées. De plus il faudrait réitérer les tests avec les agents utilisateurs 
actuels.
Note que le test 11.1.2 autorise la méthode implicite + for/id, puisque il n’y 
a pas de condition interdisant l’implicite.

Coté WCAG, c’est un peu confus également: la technique H44 
 dit qu’il faut for/id, et ne 
mentionne pas la technique du label implicite. Par contre, la failure F68 
autorise cette méthode, en 
creux, puisqu’elle fait partie des tests qui, s’ils échouent, permettent de 
prononcer l’échec du critère de succès…

Donc, difficile de se prononcer. J’aurais tendance à dire que si ça marche sur 
ta base de référence, en y ajoutant quelques configs un peu exotiques ou en 
versions N-2, tu ne risques pas grand chose. A voir, par contre, ce qui est le 
plus coûteux: faire ces tests, ou ajouter un for/id? Dans certains cas, la 
réponse n’est pas évidente…

J’espère t’avoir aidé
Olivier



> Le 3 oct. 2017 à 15:35, ROSA Giuseppe (93) 
>  a écrit :
> 
> Bonjour la liste,
> 
> Je ne sais plus si la question a déjà été posé :
> 
> Lorsqu'un champ input est entre balise label, sans autre moyen préconisé par 
> le test 11.1.1 (ni title, ni aria-label ou aria-labelledby) et sans respecter 
> le test 11.1.2 (pas de id / for) :
> 
> Prénom : 
> 
> Je dois le considérer comme 'Non Conforme'.
> 
> Pourtant : 
> Au moins NVDA (et a priori JAWS) m'indique bien "Prénom" lorsque je tabule 
> dans le champ (NVDA donne "Prénom :  édition  avec auto-complétion vide", 
> soit exactement la même chose que si j'avais Prénom : 
> )
> Ce label se comporte comme un label rattaché au champ, c'est à dire en 
> cliquant sur Prénom , le focus est mis dans le champ
> le validateur W3C n'indique pas d'erreur
> Par conséquent, il est difficile demander à un développeur de "revoir sa 
> copie" avec pour unique argument que ce n'est pas RGAA.
> 
> Auriez-vous des arguments pour inciter à mettre le code en conformité (cas où 
> l'input dans le label ne fonctionnerait pas correctement...) ?
> 
> Merci la liste
> 
> PS : pour cause de déplacement professionnel prévu de longue date, je ne 
> pourrai pas être des vôtres le 17.10.
> 
> 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
> 
> 
> ___
> 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] Report des erreurs dans un audit

[Olivier Nourry]

Bonjour,
Je vous invite à  consulter le guide de l’auditeur, fourni en tant que 
ressource du RGAA. Il dédie un chapitre à cette question, sur cette page: 
https://disic.github.io/guide-auditeur/2.1-realisation-audit.html 
<https://disic.github.io/guide-auditeur/2.1-realisation-audit.html> 

Je copie le passage ci-dessous, en italique:

Éléments communs aux pages
Aujourd’hui, un site web qui n’est pas réalisé avec un outil de gestion de 
contenu (CMS par exemple) fait exception. Avec cette industrialisation des 
sites web, les éléments de gabarits (navigation, entête, pied de page…) sont 
identiques (même code source, même fonctionnement…) sur toutes les pages du 
site, ou sur un même ensemble de pages. Bien qu’il soit demandé d’évaluer tous 
les composants d’une page pour la déclarer conforme ou non conforme, il est 
possible de faire l’économie d’auditer plus de 15 fois le même code (par 
exemple la navigation), lorsqu’on est assuré qu’il est le même sur toutes les 
pages.

Vous pouvez relever la non-conformité une seule fois la première fois qu'elle 
est rencontrée et ne plus auditer cette partie de contenu répété sur les autres 
pages. Si nécessaire, vous pouvez reporter systématiquement la non-conformité 
sur toutes les pages directement ou par l'intermédiaire d'une référence, par 
exemple « voir page x ».


(fin de citation)


Cordialement,
Olivier Nourry
cont...@access-first.fr <mailto:cont...@access-first.fr> 

> Le 8 sept. 2017 à 12:07, BERNIER-MALCOIFFE, Frédéric 
> <frederic.bernier-malcoi...@capgemini.com> a écrit :
> 
> Bonjour,
>  
> Je fais comme Sanvin. Cela factorise l’info ce qui plus efficace pour 
> l’équipe de correction.
> Par contre, cela a un impact sur les indicateurs de conformité.
>  
> De : liste_gta [mailto:liste_gta-boun...@list.accessiweb.org 
> <mailto:liste_gta-boun...@list.accessiweb.org>] De la part de Steven Mouret
> Envoyé : vendredi 8 septembre 2017 11:59
> À : liste_gta@list.accessiweb.org <mailto:liste_gta@list.accessiweb.org>
> Objet : Re: [Liste GTA] Report des erreurs dans un audit
>  
> Rachel je faisais comme toi avant mais je trouve long et compliqué de gérer 
> les erreurs identiques sur toutes les pages. Cependant je comprends que ce 
> soit moins source d'erreur pour les développeurs.
>  
> Du coup j'aime bien l'idée de Sanvin. Je pense que mon prochain audit ira 
> dans ce sens.
>  
> Merci à vous pour vos réponses.
> 
> 
> --
> Steven Mouret
>  
> Le 8 septembre 2017 à 11:52, <san...@free.fr <mailto:san...@free.fr>> a écrit 
> :
> hello,
> pour ma part, les erreurs qui sont présentes dans toutes les pages sont 
> importantes avec un impact fort sur l'a11y générale du site/appli et 
> (souvent) corrigeables en une seule fois sur le gabarit !
> Donc je les rassemble dans un chapitre "erreurs communes à toutes les pages" 
> pour bien les mettre en avant sans le répéter dans toutes les pages sauf un 
> lien vers "erreurs communes à toutes les pages" en début de liste des erreurs 
> pour que les dev n'oublient pas,
> 
> voilà mes 2cts
> 
> a+
> 
> Sanvin
> 
> - Mail original -
> De: "Rachel Foucard" <rfouc...@w-seils.com <mailto:rfouc...@w-seils.com>>
> À: "liste gta" <liste_gta@list.accessiweb.org 
> <mailto:liste_gta@list.accessiweb.org>>
> Envoyé: Vendredi 8 Septembre 2017 11:39:23
> Objet: Re: [Liste GTA] Report des erreurs dans un audit
> 
> 
> 
> 
> 
> Bonjour Steven,
> 
> 
> 
> Pour ma part d’une manière générale, si une erreur est présente sur toutes 
> les pages parce qu’elle porte sur un bloc présent sur toutes les pages, je 
> l’indique bien sur toutes les pages.
> 
> Lorsqu’on va regarder l’ensemble des erreurs sur une page donnée, on a comme 
> ça une vision exhaustive des problèmes, et on peut choisir des solutions 
> cohérentes.
> 
> C’est plus confortable pour le développeur qui devra corriger d’avoir une 
> vision transversale (erreurs qui ont un impact sur l’ensemble des pages du 
> site) et une vision globale sur une page donnée.
> 
> Il va plus facilement savoir dans quel ordre travailler et prendre les bonnes 
> décisions.
> 
> 
> 
> Cordialement,
> 
> 
> 
> 
> 
> 
> 
> 
> cid:image001.jpg@01CDD6D4.98875830 <cid:image001.jpg@01CDD6D4.98875830>
> 
> 
> 
> 
> 
> 
> --
> 
> RACHEL FOUCARD
> Responsable Technique
> 
> TYPO3 French Committee Representative
> 
> www.w-seils.com <http://www.w-seils.com/>
> 
> 
> 
> 
> rfouc...@w-seils.com <mailto:rfouc...@w-seils.com>
> Tel +33 (0)2 28 22 75 42 <tel:%2B33%20%280%292%2028%2022%2075%2042>
> Mobile +33 (0)6 98 87 88 18 <tel:%2B33%20%

Re: [Liste GTA] Evaluer un Date picker

[Olivier Nourry]

Bonjour Frédéric,
Ce n’est effectivement plus dans la version courante du APG 1.1, mais prévu 
pour la release 2, prévue 6 mois après le passage d’ARIA au statut Proposed 
Recommendation:
https://github.com/w3c/aria-practices/issues/34 
<https://github.com/w3c/aria-practices/issues/34>

En attendant tu peux t’appuyer sur l’exemple fourni dans les ressources du 
RGAA, basé sur ARIA 1.0: 
http://disic.github.io/rgaa_composants_javascript/#datepicker 
<http://disic.github.io/rgaa_composants_javascript/#datepicker>

J’espère t’avoir aidé!

Olivier Nourry
http://access-first.fr <http://access-first.fr/> 


> Le 16 mai 2017 à 14:36, BERNIER-MALCOIFFE, Frédéric 
> <frederic.bernier-malcoi...@capgemini.com> a écrit :
> 
> Bonjour la liste,
>  
> A ce jour, comment évaluer un date picker ?
> Y a-t-il un motif de conception à respecter ?
> Dans le working draft de la WAI-ARIA Authoring Practices 1.1 
> <https://www.w3.org/TR/wai-aria-practices-1.1/#accordion>, il n’en est plus 
> fait mention.
>  
> Merci de votre aide J
> ___
> 
> Frédéric Bernier-Malcoiffe
> Chef de projets / Expert en accessibilité - DCX | Digital Factory | 
> Application Services France Secteur Services
>  
> Capgemini | Nantes
> Tel.: +33 2 40 99 25 37
> www.fr.capgemini.com <http://www.capgemini.com/>
>  
>  <http://www.facebook.com/pages/Labinnovation/129058430478934>  
>  <http://www.youtube.com/LabInnovation>   
> <http://twitter.com/#!/CapgeminiLabs>
> People matter, results count.
> ___
> 
> Capgemini is a trading name used by the Capgemini Group of companies which 
> includes CAPGEMINI FRANCE (SAS),
> a company registered in France (RCS : 328-781-786 NANTERRE)
> whose registered office is at Tour Europlaza, 20 avenue André Prothin, 92927 
> Paris la Défense cedex.
>  
> This message contains information that may be privileged or confidential and 
> is the property of the Capgemini Group. It is intended only for the person to 
> whom it is addressed. If you are not the intended recipient, you are not 
> authorized to read, print, retain, copy, disseminate, distribute, or use this 
> message or any part thereof. If you receive this message in error, please 
> notify the sender immediately and delete all copies of this 
> message.___
> 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 
> <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] Scripts et alternatives

[Olivier Nourry]

Bonjour Raphaël,

Plus exactement: il n’est plus demandé de gérer le cas où JS n’est pas supporté.
En revanche:
tout composant JS (hors cas particuliers) doit être accessible (ce qui est 
indépendant d’ARIA - ARIA est un moyen d’ajouter les rôles, propriétés, états 
et relations qui manquent au HTML; choses que l’on va pouvoir modifier en JS si 
besoin, mais c’est le seul lien); OU ALORS, une alternative accessible est 
disponible
Le moyen d’activer cette alternative accessible, si c’est l’option choisie, ne 
doit pas impliquer de désactiver une technologie (par ex. de désactiver JS ou 
Flash). Donc le recours à  n’est pas la bonne solution d’accès à 
cette alternative
Si, indépendamment de l’accessibilité du composant avec JS, il est décidé de 
proposer de supporter le no-JS, cette version en no-JS doit être accessible 
également (en fait c’est traité comme une autre version de la page, du point de 
vue de l'audit) 

J’ajouterais que "Veuillez activer javascript pour pour accéder à 
l'information » n’a jamais été la bonne façon de faire ;) [clin 
d’oeil] car l’utilisateur n’a pas forcément la possibilité d’activer JS. On ne 
résout donc rien ainsi. En revanche il n’est pas très difficile de rendre un 
carrousel fonctionnel sans JS, en partant sur une conception en amélioration 
progressive. Il suffit de le construire en HTML comme une liste d’images, mise 
en forme en CSS et animée en JS. Sans JS, on se retrouve avec juste la liste, 
statique.

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

Olivier Nourry
http://access-first.fr <http://access-first.fr/> 

> Le 20 mars 2017 à 16:27, Raphaël Franchet 
> <raphael.franc...@anyware-services.com> a écrit :
> 
> Bonjour à tous,
> je suis un peu rouillé puisque j'avais été formé sur l'ancien référentiel : 
> Ma question porte sur le script, son accessibilité et son alternative.
> 
> Dans l'ancien référentiel, à chaque fois que j'avais un composant en 
> javascript, je devais fournir un équivalent en noscript.
> Il me semblait que dans le nouveau référentiel, il fallait maintenant fournir 
> un javascript "accessible" à l'aide d'ARIA notamment et pas de noscript. 
> Pourtant si le lis le RGAA 2016 7.2.1 on me dit que si une alternative 
>  est présente elle doit être équivalente au script.
> 
> Est-ce que cela signifie que les javascripts "importants" doivent être 
> accessibles mais que si jamais je mets facultativement la balise  
> elle doit contenir la même chose ? Donc je ne peux pas mettre après un 
> carrousel un Veuillez activer javascript pour pour accéder à 
> l'information ?
> 
> Merci
> 
> --
> Cordialement,
> Raphaël Franchet
> 
> ___
> 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] Design pattern d'un menu déroulant au clic.

[Olivier Nourry]

Hello Steven,

Pour moi tu peux traiter entièrement ce cas avec le DP menubar, qui tient 
compte des cas où un item sert à ouvrir un sous-menu. Ce qui est particulier, 
ici, c’est que les items du second niveau sont en réalité deux items sur une 
même ligne, qui font 2 choses différentes, avec donc des propriétés ARIA 
différentes (aria-haspopup pour les boutons notamment). 

J’espère avoir répondu à ta demande.

Olivier Nourry
http://access-first.fr <http://access-first.fr/> 


> Le 20 févr. 2017 à 13:31, Steven Mouret <steven.mou...@gmail.com> a écrit :
> 
> Bonjour à tous,
> 
> Je dois réaliser une menu déroulant sur 3 niveaux fonctionnant au clic.
> Au premier niveau, au clic sur l'intitulé ouverture du menu enfant.
> Au second niveau, au clic sur l'intitulé on se rend sur la page, au clic sur 
> un bouton + accolé à l'intitulé, ouverture du niveau enfant.
> Au troisième niveau simples liens vers les pages.
> L'onglet courant du niveau 1 et 2 se ferme si l'on clique sur un autre onglet.
> 
> Je cherche le meilleur design pattern mais j'ai du mal à faire la différence 
> entre :
> Menubar <https://www.w3.org/TR/wai-aria-practices/#menu>
> Accordion <https://www.w3.org/TR/wai-aria-practices/#accordion>
> Tabpanel <https://www.w3.org/TR/wai-aria-practices/#tabpanel>
> Mon premier niveau à l'horizontal (en mobile il est en vertical) me fait 
> penser à tabpanel et mon deuxième niveau à un accordéon.
> 
> Est ce correcte si je fais ainsi ?
> 
> Merci
> 
> --
> Steven Mouret
> ___
> 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] Angularjs et accessibilité

[Olivier Nourry]

Bonjour Eric,
Bonne année également!

Tu devrais obtenir pas mal d’éléments de réponse ici:
https://disic.github.io/rgaa_bibliotheques-javascript/tutoriels/angular-ui.html 
<https://disic.github.io/rgaa_bibliotheques-javascript/tutoriels/angular-ui.html>
et des correctifs là: https://github.com/DISIC/rgaa_angular-bootstrap 
<https://github.com/DISIC/rgaa_angular-bootstrap>

Cela nécessite potentiellement une mise à jour, et, bonne nouvelle, c’est en 
cours!
J’espère que cela t’aidera.

Cordialement,
Olivier Nourry
Access First <http://access-first.fr/>


> Le 6 janv. 2017 à 10:37, liste_...@federici.fr a écrit :
> 
> Bonjour,
> 
> Tout d'abord, bonne année à tous !
> 
> Ma question : Angulatjs et accessibilité, ici WCAG 2.0, sont-ils compatibles ?
> Je n'arrive pas à trouver de réponse claire sur le sujet.
> Avez-vous déjà travaillé sur des projets Angular accessibles ?
> Votre avis ?
> 
> Merci d'avance pour vos réponses.
> 
> Cordialement,
> Eric Federici
> 
> ___
> 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] Barre de navigation Critère 12-2

[Olivier Nourry]

Bonjour,
et bonne année à tous!

Ce critère s’applique à un ensemble de pages. Si les pages font partie 
d’ensembles différents, il n’est pas requis d’y trouver les mêmes barres de 
navigation.
J’espère que cela répond à ta question.

Olivier Nourry
http://access-first.fr <http://access-first.fr/> 


> Le 28 déc. 2016 à 14:21, Cyril Lamotte <clamo...@jouve.fr> a écrit :
> 
> Bonjour,
> 
> Un audit d'accessibilité remonte une anomalie dans le cas suivant : Une barre 
> de navigation qui permet l'accès à une collection de page, n'est pas affichée 
> sur certaines pages, (résultat de recherche par exemple ou page de contact).
> 
> Doit-on obligatoirement insérer la barre de navigation sur littéralement 
> toutes les pages ?
> 
> (Critère 
> http://references.modernisation.gouv.fr/rgaa-accessibilite/criteres.html#crit-12-2
>  
> <http://references.modernisation.gouv.fr/rgaa-accessibilite/criteres.html#crit-12-2>)
> 
> -- 
> Cyril Lamotte
> Développeur Front-end / Référent accessibilité
> clamo...@jouve.fr <mailto:clamo...@jouve.fr>
> 02 43 08 39 97
> 
> <Logo-JOUVE-100(1).jpg> <http://www.jouve.com/fr>
> 1, rue du docteur Sauvé, 53101 Mayenne CEDEX
> www.jouve.com <http://www.jouve.com/>
>  <https://twitter.com/GroupeJouve> 
> <https://plus.google.com/103316327091227322721/posts>
> <http://www.linkedin.com/company/groupe-jouve> 
> <http://www.viadeo.com/v/company/jouve?ga_from=Fu:undefined;Fb%3Amininews%3Bfe%3AMN-pic%0A%0A%3BMNType%3A46>
>  <http://www.jouve.com/fr/signatureITS>
> 
>  
> ___
> 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 
> <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] RGAA Critère 1.3.8

[Olivier Nourry]

Bonjour,
il s’agit bien de l’attribut title.
Olivier Nourry
Access First <http://access-first.fr/>


> Le 16 déc. 2016 à 16:42, Renan Michaud <renan.mich...@gmail.com> a écrit :
> 
> Bonjour,
> 
> juste une petite question bête sur le critère 1.3.8 du RGAA.
> 
> Test 1.3.8 : Chaque image vectorielle (balise svg) porteuse d’information, en 
> l’absence d’alternative, vérifie-t-elle ces conditions (hors cas 
> particuliers) ?
> La balise svg possède un role="img" ;
> La balise svg possède une propriété aria-label dont le contenu est pertinent 
> et identique à l’attribut title s’il est présent ;
> La balise svg possède une balise desc dont le contenu est pertinent et 
> contient un passage de texte identique à la propriété aria-label et à 
> l’attribut title de la balise svg s’il est présent.
> Il est fait mention d'un attribut "title". Est ce bien une erreur et doit-on 
> bien considérer la balise title de l'élément SVG ?
> 
> Merci d'avance.
> 
> Cordialement,
> -- 
> Renan Michaud
> ___
> 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] Titre de page après une recherche

[Olivier Nourry]

Bonjour Antoine,

La définition du glossaire pour titre de page 
(http://references.modernisation.gouv.fr/rgaa/glossaire.html#titrePage 
<http://references.modernisation.gouv.fr/rgaa/glossaire.html#titrePage>) 
précise: 
Contenu de la balise title d’une page Web permettant d’identifier de manière 
claire, concise et unique les contenus/la nature de la page.
J’ai mis le mot « unique » en gras car c’est ce qui va potentiellement obliger 
à être suffisamment spécifique pour le titre.

En effet, si l’on se contente de « résultats de recherche », par exemple, 
l’utilisateur ne pourra pas, à partir du titre, faire la différence entre 2 
pages de résultats avec des clés de recherche différentes. C’est une situation 
qui peut se présenter sur des sites avec un gros volume de contenus, pour 
lesquelles on ne souhaite pas perdre les résultats d’une requête lorsque l’on 
en fait une seconde; je pense à Wikipédia par exemple.
On peut faire comme sur Google par exemple, en rappelant la clé de recherche 
dans le titre.

Ce que ne fait pas Google en revanche, c’est d’indiquer le numéro de page. 
Pourtant ce sera nécessaire également, dans le cas de résultats paginés.

J’espère avoir répondu à ta demande!

Olivier Nourry
Access First <http://access-first.fr/>


> Le 8 déc. 2016 à 11:34, Antoine Bouet <antoine.bo...@cimeos.com> a écrit :
> 
> Bonjour la liste,
> 
> J'ai une question concernant les pages de recherche et leur .
> 
> Après une recherche, est-ce que le titre de la page doit indiquer les 
> critères recherchés pour respecter la pertinence du 8.6 ?
> Exemple : Recherche des mots "lapin" et "montagne" et de la catégorie 
> "pêche"
> 
> Jusqu'au faut-il aller quand des filtres sont sélectionnés ?
> 
> 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
> 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 10.6 dans le cas d'un bloc cliquable

[Olivier Nourry]

Bonjour Cyril,
Hum, le fait que c’est en gras et espacé fait surtout penser à un titre de 
section. Mais rien n’indique qu’il est cliquable, hormis une couleur différente 
du texte environnant, sensée suggérer un lien (d’autres liens ont la même 
couleur dans la page). Ce qui vend la mèche, c’est la mention « tous les 
articles » qui n’est pas un lien mais dans la même zone cliquable que le lien.
La réponse de JPV confirme mon sentiment, donc je laisse passer sur ce coup-là.

> Le 9 déc. 2016 à 09:58, Cyril Lamotte <clamo...@jouve.fr> a écrit :
> 
> Salut Olivier,
> 
> Je crois que ce critère porte sur les liens qui sont au milieu d'un texte
> Dans le glossaire l'exemple est  "Nouvelle grève à la SNCF" avec "grève" en 
> lien.
> 
> Dans le cas de ton titre, je suppose que sa mise en page le met en avant 
> (gras / espacements), on entrerai alors pas dans ce critère dans ce cas.
> 
> Non ?
> 
> Cyril Lamotte
> Développeur Front-end / Référent accessibilité
> clamo...@jouve.fr <mailto:clamo...@jouve.fr>
> 02 43 08 39 97
> 
> <Logo-JOUVE-100(1).jpg> <http://www.jouve.com/fr>
> 1, rue du docteur Sauvé, 53101 Mayenne CEDEX
> www.jouve.com <http://www.jouve.com/>
>  <https://twitter.com/GroupeJouve> 
> <https://plus.google.com/103316327091227322721/posts>
> <http://www.linkedin.com/company/groupe-jouve> 
> <http://www.viadeo.com/v/company/jouve?ga_from=Fu:undefined;Fb%3Amininews%3Bfe%3AMN-pic%0A%0A%3BMNType%3A46>
>  <http://www.jouve.com/fr/signatureITS>
> 
>  
> Le 08/12/2016 à 22:27, Olivier Nourry a écrit :
>> Bonjour,
>> 
>> J’ai un doute relatif au critère 10.6: 
>> Dans chaque page Web, chaque lien dont la nature n’est pas évidente 
>> <http://references.modernisation.gouv.fr/rgaa/glossaire.html#lien-nature-pas-evidente>
>>  est-il visible par rapport au texte environnant ?
>> 
>> J’ai sous les yeux une page avec des blocs de contenu rendus entièrement 
>> cliquables par la magie du CSS. A l’intérieur, seul le titre est réellement 
>> un lien. Et on a un texte « lire tous les articles en fin de bloc ».  Or le 
>> lien (le titre) n’est pas souligné (donc signalé uniquement par la couleur) 
>> et son contraste par rapport au texte est trop faible. Mais je ne vois pas 
>> de raison d’invalider ici, car je ne trouve pas de situation utilisateur où 
>> cela pose problème:
>> aucun souci pour les utilisateurs non visuels qui ont l’info de la présence 
>> du lien, avec un intitulé suffisamment explicite
>> aucun souci en lecture visuelle + clavier, car le lien est entouré par 
>> l’outline par défaut du navigateur, donc on sait que c’est clivable
>> aucun souci en lecture visuelle + souris, puisque le texte « lire les 
>> articles » suggère la nature cliquable du bloc, même si techniquement ce 
>> n’est pas un lien
>> 
>> Qu’en pensez-vous? Faut-il étendre la notion de lien à un élément cliquable 
>> dans le cas présent?
>> 
>> 
>> ___
>> 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 
>> <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 
> <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] Critère 10.6 dans le cas d'un bloc cliquable

[Olivier Nourry]

Bonjour,

J’ai un doute relatif au critère 10.6: 
Dans chaque page Web, chaque lien dont la nature n’est pas évidente 

 est-il visible par rapport au texte environnant ?

J’ai sous les yeux une page avec des blocs de contenu rendus entièrement 
cliquables par la magie du CSS. A l’intérieur, seul le titre est réellement un 
lien. Et on a un texte « lire tous les articles en fin de bloc ».  Or le lien 
(le titre) n’est pas souligné (donc signalé uniquement par la couleur) et son 
contraste par rapport au texte est trop faible. Mais je ne vois pas de raison 
d’invalider ici, car je ne trouve pas de situation utilisateur où cela pose 
problème:
aucun souci pour les utilisateurs non visuels qui ont l’info de la présence du 
lien, avec un intitulé suffisamment explicite
aucun souci en lecture visuelle + clavier, car le lien est entouré par 
l’outline par défaut du navigateur, donc on sait que c’est clivable
aucun souci en lecture visuelle + souris, puisque le texte « lire les articles 
» suggère la nature cliquable du bloc, même si techniquement ce n’est pas un 
lien

Qu’en pensez-vous? Faut-il étendre la notion de lien à un élément cliquable 
dans le cas présent?___
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org

Re: [Liste GTA] Placeholder animé

[Olivier Nourry]

Je n’avais pas pu voir l’animation, car le site ne se chargeait pas la première 
fois… Quelle horreur! Qui peut trouver ça cool?….

> Le 18 nov. 2016 à 11:34, Julie Moynat <juliemoy...@gmail.com> a écrit :
> 
> Merci Olivier pour tes éclaircissements.
> 
> Dans l'exemple qui a été fourni, l'animation tourne en boucle donc dure à 
> l'infini. Elle n'est donc pas valide.
> 
> Bonne journée
> 
> Julie Moynat
> 
> 
> Le 18 nov. 2016 9:03 AM, "Olivier Nourry" <olv.nou...@gmail.com 
> <mailto:olv.nou...@gmail.com>> a écrit :
> Bonjour,
> tant que l’animation dure moins de 5 secondes, elle n’invalide pas ce critère.
> On vise ici surtout les animations continues, ou suffisamment longues pour 
> causer une source durable de distraction. La plupart des effets de 
> transitions ne sont pas concernés.
> Ceci dit, un site où tout bouge à chaque action va vite devenir très pénible 
> à consulter. Je ne serais pas étonné que la prochaine version des WCAG 
> mentionne ceci comme un problème au titre de certains troubles cognitifs ou 
> de l’équilibre.
> 
> Autre point: la note 2 (la première…) de la définition de contrôle du 
> mouvement dans le glossaire 
> (http://references.modernisation.gouv.fr/rgaa/glossaire.html#controle-mouvement
>  
> <http://references.modernisation.gouv.fr/rgaa/glossaire.html#controle-mouvement>)
>  précise que le fait d’arrêter le mouvement par prise du focus ou hover 
> souris ne valide pas le critère.
> 
> Bonne journée,
> Olivier Nourry
> http://access-first.fr <http://access-first.fr/> 
> 
>> Le 17 nov. 2016 à 21:12, Julie Moynat <juliemoy...@gmail.com 
>> <mailto:juliemoy...@gmail.com>> a écrit :
>> 
>> En fait, non car on n'a aucun moyen alors de relancer l'animation ici. Le 
>> test dit "L’utilisateur peut arrêter et relancer le mouvement".
>> 
>> Cependant, si on réactive l'animation quand l'utilisateur perd le focus... 
>> je ne suis pas sûre que ce serait valide malgré tout car l'utilisateur 
>> pourra toujours être gêné dans sa lecture du reste de la page s'il prend le 
>> focus ailleurs.
>> 
>> 
>> 
>> Le 17 novembre 2016 à 20:55, Sébastien Huillet - Tribu and Co 
>> <shuil...@tribu-and-co.fr <mailto:shuil...@tribu-and-co.fr>> a écrit :
>> Bonjour à tous,
>> 
>> Incroyable je poste un message sur la liste après 4651 messages  Bref.
>> Comme l'animation s'arrête en faisant un focus avec la souris ou par le 
>> clavier (tab), on peut considérer que le mécanisme pour l'arrêter est en 
>> place? 
>> Ce qui valide le critère 13.17 !?
>> 
>> A dans 7 ans.
>> 
>> Seb
>> Sébastien Huillet
>> Directeur
>> 
>>
>> 22, bis place Gaston Paillhou 
>> 37000 Tours
>> Tél : 02 47 38 49 74 
>> Fax: 09 57 33 32 13
>> www.tribu-and-co.fr <http://tribu-and-co.fr/> 
>> 
>> Le 17/11/2016 à 20:45, Julie Moynat a écrit :
>>> Bonjour,
>>> 
>>> Selon moi, pour ce genre d'animation, il faut un moyen de l'arrêter. C'est 
>>> le critère 13.17 qui est non conforme.
>>> 
>>> (Je passe sur le fait qu'il ne s'agit pas ici d'un placeholder et que le 
>>> champ n'a pas de libellé ;-) )
>>> 
>>> Cordialement,
>>> 
>>> Julie Moynat
>>> 
>>> 
>>> Le 17 novembre 2016 à 09:51, Antoine Bouet <antoine.bo...@cimeos.com 
>>> <mailto:antoine.bo...@cimeos.com>> a écrit :
>>> Bonjour la liste !
>>> 
>>> J'ai une question concernant un placeholder animé que je vais devoir mettre 
>>> en place prochainement.
>>> 
>>> Je voulais savoir si pour vous, une animation d'un placeholder géré en CSS 
>>> était accessible, un peu comme celui de ce site :
>>> http://ville.valdor.qc.ca/ <http://ville.valdor.qc.ca/> (voir moteur de 
>>> recherche).
>>> 
>>> Je pense surtout aux critères qui visent à laisser le choix à l'internaute 
>>> d'arrêter une animation automatique.
>>> 
>>> Merci pour vos retours ;)
>>> 
>>> 
>>> -- 
>>> 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 mail

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

[Olivier Nourry]

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> 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" <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?
>>
>>
>>
>> [image: --]
>> Olivier Nourry
>> [image: http://]about.me/oliviernourry
>>
>>
>>
>> --
>>
>> liste_gta mailing listliste_...@list.accessiweb.org 
>> <javascript:_e(%7B%7D,'cvml','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 listliste_...@list.accessiweb.org 
> <javascript:_e(%7B%7D,'cvml','liste_gta@list.accessiweb.org');>http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>
> --
> Aurélien Levy
> 
> Temesis
>
>

-- 



[image: --]
Olivier Nourry
[image: 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

Re: [Liste GTA] bouton ou lien précédent/suivant

[Olivier Nourry]

Bonjour,
Est-ce que ça charge une nouvelle page à chaque fois? Ou est-ce que tout le
contenu est dans la même page?

Dans le premier cas, il vaut mieux des liens, c'est leur fonction première.
Ce sera plus robuste, notamment en cas de retard de chargement du JS. Par
ailleurs cela permet de naviguer via l'historique du navigateur, ce qui est
très appréciable (vive Backspace!).

Dans le second, des boutons pourront convenir, en prenant soin de les
rendre plus explicites (via title ou aria-label ou aria-labelledby), car il
faut informer l'utilisateur sur l'action effectuée de manière claire. Si on
est dans une longue série d'étapes cela devient vite compliqué de savoir où
l'on en est.

Personnellement je déconseille de styler des liens comme des boutons (et
inversement) car il y a des comportements propres aux 2 éléments. Par
exemple: Espace déclenche un bouton mais pas un lien. Et si on
touche/clique sur un bouton, en maintenant la pression, puis on sort de la
zone touchable/cliquable, le bouton ne sera pas déclenché, tandis que le
lien pourra réagir (par exemple, sur navigateur mobile, en proposant un
menu contextuel).

J'espère t'avoir aidé!




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


Le 26 octobre 2016 à 10:40, BECHE, Michel <michel.be...@capgemini.com> a
écrit :

> Bonjour à tous,
>
>
>
> Question innocente qui m’a été posée et je reste sec …
>
>
>
> J’ai un assistant (étape 1, étape 2, …)
>
> A l’étape 1, j’ai du texte d’intro et un  « commencer » ,
>
> A l’étape 2, j’ai des champs de saisie et des 
> « précédent »/ « suivant »
>
>
>
> Dans cet exemple :
>
> -  « commencer » devrait-il plutôt être un lien avec une
> apparence de bouton ? il n’y a pas de formulaire dans cette page …
>
> -  Idem pour précédent ? un lien avec une apparence de bouton ?
>
>
>
> Avez-vous des convictions ou des bonnes pratiques ?
>
>
>
>
>
> Michel
>
>
>
>
> This message contains information that may be privileged or confidential
> and is the property of the Capgemini Group. It is intended only for the
> person to whom it is addressed. If you are not the intended recipient, you
> are not authorized to read, print, retain, copy, disseminate, distribute,
> or use this message or any part thereof. If you receive this message in
> error, please notify the sender immediately and delete all copies of this
> message.
>
> ___
> 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] liens dont la nature n'est pas évidente: cas du lien "tel"

[Olivier Nourry]

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?



[image: --]
Olivier Nourry
[image: 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

Re: [Liste GTA] Sourds et Malentendants > lecture

[Olivier Nourry]

Re,
En poursuivant mes recherches, je tombe sur cette véritable pépite: un
rapport de l'INSEP (PDF) sur le rapport à la santé en contexte de surdité
http://inpes.santepubliquefrance.fr/lsf/pdf/rapport-a-la-sante-surdite-resultats-etude-qualitative.pdf

C'est véritablement captivant, et très éclairant. J'en ai lu de larges
extraits, et de nombreux entretiens avec des personnes sourdes signantes et
ayant accès à l'écrit indiquent un problème qui va au-delà de la seule
capacité à lire: la capacité à comprendre un vocabulaire spécialisé (comme
celui de la santé) ou des concepts qui nécessitent un cadre de références.
Or ces cadres sont plus facilement acquis par les entendants, notamment via
leurs rapports avec leurs parents. Des notions peuvent apparaître basiques
pour les entendants, comme l'hygiène élémentaire, les grands principes de
fonctionnement du corps (respiration, circulation sanguine, sexualité...)
parce qu'on les acquiert en parlant avec ses parents et éducateurs. Et du
coup, cela va faciliter la compréhension de notions qui en découlent telles
que la contraception, la prévention des maladies infectieuses, etc. En
revanche, sans ces concepts de base, ces notions "secondaires" deviennent
abstraites. Or de nombreux jeunes sourds ont manqué, en grandissant, de
moyens de communication avec leurs parents, qui leur auraient permis
d'acquérir ces indispensables bases. Illustration de ceci: une étude
américaine a révélé que les sourds plus diplômés que la moyenne de la
population entendante, sont moins bien informés sur la santé, à cause de
ces spécificités.

Il faut donc moduler (dans l'autre sens, cette fois), cette statistique
sans nuance des 80%: ce n'est pas parce que l'on peut lire que l'on est en
mesure de comprendre. Et pour de nombreux sourds lettrés, le problème est
bien celui-ci, et non simplement celui de l'accès à l'écrit.

A noter également que la traduction en LSF ne résout pas tout: certains
termes n'ont pas de signe dédié, ou alors il faut avoir accès à des
lexiques produits par des spécialistes, avec la difficulté de la diffusion
et de l'apprentissage de ces signes spécialisés. Le rapport donne l'exemple
du mot "hormone", dont le signe est basé sur son initiale H, qui pendant
longtemps a circulé sans que tout le monde sache vraiment à quoi il
correspond. L'une des personnes interrogées propose une réponse pleine de
bon sens à cette situation: l'éducation, sans laquelle tous les efforts
d'accessibilité de l'information ne servent pas à grand chose...




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


Le 20 octobre 2016 à 13:26, Olivier Nourry <olv.nou...@gmail.com> a écrit :

> Bonjour,
>
> Ce PDF (non accessible, je le crains, d'autant qu'il s'agit de plusieurs
> tableaux de données complexes) résume des statistiques issues de l'enquête
> INSEE HID de 1998-1999: http://www.2-as.org/site/IFSI-2011/1-3-
> Statistiques-INSEE-1998-1999.pdf
> C'est précieux car ces rapports INSEE sont de véritables pavés, assez
> difficiles à appréhender (je trouve) lorsque l'on cherche une réponse
> simple à une question donnée, comme ici.
>
> J'imagine que ces données ont dût alimenter le rapport Gillot qui a fourni
> cette fameuse statistique des 80%, reprise un peu partout.
>
> On y lit notamment que 41% des Sourds ou malentendants (contre 81% dans
> l'ensemble de la population) de 6 à 11 ans savent "lire, écrire et compter
> sans difficulté". Entre 12 et 18 ans, c'est 93% (contre 97%). Et au-delà de
> 18 ans: "pas de différence observée".
>
> Bien sûr comme toute statistique c'est à traiter avec prudence, mais je
> trouve intéressantes ces fortes différences liées à l'âge. La lecture
> paraît possible mais avec un certain retard d'acquisition par rapport à la
> population entendante. Cela tempère donc fortement les fameux 80%, qui du
> coup ont l'air d'une moyenne tous âges confondus, abaissée par le niveau de
> lecture des plus jeunes.
>
> A noter aussi qu'il peut y avoir un biais "historique", puisque les
> personnes de plus de 18 ans, en 1998, se sont probablement vues imposer
> l'approche oraliste de l'éducation - la langue des signes françaises n'a le
> statut de langue, en France, que depuis 1991. Ce n'est pas forcément le cas
> des plus jeunes qui ont pu recevoir une formation véritablement Sourde. Je
> n'ai pas trouvé de donnée équivalente plus récente, ce serait instructif de
> savoir si la reconnaissance et l'utilisation de la langue des signes à
> l'école a eu cet effet de bord, ou pas.
>
>
>
>
> [image: --]
> Olivier Nourry
> [image: http://]about.me/oliviernourry
> <http://about.me/oliviernourry>
>
>
> Le 20 octobre 2016 à 12:37, Frédéric Halna <hal...@gmail.com> a écrit :
>
>> Bonjour,
>>
>> Une autre questio

Re: [Liste GTA] Sourds et Malentendants > lecture

[Olivier Nourry]

Bonjour,

Ce PDF (non accessible, je le crains, d'autant qu'il s'agit de plusieurs
tableaux de données complexes) résume des statistiques issues de l'enquête
INSEE HID de 1998-1999:
http://www.2-as.org/site/IFSI-2011/1-3-Statistiques-INSEE-1998-1999.pdf
C'est précieux car ces rapports INSEE sont de véritables pavés, assez
difficiles à appréhender (je trouve) lorsque l'on cherche une réponse
simple à une question donnée, comme ici.

J'imagine que ces données ont dût alimenter le rapport Gillot qui a fourni
cette fameuse statistique des 80%, reprise un peu partout.

On y lit notamment que 41% des Sourds ou malentendants (contre 81% dans
l'ensemble de la population) de 6 à 11 ans savent "lire, écrire et compter
sans difficulté". Entre 12 et 18 ans, c'est 93% (contre 97%). Et au-delà de
18 ans: "pas de différence observée".

Bien sûr comme toute statistique c'est à traiter avec prudence, mais je
trouve intéressantes ces fortes différences liées à l'âge. La lecture
paraît possible mais avec un certain retard d'acquisition par rapport à la
population entendante. Cela tempère donc fortement les fameux 80%, qui du
coup ont l'air d'une moyenne tous âges confondus, abaissée par le niveau de
lecture des plus jeunes.

A noter aussi qu'il peut y avoir un biais "historique", puisque les
personnes de plus de 18 ans, en 1998, se sont probablement vues imposer
l'approche oraliste de l'éducation - la langue des signes françaises n'a le
statut de langue, en France, que depuis 1991. Ce n'est pas forcément le cas
des plus jeunes qui ont pu recevoir une formation véritablement Sourde. Je
n'ai pas trouvé de donnée équivalente plus récente, ce serait instructif de
savoir si la reconnaissance et l'utilisation de la langue des signes à
l'école a eu cet effet de bord, ou pas.




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


Le 20 octobre 2016 à 12:37, Frédéric Halna <hal...@gmail.com> a écrit :

> Bonjour,
>
> Une autre question: sur les 80% des sourds profonds qui sont illettrés,
> combien pratiquent la LSF ?
>
> Une ressource sur le sujet:  La remédiation de l'illettrisme chez les
> adultes sourds locuteurs de la LSF
> <http://www.risc.cnrs.fr/mem_theses_pdf/2007_Perini.pdf>a LSF
>
> Avec notamment ce passage: En effet, selon le rapport, 9% de la population
> sourde est atteinte de surdité sévère et 3% de surdité profonde, ce qui
> représente pour ces deux types de surdité 480 000 individus. L'estimation
> des Sourds signeurs, tous types de surdité confondus, est plus périlleuse.
> Un article d’E. Martin (2005a), coordonnateur du Dispositif Emploi
> Formation de l’URAPEDA13 Bretagne, indique que 80 000 Sourds profonds
> pratiquent la LSF. Mais il ne fait pas d'estimation pour les autres types
> de surdité, et ce chiffre ne nous indique pas si la LSF constitue
> réellement la langue de référence pour ces 80 000 individus.
>
> Bien à vous,
>
> Frédéric Halna.
>
> 2016-10-20 10:58 GMT+02:00 Aurélien Levy <aurelien.l...@temesis.com>:
>
>> Bonjour,
>>
>> Le chiffre resté dans les mémoires date de 1998 et provient de ce rapport
>> http://www.ladocumentationfrancaise.fr/rapports-publics/9840
>> 01595/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 
>> listliste_gta@list.accessiweb.orghttp://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>>
>>
>>
>> --
>> Aurélien Levy
>> 
>> Temesis
>>
>>
>> ___
>> liste_gta mailing list
>> liste_gta@list.accessiweb.org
>> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>>
>>
>
> ___
> liste_gta mailing list
> liste_gta@list.accessiweb.org
> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>
>
___
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"

[Olivier Nourry]

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

Merci pour cette piste!




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


Le 18 octobre 2016 à 16:01, Aurélien Levy <aurelien.l...@temesis.com> a
écrit :

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

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

[Olivier Nourry]

Re-bonjour,

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

Une idée?


Olivier Nourry
[image: http://]about.me/oliviernourry
<http://about.me/oliviernourry>
___
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org

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

[Olivier Nourry]

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

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

Merci en tous cas pour ces éclairages!




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


Le 18 octobre 2016 à 13:04, Alex Bernier <alex.bern...@braillenet.org> a
écrit :

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

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

[Olivier Nourry]

Bonjour la  liste,

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

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

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



[image: --]
Olivier Nourry
[image: http://]about.me/oliviernourry
<http://about.me/oliviernourry>
___
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org

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

[Olivier Nourry]

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]





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


Le 12 octobre 2016 à 09:24, Aurélien Levy <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
> 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> <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.
>
>
>
>
> [image: --]
> Olivie

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

[Olivier Nourry]

Bonjour,

Il n'est pas requis par le RGAA d'utiliser un design pattern ARIA pour
coder un composant. On peut par exemple coder un système d'onglets "à
l'ancienne", à base de listes de liens pour les onglets, de contenus
intercalés ou listés à la suite pour les panneaux, et gérer
l'affichage/masquage par manipulation du DOM via CSS et JS. Tout cela peut
être accessible et consultable avec un lecteur d'écran, tant que l'on gère
correctement l'affichage et le focus.

Par contre, ce qui est requis, c'est que si l'on utilise ARIA (par exemple,
role="tab" sur les onglets), il faut aller au bout de la logique, et
appliquer entièrement le design pattern proposé par le doc 'authoring
practices" accompagnant la spec ARIA. Ce design pattern est une tentative
de normalisation de composants d'interface qui dans les faits ne sont que
des assemblages de HTML, CSS et JS résultant en un simulacre visuel de
composants d'interface riches. Cela permet de se mettre tous d'accord
(développeurs Web, éditeurs de navigateurs, éditeurs de lecteurs d'écran)
sur les conventions d'écriture qui feront que le lecteur d'écran
reconnaitra tel assemblage comme étant un système d'onglets, et le
restituera correctement, en étant capable de fournir des indications du
type nombre d'onglets, onglet actif, etc.
Par ailleurs il faut respecter le schéma d'interaction clavier proposé pour
le design pattern; pour le RGAA on ne vérifiera que le support des touches
Entrée, Flèches, Espace, Tab et Echap.

J'ai écrit "tentative de normalisation" car ce doc n'est pas normatif, et
c'est un document de travail en évolution permanente. Le choix du RGAA est
de s'appuyer dessus malgré tout, faute de mieux j'allais dire...
De fait, si les design patterns sont plutôt bien supportés pour certains
composants et pour certaines configurations de consultation, ça peut ne pas
être toujours le cas. D'où l'exigence complémentaire de tester a minima sur
la base de référence définie pour le projet.


Donc en résumé: si on met de l'ARIA, il faut le faire entièrement, et
tester que ça restitue bien. Sinon, on n'en met pas.

Pour le fait que l'on s'adresse à l'auditeur uniquement: en fait le RGAA
est juste une méthode de vérification de conformité. Sa cible est donc
l'auditeur, et il ne serait ni opportun ni pertinent qu'il s'adresse à un
autre type d'intervenant. Même si, bien entendu, sur cette base il est
possible de décliner des méthodes de conception, des précos de
développement, des specs, etc.

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






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


Le 6 octobre 2016 à 12:15, Julie Moynat <juliemoy...@gmail.com> a écrit :

> Merci Aurélien pour ta réponse. C'est vrai que le lien de ce glossaire
> explicite mieux tout ça.
>
> Alex, il semble donc, d'après ce glossaire, qu'on peut aussi définir
> l'état dynamiquement dans le nom (hors HTML5 et hors ARIA) via JavaScript.
> Ce qui nous offre finalement pas mal de possibilités.
>
> La citation : "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."
>
>
> Bonne journée !
>
> Julie
>
>
> Le 6 octobre 2016 à 12:04, Alex Bernier <alex.bern...@braillenet.org> a
> écrit :
>
>> Bonjour,
>>
>> Un script peut être accessible aux technologies d'assistance sans pour
>> autant qu'il utilise ARIA (i.e. quand les rôle, l'état, la propriété...
>> utilisés existent "nativement" en HTML5).
>>
>> Alex
>>
>>
>> On Thu, Oct 06, 2016 at 10:45:04AM +0200, Julie Moynat wrote:
>> >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.
>> >[1]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.
>> >[2]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éco

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

[Olivier Nourry]

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.




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


Le 11 octobre 2016 à 10:49, ROSA Giuseppe (93) <
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’étiquette
> <http://references.modernisation.gouv.fr/rgaa-accessibilite/glossaire.html#tiquette-de-champs-de-formulaire>
> (balise label) ou dans un passage de texte lié au champ par la propriété
> ARIA aria-describedby ou aria-labelledby, cette règle est-elle
> respectée ?"
>
> Pourrait-on considérer qu'on répond implicitement au test du fait que le
> mot "facultatif" n'est pas utilisé ?
>
> Si ce n'est pas le cas pensez-vous qu'il serait préférable de mentionner
> avant le formulaire que "tous les champs sont obligatoires sauf ceux
> indiqués facultatif" ou de conserver la pratique usuelle d'indiquer
> visuellement (par exemple avec *) les champs obligatoires.
>
> Merci pour vos avis.
>
>
> 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
>
>
> ___
> 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] Evaluathon organisé par la DInSIC, le 16 novembre

[Olivier Nourry]

Bonjour à tous,

Avec l'autorisation de Braillenet, je vous transmets l'info suivante:


A l’occasion du Sommet mondial de l’OGP organisé par la France en décembre
2016 à Paris et de la Semaine de l’innovation Publique, la direction
interministérielle du numérique et du système d’information de l’Etat a le
plaisir de vous inviter au



*1er Evaluathon, le salon de l’évaluation par les usagers de l’inclusion
des services publics numériques*

*le 16 novembre*

de 10h à 13h00

dans les locaux de Superpublic

4 rue la Vacquerie  - 75011 Paris



Vous êtes un particulier, un professionnel ou une association ? En
situation de handicap ou non ? Venez aider les administrations à vous
proposer des services numériques adaptés à vos besoins.



Voici les services numériques que nous vous proposons de découvrir, tester
et commenter cette année :


   - Séjour Intégré, le service de demandes de séjour pour les étrangers
   souhaitant s’établir en France (Ministère de l’Intérieur)
   - ARPENT, le service permettant aux candidats libres de s'inscrire aux
   examens de l'enseignement agricole (Ministère de l’Agriculture et de la
   Forêt)
   -  Portail des Opérations Funéraires destiné aux familles endeuillées et
   aux professionnels (Ministère des Affaires Sociales)
   -  Portail de Paris pour les services « stationnement résidentiel et
   professionnel » et « calcul de coefficient familial » (Mairie de Paris)
   -  TPS, le service de Télé Procédures Simplifiées pour les particuliers,
   les professionnels et les administrations (Services du Premier
   Ministre/SGMAP)
   -  ALICEM, le service d’identification et d’authentification sécurisée à
   partir d’un titre électronique (exemple : passeport, titre de séjour)
   (Ministère de l’Intérieur / Agence Nationale des Titres Sécurisés)
   -  ENSAP, le portail d’information, de démarches et de la
   dématérialisation des bulletins de paie et de pension (Ministères
   Economiques et Financiers)



Vos réactions, avis et propositions permettront de définir les actions
nécessaires à l’amélioration de ces services numériques avant leur mise en
production, notamment en matière d’accessibilité numérique. L’évaluathon
fera également l’objet d’un retour d’expérience et d’échanges sur les
démarches d’inclusion lors du Sommet mondial de l’OGP.



Gratuit, sur réservation :
https://www.eventbrite.fr/e/billets-evaluathon-le-salon-de-levaluation-par-les-usagers-de-linclusion-des-services-publics-numeriques-28501081502


*Moyens d’accès* :



*Métros : *Philippe Auguste (ligne 2), Charonne ou Voltaire (ligne 9)

*Bus : *Saint-Maur Servan (lignes 61 et 69), Charonne-Voltaire (ligne 76),
Voltaire Léon Blum (lignes 46 et 56)



[image: --]
Olivier Nourry
[image: 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

Re: [Liste GTA] Livre blanc "L'accessibilité des sites Web et des applications pour les mobiles"

[Olivier Nourry]

Bonjour Maud,
Oui, ce document a vocation à être diffusé le plus largement possible!

Cordialement,




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


Le 19 septembre 2016 à 23:35, Maud DUPUIS-CAILLOT <
mdup...@polymorphe-design.fr> a écrit :

> Bonjour
>
> Peut-on diffuser ce document hors GTA ?
>
> Maud DUPUIS-CAILLOT
>
> POLYMORPHE DESIGN
> Tél. : 04 78 66 08 72
> 166 RUE DU GROS BOIS
> 69380 CHAZAY D'AZERGUES
>
> Le 19 sept. 2016 à 22:11, Olivier Nourry <olv.nou...@gmail.com> a écrit :
>
> Alex,
> j'ai tweeté l'annonce de la publication de ce livre blanc, en mentionnant
> les sponsors et les contributeurs. J'ai eu pas mal de retours.
> Par contre Yann Olive me signale à juste titre que les articles sur
> l'atelier et les frameworks auraient dû citer Jérôme Botineau comme
> co-auteur.. Peux-tu corriger stp?
>
> Merci d'avance
>
>
>
>
> [image: --]
> Olivier Nourry
> [image: http://]about.me/oliviernourry
> <http://about.me/oliviernourry>
>
>
> Le 19 septembre 2016 à 10:12, Alex Bernier <alex.bern...@braillenet.org>
> a écrit :
>
>> Bonjour à tous,
>>
>> Nous venons de mettre en ligne le livre blanc du 22ème séminaire du
>> Groupe de Travail AccessiWeb, sur "L'accessibilité des sites Web et des
>> applications pour les mobiles". Au sommaire : la prise en compte des
>> mobiles dans le RGAA, une présentation des guides d'accompagnements sur la
>> conception, le développement et le tests d'applications mobiles, un retour
>> d'expérience d'Orange, un compte-rendu de notre atelier de tests, etc. Vous
>> pouvez le télécharger ici : http://tinyurl.com/jxgq3bx
>>
>> Un grand merci aux sponsors qui ont soutenu ce séminaire : Access42,
>> BlaBlacar, Smile et V-Technologies !
>>
>>
>> Nous finalisons le programme du prochain séminaire, sur
>> l'industrialisation de l'accessibilité. Ce sera le 28 septembre à la Cité
>> des Sciences. Inscription à cette adresse :
>> http://gta23.braillenet.org/evenements/colloques/colloques/
>> 91_index_fr.html
>>
>> Cordialement,
>>
>> Alex Bernier
>> --
>> Directeur
>>
>> Association BrailleNet
>> 12bis avenue Maurice Thorez
>> 94200 Ivry sur Seine
>>
>> Tél. + 33 1 85 09 05 13
>>
>> Fax  + 33 1 46 70 35 84
>>
>> ___
>> 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] Livre blanc "L'accessibilité des sites Web et des applications pour les mobiles"

[Olivier Nourry]

Alex,
j'ai tweeté l'annonce de la publication de ce livre blanc, en mentionnant
les sponsors et les contributeurs. J'ai eu pas mal de retours.
Par contre Yann Olive me signale à juste titre que les articles sur
l'atelier et les frameworks auraient dû citer Jérôme Botineau comme
co-auteur.. Peux-tu corriger stp?

Merci d'avance




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


Le 19 septembre 2016 à 10:12, Alex Bernier <alex.bern...@braillenet.org> a
écrit :

> Bonjour à tous,
>
> Nous venons de mettre en ligne le livre blanc du 22ème séminaire du Groupe
> de Travail AccessiWeb, sur "L'accessibilité des sites Web et des
> applications pour les mobiles". Au sommaire : la prise en compte des
> mobiles dans le RGAA, une présentation des guides d'accompagnements sur la
> conception, le développement et le tests d'applications mobiles, un retour
> d'expérience d'Orange, un compte-rendu de notre atelier de tests, etc. Vous
> pouvez le télécharger ici : http://tinyurl.com/jxgq3bx
>
> Un grand merci aux sponsors qui ont soutenu ce séminaire : Access42,
> BlaBlacar, Smile et V-Technologies !
>
>
> Nous finalisons le programme du prochain séminaire, sur
> l'industrialisation de l'accessibilité. Ce sera le 28 septembre à la Cité
> des Sciences. Inscription à cette adresse : http://gta23.braillenet.org/
> evenements/colloques/colloques/91_index_fr.html
>
> Cordialement,
>
> Alex Bernier
> --
> Directeur
>
> Association BrailleNet
> 12bis avenue Maurice Thorez
> 94200 Ivry sur Seine
>
> Tél. + 33 1 85 09 05 13
>
> Fax  + 33 1 46 70 35 84
>
> ___
> 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] tableaux de données générés à la volée qui passent de simple à complexe

[Olivier Nourry]

Bonjour Marie, et merci pour cette réponse.
Effectivement le fait de passer l'info "en plus" dans un conteneur "tiers"
(que ce soit une pop-in, une tooltip ou autre) pourrait permettre de
contourner le problème. Je vais approfondir cette piste!




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


Le 2 août 2016 à 16:15, Marie Hanotte <m.hano...@acti.fr> a écrit :

>
> *Bonjour Olivier,*
>
> Je me permets de rebondir bien tardivement sur cette question des
> tableaux...
> J'avais rencontré un cas similaire il y a quelques mois.
>
> De notre côté nous avions opté pour le système de pop-in simple pour
> afficher le "sous-contenu", afin d'éviter les développement
> supplémentaires.
> Cela nous permettait également de gérer le comportement responsive plus
> facilement : par défaut c'est un lien vers une nouvelle page, mais si
> l'écran est assez grand on charge le contenu interne de cette page dans une
> pop-in.
>
> Dans notre cas, c'était d'autant plus pertinent que le sous-contenu était
> assez massif pour justifier d'avoir une page à part entière, mais je peux
> comprendre que ce ne soit pas forcément adapté s'il s'agit de quelques
> infos supplémentaires uniquement.
>
> Dans ce cas-là, mon avis serait qu'il faut trouver une structure de
> tableau qui permette d'avoir ce sous-contenu présent par défaut et gérer
> uniquement l'affichage/masquage visuel, pour éviter la modification de
> structure à la volée.
> Sachant qu'il est quasi-impossible de faire ça a posteriori sans impacter
> le design, d'où l'intérêt de valider ce type de concept bien en amont dans
> le projet.
>
> D'une certaine manière, je trouve que ce questionnement rejoint la
> problématique des tableaux responsive, où la structure peut changer
> complètement sur petits écrans.
> Il me semble que tu avais aussi soulevé la question dans la liste GTA,
> sans que cela ait déclenché de discussion.
>
> Pour moi, s'il doit y avoir une grosse différence d'affichage, je
> privilégie une structure de liste, qui permet d'être beaucoup plus souple
> sur le rendu visuel, quitte à simuler visuellement un tableau sur grands
> écrans (ne faire apparaitre les titres que sur le premier élément, égaliser
> les "colonnes"...).
>
> J'ai eu par contre le cas d'un tableau d'horaires, qui était difficilement
> réajustable sans perdre de la signification. Dans cette situation, j'ai
> privilégié alors de garder la structure et la forme de tableau, même sur
> petits écrans, avec un scroll horizontal.
> L'enjeu était alors de signifier visuellement que du contenu "déborde"
> d'un côté, et de garder les en-têtes de ligne visibles. Nous l'avons fait
> avec un système d'ombre sur le côté et du positionnement en javascript.
> Voici un exemple : http://codepen.io/mh-nichts/full/KrxmqK/
> Je serais d'ailleurs curieuse d'avoir des avis là-dessus, il y a peut-être
> des problématiques de navigation dans le tableau auxquelles je n'aurais pas
> pensé.
>
> Voilà, je serais autant intéressée qu'Olivier d'avoir des idées de
> structures, et voir si d'autres personnes ont rencontré des cas de gestion
> un peu complexes de tableaux et surtout quelles solutions ont été mises en
> place !
>
> Cordialement,
>
> *Marie Hanotte* // Intégratrice multimédia - *Interactive Designer*
> [image: Experte Accessiweb]
> <http://www.accessiweb.org/index.php/fiche_gta_experts/items/hanotte-marie.html>
>   [image: 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>
> [image: acti a le plaisir de présenter le livre À la Conquête du Social
> Media]
> <http://www.acti.fr/blog/acti-est-fier-de-presenter-le-livre-a-la-conquete-du-social-media/>
> Le 01/07/2016 à 16:05, Olivier Nourry a écrit :
>
> Bonjour la liste,
>
> Une page que j'audite me pose une colle, et je n'aipas trouvé d esolution
> élégante.
>
> On a un tableau de données simple, avec des données en colonne (8
> colonnes), donc scope="col" sur les TH, normal.
> Mais quand on clique sur un bouton "détails" dans l'une des colonnes, on
> génère à la volée un sous tableau, avec moins de colonnes. L'intégrateur a
> mis ce sous-tableau dans une ligne à une cellule (colspan=7 sur le TD).
> Du coup, le tableau qui était simple devient complexe, du fait de cette
> fusion et d'une mécanique différente pour les entêtes. Et donc on devrait
> passer à une structure id/headers.
> Mais franchement je

[Liste GTA] tableaux de données générés à la volée qui passent de simple à complexe

[Olivier Nourry]

Bonjour la liste,

Une page que j'audite me pose une colle, et je n'aipas trouvé d esolution
élégante.

On a un tableau de données simple, avec des données en colonne (8
colonnes), donc scope="col" sur les TH, normal.
Mais quand on clique sur un bouton "détails" dans l'une des colonnes, on
génère à la volée un sous tableau, avec moins de colonnes. L'intégrateur a
mis ce sous-tableau dans une ligne à une cellule (colspan=7 sur le TD).
Du coup, le tableau qui était simple devient complexe, du fait de cette
fusion et d'une mécanique différente pour les entêtes. Et donc on devrait
passer à une structure id/headers.
Mais franchement je ne me vois pas imposer ça, compte tenu de la complexité
du script à prévoir, et surtout parce qu'au final on aura un bouzin sans
doute conforme mais pas franchement utilisable.

Je fais donc appel à votre créativité... Quelle structure HTML pourrait-on
proposer?

J'avais pensé à une modale déguisée en sous-tableau, ce qui alourdirait
l'interface pour la fermeture, potentiellement, mais laisse plus de chances
aux utilisateurs de comprendre la structure.
Vos avis?

Merci d'avance,



[image: --]
Olivier Nourry
[image: 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

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

[Olivier Nourry]

Hello,
Il me semble que le problème avec les solutions sur base de background est
que ça coince avec les options de modifications de couleurs au niveau de
Windows. Tandis que l'outline marche dans tous les cas.
Mais à vérifier...




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


Le 3 juin 2016 à 12:02, Steven Mouret <steven.mou...@gmail.com> a écrit :

> Salut Aurélien,
>
> Merci pour ta réponse.
>
> Du coup est ce un problème de RGAA ou y a t-il un réel problème à utiliser
> autre chose que outline ? Peut-être existe t-il des aides techniques qui
> utilisent outline.
>
>
>
>
> --
> Steven Mouret
>
> Le 3 juin 2016 à 11:37, Aurélien Levy <aurelien.l...@temesis.com> a écrit
> :
>
>> 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 
>> listliste_gta@list.accessiweb.orghttp://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>>
>>
>>
>> --
>> Aurélien Levy
>> 
>> Temesis
>>
>>
>> ___
>> liste_gta mailing list
>> liste_gta@list.accessiweb.org
>> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>>
>>
>
> ___
> liste_gta mailing list
> liste_gta@list.accessiweb.org
> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
>
>
___
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org

Re: [Liste GTA] Que penser des pistes audio qui se déploient sur les sites actuellement ?

[Olivier Nourry]

@giuseppe @steven
a priori le problème se pose sur les pages où il y a le bouton de recherche
(donc pas sur la home)
(merci @goetsu pour l'info et la confirmation)




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


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

> Bonjour,
>
> Je ne vois pas de piège au clavier non plus : firefox 46, body à 1664 px,
> ni sous chrome !
>
> 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
>
>
>  Message original 
> Sujet : Re: [Liste GTA] Que penser des pistes audio qui se déploient sur
> les sites actuellement ?
> De : Olivier Nourry <olv.nou...@gmail.com> <olv.nou...@gmail.com>
> Pour : liste_gta@list.accessiweb.org <liste_gta@list.accessiweb.org>
> <liste_gta@list.accessiweb.org>
> Date : 11/05/2016 10:50
>
> Hello,
>
> Vous m'avez mis le doute, alors j'ai vérifié, et en fait c'est un exemple
> encore plus intéressant!
> Le problème de piège au clavier apparaît quand la largeur de body est
> supérieure ou égale à 1160px. Le site étant responsive, en dessous de cette
> largeur, un menu burger remplace le menu "étalé", et là on arrive bien à
> tabuler dans le contenu. Par contre, au-delà (menu étalé en largeur), le
> bug se vérifie sur Chrome ET Firefox...
>
> Une preuve de plus que pour tester, désormais, il faut détecter les
> breakpoints et valider sous les différentes tailles, en particulier lorsque
> des éléments interactifs sont en jeu.
>
>
>
>
> [image: --]
> Olivier Nourry
> [image: http://]about.me/oliviernourry
> <http://about.me/oliviernourry>
>
>
> Le 11 mai 2016 à 10:20, Webmaster <webmas...@avh.asso.fr> a écrit :
>
>> Bonjour Olivier,
>>
>>
>>
>> Idem, je ne vois pas de problème avec le bandeau sous Chrome.
>>
>> Par contre, il y a une rubrique cachée.
>>
>>
>>
>>
>>
>> [image: Accueil du site Association Valentin Haüy (Logo)]
>> <http://www.avh.asso.fr/>
>>
>> *Marc-Antoine Bonnet*
>>
>> Webmaster Internet/Intranet
>> Expert accessibilité Web (EAE AccessiWeb)
>> *Email : **webmas...@avh.asso.fr* <webmas...@avh.asso.fr>
>>
>>
>> * association Valentin Haüy Siège*
>>
>> *Tel : *01 44 49 27 27 *– Poste *2219
>> * 5 rue Duroc – 75343 Paris cedex 07*
>>
>>
>>
>> [image: Partagez sur Facebook !]
>> <http://www.facebook.com/pages/Association-Valentin-Hauy-AVH/162383987105585>[image:
>> Partagez sur Twitter !] <http://www.twitter.com/ValentinHauy>[image:
>> Partagez sur Youtube !] <http://www.youtube.com/user/AssoValentinHauy>[image:
>> Consultez nos E-newsletter !]
>> <http://www.avh.asso.fr/rubriques/newsletter/dernier_enews.php>
>>
>>
>>
>>
>>
>> *De :* liste_gta [mailto:liste_gta-boun...@list.accessiweb.org] *De la
>> part de* Olivier Nourry
>> *Envoyé :* mercredi 11 mai 2016 09:49
>> *À :* liste_gta@list.accessiweb.org
>> *Objet :* Re: [Liste GTA] Que penser des pistes audio qui se déploient
>> sur les sites actuellement ?
>>
>>
>>
>> Bonjour Steven,
>>
>> Sous Chrome (Windows), tu mets le focus sur la barre d'adresse, et tu
>> tabules. Le focus circule en boucle dans le bandeau.
>>
>> Le mercredi 11 mai 2016, Steven Mouret <steven.mou...@gmail.com> a
>> écrit :
>>
>> Plutôt d'accord avec Olivier, combien de clients j'ai qui demandent une
>> vocalisation des pages mais qui ne souhaitent pas une simple formation des
>> contributeurs en accessibilité. Je ne sais pas si c'est la méconnaissance
>> de ce qu'est l'accessibilité ou juste une simple volonté de faire croire
>> que. Surement un peu des deux.
>>
>>
>>
>> NB : Olivier je ne vois pas le piège au clavier dans le bandeau.
>>
>>
>>
>> --
>> Steven Mouret
>>
>>
>>
>> Le 10 mai 2016 à 11:04, Olivier Nourry <olv.nou...@gmail.com> a écrit :
>>
>> Bonjour Nathalie,
>>
>>
>>
>> Normal que tu n'arrives à atteindre le lecteur au clavier, c'est un
>> simple paragraphe, sans tabindex. Aucune chance d'y arriver!
>>
>>
>>
>> Ma position personnelle: je n'ai rien contre les outils de vocalisation
>> on

Re: [Liste GTA] Que penser des pistes audio qui se déploient sur les sites actuellement ?

[Olivier Nourry]

Hello,

Vous m'avez mis le doute, alors j'ai vérifié, et en fait c'est un exemple
encore plus intéressant!
Le problème de piège au clavier apparaît quand la largeur de body est
supérieure ou égale à 1160px. Le site étant responsive, en dessous de cette
largeur, un menu burger remplace le menu "étalé", et là on arrive bien à
tabuler dans le contenu. Par contre, au-delà (menu étalé en largeur), le
bug se vérifie sur Chrome ET Firefox...

Une preuve de plus que pour tester, désormais, il faut détecter les
breakpoints et valider sous les différentes tailles, en particulier lorsque
des éléments interactifs sont en jeu.




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


Le 11 mai 2016 à 10:20, Webmaster <webmas...@avh.asso.fr> a écrit :

> Bonjour Olivier,
>
>
>
> Idem, je ne vois pas de problème avec le bandeau sous Chrome.
>
> Par contre, il y a une rubrique cachée.
>
>
>
>
>
> [image: Accueil du site Association Valentin Haüy (Logo)]
> <http://www.avh.asso.fr/>
>
> *Marc-Antoine Bonnet*
>
> Webmaster Internet/Intranet
> Expert accessibilité Web (EAE AccessiWeb)
> *Email : **webmas...@avh.asso.fr* <webmas...@avh.asso.fr>
>
>
> * association Valentin Haüy Siège*
>
> *Tel : *01 44 49 27 27 *– Poste *2219
> * 5 rue Duroc – 75343 Paris cedex 07*
>
>
>
> [image: Partagez sur Facebook !]
> <http://www.facebook.com/pages/Association-Valentin-Hauy-AVH/162383987105585>[image:
> Partagez sur Twitter !] <http://www.twitter.com/ValentinHauy>[image:
> Partagez sur Youtube !] <http://www.youtube.com/user/AssoValentinHauy>[image:
> Consultez nos E-newsletter !]
> <http://www.avh.asso.fr/rubriques/newsletter/dernier_enews.php>
>
>
>
>
>
> *De :* liste_gta [mailto:liste_gta-boun...@list.accessiweb.org] *De la
> part de* Olivier Nourry
> *Envoyé :* mercredi 11 mai 2016 09:49
> *À :* liste_gta@list.accessiweb.org
> *Objet :* Re: [Liste GTA] Que penser des pistes audio qui se déploient
> sur les sites actuellement ?
>
>
>
> Bonjour Steven,
>
> Sous Chrome (Windows), tu mets le focus sur la barre d'adresse, et tu
> tabules. Le focus circule en boucle dans le bandeau.
>
> Le mercredi 11 mai 2016, Steven Mouret <steven.mou...@gmail.com> a écrit :
>
> Plutôt d'accord avec Olivier, combien de clients j'ai qui demandent une
> vocalisation des pages mais qui ne souhaitent pas une simple formation des
> contributeurs en accessibilité. Je ne sais pas si c'est la méconnaissance
> de ce qu'est l'accessibilité ou juste une simple volonté de faire croire
> que. Surement un peu des deux.
>
>
>
> NB : Olivier je ne vois pas le piège au clavier dans le bandeau.
>
>
>
> --
> Steven Mouret
>
>
>
> Le 10 mai 2016 à 11:04, Olivier Nourry <olv.nou...@gmail.com> a écrit :
>
> Bonjour Nathalie,
>
>
>
> Normal que tu n'arrives à atteindre le lecteur au clavier, c'est un simple
> paragraphe, sans tabindex. Aucune chance d'y arriver!
>
>
>
> Ma position personnelle: je n'ai rien contre les outils de vocalisation
> on-page, tant qu'ils ne prétendent pas être autre chose que ce qu'ils sont:
> une simple version vocale d'un contenu textuel. Leur efficacité est
> directement liée à l'accessibilité du code en lui-même.
>
>
>
> Alors quand je vois sur le site de Voxygen, éditeur de la solution
> utilisée sur paris.fr:
>
> "Voxygen WebReader est un outil de lecture vocale de sites qui garantit
> l’accessibilité vocale de votre site internet pour tous : seniors, enfants,
> malvoyants, non-voyants, illettrés, dyslexiques et pour toutes les
> personnes plus à l’aise à l’oral qu’à l’écrit.
>
> Avec Voxygen WebReader, **vous vous mettez en conformité avec la norme
> RGAA** et vous renforcez votre image RSE." (emphase par moi)
>
>
> ...je suis plus qu'énervé. Une telle déclaration est juste mensongère, et
> irrespectueuse des utilisateurs.
>
> D'autres éditeurs, comme Readspeaker, ont un discours bien plus sensé et
> mesuré, et c'est tout à leur honneur.
>
>
>
> Que des acheteurs crédules se laissent avoir par ce genre d'arguments pose
> un problème de fond très sérieux: les maigres budgets que l'on daigne
> consacrer à l'accessibilité partent dans ce genre de produits, au détriment
> d'une action de fond bien plus profitable aux utilisateurs, comme une
> formation intra ou un accompagnement.
>
>
>
> Par ailleurs j'estime que nous avons, au titre de notre devoir de conseil,
> une responsabilité dans le fait de déjouer ces arguments foireux, et
> néfastes pour la "vraie" accessibilité.
>
>
>
> NB: le bandeau de paris.fr est un magnifique exemple d

Re: [Liste GTA] Que penser des pistes audio qui se déploient sur les sites actuellement ?

[Olivier Nourry]

Bonjour Steven,
Sous Chrome (Windows), tu mets le focus sur la barre d'adresse, et tu
tabules. Le focus circule en boucle dans le bandeau.

Le mercredi 11 mai 2016, Steven Mouret <steven.mou...@gmail.com> a écrit :

> Plutôt d'accord avec Olivier, combien de clients j'ai qui demandent une
> vocalisation des pages mais qui ne souhaitent pas une simple formation des
> contributeurs en accessibilité. Je ne sais pas si c'est la méconnaissance
> de ce qu'est l'accessibilité ou juste une simple volonté de faire croire
> que. Surement un peu des deux.
>
> NB : Olivier je ne vois pas le piège au clavier dans le bandeau.
>
>
> --
> Steven Mouret
>
> Le 10 mai 2016 à 11:04, Olivier Nourry <olv.nou...@gmail.com
> <javascript:_e(%7B%7D,'cvml','olv.nou...@gmail.com');>> a écrit :
>
>> Bonjour Nathalie,
>>
>> Normal que tu n'arrives à atteindre le lecteur au clavier, c'est un
>> simple paragraphe, sans tabindex. Aucune chance d'y arriver!
>>
>> Ma position personnelle: je n'ai rien contre les outils de vocalisation
>> on-page, tant qu'ils ne prétendent pas être autre chose que ce qu'ils sont:
>> une simple version vocale d'un contenu textuel. Leur efficacité est
>> directement liée à l'accessibilité du code en lui-même.
>>
>> Alors quand je vois sur le site de Voxygen, éditeur de la solution
>> utilisée sur paris.fr:
>> "Voxygen WebReader est un outil de lecture vocale de sites qui garantit
>> l’accessibilité vocale de votre site internet pour tous : seniors, enfants,
>> malvoyants, non-voyants, illettrés, dyslexiques et pour toutes les
>> personnes plus à l’aise à l’oral qu’à l’écrit.
>>
>> Avec Voxygen WebReader, **vous vous mettez en conformité avec la norme
>> RGAA** et vous renforcez votre image RSE." (emphase par moi)
>>
>> ...je suis plus qu'énervé. Une telle déclaration est juste mensongère, et
>> irrespectueuse des utilisateurs.
>> D'autres éditeurs, comme Readspeaker, ont un discours bien plus sensé et
>> mesuré, et c'est tout à leur honneur.
>>
>> Que des acheteurs crédules se laissent avoir par ce genre d'arguments
>> pose un problème de fond très sérieux: les maigres budgets que l'on daigne
>> consacrer à l'accessibilité partent dans ce genre de produits, au détriment
>> d'une action de fond bien plus profitable aux utilisateurs, comme une
>> formation intra ou un accompagnement.
>>
>> Par ailleurs j'estime que nous avons, au titre de notre devoir de
>> conseil, une responsabilité dans le fait de déjouer ces arguments foireux,
>> et néfastes pour la "vraie" accessibilité.
>>
>> NB: le bandeau de paris.fr est un magnifique exemple de piège au
>> clavier, soit dit en passant!
>>
>>
>> [image: --]
>> Olivier Nourry
>> [image: http://]about.me/oliviernourry
>> <http://about.me/oliviernourry>
>>
>>
>> Le 9 mai 2016 à 13:53, Rosenberg Nathalie <nathalie_rosenb...@yahoo.fr
>> <javascript:_e(%7B%7D,'cvml','nathalie_rosenb...@yahoo.fr');>> a écrit :
>>
>>> Bonjour
>>>
>>> Je commence à voir pas mal de sites qui ont des pistes audio de leurs
>>> contenus. J'aimerais votre avis sur le sujet.
>>>
>>> Ex :
>>>
>>> http://www.paris.fr/services-et-infos-pratiques/logement/logement-social/demander-un-logement-social-37
>>>
>>>
>>> http://www.carsat-mp.fr/telechargements/flipbook/entretien_information_retraite/entretien_information_retraite.html#p=1
>>>
>>> Dans les 2 cas, je n'ai pas réussi à atteindre le bouton d'envoi en
>>> naviguant au clavier (mais c'est peut-être parce que c'est mal conçu)
>>>
>>> <http://www.linkedin.com/in/nathalierosenberg>
>>>
>>> ___
>>> 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
>>>
>>>
>>
>> ___
>> 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
>>
>>
>

-- 



[image: --]
Olivier Nourry
[image: 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

Re: [Liste GTA] Que penser des pistes audio qui se déploient sur les sites actuellement ?

[Olivier Nourry]

Bonjour Nathalie,

Normal que tu n'arrives à atteindre le lecteur au clavier, c'est un simple
paragraphe, sans tabindex. Aucune chance d'y arriver!

Ma position personnelle: je n'ai rien contre les outils de vocalisation
on-page, tant qu'ils ne prétendent pas être autre chose que ce qu'ils sont:
une simple version vocale d'un contenu textuel. Leur efficacité est
directement liée à l'accessibilité du code en lui-même.

Alors quand je vois sur le site de Voxygen, éditeur de la solution utilisée
sur paris.fr:
"Voxygen WebReader est un outil de lecture vocale de sites qui garantit
l’accessibilité vocale de votre site internet pour tous : seniors, enfants,
malvoyants, non-voyants, illettrés, dyslexiques et pour toutes les
personnes plus à l’aise à l’oral qu’à l’écrit.

Avec Voxygen WebReader, **vous vous mettez en conformité avec la norme
RGAA** et vous renforcez votre image RSE." (emphase par moi)

...je suis plus qu'énervé. Une telle déclaration est juste mensongère, et
irrespectueuse des utilisateurs.
D'autres éditeurs, comme Readspeaker, ont un discours bien plus sensé et
mesuré, et c'est tout à leur honneur.

Que des acheteurs crédules se laissent avoir par ce genre d'arguments pose
un problème de fond très sérieux: les maigres budgets que l'on daigne
consacrer à l'accessibilité partent dans ce genre de produits, au détriment
d'une action de fond bien plus profitable aux utilisateurs, comme une
formation intra ou un accompagnement.

Par ailleurs j'estime que nous avons, au titre de notre devoir de conseil,
une responsabilité dans le fait de déjouer ces arguments foireux, et
néfastes pour la "vraie" accessibilité.

NB: le bandeau de paris.fr est un magnifique exemple de piège au clavier,
soit dit en passant!


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


Le 9 mai 2016 à 13:53, Rosenberg Nathalie <nathalie_rosenb...@yahoo.fr> a
écrit :

> Bonjour
>
> Je commence à voir pas mal de sites qui ont des pistes audio de leurs
> contenus. J'aimerais votre avis sur le sujet.
>
> Ex :
>
> http://www.paris.fr/services-et-infos-pratiques/logement/logement-social/demander-un-logement-social-37
>
>
> http://www.carsat-mp.fr/telechargements/flipbook/entretien_information_retraite/entretien_information_retraite.html#p=1
>
> Dans les 2 cas, je n'ai pas réussi à atteindre le bouton d'envoi en
> naviguant au clavier (mais c'est peut-être parce que c'est mal conçu)
>
> <http://www.linkedin.com/in/nathalierosenberg>
>
> ___
> 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] Structure Fil d'Ariane

[Olivier Nourry]

Salut Steven,

Arf, l'exemple WCAG qui tue!! Bon visiblement ils sont pas d'accord avec
moi. Je trouve un peu bidon l'argument de donner à l'utilisateur un numéro
d'item via la structure UL, je ne vois pas trop ce que cela apporte de
savoir que l'on est sur l'item n°3, sous entendu 3ème niveau d'arbo, dans
ce cas de figure. Je ne dis pas que ça ne sert à rien du tout, mais mis en
balance avec le surplus de vocalisation, je ne suis pas certain que c'est
gagnant.
On a eu l'avis de Sylvie (qui penchait pour la succession de liens à plat),
d'autres avis seraient bienvenus!

Sur la balise NAV, pareil, je suis circonspect. En fait il y a peut-être
une divergence WCAG/RGAA ici. Car tel que c'est rédigé dans le RGAA
(critère 9.2 notamment), pour moi NAV est l'apanage des menus,
exclusivement. Or, si la balise  existait, il ne me viendrait pas à
l'idée de la mettre sur un fil d'Ariane... Car en soi ce n'est pas un menu
dans le sens: liste exhaustive des liens d'une section donnée.
On peut le voir sous un autre angle: si j'ai, mettons, un plan de site et
un fil d'Ariane, et rien d'autre, je ne validerai pas le critère 12.1 ("au
moins 2 systèmes de navigation"), considérant que le fil d'Ariane ne répond
pas au besoin d'un système de navigation me permettant de parcourir
l'ensemble du site (fonctionnellement c'est juste un rappel de la position
courante, et parfois il n'y a même pas de liens). Si je veux rester
cohérent avec cette position (qui parait logique), je ne peux pas
considérer le fil d'Ariane comme un menu de navigation.

Mais bon, j'ai peut-être juste mal compris la nuance menu/barre de
navigation!




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


Le 21 avril 2016 à 17:13, Steven Mouret <steven.mou...@gmail.com> a écrit :

> Plutôt d'accord pour la liste ordonnées, trop verbeux et ça n'apporte pas
> grand chose finalement comme le précise Sylvie et Olivier.
>
> Pour le title, je me demande toujours si tous les utilisateurs comprennent
> qu'on est sur une page en cours si on ne met pas le lien. Sylvie je veux
> bien ton retour sur ce point.
>
> Par contre pour le role navigation, pour moi le fil d'Ariane est une
> navigation à part entière. La fonction première et d'indiquer ou l'on se
> trouve mais il permet aussi de remonter dans l'arborescence du site.
>
> Le W3C explique bien ce qu'il ne faut pas faire dans l'exemple 3 :D
> (sourire)
> https://www.w3.org/TR/WCAG-TECHS/G65.html
>
>
> --
> Steven Mouret
>
> Le 21 avril 2016 à 17:03, Sylvie Duchateau <sduchat...@access42.net> a
> écrit :
>
>> Bonjour Ariane,
>>
>> Merci pour ton fil :-)
>>
>> Si la "page en cours" est un lien, ça peut être utile de préciser qu'il
>> s'agit de la page actuelle. Si le lien est désactivé, pas la peine de dire
>> qu'il s'agit de la page en cours.
>>
>> Le souci avec les listes ordonnées, cela fait un truc en plus à lire pour
>> le lecteur d'écran, donc encore plus d'info vocalisée.
>>
>> Sylvie
>> Le 21/04/2016 à 16:12, Ariane Andurand a écrit :
>>
>> Pour faire sourire Sylvie ;-) ... voilà Ariane qui s'en mêle !
>>
>> title="dolor (page en cours)"  >> est-ce bénéfique le "page en cours"
>> côté utilisateur j'entends ?
>>
>> Le 21 avril 2016 à 15:56, <san...@free.fr> a écrit :
>>
>>> ... mais sémantiquement fort à propos :)
>>> en revanche la liste de définition, c'est beurk, à  ne pas utiliser, un
>>> fil d'ariane n'est pas une liste de définition !
>>> a+
>>>
>>> Vincent just on time this time !
>>>
>>> - Mail original -
>>> De: "Steven Mouret" <steven.mou...@gmail.com>
>>> À: "liste gta" <liste_gta@list.accessiweb.org>
>>> Envoyé: Jeudi 21 Avril 2016 15:34:50
>>> Objet: Re: [Liste GTA] Structure Fil d'Ariane
>>>
>>>
>>>
>>> Pour ma part, j'utilise cette structure :
>>>
>>> 
>>> Vous êtes ici : 
>>> 
>>> Accueil
>>> lorem
>>> ipsum
>>> dolor
>>> 
>>> 
>>>
>>>
>>> Un peu verbeux.
>>>
>>>
>>>
>>>
>>> --
>>> Steven Mouret
>>>
>>> Le 21 avril 2016 à 15:25, Anthony Ladeuil < <anth...@ladeuil.com>
>>> anth...@ladeuil.com > a écrit :
>>>
>>>
>>>
>>>
>>> Hello tout le monde
>>>
>>>
>>> Pour ma part j'aime bien utiliser la structure suivante :
>>>
>>>
>>> 
>>> Vous êtes ici : 
>>> 
>>> accueil
>>> 
&

Re: [Liste GTA] Structure Fil d'Ariane

[Olivier Nourry]

Salut Vincent,
Allez, c'est vendredi, on lâche les trolls!

Je suis à fond pour la sémantique, avec une limite: le bénéfice
utilisateurs. Si une structure est correcte sur le plan de la sémantique,
mais génère du bruit, je ne l'utilise pas.

Concernant les OL pour un fil d'Ariane: pour le coup, en plus je pense que
ce n'est pas adapté à la situation. Je vais tenter de le démontrer par
l'absurde.

Tentative 1:
Tu as un article long réparti sur 4 pages. Tu proposes une liste de liens
pour passer de l'une à l'autre. Naturellement tu vas utiliser une liste OL
de liens, car ces 4 pages font partie d'un ensemble, qu'il faut lire dans
l'ordre indiqué pour faire sens. Incontestable, non?
Mais la structure que tu proposes est strictement identique, pour quelque
chose qui conceptuellement est très différent. Comment l'utilisateur non
visuel peut faire la distinction entre 4 pages qu'il faut lire dans un
ordre donné, et 4 pages "en branche", si la structure et donc la
restitution est la même?
AMHA ça invalide l'option OL pour un fil d'Ariane, car crée une confusion
avec autre chose.

Tentative 2: admettons que tu codes l'arborescence complète du site, avec x
rubriques, y sous-rubriques, comportant chacune z pages. Naturellement, tu
vas faire une liste UL de x éléments (rubriques), ayant y enfants qui sont
des listes ayant z items (pages). Tu aurais donc 2 listes UL imbriquées, ce
qui donnerait:

Rubrique 1

 Sous-rubrique 1
 
  page 1
  ...
  page z
  
 
 Sous-rubrique 2
 
  page 1
  ...
  page z
  
 


Rubrique 2>[tout le bazar au-dessus]


Dans cette configuration il ne te viendrait jamais à l'idée de construire
chaque branche comme une liste OL à 1 niveau, ça n'aurait aucun sens. Les
pages d'une branche donnée ne sont pas de même niveau, donc l'utilisateur
ne devrait pas recevoir une info qui suggère cela (ce qui est le cas si on
met tout dans une même liste); d'autre part il n'y a pas d'ordre de lecture
particulier, on peut consulter dans l'ordre que l'on veut sans problème de
compréhension, donc pas d'ordre suggéré par la structure (donc pas OL).
Or le Fil d'Ariane n'est ni plus ni moins que la branche courante, détachée
de l'arbo. Donc pourquoi devrait-elle tout à coup changer radicalement de
nature?
Avec cet exemple on pourrait se dire: pour le fil d'Ariane faudrait donc
des UL imbriquées à 1 item? Sauf qu'on atteint la limite de la sémantique:
elle pénalise plus qu'elle n'aide. Donc, non.

Voilà pourquoi, perso, je me contente de liens successifs, n'ayant rien de
plus pertinent sous la main.


PS: après chacun fait comme il le sent, hein! ;) [clin d’œil]




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


Le 21 avril 2016 à 16:58, <san...@free.fr> a écrit :

> Olivier,
> je veux pas troller mais j'ai des réserves :
> si ton fil d'ariane est collé (côte à côte niveau code) à un menu de nav,
> ou si ton site a peu de role=navigation (par exemple qu'un seul menu de
> navig principal), il me semble que l'on puisse mettre le fil d'ariane dans
> une grande div role=navigation.
> Second point, moi j'aime quand y'a de la sémantique et donc une liste de
> liens à plat, en plus sans role=navigation, ça me chagrine, c'est dommage
> de ne pas utiliser la liste ordonnée pour dire on a la rubrique X, en
> premier, en second (dedans), la sous rubrique XY... ett enfin qu'on est là !
> pourquoi s'en priver ?
>
> - Mail original -
> De: "Olivier Nourry" <olv.nou...@gmail.com>
> À: "liste gta" <liste_gta@list.accessiweb.org>
> Envoyé: Jeudi 21 Avril 2016 16:35:22
> Objet: Re: [Liste GTA] Structure Fil d'Ariane
>
>
>
> Hmm, je ne mettrais pas un  personnellement.
> Le référentiel préconise de réserver ces balises et attributs aux menus
> principaux et secondaires. Or, à mon sens le fil d'Ariane n'entre pas dans
> cette définition (menus de navigation au sens RGAA: liens permettant de
> naviguer dans les rubriques d'un site). Le fil d'Ariane est cité
> explicitement dans le glossaire comme étant une barre de navigation
> (nuance!), mais AMHA ce n'est pas dans le scope de NAV et role=navigation.
> Le problème est qu'à ce compte-là, tout ensemble de liens devient une NAV,
> et l'utilisateur perd en lisibilité; ce qui va à l'encontre du bénéfice
> supposé des landmarks. C'est un peu comme les headings: trop de headings
> crée du bruit parasite. Idem pour les labels ARIA surabondants (un peu le
> cas ici, à mon avis).
>
>
> En l'occurrence, le mieux est l'ennemi du bien!
>
>
> Pas convaincu non plus par les OL. OL caractérise une liste d'éléments à
&

Re: [Liste GTA] Structure Fil d'Ariane

[Olivier Nourry]

Hmm, je ne mettrais pas un  personnellement.
Le référentiel préconise de réserver ces balises et attributs aux menus
principaux et secondaires. Or, à mon sens le fil d'Ariane n'entre pas dans
cette définition (menus de navigation au sens RGAA: liens permettant de
naviguer dans les rubriques d'un site). Le fil d'Ariane est cité
explicitement dans le glossaire comme étant une *barre *de navigation
(nuance!), mais AMHA ce n'est pas dans le scope de NAV et role=navigation.
Le problème est qu'à ce compte-là, tout ensemble de liens devient une NAV,
et l'utilisateur perd en lisibilité; ce qui va à l'encontre du bénéfice
supposé des landmarks. C'est un peu comme les headings: trop de headings
crée du bruit parasite. Idem pour les labels ARIA surabondants (un peu le
cas ici, à mon avis).

En l'occurrence, le mieux est l'ennemi du bien!

Pas convaincu non plus par les OL. OL caractérise une liste d'éléments à
consulter dans l'ordre indiqué; ceci, pour moi, sous-entend que les
éléments sont de "même niveau". Or dans un fil d'Ariane on a une notion de
hiérarchie; que l'on ne retrouve pas en HTML, hormis via des listes
imbriquées, mais pareil, c'est trop lourd pour être réellement utile.

Je pense qu'il ne faut pas chercher midi à quatorze heures. Si une
succession de liens fonctionne, et fournit tout ce dont l'utilisateur a
besoin (en l'occurrence, rien), il faut s'en tenir à cela. Donc, des liens
à plat, point.




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


Le 21 avril 2016 à 15:34, Steven Mouret <steven.mou...@gmail.com> a écrit :

> Pour ma part, j'utilise cette structure :
>
> 
>   Vous êtes ici : 
>   
> Accueil
> lorem
> ipsum
> dolor
>   
> 
>
> Un peu verbeux.
>
>
> --
> Steven Mouret
>
> Le 21 avril 2016 à 15:25, Anthony Ladeuil <anth...@ladeuil.com> a écrit :
>
>> Hello tout le monde
>>
>> Pour ma part j'aime bien utiliser la structure suivante :
>>
>> 
>> Vous êtes ici : 
>> 
>> accueil
>> 
>> 
>> lorem
>> 
>> 
>> lorem ipsum
>> 
>> 
>>
>> Ca peut faire hurler (ou pas) mais j'y trouve mon compte pour la mise en
>> forme...
>> Du coup, je veux bien des avis :)
>>
>> Anthony
>>
>>
>> Le 21 avr. 2016 à 12:58, san...@free.fr a écrit :
>>
>> hello,
>> moi j'aime sémantiquement que mes liens soient en ol/li, une liste
>> ordonnée, ça le fait , non ?
>> Je veux bien des retours d'utilisateurs sur l'emploi d'une liste ordonnée
>> !
>> avec le "vous êtes ici" devant sans titre, en effet.
>>
>> vincent qui arrive après le train !
>>
>> - Mail original -
>> De: "Cyril Lamotte" <clamo...@jouve.fr>
>> À: "liste gta" <liste_gta@list.accessiweb.org>
>> Envoyé: Jeudi 21 Avril 2016 11:51:39
>> Objet: Re: [Liste GTA] Structure Fil d'Ariane
>>
>>
>> Ok je pars là-dessus alors !
>>
>> Succession de liens avec "vous êtes ici" devant (pas dans un titre).
>>
>> Merci
>>
>>
>>
>>
>> Cyril Lamotte
>> Développeur Front-end / Référent accessibilité
>>
>>
>> clamo...@jouve.fr
>>
>>
>> 02 43 08 39 97
>>
>> Jouve
>> 1, rue du docteur Sauvé, 53101 Mayenne CEDEX
>> www.jouve.com
>> Twitter Google + LinkedIn ViadeoJouve
>>
>>
>>
>>
>> Le 21/04/2016 11:38, Sylvie Duchateau a écrit :
>>
>>
>>
>>
>> Bonjour Cyril, Olivier et tous,
>>
>> Je pense qu'un h2 « vous êtes ici » n'est pas nécessaire.
>>
>>
>> Fil d'Ariane, non plus, ceux qui ne connaissent pas les recommandations
>> se demanderont ce qu'Ariane vient faire là-dedans.
>>
>> Vous êtes ici me paraît parlant.
>>
>>
>> Je suis d'accord avec Olivier sur la « bête succession de liens ».
>>
>>
>> Bonne journée
>>
>> Sylvie
>>
>>
>> Le 21/04/2016 à 11:17, Olivier Nourry a écrit :
>>
>>
>>
>> Bonjour Cyril,
>> Il n'y a aucune structure HTML qui corresponde à un fil d'Ariane, et à
>> vrai dire, je ne vois pas trop ce que l'on pourrait faire de mieux qu'une
>> bête succession de liens comme l'exemple que tu donnes. D'ailleurs ni la
>> spec HTML, ni les design patterns ARIA ne le prévoient, malgré le coté très
>> répandu de la pratique. Sans doute un signe qu'il n'y a pas besoin de
>> structure particulière.
>> Je ne recommande en tout cas pas la liste non ordonnée, ça ne colle pas
>> avec le fait que les éléments ne sont pas interchangeables, et ne sont p

Re: [Liste GTA] Structure Fil d'Ariane

[Olivier Nourry]

Bonjour Cyril,
Il n'y a aucune structure HTML qui corresponde à un fil d'Ariane, et à vrai
dire, je ne vois pas trop ce que l'on pourrait faire de mieux qu'une bête
succession de liens comme l'exemple que tu donnes. D'ailleurs ni la spec
HTML, ni les design patterns ARIA ne le prévoient, malgré le coté très
répandu de la pratique. Sans doute un signe qu'il n'y a pas besoin de
structure particulière.
Je ne recommande en tout cas pas la liste non ordonnée, ça ne colle pas
avec le fait que les éléments ne sont pas interchangeables, et ne sont pas
du même "niveau". Du coup on pourrait penser à des UL ou OL imbriquées à 1
élément, mais en lecture vocale ça serait franchement lourdingue, et pas
pratique du tout.
Sinon peut-être optimiser la restitution en rendant les séparateurs non
vocalisés (role=presentation par exemple).

Le H2 me parait excessif pour la plupart des cas, ça fait un point d'arrêt
dans l'arborescence en plus qui ne se justifie pas franchement. J'aurais
juste mis le tout (incluant "vous êtes ici")  dans un conteneur avec un id.
Si le masquage est fait correctement (contenu hors viewport), il reste
trouvable avec CTRL+F, ça permet de le retrouver facilement si on est déjà
passé dessus. Tant qu'à le masquer, autant avoir un libellé plus
spécifique: "localisation" ou "fil d'Ariane" (le second est un terme
technique, mais au moins il ne peut pas être confondu avec autre chose.

Juste mes deux centimes Sur tous ces points d'amélioration UX, je suis
preneur de l'avis d'utilisateurs de lecteurs d'écran pour ce qui est le
plus agréable ou pratique.





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


Le 21 avril 2016 à 10:45, Cyril Lamotte <clamo...@jouve.fr> a écrit :

> Bonjour la Liste,
>
> Comment structureriez-vous un fil d'Ariane et mettriez-vous un titre juste
> avant ?
>
> Dans Drupal, le code généré par défaut  est celui-ci, le jugez-vous
> correct ? :
>
> Vous êtes ici (titre masqué)
> 
> Rubrique
> >>
>Titre
> 
>
>
> Ou feriez-vous une liste ul / li ?
>
>
> Ou autre.. ?
>
>
>
> Merci à vous !
>
>
>
> --
>
> *Cyril Lamotte*
> Développeur Front-end / Référent accessibilité
>
> clamo...@jouve.fr
>
> 02 43 08 39 97
>
> [image: Jouve] <http://www.jouve.com/fr>
> 1, rue du docteur Sauvé, 53101 Mayenne CEDEX
> www.jouve.com
> [image: Twitter] <https://twitter.com/GroupeJouve> [image: Google +]
> <https://plus.google.com/103316327091227322721/posts> [image: LinkedIn]
> <http://www.linkedin.com/company/groupe-jouve> [image: Viadeo]
> <http://www.viadeo.com/v/company/jouve?ga_from=Fu:undefined;Fb%3Amininews%3Bfe%3AMN-pic%0A%0A%3BMNType%3A46>
>  [image:
> 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
>
>
___
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org

Re: [Liste GTA] Solution FACIL'iti, des avis, REX?

[Olivier Nourry]

Bonjour,

je plussoie l'avis de Vincent: cet outil, comme les autres du même type,
est un type particulier de technologie d'assistance. Comme toute TA, son
efficacité dépend totalement du niveau d'accessibilité du site. C'est vrai
des barres d'accessibilité comme des logiciels générant des versions
vocales, ou encore des post-processeurs qui modifient les contenus à la
volée ou de manière asynchrone.
En la matière il n'y a pas de miracle. Pour ma part, j'adorerais qu'un
outil, quelqu'il soit, transforme un contenu inaccessible en quelque chose
d'accessible, mais ça n'existe pas (encore).

En soi, cela ne me choque pas qu'un outil ne fasse que ce qu'il est
techniquement possible de faire - c'est déjà pas mal! Le problème, comme le
dit très justement Vincent, c'est que certains vendeurs peu scrupuleux
survendent leur produit. En envoyant parfois des messages qu'il faut bien
qualifier de mensongers, tant vis-à-vis des utilisateurs que des acheteurs
(en général les gestionnaires de sites).
Je ne me prononcerai pas sur le discours de Facil'iti, chacun se fera son
opinion. Le point qu'il ne faut pas oublier, c'est que les budgets affectés
à ce type de solutions sont autant de moins pour un travail de fond sur
l'accessibilité, qui profite à *tous* les utilisateurs de toutes les TA, et
pas uniquement à ceux qui ont souscrit (contre infos personnelles en
général) à la solution installée sur le site. Avec même le risque très fort
de laisser aux décideurs l'impression que le job est fait une fois que
l'outil miraculeux est installé, ce qui met en péril la possibilité d'avoir
un jour un travail de fond pérenne et pertinent sur l'accessibilité.

Pour ceux qui lisent l'anglais, je ne peux que vous renvoyer à
l'incontournable Karl Groves, et cet article: Can Assistive Technology Make
a Website Accessible?
<http://www.karlgroves.com/2012/04/19/can-assistive-technology-make-a-website-accessible/>
.
Morceau choisi: "These things are like the penis enlargement pills of
accessibility." En français: "ces trucs sont pour l'accessibilité ce que
sont les pilules d'agrandissement du pénis".
Enjoy!




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


Le 13 avril 2016 à 15:58, <san...@free.fr> a écrit :

> bonjour la liste,
> j'ai eu à faire à Facil'iti, voici mon retour.
> Ils sont commercialement "agressif", leur discourt est pour le moins très
> flou. En effet, ils laissent entendre (même le dise clairement) qu'avec
> leur outils pas besoin de faire un site accessible, leur outil permet ça.
> Bien évidemment, c'est complètement faux, leur outil au mieux permet
> d'améliorer le confort pour certains types d'utilisateurs non équipés
> d'aide technique et ne dispense ABSOLUMENT pas de rendre son site
> accessible !!
> Il est très dangereux de communiquer sur ce genre de terrain : "ne faites
> aucun effort en termes d'accessibilité web, notre outil fait tout !".
> En plus, les prix sont, il me semble, élevés.
>
> Clairement, je ne suis pas un de leur amis, leur discour me laisse sans
> voix !
> a+
>
> - Mail original -
> De: "Ravet Isabelle" <isabelle.ra...@insee.fr>
> À: "liste gta" <liste_gta@list.accessiweb.org>
> Envoyé: Mercredi 13 Avril 2016 13:41:57
> Objet: Re: [Liste GTA] Solution FACIL'iti, des avis, REX?
>
>
>
> Bonjour Anne-lise et les autres,
>
> c'est la première fois que j'entends parler de ce produit. Etant curieuse,
> j'attends comme toi les retours de la liste...
>
> Cordialement
>
>
>
> Isabelle RAVET
>
> Conseil, assistance et méthodes pour les applications et les projets
>
> Tél. : 01 41 17 57 86
>
> mél : isabelle.ra...@insee.fr
>
> INSEE - Direction Générale
>
> 18, Bd Adolphe-Pinard
>
> 75675 Paris CEDEX 14
>
>
>
>
>
>
> De : liste_gta [mailto:liste_gta-boun...@list.accessiweb.org] De la part
> de Anne Lise Agoye
> Envoyé : mercredi 13 avril 2016 09:40
> À : Groupe de Travail Accessiweb
> Objet : [Liste GTA] Solution FACIL'iti, des avis, REX?
>
>
>
>
>
> Bonjour à tous,
>
>
>
>
> Avez-vous des retours d'expérience autour de la solution proposée par
> FACIL'iti? ( http://pro.facil-iti.fr/ )
>
>
> Mon client a eu une présentation rapide du projet et s'interroge sur une
> intégration de ce type de solution dans son site.
>
>
>
>
> Merci d'avance,
>
>
>
>
> Cordialement,
>
>
>
>
>
>
>
>
>
> Anne-Lise Agoyé
> Chef de projets web et mobilité
> Tél : 06.76.45.51.94
> E-mail : alag...@sodifrance.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
>
___
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 ?

[Olivier Nourry]

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.




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


Le 22 janvier 2016 à 15:40, Antoine Bouet <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
> www.cimeos.com
>
>
> ___
> 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] Champ de formulaires & cellules de tableaux

[Olivier Nourry]

Je me disais justement qu'il fallait réouvrir ce fil de discussion pour la
question des loupes d'écran, discutée en off avec JP récemment ;-) [clin
d'oeil]

Une question que je me pose: dans une perspective responsive web design,
quelle liberté a-t-on pour réorganiser l'affichage d'un tableau avec
nombreuses colonnes, sur un écran étroit?
On peut a priori remettre en cause entièrement la structure de tableau pour
en faire tout autre chose en CSS3. Mais du coup, est-ce que ça vaut le coup
de se prendre la tête à partir sur un tableau, et ne vaut-il mieux pas
directement adopter un affichage de grille, plus souple, à base de
conteneurs empilés? (sachant qu'au final on fait tout ce qu'on peut avec
cette construction via TABLE pour se débarrasser des propriétés de TABLE...)



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


Le 18 décembre 2015 à 11:17, ROSA Giuseppe (93) <
giuseppe.r...@dgfip.finances.gouv.fr> a écrit :

> Merci Jean-Pierre pour ces précisions, j'avais effectivement omis le cas
> des utilisateurs de loupe d'écran. Je transmets tes recommandations.
>
> Bonnes fêtes.
>
> 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
>
>
>  Message original 
> Sujet : Re: [Liste GTA] Champ de formulaires & cellules de tableaux
> De : Jean-Pierre Villain <jpvill...@access42.net> <jpvill...@access42.net>
> Pour : liste_gta@list.accessiweb.org
> Date : 18/12/2015 10:26
>
> Bonjour,
>
> Je n'avais pas vu  cette conversation, je me me permet d'ajouter mon grain
> de sel et quelques précisions.
>
> Comme tout le monde l'utilisation d'un tableau de données est à proscrire.
> En revanche la solution de labels cachés ou de liaison aria-labelledby
> peux être insuffisante, par exemple pour les utilisateurs de loupe d'écran
> qui ne voyant qu'une portion du tableau risque de perdre l'information du
> label fournie par les en-têtes.
> Ce souci est habituel sur les tableaux de grande dimension mais il peut
> être, dans le cas de champ de formulaire considérablement amélioré en
> traitant un label caché en tooltip ou en utilisant un title de préférence à
> aria-labelledby.
>
> Pour les fieldset, le critère est "Critère 11.5 [A] Dans chaque
> formulaire, les informations de même nature sont-elles regroupées, si
> nécessaire ? " ce qui laisse tout le loisir d'adapter l'exigence de la
> présence d'un fieldset.
>
> Si les labels sont suffisamment explicites le couple fielset/legend
> devient naturellement inutile.
>
> J'aurais donc tendance  traiter ce cas en tableau de présentation, les
> lignes et colonnes d'en-tête en aria-hidden true et des labels masqués,
> suffisamment pertinents pour éviter le fieldset, traités en tooltip au
> moment de la prise d'action (souris/clavier naturellement).
>
> JPV
>
>
>
>
> Le 09/11/2015 14:32, Romain Gervois a écrit :
>
> Bonjour Olivier,
>
> Désolé pour ma réponse tardive. J'ai effectivement mal lu ta précédente
> réponse. On est donc d'accord sur le fait que si il y a utilisation d'un
> tableau, il doit s'agir d'un tableau de présentation et non de données.
> Pour ARIA, il s'agit ici surtout de réaliser les liaisons input et
> pseudo-en-têtes, rien de plus ; on est loin de la bidouille et, pour le
> coup, ça n'évite de toute façon pas les redites. On pourrait imaginer une
> implémentation s'appuyant sur ARIA pour gérer ça mais ça touche au problème
> de support et du "où doit-on s'arrêter ?".
>
> Concernant la redistribution d'un tableau de présentation en contexte
> responsive, je n'ai pas d'exemple à dispo (c'est forcément du spécifique
> pour le coup). Mais il suffit d'appliquer des display block sur les
> éléments td pour réaliser une simple linéarisation de ce tableau et de
> masquer/afficher les éléments nécessaires à la situation. Alors, il faut
> bien avoir en tête que dans le cas évoqué, c'est jouable. Dans un cas où il
> s'agit d'un tableau de données ça peut être bien autre chose...
>
> Concernant le problème du support, il s'agit surtout de mesurer la réelle
> pérennité de l'implémentation (quelle soit pour contourner ou pour
> améliorer).  Et ça, effectivement, ça dépend de plein de facteurs
> (compétences du concepteur, impacts réels du problème, projet...).
>
> Romain
>
> Le 2 novembre 2015 15:47, Olivier Nourry <olv.nou...@gmail.com> a écrit :
>
>> Bonjour Romain,
>>
>> J'ai bien précisé que c'est l'utilisation d'un tableau de données qui 

Re: [Liste GTA] Champ de formulaires & cellules de tableaux

[Olivier Nourry]

L'usage d'un tableau de données ne me parait pas souhaitable car c'est à
mon sens un détournement d'usage de l'élément (même si on a vu pire!). Face
à cette construction, le lecteur d'écran va rentrer dans quel mode?
Formulaire ou tableau? Je ne sais pas trop, et je ne sais pas non plus
comment l'utilisateur comprendra réellement la chose -- Tu as sûrement un
avis plus pertinent que moi sur la question!
La longueur réelle des labels ne joue pas trop, puisqu'ils sont cachés avec
mon "affichage tableau".
La solution que je te propose n'est pas plus complexe, en termes de code,
qu'une table; si tu crées un plug-in de zéro, cela reviendra au même.
L'avantage est que sur un design responsive, en largeur étroite tu pourras
facilement revenir à une représentation en fieldset, où tu fais
réapparaitre les labels, et tu positionnes les boutons les uns en dessous
des autres. Chose impossible avec un tableau, pour lequel la largeur
minimale sera la somme de celles des colonnes.




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


Le 2 novembre 2015 13:37, ROSA Giuseppe (93) <
giuseppe.r...@dgfip.finances.gouv.fr> a écrit :

> Merci Olivier pour ta réponse.
>
> En effet, je sais qu'on ne peut pas croiser les fieldset avec les cellules
> de tableaux, c'est pourquoi j'ai par ailleurs chercher s'il existait des
> role fieldset et legend, mais ce n'est à priori pas le cas. La solution du
> tableau intéressait le client pour des questions d'alignement et parce que
> ces tableaux seront en fait généré par un CMS, le contenu ajouté
> probablement par des contributeurs non développeur. Je cherchai donc un
> moyen "d'émuler" le comportement du fieldset à partir du tableau.
>
> La solution display table est une solution que j'avais mis de côté bien
> qu'elle semblait intéressante car je la maîtrise imparfaitement (donc me
> demandera un peu de temps) et j'ai peur d'avoir du mal à donner des
> indications pour l'auto-générer ensuite avec des plugins drupal. Mais je
> vais regarder de plus près puisque c'est une solution que tu sembles
> également penser viable.
>
> Pour information, les labels de l'exemple, sont donnés juste pour
> illustration. Ceux utilisé sont généralement plus long (20 à 30 caractères)
>
> A ton avis, la solution 1 : tableau de donnée peut elle être viable ou est
> à proscrire ?
>
> Merci encore pour ta réactivité et ton analyse.
>
> 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
>
>
>  Message original 
> Sujet : Re: [Liste GTA] Champ de formulaires & cellules de tableaux
> De : Olivier Nourry <olv.nou...@gmail.com> <olv.nou...@gmail.com>
> Pour : liste_gta@list.accessiweb.org <liste_gta@list.accessiweb.org>
> <liste_gta@list.accessiweb.org>
> Date : 02/11/2015 12:55
>
> Bonjour Giuseppe,
>
> L'inconvénient de ta solution 2 (fieldset dans une table) est qu'on ne
> peut pas "croiser" de la sorte fieldset et table, ça casse le code HTML. Ou
> alors il faut faire une table à l'intérieur de chaque fieldset, et une
> table à 1 colonne comme wrapper. Bof bof.
> Perso j'aurais fait une suite de fieldset, un par matière, avec des label
> à chaque bouton.
> Pour obtenir la représentation visuelle que tu décris, j'aurais ensuite
> mis ça en lignes, caché les label (mais est-ce nécessaire?), et aligné avec
> des propriétés display de la famille table-* ou équivalent.
> Les textes dans la 1ère ligne, rappelant la fonction des boutons, ne sont
> alors utiles que pour la représentation visuelle, pas besoin de les relier
> aux boutons.
> De cette manière, en lecture non visuelle, c'est accessible (avec un peu
> d'infos en trop, celles de la première ligne); et en visuel, on a les
> informations et l'alignement nécessaires pour comprendre la fonction de
> chaque bouton radio.
>
> J'espère t'avoir été utile
>  J'espère t'avoir été utili
> [image: --]
> Olivier Nourry
> [image: http://]about.me/oliviernourry
> <http://about.me/oliviernourry>
>
>
> Le 2 novembre 2015 11:08, ROSA Giuseppe (93) <
> giuseppe.r...@dgfip.finances.gouv.fr> a écrit :
>
>> Bonjour la liste,
>>
>> Je voulais connaître votre avis sur la meilleur manière d'implémenter un
>> formulaire présenter dans un tableau (plusieurs "clients" semblent impacter
>> chez nous par ce type de présentation).
>>
>> Je pense qu'il s'agit d'un cas déjà rencontré, puisque des outils de
>> génération de ques

Re: [Liste GTA] Champ de formulaires & cellules de tableaux

[Olivier Nourry]

Giuseppe,  j'oubliais cette très bonne introduction aux propriétés
display:table
<http://www.alsacreations.com/tuto/lire/610-Mise-en-page-CSS-avancee-grace-a-la-propriete-display.html>
sur le site d'Alsacréations.



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


Le 2 novembre 2015 14:03, Olivier Nourry <olv.nou...@gmail.com> a écrit :

> L'usage d'un tableau de données ne me parait pas souhaitable car c'est à
> mon sens un détournement d'usage de l'élément (même si on a vu pire!). Face
> à cette construction, le lecteur d'écran va rentrer dans quel mode?
> Formulaire ou tableau? Je ne sais pas trop, et je ne sais pas non plus
> comment l'utilisateur comprendra réellement la chose -- Tu as sûrement un
> avis plus pertinent que moi sur la question!
> La longueur réelle des labels ne joue pas trop, puisqu'ils sont cachés
> avec mon "affichage tableau".
> La solution que je te propose n'est pas plus complexe, en termes de code,
> qu'une table; si tu crées un plug-in de zéro, cela reviendra au même.
> L'avantage est que sur un design responsive, en largeur étroite tu pourras
> facilement revenir à une représentation en fieldset, où tu fais
> réapparaitre les labels, et tu positionnes les boutons les uns en dessous
> des autres. Chose impossible avec un tableau, pour lequel la largeur
> minimale sera la somme de celles des colonnes.
>
>
>
>
> [image: --]
> Olivier Nourry
> [image: http://]about.me/oliviernourry
> <http://about.me/oliviernourry>
>
>
> Le 2 novembre 2015 13:37, ROSA Giuseppe (93) <
> giuseppe.r...@dgfip.finances.gouv.fr> a écrit :
>
>> Merci Olivier pour ta réponse.
>>
>> En effet, je sais qu'on ne peut pas croiser les fieldset avec les
>> cellules de tableaux, c'est pourquoi j'ai par ailleurs chercher s'il
>> existait des role fieldset et legend, mais ce n'est à priori pas le cas. La
>> solution du tableau intéressait le client pour des questions d'alignement
>> et parce que ces tableaux seront en fait généré par un CMS, le contenu
>> ajouté probablement par des contributeurs non développeur. Je cherchai donc
>> un moyen "d'émuler" le comportement du fieldset à partir du tableau.
>>
>> La solution display table est une solution que j'avais mis de côté bien
>> qu'elle semblait intéressante car je la maîtrise imparfaitement (donc me
>> demandera un peu de temps) et j'ai peur d'avoir du mal à donner des
>> indications pour l'auto-générer ensuite avec des plugins drupal. Mais je
>> vais regarder de plus près puisque c'est une solution que tu sembles
>> également penser viable.
>>
>> Pour information, les labels de l'exemple, sont donnés juste pour
>> illustration. Ceux utilisé sont généralement plus long (20 à 30 caractères)
>>
>> A ton avis, la solution 1 : tableau de donnée peut elle être viable ou
>> est à proscrire ?
>>
>> Merci encore pour ta réactivité et ton analyse.
>>
>> 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
>>
>>
>>  Message original 
>> Sujet : Re: [Liste GTA] Champ de formulaires & cellules de tableaux
>> De : Olivier Nourry <olv.nou...@gmail.com> <olv.nou...@gmail.com>
>> Pour : liste_gta@list.accessiweb.org <liste_gta@list.accessiweb.org>
>> <liste_gta@list.accessiweb.org>
>> Date : 02/11/2015 12:55
>>
>> Bonjour Giuseppe,
>>
>> L'inconvénient de ta solution 2 (fieldset dans une table) est qu'on ne
>> peut pas "croiser" de la sorte fieldset et table, ça casse le code HTML. Ou
>> alors il faut faire une table à l'intérieur de chaque fieldset, et une
>> table à 1 colonne comme wrapper. Bof bof.
>> Perso j'aurais fait une suite de fieldset, un par matière, avec des label
>> à chaque bouton.
>> Pour obtenir la représentation visuelle que tu décris, j'aurais ensuite
>> mis ça en lignes, caché les label (mais est-ce nécessaire?), et aligné avec
>> des propriétés display de la famille table-* ou équivalent.
>> Les textes dans la 1ère ligne, rappelant la fonction des boutons, ne sont
>> alors utiles que pour la représentation visuelle, pas besoin de les relier
>> aux boutons.
>> De cette manière, en lecture non visuelle, c'est accessible (avec un peu
>> d'infos en trop, celles de la première ligne); et en visuel, on a les
&g

Re: [Liste GTA] Champ de formulaires & cellules de tableaux

[Olivier Nourry]

Bonjour Giuseppe,

L'inconvénient de ta solution 2 (fieldset dans une table) est qu'on ne peut
pas "croiser" de la sorte fieldset et table, ça casse le code HTML. Ou
alors il faut faire une table à l'intérieur de chaque fieldset, et une
table à 1 colonne comme wrapper. Bof bof.
Perso j'aurais fait une suite de fieldset, un par matière, avec des label à
chaque bouton.
Pour obtenir la représentation visuelle que tu décris, j'aurais ensuite mis
ça en lignes, caché les label (mais est-ce nécessaire?), et aligné avec des
propriétés display de la famille table-* ou équivalent.
Les textes dans la 1ère ligne, rappelant la fonction des boutons, ne sont
alors utiles que pour la représentation visuelle, pas besoin de les relier
aux boutons.
De cette manière, en lecture non visuelle, c'est accessible (avec un peu
d'infos en trop, celles de la première ligne); et en visuel, on a les
informations et l'alignement nécessaires pour comprendre la fonction de
chaque bouton radio.

J'espère t'avoir été utile
 J'espère t'avoir été utili
[image: --]
Olivier Nourry
[image: http://]about.me/oliviernourry
<http://about.me/oliviernourry>


Le 2 novembre 2015 11:08, ROSA Giuseppe (93) <
giuseppe.r...@dgfip.finances.gouv.fr> a écrit :

> Bonjour la liste,
>
> Je voulais connaître votre avis sur la meilleur manière d'implémenter un
> formulaire présenter dans un tableau (plusieurs "clients" semblent impacter
> chez nous par ce type de présentation).
>
> Je pense qu'il s'agit d'un cas déjà rencontré, puisque des outils de
> génération de questionnaire en ligne doivent générer des cas similiaires.
>
> Dans le dernier cas qu'il m'a été soumis, il s'agit d'une sorte de
> formulaire de notation (pour faire simple) :
>
>- Sur la première ligne les intitulés des notes
>- Sur les lignes suivantes :
>   - première cellule : l'intitulé de la matière
>   - cellules suivantes : bouton radio (symbolisé ci-dessous par ©)
>
>
>  Bon
> Moyen
> Mauvais
> Matière 1
> ©
> © © Matière 2
> © © © Matière 3
> © © ©
> Le problème est doit-on (ou est-il préférable) traiter ce tableau en tant
> que tableau de données, et dans ce cas les cellules de la première ligne et
> de la première colonne seraient les cellules d'en-tête.
> Par contre, les contenus de ces en-têtes peuvent-ils être considérés comme
> les étiquettes des cases boutons radio (cas prévus pour rendre explicite
> des liens mais je n'ai pas l'impression que cela soit le cas pour des
> boutons radio, cases à cocher voire champ de saisie de formulaire). Si je
> rajoute des labels (aria-label ou autre), j'ai un redondance d'information
> (intitulé de la cellule d'en-tête + étiquette du bouton).
>
> Une autre solution serait de traiter cela comme un tableau de
> présentation, avec un label (aria-label ou aria-labelledby par exemple) sur
> chaque bouton, avec un aria-hidden sur la 1ère ligne. Par contre, je ne
> sais pas si on peut regrouper chaque ligne pour simuler le cas d'un
> fieldset/legend afin d'éviter de répéter à chaque bouton le nom de la
> matière et ainsi fonctionner comme avec une succession de groupement tel
> que celui-ci :
> 
> Matière 1
> 
> ...
> 
>
> Si vous avez des suggestions du meilleur traitement d'un cas tel que
> celui-ci je suis preneur.
>
> Avec tous mes remerciements pour cette lecture.
>
> 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

Re: [Liste GTA] Critère 12.11 (liens d'évitement) et mobile

[Olivier Nourry]

Bonjour Romain,
L'embêtant avec cette solution, est qu'elle suppose l'utilisation de
technologie d'assistance ou de matériel. Un utilisateur qui a juste besoin
d'être aidé pour se repérer dans la page, ou se rendre à un endroit précis
alors que le swipe lui pose problème, n'est pas servi.

Il y a une problématique d'arbitrage entre la consommation de surface
d'écran et l'utilisabilité, c'est certain. Je pense qu'il y a des cas où
garder les liens visibles s'impose, et même de manière permanente (menu
"sticky").
Le 30 sept. 2015 16:29, "Romain Gervois" <cont...@romaingervois.fr> a
écrit :

> Bonjour,
>
> Plus simplement, juste prévoir l'affichage au focus et le masquage au blur
> (perte de focus) pour ces liens d'évitement.
> Cela répondra aux besoins des utilisateurs ayant couplé leurs équipements
> tactiles à un clavier.
>
> Des fonctionnalités (via rotor et/ou item selector de VO/iOS et via
> système de gestures de TalkBack/Android) permettent de se passer d'une
> implémentation visible de ces liens et cela quelque soit le type
> d'exploration utilisée (que ce soit pas "balayage" ou par toucher) tant que
> l'implémentation des landmarks est correcte.
>
> Romain
>
> Le 30 septembre 2015 15:29, Olivier Nourry <olv.nou...@gmail.com> a écrit
> :
>
>> Bonjour Giuseppe,
>>
>> On m'a posé la même question, ça doit donc être une préoccupation
>> partagée...
>> Sur le plan de la conformité, le RGAA s'applique à tout dispositif de
>> restitution Web. Si on devait produire une exception, il faudrait la
>> justifier par l'usage, mais sur ce point je pense que déroger sera
>> compliqué. En effet, sur le plan de l'accessibilité, je vois au moins trois
>> cas utilisateurs où des liens d'évitement se justifient:
>>
>>- certains utilisateurs d'appareils mobiles utilisent un clavier, et
>>ont des difficultés à utiliser une interface tactile
>>- certains utilisateurs d'appareils mobiles utilisent un système de
>>commutateurs de type Switch Access (cf.
>>https://support.google.com/accessibility/android/answer/6122836?hl=fr).
>>Ce système simule des combinaisons de touches clavier
>>- sur une interface visuellement chargée, disposer d'un moyen rapide
>>de trouver, par exemple, le moteur de recherche, noyé dans le reste, peut
>>être appréciable.
>>
>> Si on ajoute qu'en lecture d'écran tactile, certains utilisent
>> l'exploration par le toucher, cet argument plus le troisième tendent à
>> renforcer le besoin de rendre ces liens apparents, et faciles à trouver.
>>
>> Malheureusement cette pratique consomme de l'espace de restitution, et
>> crée donc une contrainte dans le cadre d'un design mobile... Une solution à
>> cela pourrait être de rendre la liste de liens d'évitement optionnelle:
>> elle est affichée par défaut, avec un bouton de fermeture pour la masquer
>> (et un autre pour la faire réapparaitre). A tester...
>>
>>
>>
>> [image: --]
>> Olivier Nourry
>> [image: http://]about.me/oliviernourry
>> <http://about.me/oliviernourry>
>>
>>
>> Le 30 septembre 2015 09:27, ROSA Giuseppe (93) <
>> giuseppe.r...@dgfip.finances.gouv.fr> a écrit :
>>
>>> Bonjour la liste,
>>>
>>> Un "client" a intégré des liens d'évitement pour accéder notamment au
>>> menu et au contenu, mais souhaiterait les retirer sur la version mobile. Ne
>>> connaissant pas trop le mode de navigation sur ce type de terminal je ne
>>> connais pas trop les contraintes pour les personnes avec handicap.
>>>
>>> J'ignore par exemple si le vocalisateur permet d'avoir la liste de liens
>>> comme avec NVDA ou JAWS et surtout, j'ignore si des personnes avec handicap
>>> moteur sont susceptibles d'utiliser ce type d'appareil (sur desktop les
>>> liens d'évitement étant en grande partie destinés aux personnes ne pouvant
>>> pas se servir d'un clavier).
>>>
>>> Par conséquent je souhaiterai savoir si ce critère s'applique de la même
>>> façon sur version mobile.
>>> --
>>>
>>> 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
>>
>>
>
> ___
> 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] Label e-accessible

[Olivier Nourry]

OK, je comprends.
Dans ce cas je ne pense pas que cette liste, quelque soit sa pertinence
dans l'absolu, soit le meilleur outil pour prioriser des critères, si une
telle priorisation s'avère nécessaire.
En effet, il vaut mieux étudier le besoin réel, ce qui est d'autant plus
faisable que la cible est a priori connue. On peut imaginer par exemple que
s'il y a une forte représentation d'utilisateurs de loupes d'écran, on
place les critères qui s'y rapportent en haut de liste, même s'il s'agit de
critères AAA. Inversement, on ne sera pas aussi regardant sur des critères
de niveau A ou AA qui n'auraient qu'un faible impact pour la base
utilisateurs.
Il y a, de manière générale un vrai malentendu sur la signification des
niveaux WCAG2; il y a d'ailleurs des discussions assez pointues à ce sujet
sur la liste W3C/WAI (en anglais):
https://lists.w3.org/Archives/Public/w3c-wai-ig/2015JulSep/0052.html
Lire également ce qu'en pense Karl Groves: Understanding WCAG level (en
anglais) <http://www.karlgroves.com/2013/05/20/understanding-wcag-level/>




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


Le 30 septembre 2015 09:19, Ravet Isabelle <isabelle.ra...@insee.fr> a
écrit :

> Merci Olivier, mais le projet qui m'a posé la question ne rentrera pas
> dans une démarche de labellisation ; il s'agit d'une appli backoffice que
> l'équipe tient à rendre accessible à minima. Mais je leur passerai l'info.
>
> Bonne journée
>
> Isabelle
> --
> *De :* liste_gta [mailto:liste_gta-boun...@list.accessiweb.org] *De la
> part de* Olivier Nourry
> *Envoyé :* mercredi 30 septembre 2015 08:45
> *À :* liste_gta@list.accessiweb.org
> *Objet :* Re: [Liste GTA] Label e-accessible
>
> Bonjour Isabelle,
> La liste n'est pas diffusée publiquement par la DInSIC pour le moment,
> dans l'attente de sa validation finale. Cependant une version provisoire
> peut être obtenue sur demande, dans le cadre d'un projet concret de
> labellisation.
>
> Comme j'assiste la DInSIC sur l'accompagnement des candidats au label, il
> est possible de me solliciter à ce sujet en m'écrivant à
> olivier.nou...@smile.fr, je relaierai les demandes d'information.
>
> Bonne journée
> Olivier Nourry
> Le 30 sept. 2015 07:58, "Ravet Isabelle" <isabelle.ra...@insee.fr> a
> écrit :
>
>> Bonjour la liste,
>> je vous sollicite pour une question toute bête : est-ce que la liste des
>> 50 critères essentiels du 1er niveau du label est sorti  ?
>> Bien cordialement
>>
>> *Isabelle RAVET *
>> Référente Accessibilité
>> Conseil, Assistance et Méthodes pour les Applications et les Projets
>> Département Applications et Projets - INSEE
>> 19 boulevard Adolphe Pinard
>> 92245 MALAKOFF
>> ( 01.41.17.57.86
>>
>>
>>
>> ___
>> 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] Label e-accessible

[Olivier Nourry]

Bonjour Isabelle,
La liste n'est pas diffusée publiquement par la DInSIC pour le moment, dans
l'attente de sa validation finale. Cependant une version provisoire peut
être obtenue sur demande, dans le cadre d'un projet concret de
labellisation.

Comme j'assiste la DInSIC sur l'accompagnement des candidats au label, il
est possible de me solliciter à ce sujet en m'écrivant à
olivier.nou...@smile.fr, je relaierai les demandes d'information.

Bonne journée
Olivier Nourry
Le 30 sept. 2015 07:58, "Ravet Isabelle" <isabelle.ra...@insee.fr> a écrit :

> Bonjour la liste,
> je vous sollicite pour une question toute bête : est-ce que la liste des
> 50 critères essentiels du 1er niveau du label est sorti  ?
> Bien cordialement
>
> *Isabelle RAVET *
> Référente Accessibilité
> Conseil, Assistance et Méthodes pour les Applications et les Projets
> Département Applications et Projets - INSEE
> 19 boulevard Adolphe Pinard
> 92245 MALAKOFF
> ( 01.41.17.57.86
>
>
>
> ___
> 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 12.11 (liens d'évitement) et mobile

[Olivier Nourry]

Bonjour Giuseppe,

On m'a posé la même question, ça doit donc être une préoccupation
partagée...
Sur le plan de la conformité, le RGAA s'applique à tout dispositif de
restitution Web. Si on devait produire une exception, il faudrait la
justifier par l'usage, mais sur ce point je pense que déroger sera
compliqué. En effet, sur le plan de l'accessibilité, je vois au moins trois
cas utilisateurs où des liens d'évitement se justifient:

   - certains utilisateurs d'appareils mobiles utilisent un clavier, et ont
   des difficultés à utiliser une interface tactile
   - certains utilisateurs d'appareils mobiles utilisent un système de
   commutateurs de type Switch Access (cf.
   https://support.google.com/accessibility/android/answer/6122836?hl=fr).
   Ce système simule des combinaisons de touches clavier
   - sur une interface visuellement chargée, disposer d'un moyen rapide de
   trouver, par exemple, le moteur de recherche, noyé dans le reste, peut être
   appréciable.

Si on ajoute qu'en lecture d'écran tactile, certains utilisent
l'exploration par le toucher, cet argument plus le troisième tendent à
renforcer le besoin de rendre ces liens apparents, et faciles à trouver.

Malheureusement cette pratique consomme de l'espace de restitution, et crée
donc une contrainte dans le cadre d'un design mobile... Une solution à cela
pourrait être de rendre la liste de liens d'évitement optionnelle: elle est
affichée par défaut, avec un bouton de fermeture pour la masquer (et un
autre pour la faire réapparaitre). A tester...



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


Le 30 septembre 2015 09:27, ROSA Giuseppe (93) <
giuseppe.r...@dgfip.finances.gouv.fr> a écrit :

> Bonjour la liste,
>
> Un "client" a intégré des liens d'évitement pour accéder notamment au menu
> et au contenu, mais souhaiterait les retirer sur la version mobile. Ne
> connaissant pas trop le mode de navigation sur ce type de terminal je ne
> connais pas trop les contraintes pour les personnes avec handicap.
>
> J'ignore par exemple si le vocalisateur permet d'avoir la liste de liens
> comme avec NVDA ou JAWS et surtout, j'ignore si des personnes avec handicap
> moteur sont susceptibles d'utiliser ce type d'appareil (sur desktop les
> liens d'évitement étant en grande partie destinés aux personnes ne pouvant
> pas se servir d'un clavier).
>
> Par conséquent je souhaiterai savoir si ce critère s'applique de la même
> façon sur version mobile.
> --
>
> 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

Re: [Liste GTA] Flying focus

[Olivier Nourry]

Bonjour,
J'y vois les mêmes avantages et y mets les mêmes réserves que pour les
fonctionnalités de type agrandissement des polices on page. C'est
intéressant pour aider ponctuellement les utilisateurs qui ne savent pas
utiliser leur navigateur (un gros pourcentage) et qui ne sauront pas
installer une extension, ou utiliser un style type Bright Focus via
l'extension Stylish.
Mais le problème est que cette fonctionnalité ne sera par définition pas
disponible pour d'autres sites.
S'agissant d'un comportement inhabituel, cela peut gêner certains
utilisateurs. Personnellement j'en ferais plutôt une option désactivée par
défaut.

M2c
Olivier
Le 29 juin 2015 10:51, Steven Mouret steven.mou...@gmail.com a écrit :

 Merci Axel pour ton avis. Si il y a d'autres avis je suis preneur.

 Merci


 --
 Steven Mouret

 Le 24 juin 2015 19:52, Axel Roche a...@aquelito.fr a écrit :

 Hello Steven, Hello la liste,

 Je ferai tout pour ne pas cette lib en presta.
 Je n'y vois pas d'intérêt, il n'y a aucune prise en charge d'ARIA.
 La lib date un peu.. la démo n'est pas très attirante...

 Axel

 Le 24 juin 2015 11:57, Steven Mouret steven.mou...@gmail.com a écrit :

 Bonjour à tous,

 Pensez vous qu'une aide visuelle du type flying focus
 http://n12v.com/focus-transition/ doit être ajouté par l'éditeur d'un
 site web ou est ce plutôt un outil réservé côté client ?

 Je trouve l'idée plutôt bonne mais je me demande si les utilisateurs qui
 en ont le besoin ne sont pas déjà équipés.

 Après il y a toujours le moyen de le mettre par défaut et de pouvoir le
 désactiver.

 Merci pour votre retour d’expérience.

 --
 Steven Mouret

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




 --
 Cheers,
 Axel


 ___
 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] Hierarchisation de titres et référencement

[Olivier Nourry]

Bonsoir,
J'en remets une couche...
Utiliser ARIA pour patcher une pseudo -bonne pratique SEO me paraît
dangereux à plusieurs titres.
D'abord ce n'est pas robuste. Rien ne prouve que tous les utilisateurs
auront bien le rendu espéré. Il  y aura notamment des situations où les
headings sont utilisés sans avoir recours à un lecteur d'écran intégrant
totalement cette partie de la spec ARIA.
Et, comme pour les pansements IRL, des pansements sur des pansements sur
des trucs mal nettoyés c'est un nid à emmerdes (mais ce n'est pas
spécifique à l'accessibilité).
Plus secondairement (mais tout de même) ceci rend le 7.1 NC. Il y a des
situations où ça compte.
D'autre part rien ne dit que cela répond au problème sur le plan du SEO.
(il serait peut-être bien aussi de rappeler que les precos SEO sont de
l'ordre de la conjecture et que la vérité d'un jour n'est pas celle de la
version suivante de l'algorithme de Google).
Clairement, la seule approche saine, dans cette situation, est bien de
repartir à la base, lister les plus et les moins respectifs, et faire
prendre une décision en conséquence. Sachant qu'à ma connaissance il est
très difficile de prouver le bénéfice réel d'une telle pratique pour le
SEO, contrairement à l'impact utilisateur.

Sur un plan plus profond: ARIA est un outil formidable pour
l'accessibilité. On a enfin à disposition un outil pour tenter de faire des
interfaces vraiment accessibles. L'utiliser pour ce genre de déviance c'est
lui tirer dans le dos. Aussi sûrement que le détournement de balises pour
des raisons de SEO ou de mise en forme à flingué l'espoir d'un web
sémantique. Si même nous qui en comprenons les conséquences pour les
utilisateurs, ne défendons pas ARIA contre ce type de dévoiement, alors
c'est mal barré.
Franchement, sur ce coup là, je suis prêt à assumer toutes les accusations
d'intégrisme...
Le 13 mai 2015 10:38, Jean-Pierre Villain jpvill...@access42.net a
écrit :

  Bonjour Isabelle,

 Jean-Pierre, rassures-toi j'ai toujours à l'esprit ce qu'est mon job et
 j'en suis fière 

 Je n'en ai jamais douté et, pour te lire régulièrement sur cette liste,
 je suis certain que tu fera les choix les plus adaptés à la situation.
 Ce sont les affres de notre beau métier, ce qui le rends difficile mais
 passionnant.

 Bon courage

 JPV

 Le 13/05/2015 09:02, Ravet Isabelle a écrit :

 Merci pour vos réponses.

 Avec toutes vos remarques et suggestions, je vais reformuler mon
 argumentation.
 Jean-Pierre, rassures-toi j'ai toujours à l'esprit ce qu'est mon job et
 j'en suis fière

 Bonne journée à tous.

 Isabelle
  --
  *De :* liste_gta [mailto:liste_gta-boun...@list.accessiweb.org
 liste_gta-boun...@list.accessiweb.org] *De la part de* Jean-Pierre
 Villain
 *Envoyé :* mercredi 13 mai 2015 01:15
 *À :* liste_gta@list.accessiweb.org
 *Objet :* Re: [Liste GTA] Hierarchisation de titres et référencement

  Bonjour,

 De mon point de vue les tentatives de patcher ce genre d'usages sont,
 inéluctablement, vouées à l'échec et une bien mauvaise manière de
 promouvoir l'accessibilité.
 Après les headings, tu auras à patcher les alternatives d'images puis les
 liens, les titles etc etc.

 Tu devrais tenter de discuter, avec le formateur, lui demander de
 justifier sa recommandation, lui demander si c'est un point critique, lui
 exposer le problème qu'elle pose.
 Peut-être n'est-il simplement pas au courant que sa recommandation pose
 des problèmes.
 Il aura déjà un peu de mal (s'il est honnête et consciencieux) à montrer
 l'effet positif de ce genre d'astuce sur la performance en matière de
 référencement.
 Comme l'explique très bien Régine, il y a autant de risques avérés que de
 gains supposés...

 Peut-être est-il également possible que le site rentre dans le cadre
 règlementaire du RGAA, ce qui te donnera la possibilité d'expliquer qu'en
 plus de poser un problème d'accessibilité, ce détournement de balisage pose
 également un problème de légalité.
 Auprès d'un développeur la légalité bon
 Auprès d'un responsable, un risque juridique peut avoir un tout autre écho.

 Et si tu n'obtiens pas gain de cause, ne fais rien d'autre que ton job :
 reporte le problème, fais le exister sur tes rapports.

 Ce qui est important ce n'est pas tant l'utilisation abusive de heading,
 ce qui est important c'est que chacun fassent ses choix en conscience.

 Tu aura fais ton job.

 Mettre des morceaux de scotchs mal ficelés ne fera que rajouter de
 l'astuce à l'astuce pour un résultat saumâtre.

 Et je crains que tu ne satisfasse personne, surtout pas toi.

 Il ne faut pas confondre compromis et compromission.

 JPV

 Le 12/05/2015 21:28, Romain Gervois a écrit :

   Bonjour,

  Bon mon message va un peu piqué, j'en suis désolé mais je ne vois que ça
 dans un contexte défavorable pour l'accessibilité (c'est à dire où le SEO
 remporte la mise d'avance sans la moindre discussion) : on suit toutes les
 recos SEO et on patche avec ARIA c'est-à-dire :
 - utiliser des rôles 

Re: [Liste GTA] sortie officielle du RGAA 3.0

[Olivier Nourry]

Bonjour Ariane,

Je t'invite à te reporter à ce chapitre du guide d'accompagnement:
https://references.modernisation.gouv.fr/sites/default/files/RGAA3_RC2-1/guide_accompagnement.htm#__RefHeading__74798_1264946727

Rien de changé par rapport au RGAA 2.2.1, donc. Techniquement, tout le
monde est en mesure d'utiliser le RGAA pour vérifier une conformité. Le
guide conseille de le faire faire par un tiers indépendant du projet, mais
c'est à chacun d'en décider. Pour ce qui concerne une vérification
officielle, la mention indique que c'est par le Ministère chargé des
Personnes Handicapées... Ce qui reste théorique pour le moment. Il faudrait
notamment définir quels seraient les missions, pouvoirs, et surtout les
moyens de l'entité chargée de cette vérification.

Si on parle du label e-accessible (qui est quelque chose de totalement à
part, une mesure d'incitation parallèle, un bonus en quelque sorte), pour
le moment la situation est la suivante.
Le marché public relatif à la mise à jour du RGAA inclut la mise en place
et le lancement de ce label. C'est donc la DISIC qui en a la charge, et qui
délivre(ra) les labels. Pour l'inspection, la DISIC s'appuie pour le moment
sur les entreprises titulaires du marché pour exécuter et suivre les
audits. C'et la solution la plus logique et la plus simple dans cette phase
de mise au point. D'autant que le système dont s'inspire le label
e-accessible est le label AccessiWeb, du coup Braillenet et ses partenaires
du groupement (de longue date prestataires de Braillenet pour les
inspections) ont l'expérience nécessaire.
Mais c'est transitoire; à terme il y aura des inspecteurs agréés par
l'Etat, qui seront habilités à réaliser les inspections de labellisation.
Idem, ceci demande du travail en amont, pour définir les critères
d'attribution de l'agrément, évaluer les candidats, suivre l'évolution du
processus, contrôler le tout, etc. Mais c'est une évolution nécessaire. Ce
système ne serait pas viable, à long terme, s'il ne reposait que sur une
poignée d'inspecteurs liés par un marché limité dans le temps.

J'espère que ceci répond à ta question... Que tu ne dois pas être la seule
à te poser!

Cordialement,

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


Le 3 mai 2015 22:01, Ariane Pro ariane.andur...@gmail.com a écrit :

  Merci Aurélien!
 Ça tombe à pic pour ma conférence aux Joomla!day.

 Et j'ose poser la question, qui ça pourvoir auditer les sites publics ?

 --
 Ariane Pro
 Envoyé avec Sparrow http://www.sparrowmailapp.com/?sig

 Le dimanche 3 mai 2015 à 18:53, Aurélien Levy a écrit :

 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 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] Images - alt et title avec un espace plutôt qu'un vide

[Olivier Nourry]

Je suis peut-être à coté de la plaque mais voici ce que j'ai compris du
problème: si on ne saisit rien en back pour le alt, le module envoie le
chemin du fichier dans le alt.
La (bonne) proposition de patch js est de vérifier l'égalité de @src et
@alt et de vider @alt si égalité.
Si on saisit _espace_, l'espace est injecté dans @alt. D'où une (pas très
heureuse) proposition d'utiliser cette propriété pour remplacer les   par
. Mais restons sur la première.

Je dis que si ça parait simple, comme ça, il faut bien tout prendre en
compte, et notamment les cas où l'image est modifiée ou insérée
dynamiquement. Il y a des impacts, indéniablement, et pas uniquement
utilisateur. Se limiter à la seule résolution du problème ponctuellement,
c'est omettre toute la partie immergée de l'iceberg.
Tout cela en comparant aux deux autres voies possibles: corriger à la
source, ou ne rien faire.

L'enfer des projets Web est pavé de trucs qui à la base tiennent en 2
lignes de code...

Maintenant, ça ne reste que mon avis, et si je le partage ;-) [clin d’œil],
je n'oblige personne à y adhérer.

J'en profite pour lever une ambiguïté: jamais dit que l'accessibilité n'a
pas de coût (ce que laisse entendre ta réponse). Il faut être très naïf, ou
très malhonnête, pour croire cela. Juste qu'on ne peut pas prétendre le
budgéter de manière isolée, parce que sauf éléments très spécifiques (genre
production de contenus alternatifs, et recette et formation dédiées) c'est
dilué dans le reste, comme la sécurité, la perf et toutes ces sortes de
choses.


Cordialement,

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


Le 23 avril 2015 16:51, Romain Gervois cont...@romaingervois.fr a écrit :

 Je me corrige concernant le @src : ça fera deux conditions au lieu d'une
 mais ça change pas grand chose.

 Romain

 Le 23 avril 2015 16:36, Romain Gervois cont...@romaingervois.fr a écrit
 :

 Bonjour,




 *Olivier a écrit : Deux lignes? Peut-être, si tu as déjà une librairie
 chargée qui permet de condenser le code nécessaire pour parcourir le DOM,
 lister les éléments IMG, comparer @src et @alt (en n'oubliant pas de
 traiter les chaines pour éviter les blagues liées aux caractères spéciaux
 et autres scories de nommage de fichiers dans différents OS), remplacer
 l'un par l'autre. En ne se plantant pas sur le moment où on le fait, pour
 être sûr que l'image modifiée soit bien celle consultée par la TA via l'API
 d'access du client. Mais sinon, oui...Ah, attends, si des images sont
 insérées dynamiquement dans le DOM, genre sur un flux d'actus?Ou si on a
 plusieurs versions de l'image dans un contexte de RWD? Faut détecter
 l'événement et relancer la routine, non? Si tu sais faire ça en deux
 lignes, sans tester, je veux bien le code.*

 Les 2 lignes c'est une façon de parler, je remplace par une fonction de
 quelques lignes ça te convient mieux ?
 Et sans librairie (derrière au final ça fait la même chose que sans
 hein... donc pour ton histoire du chargement c'est encore pire).
 Et je ne comprends rien à ce que tu m'expliques là : que vient faire la
 source de l'image là dedans ? que vient faire le moment de l'exécution
 (événementiel ou autre) ? quel rapport avec le responsive ? quel rapport
 avec la TA ? Le problème est identifié, non ?
 Si tu cherches à me faire dire que ça demande des compétences de
 développeur, je te le confirme si tu avais un doute.
 Et enfin, la remarque sur le test, là encore je ne vois pas le rapport :
 un test n'est pas dépendant d'un nombre de lignes.

 Donc oui, l'accessibilité ce n'est pas que de l'orthographe et ça a donc
 un coût et si pas de budget, on peut compter sur autre chose pour que ce
 soit fait (ce que j'ai appelé convictions, le terme peut être différent si
 on veut : sérieux, l'implication ou autres, bref). On peut se cacher les
 yeux mais c'est comme ça (et ça ne veut pas dire que je suis un partisan de
 ces modes de prod, très loin de là).



 *Olivier : Et, oui, bien sûr, ne documentons pas cela. Cela n'arrive
 jamais qu'un bout de code, au rôle mystérieux pour quiconque sauf celui qui
 l'a écrit, traine des années dans le code sans que personne n'ose jamais le
 supprimer, y compris lorsqu'il est rendu obsolète par une autre évol. Et
 d'ailleurs, ne documentons rien, jouons-la hard core, c'est nettement plus
 fun.*

 Je ne me rappelle pas avoir écrit qu'il ne fallait pas documenter (comme
 je n'ai jamais dit que 2 lignes de code ça ne se teste pas). Je n'ai rien
 écrit de la sorte mais bon (j'adore le fait de faire reposer ce genre de
 problèmes sur le développeur ermite et asocial qui veut garder son code
 mystérieux).

 Olivier a écrit : Pure conjecture, on ne sait pas comment est monté ce
 projet. Si chaque page (ou groupe de pages) charge la même quantité de JS
 quelque soit le contenu, et les fonctionnalités, il y a sans doute aussi un
 problème...

 Certes, on a pas toutes les infos mais là encore je ne vois pas le
 problème avec ce qui nous

Re: [Liste GTA] Images - alt et title avec un espace plutôt qu'un vide

[Olivier Nourry]

Bonjour Nathalie,

*Il n'y a pas de ligne budgétaire pour l'accessibilité.*
Pardon, mais j'ai un peu de mal avec cet argument. Le module est buggé; il
faut donc traiter le bug, c'est-à-dire évaluer son impact (=le coût de
l'inaction), son coût de correction, et prendre une décision en fonction de
ces éléments. Point. Si l'impact est plus important que le coût, c'est à
corriger, sinon, on laisse en l'état. Personnellement je n'ai pas de
scrupule à laisser un bug qui ne dérange personne (*se couvre la tête avec
les bras pour se protéger des projectiles lancés par les
jusqu'au-boutistes*). Car l'argent dépensé ici pour rien aurait pu être
investi de manière plus utile sur un problème plus impactant. Le fait
d'avoir budgété ou non l'accessibilité (on va en reparler plus bas) n'a pas
grand chose à voir là-dedans. Note: dans les impacts, ne pas oublier tout
ce qui n'est pas accessibilité, genre SEO, dette technique et connexions
bas débit.

Je n'ignore pas les contraintes du terrain et la difficulté qu'il y a à
faire le job de CP (je l'ai été), où l'on est redevable des remises
accordées par un commercial qui empoche sa prime tandis que l'équipe se
fait engueuler pour avoir dépassé la charge qu'elle avait évaluée comme
insuffisante. Mais cette excuse du budget accessibilité est fumeuse, pour
rester poli. Y a-t-il un budget orthographe? Un budget commentaires du
code? Un budget réduction de la dette technique? J'en doute. Pourtant
tout designer/CP/contributeur/développeur conscient de sa responsabilité va
agir dans le bon sens. Pas de raison qu'il en soit autrement pour
l'accessibilité. Nous sommes tous bien placés sur cette liste pour savoir
que l'accessibilité requiert une compétence spécifique, acquise via de la
formation et l'expérience... Mais il en va de même de toute composante de
ce que l'on appelle, pour faire simple, un travail de qualité. Isoler
l'accessibilité en tant qu'acte technique revient à en faire un élément
optionnable, ce qui est le meilleur moyen d'en faire un élément optionné.
Ce qui distingue l'accessibilité du reste, c'est qu'il y a des situations
où elle n'est pas négociable...

Et comment budgète-t-on l'accessibilité dans un développement? Je fais ce
métier depuis 8 ou 9 ans. J'ai accompagné 15 ou 20 projets, je forme des
chefs de projets à l'accompagnement, j'ai obtenu ou contribué à obtenir 6
labels AccessiWeb. Mais je suis toujours bien incapable de dire ce que
coûte l'accessibilité, réellement... Tout comme je ne sais pas ce que coûte
une bonne orthographe. Je peux isoler des interventions dont le coût est
directement et uniquement imputable à l'accessibilité... mais c'est tout.
Pour moi cette notion de ligne budgétaire pour l'accessibilité est
artificielle, et dangereuse.



Je ne suis pas fan de la solution JS. Déjà, il faudrait la coder, la
documenter, la tester (on prend sur le budget rustines pour cela?),
l'implémenter sur toutes les pages... Plus l'imposer à chaque
téléchargement de page, et la faire tourner sur chaque page, pour tous les
utilisateurs. Tout ça pour? De plus, que se passera-t-il lorsque le module
évoluera? Qu'il aura un autre comportement qui mettra en échec le bout de
JS bricolé? AMHA, il faut soit faire la correction dans les règles (donc à
la racine), soit ne rien faire.


Cordialement,

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


Le 22 avril 2015 13:31, Nathalie Le Pontois - AE 
nathalielepont...@gmail.com a écrit :

 Je suis le prestataire. Nous installons un module communautaire. Le
 modifier implique que les mises a jour ne sont plus possibles sauf si la
 modification est impactée sur le module dans sa version communautaire.
 Il n'y a pas de ligne budgétaire pour l'accessibilité.

 Nathalie Le Pontois

 Le 22 avr. 2015 à 13:28, Ariane Pro ariane.andur...@gmail.com a écrit :

  Surtout que le prestataire gagnerait à l'implémenter sur son composant
 pour améliorer son produit...

 --
 Ariane Pro
 Envoyé avec Sparrow http://www.sparrowmailapp.com/?sig

 Le mercredi 22 avril 2015 à 12:19, Antoine Bouet a écrit :

  A ce que je vois, tous les prestataires ne sont pas généreux avec leurs
 clients, c'est dommage car ca ne me parait pas être de grosses
 modifications ...

 Cordialement,

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

 CIMEOS
 Montbéliard - Besançon - Paris

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

 www.cimeos.com

 COORDONNEES DU SUPPORT :
 Hébergement et Nom de Domaine : supp...@cimeos.com / 0899 49 42 00
 (1.34€/appel puis 0.34/min)
 Maintenance des sites : maintena...@cimeos.com
  Le 22/04/2015 12:16, Nathalie Le Pontois - AE a écrit :

 Je ne serai pas contre si mon budget me le permettait.. Ce n'est
 malheureusement pas le cas.

 Nathalie Le Pontois

 Le 22 avr. 2015 à 11:49, Antoine Bouet antoine.bo...@cimeos.com a
 écrit :

  Bonjour à tous,

 En même temps, quitte à intervenir autant modifier l'extension générant
 cette absurdité

Re: [Liste GTA] Images - alt et title avec un espace plutôt qu'un vide

[Olivier Nourry]

 qu'apparente, dès que l'on ajoute
quelque chose il faut être conscient que l'on ajoute des couches et des
couches de complexité.

Je me rappelle aussi cet audit où lorsque j'ai fait une préco toute simple
sur les alt, le client m'a dit qu'avec 6000 images dans la médiathèque,
j'allais le rendre fou. Qu'adviendra-t-il sur ce projet lorsque, ben,
finalement l'accessibilité devient une exigence, et qu'il faudra se
recogner l'ensemble des images déjà contribuées pour mettre le bon alt? On
a le droit de s'en foutre... ou pas.



Cordialement,

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


Le 23 avril 2015 12:00, Romain Gervois cont...@romaingervois.fr a écrit :

 Bonjour,

 Pardon, mais j'ai un peu de mal avec cet argument ... Isoler
 l'accessibilité en tant qu'acte technique revient à en faire un élément
 optionnable, ce qui est le meilleur moyen d'en faire un élément optionné.
 Ce qui distingue l'accessibilité du reste, c'est qu'il y a des situations
 où elle n'est pas négociable...

 Ce qui est recherché c'est du mesurable, mettre des tâches dans des cases
 (acte technique ou autre peu importe) et pouvoir
 les estimer pour les facturer et gérer des budgets ; ça ne va pas plus
 loin que ça. Aller plus loin c'est avoir des convictions.

 Je ne suis pas fan de la solution JS. Déjà, il faudrait la coder, la
 documenter, la tester (on prend sur le budget rustines pour cela?),
 l'implémenter sur toutes les pages... Plus l'imposer à chaque
 téléchargement de page, et la faire tourner sur chaque page, pour tous les
 utilisateurs. Tout ça pour? De plus, que se passera-t-il lorsque le module
 évoluera? Qu'il aura un autre comportement qui mettra en échec le bout de
 JS bricolé? AMHA, il faut soit faire la correction dans les règles (donc à
 la racine), soit ne rien faire.

 La coder c'est deux lignes. La documenter ? La tester ? Bon soyons fous,
 on le fait c'est pas bien long sur un tel truc.

 Concernant le déploiement sur toutes les pages, les systèmes de templates
 facilitent grandement le travail.

 En ce qui concerne le téléchargement, on parle d'un script de deux lignes
 mis en cache au premier appel. Quand on commencera à s'intéresser aux perfs
 sur des scripts aussi ridicules c'est qu'on aura fait un bon de géant dans
 nos productions.

 Enfin, j'ai beau retourné la chose dans tous les sens, je ne vois pas
 comment un truc non fonctionnel (remplacer un   par ) peut impacter
 quoi que ce soit dans le fonctionnement d'un module (sauf si il fait des
 choses en se basant sur un attribut alt  ).

 Bref, la solution JS me semble tout à fait pertinente dans ce cas (tout en
 remontant et en attendant des retours côté éditeur).
 Le tout ou rien, bof bof (on ne parle quand même pas d'un patch monstrueux
 d'une webapp là).

 Romain

 Le 23 avril 2015 11:00, Olivier Nourry olv.nou...@gmail.com a écrit :

 Bonjour Nathalie,

 *Il n'y a pas de ligne budgétaire pour l'accessibilité.*
 Pardon, mais j'ai un peu de mal avec cet argument. Le module est buggé;
 il faut donc traiter le bug, c'est-à-dire évaluer son impact (=le coût de
 l'inaction), son coût de correction, et prendre une décision en fonction de
 ces éléments. Point. Si l'impact est plus important que le coût, c'est à
 corriger, sinon, on laisse en l'état. Personnellement je n'ai pas de
 scrupule à laisser un bug qui ne dérange personne (*se couvre la tête avec
 les bras pour se protéger des projectiles lancés par les
 jusqu'au-boutistes*). Car l'argent dépensé ici pour rien aurait pu être
 investi de manière plus utile sur un problème plus impactant. Le fait
 d'avoir budgété ou non l'accessibilité (on va en reparler plus bas) n'a pas
 grand chose à voir là-dedans. Note: dans les impacts, ne pas oublier tout
 ce qui n'est pas accessibilité, genre SEO, dette technique et connexions
 bas débit.

 Je n'ignore pas les contraintes du terrain et la difficulté qu'il y a à
 faire le job de CP (je l'ai été), où l'on est redevable des remises
 accordées par un commercial qui empoche sa prime tandis que l'équipe se
 fait engueuler pour avoir dépassé la charge qu'elle avait évaluée comme
 insuffisante. Mais cette excuse du budget accessibilité est fumeuse, pour
 rester poli. Y a-t-il un budget orthographe? Un budget commentaires
 du code? Un budget réduction de la dette technique? J'en doute. Pourtant
 tout designer/CP/contributeur/développeur conscient de sa responsabilité va
 agir dans le bon sens. Pas de raison qu'il en soit autrement pour
 l'accessibilité. Nous sommes tous bien placés sur cette liste pour savoir
 que l'accessibilité requiert une compétence spécifique, acquise via de la
 formation et l'expérience... Mais il en va de même de toute composante de
 ce que l'on appelle, pour faire simple, un travail de qualité. Isoler
 l'accessibilité en tant qu'acte technique revient à en faire un élément
 optionnable, ce qui est le meilleur moyen d'en faire un élément optionné.
 Ce qui distingue l'accessibilité du reste, c'est

Re: [Liste GTA] Alternatives à SVG et bug NVDA

[Olivier Nourry]

Bonjour Nicolas,

Quelle est ta config? Pour ma part, sous FF 36.0.4 et NVDA 2015.1,
l'alternative est restituée une et une seul fois, sur les deux exemples.
Du coup je ne peux pas vraiment t'aider, désolé!

Pour info, la meilleure ressource que j'aie trouvée sur le sujet, pour
l'instant, est celle-ci (en anglais):
http://www.sitepoint.com/tips-accessible-svg/
Il se confirme que le role=img est bien nécessaire pour signaler la
présence d'un élément graphique à un maximum de couples
lecteurs/navigateurs. Donc la condition 1 du test 1.3.6 devrait être
systématiquement satisfaite. Tu peux aussi utiliser aria-labelledby, bien
que cette possibilité ne soit pas listée dans le test 1.3.6, tout en étant
recommandé dans l'article mentionné. Dans tous les cas, le test 1.3.7 te
permet de vérifier que tu as fait un choix adéquat.

J'espère que cela t'aidera.

Cordialement,

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


Le 8 avril 2015 18:36, Chardon Nicolas nchar...@voyages-sncf.com a écrit :

  Bonjour la liste !



 J’ai un souci en développement avec NVDA et Firefox, avec des SVG. Les
 graphiques SVG étant porteur d’information, j’ai renseigné une alternative
 via desc, ou aria-label comme recommandé dans le référentiel Accessiweb
 HTML 5. J’ai constaté que les alternatives ne sont lues que si le SVG un
 rôle image, mais, encore plus gênant, l’alternative est lue deux fois de
 suite par NVDA. Avez-vous rencontré ce bug, et avez-vous des solutions ? Le
 nombre important de graphiques dans la page pose en effet pas mal de
 problème aux utilisateurs de lecteurs d’écran, en raison des répétitions
 des alternatives. Voici le code utilisé :

 http://jsbin.com/boyetonoma/1/edit?html,output



 Merci par avance de vos lumières sur ce sujet !



 *NICOLAS CHARDON *

 *ARCHITECTE IHM *

 *VSC Technologies*

 2 place de la Défense – CNIT 1 – BP 440 – 92053 Paris La Défense Cedex

 TÉL. : +33 (0)1 58 13 73 22 (73 22)  - nchar...@voyages-sncf.com

 STANDARD : +33 (0)1 74 54 13 00

 Voyages-sncf.com, 23 sites couvrant plus de 30 pays.

 *[image: cid:image001.png@01CE40E4.80C5F060]*

 *[image: V.png]* http://mobile.voyages-sncf.com/

 Téléchargez notre application mobile http://mobile.voyages-sncf.com/

 *[image: twitter.jpg]* https://twitter.com/Voyagessncf_com

 Suivez-nous sur Twitter https://twitter.com/Voyagessncf_com

 *[image: Facebook.png]* https://fr-fr.facebook.com/VoyagesSncf.com

 Rejoignez-nous sur Facebook https://fr-fr.facebook.com/VoyagesSncf.com

 *[image: GooglePlus-512-Red.png]*
 https://plus.google.com/+voyagessncf/posts

 Rejoignez-nous sur Google + https://plus.google.com/+voyagessncf/posts





 ___
 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] Alternatives à SVG et bug NVDA

[Olivier Nourry]

J'ai pu reproduire aussi, finalement. Très bizarre. J'ai vérifié avec DOM
inspector: on n'a bien qu'un seul accessible name. Peut-être la présence de
role img? Ça rajoute un noeud graphic sous diagram, alors que j'aurais cru
que ça modifierait diagramme en graphic...
Un truc rigolo: quand tu passes le curseur souris sur le segment, la
vocalisation se fait en 2 endroits différents, dont l'un semble
correspondre à l'emplacement de use (activer l'inspecteur de Firefox
pour le visualiser). C'est peut-être lié.  As-tu essayé de mettre le path
directement dans la balise ? De jouer avec le rôle présentation ?
Le 9 avr. 2015 17:08, Steven Mouret steven.mou...@gmail.com a écrit :

 Bonjour,

 Je confirme la répétition avec NVDA 2015.1 et Firefox 37.0.1 sous windows 7


 --
 Steven Mouret

 Le 9 avril 2015 16:58, Chardon Nicolas nchar...@voyages-sncf.com a
 écrit :

  Bonjour Olivier,



 Merci pour ta réponse ! Je teste avec Firefox 37 sous Windows 7, avec
 NVDA 2015.1. Précédemment, sous Firefox 36, avec NVDA 2014.3, j’avais déjà
 le problème. J’ai un autre utilisateur qui a reproduit le problème,
 j’attends sa réponse pour connaitre sa configuration.



 J’avais bien lu l’article de Leonie Watson, et appliqué le role img comme
 recommandé, car sans celui-ci Voice Over ne restitue pas les alternatives.



 Je me pose quelques questions sur les critères applicables au SVG, par
 rapport au référentiel :

 -  Pour le 1.1.4 et/ou le 1.3.6, faudrait-il rajouter que le svg
 doit avoir le role img ?

 -  Dans le 1.3.6, on parle d’attribut title, est-ce que ça ne
 devrait pas plutôt être la balise title, dans le cas d’un SVG ?



 Nicolas



 *De :* liste_gta [mailto:liste_gta-boun...@list.accessiweb.org] *De la
 part de* Olivier Nourry
 *Envoyé :* jeudi 9 avril 2015 14:34
 *À :* liste_gta@list.accessiweb.org
 *Objet :* Re: [Liste GTA] Alternatives à SVG et bug NVDA



 Bonjour Nicolas,

 Quelle est ta config? Pour ma part, sous FF 36.0.4 et NVDA 2015.1,
 l'alternative est restituée une et une seul fois, sur les deux exemples.

 Du coup je ne peux pas vraiment t'aider, désolé!

 Pour info, la meilleure ressource que j'aie trouvée sur le sujet, pour
 l'instant, est celle-ci (en anglais):
 http://www.sitepoint.com/tips-accessible-svg/

 Il se confirme que le role=img est bien nécessaire pour signaler la
 présence d'un élément graphique à un maximum de couples
 lecteurs/navigateurs. Donc la condition 1 du test 1.3.6 devrait être
 systématiquement satisfaite. Tu peux aussi utiliser aria-labelledby, bien
 que cette possibilité ne soit pas listée dans le test 1.3.6, tout en étant
 recommandé dans l'article mentionné. Dans tous les cas, le test 1.3.7 te
 permet de vérifier que tu as fait un choix adéquat.

 J'espère que cela t'aidera.


   Cordialement,



  Olivier Nourry

 about.me/oliviernourry







 Le 8 avril 2015 18:36, Chardon Nicolas nchar...@voyages-sncf.com a
 écrit :

 Bonjour la liste !



 J’ai un souci en développement avec NVDA et Firefox, avec des SVG. Les
 graphiques SVG étant porteur d’information, j’ai renseigné une alternative
 via desc, ou aria-label comme recommandé dans le référentiel Accessiweb
 HTML 5. J’ai constaté que les alternatives ne sont lues que si le SVG un
 rôle image, mais, encore plus gênant, l’alternative est lue deux fois de
 suite par NVDA. Avez-vous rencontré ce bug, et avez-vous des solutions ? Le
 nombre important de graphiques dans la page pose en effet pas mal de
 problème aux utilisateurs de lecteurs d’écran, en raison des répétitions
 des alternatives. Voici le code utilisé :

 http://jsbin.com/boyetonoma/1/edit?html,output



 Merci par avance de vos lumières sur ce sujet !



 *NICOLAS CHARDON *

 *ARCHITECTE IHM *

 *VSC Technologies*

 2 place de la Défense – CNIT 1 – BP 440 – 92053 Paris La Défense Cedex

 TÉL. : +33 (0)1 58 13 73 22 (73 22)  - nchar...@voyages-sncf.com

 STANDARD : +33 (0)1 74 54 13 00

 Voyages-sncf.com, 23 sites couvrant plus de 30 pays.

 http://mobile.voyages-sncf.com/

 Téléchargez notre application mobile  http://mobile.voyages-sncf.com/

  http://mobile.voyages-sncf.com/

 Suivez-nous sur Twitter http://mobile.voyages-sncf.com/

  http://mobile.voyages-sncf.com/

 Rejoignez-nous sur Facebook http://mobile.voyages-sncf.com/

  http://mobile.voyages-sncf.com/

 Rejoignez-nous sur Google +  http://mobile.voyages-sncf.com/

   http://mobile.voyages-sncf.com/

   http://mobile.voyages-sncf.com/


 ___
 liste_gta mailing list
 *liste_gta@list.accessiweb.org*

 *http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org*
 http://mobile.voyages-sncf.com/

   http://mobile.voyages-sncf.com/

 ___
 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

Re: [Liste GTA] Demande peu conformiste...

[Olivier Nourry]

Bonjour Valérie,
Le fait est que rien ni personne n'oblige à appliquer les recommandations
d'accessibilité. Même pour les sites publics, cela reste très théorique...
Après tout, le payeur est seul maître à bord, s'il ne veut pas
d'accessibilité... On ne fait pas boire un âne qui n'a pas soif!
C'est presque pareil que pour tout corpus de bonnes pratiques: sécurité,
performances... Chaque décideur fait ses choix, et en assume les
conséquences.
Je dis presque, car d'un côté, les dites conséquences ne sont guère
étayées par des retours d'expérience indubitables (hormis le risque légal
aux usa). Mais d'un autre côté il y a la notion de discrimination passive
due à l'inaction. L'accessibilité est donc de ce point de vue un peu à
part, tout en restant sur le plan théorique pour le moment.
Une stratégie est possible, une fois ces arguments épuisés (car je doute de
leur efficacité avec ce client): le prendre au mot, et lister les
recommandations qui ne déforment pas le site... C'est à dire toutes, car
on doit pouvoir tout faire avec 0 impact sur l'interface, je pense, en
étant malin. Devant son étonnement, tu pourras lui expliquer que
l'accessibilité ne déforme pas les sites. Et que s'il y a des choix à
faire, c'est plutôt par rapport à l'impact utilisateur (ne pas hésiter à
l'humilier un chouïa en rappelant que l'on fait des sites pour les
internautes et pas pour soi ;-) [clin d'oeil]).

J'espère que cela t'aidera...
Le 8 avr. 2015 19:58, Valerie v.cichow...@gmail.com a écrit :

 Bonjour la liste,

 J'aimerais vous raconter une anecdote client, mais aussi savoir si cela
 vous est déjà arrivé et comment vous avez géré.

 J'ai un client marché privé pour qui on développe un nouveau site. Le
 client demande d'être RGAA dans son cahier des charges.
 Le projet, géré en Agile, donne des spécs et des wireframes validés au fil
 de l'eau.

 Les choix commercial et marketing montrent qu'une compatibilité RGAA
 devient impropable, ce que je remonte au client (qui fait de la vente de
 services en ligne après saisie de plusieurs formulaires de simulation).

 La réponse du client m'a fait tombée des nues: donnez-nous la liste des
 critères, on vous dira lesquels mettre en oeuvre, les autres seront
 éventuellement discutés en interne s'ils ne déforment pas notre site

 Que répondre à ça?? Comment lui faire comprendre qu'il ferait mieux
 d'abandonner l'access pour son site?

 Dois-je répondre à sa demande et lui prouver après dév que son choix ne
 donne rien avec une démo sur site?

 Je suis encore ce soir choquée, je suis coite pour lui répondre...

 Merci de vos retours,

 Valérie

 ___
 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] WebComponents et ARIA

[Olivier Nourry]

Tout frais issu de CSUN15, une présentation par 2 références du domaine:
http://alice.github.io/webcomponents-csun15/?full#title

Cordialement,

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


Le 5 mars 2015 00:11, Jean-Marc Delisle delisl...@gmail.com a écrit :

 Bonsoir Sylvain,

 Je suis tombé sur cette ressource, en espérant que cela te soit utile.

 Notes on Web Components + ARIA
 http://www.paciellogroup.com/blog/2012/07/notes-on-web-components-aria/

 Cordialement



 ___
 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] mise en pratique RGAA v3

[Olivier Nourry]

Aurélien a écrit: *s'entendait bien évidemment si la personne compte faire
les choses et non tout passer en dérogation ;)*

C'est précisément la valeur ajoutée de l'inspecteur, que de faire la part
des choses, et ne pas autoriser tout et n'importe quoi. Un candidat très
loin du niveau requis, et qui tortille pour essayer de rentrer au
chausse-pieds, n'a pas à recevoir de labellisation, point. Rappelons que
cela n'a rien d'obligatoire, et ne vise qu'à valoriser les efforts
réellement entrepris.
C'est pour cela d'ailleurs que l'inspection n'est pas qu'un acte technique
consistant à exécuter des tests, ce que tout le monde peut faire. Il faut
du métier, de l'expérience, et une certaine aptitude à défendre son point
de vue d'expert.


Cordialement,

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


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

  s'entendait bien évidemment si la personne compte faire les choses et
 non tout passer en dérogation ;)

 Aurélien

  Aurélien a écrit:
 *Concernant le différentiel RGAA 2 et 3 et la charge de travail que cela
 peut engendrer ce n'est pas forcement neutre ça dépend beaucoup des
 critères impliqués. Un exemple tout bête l'interdiction du pixel sur les
 tailles de caractère pour RGAA3 alors que RGAA2 se limitait aux éléments de
 formulaire. Cela peut exiger de reprendre toute la ou les feuilles de style
 et de refaire tous les tests d'affichages*

 Typiquement, si un candidat me signale que cette correction entraine cette
 charge de travail, je vais proposer une dérogation, eu égard à l'impact
 utilisateur qui peut être limité à certains cas très spécifiques. Si un
 utilisateur remonte le problème via le Canal Accessibilité, il sera demandé
 au candidat d'apporter une solution.

  Cordialement,

   [image: --]
 Olivier Nourry
 [image: 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


___
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

[Olivier Nourry]

inspecteur gadget... LOL!!! Je la replacerai celle-là!!
Effectivement, c'est quelque chose d'assez délicat, et une lourde
responsabilité, sachant qu'il y a derrière une présentation à la
labellisation, souvent, des mois ou années de travail acharné pour
appliquer les référentiels. C'est pourquoi il y aura (sans révéler de
secret d'Etat) un parcours de certification pour les inspecteurs, qui ne
portera pas uniquement sur la connaissance intime du référentiel, mais
également sur la compréhension du mécanisme de dérogation et d'aménagement
raisonnable. Pour ma part, je rajouterais un module Psychologie et Gestion
du Stress ;-) [clin d'oeil]

Cordialement,

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


Le 6 mars 2015 14:11, Ariane Andurand ariane.andur...@gmail.com a écrit :

 Ce qu'il faut en retenir, n'importe qui ne sera pas inspecteur agrée, il
 faut de la bouteille et des bases solides.
 Il ne faudra pas faire appel à un inspecteur gadget.

 Merci pour ces échanges instructifs.

 Le 6 mars 2015 12:00, Aurélien Levy aurelien.l...@temesis.com a écrit :

  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,

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


 Le 6 mars 2015 09:40, Aurélien Levy 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
 http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org




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



 --
 Aurélien Levy
 
 Temesis


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



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


___
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

[Olivier Nourry]

Bonjour,
au risque de me répéter: la procédure n'a pas évolué suite à l'audit. Elle
n'en avait pas besoin, et la notion d'aménagement raisonnable était bel et
bien décrite via le document d'accompagnement. Il est donc faux, à
plusieurs titres, d'écrire inflexibilité de la procédure de labelisation
qui ne prenait pas en compte la notion de raisonnable, et de dire que
l'audit a amené à la faire évoluer.

Ce qui s'est passé, très simplement: le candidat et l'inspecteur n'avaient
pas compris la même chose concernant les objectifs de la première visite et
de sa restitution, ce qui a amené à un malentendu, résolu par une
information plus détaillée auprès des deux parties. 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,

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


Le 6 mars 2015 09:40, Aurélien Levy 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
 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] mise en pratique RGAA v3

[Olivier Nourry]

Aurélien a écrit:
*Concernant le différentiel RGAA 2 et 3 et la charge de travail que cela
peut engendrer ce n'est pas forcement neutre ça dépend beaucoup des
critères impliqués. Un exemple tout bête l'interdiction du pixel sur les
tailles de caractère pour RGAA3 alors que RGAA2 se limitait aux éléments de
formulaire. Cela peut exiger de reprendre toute la ou les feuilles de style
et de refaire tous les tests d'affichages*

Typiquement, si un candidat me signale que cette correction entraine cette
charge de travail, je vais proposer une dérogation, eu égard à l'impact
utilisateur qui peut être limité à certains cas très spécifiques. Si un
utilisateur remonte le problème via le Canal Accessibilité, il sera demandé
au candidat d'apporter une solution.

Cordialement,

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


Le 5 mars 2015 18:09, Aurélien Levy aurelien.l...@temesis.com a écrit :

  Bonjour Claire,

 concernant les difficultés rencontrées lors de la labellisation du site du
 pas de calais il en tant qu'accompagnement coté pas de calais il y a eut
 plusieurs raisons à cela (mais Olivier Nourry qui était en charge l'audit
 de labellisation pourra corriger / amender )   :
 - différences RGAA 2 / 3 insuffisamment documentées à l'époque de l'audit
 et donc difficile à anticiper
 - remontés de choses qui étaient déjà validés précédemment lors d'autres
 audit Accessiweb et qui cette fois ne passaient plus
 - inflexibilité de la procédure de labelisation qui ne prenait pas en
 compte la notion de raisonnable

 A première vue une grande majorité de ces problèmes à depuis été traités.

 Concernant le différentiel RGAA 2 et 3 et la charge de travail que cela
 peut engendrer ce n'est pas forcement neutre ça dépend beaucoup des
 critères impliqués. Un exemple tout bête l'interdiction du pixel sur les
 tailles de caractère pour RGAA3 alors que RGAA2 se limitait aux éléments de
 formulaire. Cela peut exiger de reprendre toute la ou les feuilles de style
 et de refaire tous les tests d'affichages

 Aurélien

  Merci Régis,

 Ça répond tout à fait à ce que je cherchais.



 Par contre, je n’ai pas bien compris les retours catastrophiques de
 l’audit présenté par Access42 au séminaire accessiweb dont j’ai pu lire la
 présentation… !?







 *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 - fax.: +33 (0)4 76 44 00 41
 Services en ligne managés 24/7 - e-commerce, e-administration, e-business


  *De :* liste_gta [mailto:liste_gta-boun...@list.accessiweb.org
 liste_gta-boun...@list.accessiweb.org] *De la part de* Régis Lapeze
 *Envoyé :* jeudi 5 mars 2015 17:23
 *À :* liste_gta@list.accessiweb.org
 *Objet :* Re: [Liste GTA] mise en pratique RGAA v3



 Bonjour Claire,

 Je répond à tes questions dans l'historique de ton email (mes réponses
 sont en vert).

 Je te joint également un lien de téléchargement de la Grille Excel que
 nous utilisons pour le moment pour nos audits RGAA3 :


 http://www.oceaneconsulting.com/wp-content/uploads/2015/03/GRILLE-RGAA3-BETA3.xlsx



 J'espère que mes réponses te seront utiles.


  Cordialement,

 Lapeze Régis

 Consultant en accessibilité numérique

 email : regis.lap...@gmail.com

 mobile : 0688195411



 Le 5 mars 2015 15:11, Claire Daval claire.da...@businessdecision.com a
 écrit :

  Bonjour la liste,



 J’espère ne pas tomber trop comme un cheveu sur la soupe, mais de retour
 après une période d’interruption de quelques mois dans le monde de
 l’accessibilité numérique, je découvre un nouveau référentiel qui si je
 comprends bien  est un mélange entre l’ancien référentiel d’Accessiweb et
 la prise en compte des nouveautés liées à HTML5 et ARIA, j’ai bon
 jusque-là ?



 *En faite, c'est le référentiel AccessiWeb HTML5/ARIA qui a été utilisé
 comme base pour réaliser le RGAA3. Des critères ont été modifiés d'autres
 ajoutés ou supprimés pour apporter des réponses qui soit au plus proche des
 nouvelles technologie utilisées aujourd'hui. *





 J’ai vu passer notamment dans les questions / réponses sur les délais de
 mise en conformité :

 « Le délai de 18 mois dont il est fait mention dans le Guide
 d'accompagnement est un délai de transition pour laisser le temps aux
 administrations conformes au RGAA 2.2 de passer à la dernière version
 publiée du RGAA.

 Les sites n'étant pas conformes pourront directement se mettre en
 conformité avec la dernière version publiée ou avec la version antérieure,
 au choix, tant que le délai de transition n'est pas expiré »

 Concrètement cela veut quand même dire que quoiqu’il arrive la base de
 travail pour les sites de l’administration va devenir à court terme la
 version beta rgaa v3, j’ai toujours bon ?



 *La version officiel devrait être validé par l'administration dans les
 mois à venir. Ce sera alors la version 3.0. Il peut y avoir des

Re: [Liste GTA] Accessibilité de Jahia

[Olivier Nourry]

Hello,
Jahia est open source, déjà ça donne plus de latitude en cas de problème...
;-)
Je ne connais SharePoint que très superficiellement, mais si j'ai bien
compris on peut greffer dessus une interface de contribution différente, et
laisser à Sharepoint la pure gestion de données. Et pour le front,
développer des templates custom. Donc je pense que même avec ce produit là,
et même si c'est plus difficile, on doit pouvoir faire des sites
accessibles (un certain Tanguy devrait pouvoir le confirmer...).
Si on a le choix, autant prendre un truc plus aidant, mais je reste
convaincu que tout est faisable tant qu'on a assez de maîtrise et de
flexibilité pour tordre le code dans le bon sens.
Le 28 févr. 2015 11:39, Matthieu Faure m...@open-s.com a écrit :

  On 27/02/2015 21:14, Olivier Nourry wrote:

 Comme souvent, c'est la maîtrise du CMS, plutôt que le CMS lui-même, le
 facteur clé de réussite.

 oui, sauf si le CMS s'appelle SharePoint !

 La question est peut-être est-ce que Jahia = Sharepoint ?

 Matthieu (taquin le samedi matin)

 --
 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] Image animée : contenu en mouvement ?

[Olivier Nourry]

Bonjour Frédéric,

Réponse courte: oui, c'est un contenu en mouvement, mais à mon avis il faut
déroger.

Réponse longue:
Techniquement on a bien un contenu (image) qui bouge. En l'occurrence c'est
bien la notion de contenu qui fait question, mais en l'absence de
définition on va considérer, par précaution,que c'en est un.
Pour juger de la nécessité de faire appliquer ce critère on va d'abord
chercher à déterminer l'impact utilisateurs.
Ce critère adresse 2 situations:
- utilisateur ayant du mal à percevoir et/ou comprendre les contenus
mouvants
- Utilisateur gênés par les mouvements à l'écran tandis qu'il consulte des
contenus autres.

D'évidence le 1er cas est hors sujet. On peut même dire que le mouvement
participe à l'information. D'ailleurs tous les indicateurs de progression
reposent sur un principe similaire, ce serait pas simple de le remettre en
cause fondamentalement.

Le second cas en revanche mérite évaluation.
L'utilisateur va être gêné. Cependant l'accès à l'information n'est pas
strictement empêché.
La zone est petite, et je présume que le mouvement reste raisonnablement
discret. Ce qui réduit a priori le nombre de gens vraiment mis en
difficulté.

Pour déterminer si un correctif est approprié, un bon truc est d'imaginer
des solutions et évaluer si la difficulté de mise en place est compatible
avec l'impact utilisateurs estimé.
Ici je n'ai en tête que des choses impliquant des éléments d'interface
supplémentaires et l'enregistrement de préférences utilisateurs,
dispositifs dont la complexité me parait disproportionnée pour le besoin.
Donc, aménagement déraisonnable, d'où dérogation.

Les cas où on ne dérogera pas sont ceux où l'impact utilisateurs est plus
sévère, par exemple avec des effets stroboscopiques ou une constellation de
ces bidules dans la page... Ou alors si c'est un gyrophare, parce que faut
pas abuser non plus !

Bien sûr ne jamais oublier que si on déroge, on doit aussi proposer un
mécanisme de compensation, permettant aux utilisateurs de requérir un
aménagement s'il s'avère nécessaire.

Je ne pense pas qu'il soit nécessaire de modifier le référentiel pour une
entrée de glossaire ou des cas particuliers. AMHA ce serait
contre-productif ; la complexité d'une description exhaustive de tous les
cas nuirait à la lisibilité, et on n'est pas à l'abri de voir apparaître de
nouveaux cas imprévus. Il est sûrement plus efficace de consacrer temps et
ressources à décrire le mécanisme ci-dessus, et en permettre l'application
à bon escient. Parions sur l'intelligence de l'auditeur...
Le 18 déc. 2014 15:13, Frederic BERNIER-MALCOIFFE 
f.bernier-malcoi...@novia-systems.fr a écrit :

  Bonjour,

  voici le cas d'une image animée, déclenchée automatiquement, pour
 symboliser une synchronisation.
  L'image est petite (25 px). Elle comporte des flèches qui tournent.
  Techniquement, il s'agit d'un sprite avec une propriété CSS animation.

  Peut-on considérer cela comme du contenu en mouvement ?
  Si oui, le critère 13.17 serait donc non conforme car :
  - l'animation peut durer plus de 5 secondes,
  - l'animation n'est pas contrôlable,
  - l'animation n'est pas masquable.

  Une entrée dans le glossaire contenu en mouvement serait peut-être
 intéressante pour définir et donner des exemples.

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


___
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

[Olivier Nourry]

Bonjour Frédéric,

La solution d'une live region assertive marchera probablement, mais pas sûr
que ce soit très agréable à l'utilisation. Après tout l'utilisateur n'a pas
à subir une info systématique, il devrait pouvoir la consulter quand il le
souhaite.
Quitte à recoder, autant partir sur une progressbar. Il y a un rôle ARIA
pour ça:  http://www.w3.org/TR/wai-aria/roles#progressbar Il n'y  a pas de
DP associé, mais la doc du rôle suffit à concevoir un composant conforme.
Dans les faits:

   - role=progressbar sur le canvas
   - id sur le texte de description
   - aria-labelledby pointant vers le texte de description
   - aria-valuemin et aria-valuemax instanciées comme il faut
   - aria-valuenow mis à jour en fonction de la progression (note: pas
   besoin de aria-valuetext ici, puisque par défaut le texte restitué est
   calculé en %, si la TA suit la spec)
   - comme c'est le seul élément de la page, aria-busy pas applicable ici

Une remarque: CANVAS n'est peut-être pas le meilleur choix, sauf si tu es
sûr qu'il est supporté par les configs de tes utilisateurs. Un simple
sprite via une balise img fera l'affaire (sauf s'il y a des contraintes de
type: la forme, la couleur ou le remplissage varient selon le contexte, et
sont gérés via le script). Auquel cas tu peux utiliser le alt de l'image
pour décrire le composant (à la place du couple id/aria-labelledby), ou
garder un alt vide et le procédé id/aria-labelledby


Bien sûr, comme pour tout composant sur base ARIA et HTML5, tester sur ta
base de référence...




Cordialement,

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


Le 10 décembre 2014 18:12, Aurélien Levy aurelien.l...@temesis.com a
écrit :

  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'*E tic*) 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, *E tic* 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*.  [image: 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 
 listliste_gta@list.accessiweb.orghttp://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org



 --
 Aurélien Levy
 
 Temesis


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

Re: [Liste GTA] Liens explicites et pertinents

[Olivier Nourry]

Bonjour,

Pour moi les liens Twitter @ et # n'ont pas à être explicités du moment que
l'on sait qu'il s'agit d'un tweet. Car si ambiguïté il y a, elle est vraie
pour tout le monde: soit je sais qu'un lien @quidam mène au profil Twitter
de @quidam, soit je ne le sais pas, mais ça n'a pas de rapport avec une
situation de handicap. On pourrait imaginer de rajouter des title de type
Profil Twitter de quidam mais ça me parait un peu lourd.
Pour signaler le fait qu'il s'agit d'un tweet, en l'absence de tag
spécifique, on peut ruser de différentes façons je pense:

   - encapsuler le picto et le tweet dans un p, avec un alt de type
   Twitter sur le picto
   - utiliser un heading masqué pour l'ensemble du bloc
   - utiliser aria-label sur le bloc ou sur chaque tweet.

Pour les URL c'est encore plus clair: c'est non explicite pour tout le
monde, tweet ou pas tweet, donc N/A.

Pour Facebook, même idée, en considérant que le texte d'intro suffit à
former un contexte (le même pour tous les utilisateurs) permettant
d'expliciter le lien.

Cordialement,

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


Le 30 septembre 2014 17:07, Valerie v.cichow...@gmail.com a écrit :

 Bonjour la liste,

 Dans le cas des blocs de réseaux sociaux Twitter et Facebook affichés sur
 des pages d'accueil, doit-on et comment peut-on rendre les liens explicites
 et pertinents? Les tweets et publications FB ne possèdent pas de titre

 Peut-on accepter les titles voir le tweet sur twitter sur chaque entrée:


 [image: Images intégrées 1]

 Quel title pertinent mettre sur les lire la suite de FB:

 [image: Images intégrées 2]

 Ou pour les critères 6.1 et 6.3, peut-on parler ici de cas particuliers et
 dire que les critères sont non applicables?

 Merci pour vos réponses,

 Valérie

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

[Olivier Nourry]

Le site de commentaires préliminaire était voué à être temporaire, c'est
pour cela qu'il est fermé.
Les infos que j'ai concernant l'appel public: la recette accessibilité +
fonctionnalité d'appel à commentaire est en cours.
La mise en production est donc imminente.

Cordialement,

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



Le 4 septembre 2014 11:19, Aurélien Levy aurelien.l...@temesis.com a
écrit :

  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,

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



 Le 4 septembre 2014 10:21, Aurélien Levy 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
 http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org




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



 --
 Aurélien Levy
 
 Temesis


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


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