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

[ROSA Giuseppe (93)]

Très sympa de ta part Olivier.
Bon courage à tous

Cordialement,
Giuseppe



 Message original 
*Sujet :* [Liste GTA] attestation de déplacement dérogatoire au format 
DOCX accessible

*De :* Olivier Nourry 
*Pour :* Liste Gta 

*Date :* Mardi 17 Mars 2020, 08:59


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


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

[Liste GTA] framework tableau accessible

[ROSA Giuseppe (93)]

Bonjour la liste,

Je recherche un framework permettant d'avoir des tableaux accessibles 
proposant diverses fonctionnalités, par exemple le tri sur les entêtes 
de colonnes, la pagination, le responsive...


Il va sans dire, dans le respect du RGAA 4 (sourire).

Avez-vous des suggestions SVP et si oui quelles sont les fonctionnalités 
dont vous avez pu vérifier l'accessibilité ?


Avec tous mes remerciements

Cordialement,

DGFiP   Giuseppe ROSA
MOE en charge du projet SACRE EAI

Bureau SI-1C
Division des Recoupements et du Patrimoine (DRP)

Tél : 01.573.37.858
Pièce : 5261

Bâtiment A
4, avenue Montaigne
93468 Noisy-le-Grand Cédex


___
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

[ROSA Giuseppe (93)]

Bonjour Jean-Pierre,

"L'auditeur aurait du laisser le critère C et, éventuellement, signaler 
une amélioration possible (encore qu'en l'espèce je doute fortement de 
l'amélioration)."


C'est exactement ce que je lui ai demandé.

Encore merci pour toutes ces précisions.

Cordialement,

DGFiP   Giuseppe ROSA
MOE en charge du projet SACRE EAI

Bureau SI-1C
Division des Recoupements et du Patrimoine (DRP)

Tél : 01.573.37.858
Pièce : 5261

Bâtiment A
4, avenue Montaigne
93468 Noisy-le-Grand Cédex



 Message original 
*Sujet :* Re: [Liste GTA] liste non ordonnée vs liste de définition
*De :* Jean-pierre Villain 
*Pour :* Liste Gta 

*Date :* Mercredi 12 Décembre 2018, 09:57


Bonjour,

"L'auditeur, suite à mes remarques, a convenu que modifier cette liste 
n'était pas une priorité et qu'on pouvait s'en passer."


C'est un problème récurrent dans les audits : on remonte en NC des 
recos d'amélioration.


L'auditeur aurait du laisser le critère C et, éventuellement, signaler 
une amélioration possible (encore qu'en l'espèce je doute fortement de 
l'amélioration).


N'oubliez jamais que lorsque vous analysez un relevé de NC vous pouvez 
à tout moment contester les NC si ces dernières vous paraissent abusives.


Lorsque vous avez un doute demandez une justification par un cas 
utilisateur documenté et reproductible : vos relevés vont fondre comme 
neige au soleil lorsque l'audit aura été mené par un auditeur qui 
confond accessibilité et amélioration.


Si la réponse est que c'est "parce que le critère le demande" allez le 
vérifier et porter une attention particulière au glossaire ou au cas 
particulier.


Si la réponse est "parce qu'il y a un bug dans tel ou tel navigateur", 
"parce que l'utilisateur ne connait pas cette fonctionnalité", "parce 
que telle ou telle fonctionnalité est complexe à déclencher" appuyez 
vous sur les critères du RGAA : si ça n'est pas demandé par le RGAA 
c'est que ça n'est pas obligatoire, si ce n'est pas obligatoire ça ne 
peut pas être une NC.


JPV

Le 12/12/2018 à 08:58, ROSA Giuseppe (93) a écrit :

Bonjour,

Je vois que ma question a fait débat, et je vous en remercie.
Pour contextualiser mon intervention, on m'a demandé de relire les 
audits réalisés ces derniers mois.
L'auditeur, suite à mes remarques, a convenu que modifier cette liste 
n'était pas une priorité et qu'on pouvait s'en passer.
Par contre, des projets avaient déjà réalisé ce type de modification, 
d'autres non.


Suite à vos réponses, nous pourrons dire aussi bien aux projets qui 
l'ont fait qu'à ceux qui ne l'ont pas fait d'en rester là sur la 
question.


Encore une fois merci.

Cordialement,

DGFiP   Giuseppe ROSA
MOE en charge du projet SACRE EAI

Bureau SI-1C
Division des Recoupements et du Patrimoine (DRP)

Tél : 01.573.37.858
Pièce : 5261

Bâtiment A
4, avenue Montaigne
93468 Noisy-le-Grand Cédex



 Message original 
*Sujet :* Re: [Liste GTA] liste non ordonnée vs liste de définition
*De :* Olivier Nourry 
*Pour :* Liste Gta 

*Date :* Mardi 11 Décembre 2018, 20:40

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 <mailto:anth...@ladeuil.com>> a 

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

[ROSA Giuseppe (93)]

ap
www.atalan.fr  


Atalan est coordinateur des projets AcceDe Web et AcceDe PDF
www.accede.info
Le 11/12/2018 à 15:41, ROSA Giuseppe (93) a écrit :

Bonjour la liste,

Suite à un audit d'accessibilité sur certains de nos sites, le 
récapitulatif d'un formulaire de demande est présenté sous la 
forme d'une liste non ordonnée (ul > li).

Par exemple :

Récapitulatif de votre demande:


Nom : Dupont
Prénom : Patrick
Date et heure d'arrivé : mardi 11 décembre 2018 à 18 
heures
Date et heure de départ : jeudi 13 décembre 2018 à 13 
heures



Dans la restitution d'audit, il a été demandé de présenter cette 
liste sous la forme d'une liste de définition.
Cette demande m'a assez surpris d'une part, je ne considère pas 
que "Dupont" soit une définition du mot "Nom" et je pensais 
réserver essentiellement les listes de définitions (dl / dt / 
dd) à des glossaires essentiellement.


A titre d'exemple : sur le site du RGAA 3 (critères) nous avons :
Méthode de validationLe niveau de conformité est 
établi au niveau des critères selon ces statuts: Conforme (C): l'ensemble des tests applicables sont 
réussis; Non Conforme (NC): un test applicable est échoué, au 
moins; Non Applicable (NA): il n'y a pas de contenu concerné 
par le critère. RGAA propose, en plus de ces trois statuts de 
validation, deux statuts complémentaires: Dérogé (D): il existe des contenus dérogés applicables 
au critère; Non Testé (NT): le critère n'a pas été testé. 
 Ces deux listes sont plus proches pour moi d'une liste de 
définition que celle présentée à titre d'exemple au début de mon 
propos. J'en viens à mes questions : Quelle serait le type de 
liste le plus appropriée et/ou acceptable ? Des projets, suite à 
l'audit sont corrigés avec des listes de définition et je crains 
qu'un audit exécuté par un autre auditeur leur reproche 
d'utiliser des listes de définition.

Merci pour votre retour.

Cordialement,

DGFiP   Giuseppe ROSA
MOE en charge du projet SACRE EAI

Bureau SI-1C
Division des Recoupements et du Patrimoine (DRP)

Tél : 01.573.37.858
Pièce : 5261

Bâtiment A
4, avenue Montaigne
93468 Noisy-le-Grand Cédex



___
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

--
Access42

*Jean-Pierre VILLAIN*
Expert accessibilité numérique — Gérant
06 98 08 50 49 — 09 72 45 06 14

Expertise et formation en accessibilité numérique

Site web <https://access42.net/> — Twitter 
<https://twitter.com/access42net> — LinkedIn 
<https://www.linkedin.com/company/access42> — Newsletter 
<http://eepurl.com/dgHY2b>


Organisme de formation référencé dans le Datadock

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


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


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


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




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


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

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

[ROSA Giuseppe (93)]

Re-Bonjour,

Merci à Jean-Pierre et à Sébastien pour leurs réponse.

En conclusion, il est totalement inutile de changer (couteux pour un 
résultat au mieux inexistant). Pour ceux qui auraient déjà modifié leur 
code, il y a peu de risque qu'on leur demande de revenir en arrière.


Cordialement,

DGFiP   Giuseppe ROSA
MOE en charge du projet SACRE EAI

Bureau SI-1C
Division des Recoupements et du Patrimoine (DRP)

Tél : 01.573.37.858
Pièce : 5261

Bâtiment A
4, avenue Montaigne
93468 Noisy-le-Grand Cédex



 Message original 
*Sujet :* Re: [Liste GTA] liste non ordonnée vs liste de définition
*De :* Jean-pierre Villain 
*Pour :* Liste Gta 

*Date :* Mardi 11 Décembre 2018, 17:57


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 :

 1. 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.
 2. Comme l'auditeur sera incapable d'apporter cette preuve, refuser
la Non conformité
 3. Ne rien changer à l'implémentation a actuelle
 4. 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'utilisateur c'est zéro, y compris si le type était 
supporté. Pire cela alourdirait la restitution pour rien


JPV

Le 11/12/2018 à 16:07, Sébastien Delorme a écrit :

Bonjour Giuseppe,

On a pris l'habitude d'appeler liste de définitions les listes 
.
C'est lié de mémoire à la manière dont elles étaient présentées par 
le W3C dans HTML4.


Toutefois, depuis HTML5, la sémantique de ces listes est plus claire 
: il ne s'agit pas de listes de définitions mais de *listes de 
descriptions*.


The |dl 
<https://www.w3.org/TR/html/grouping-content.html#elementdef-dl>| 
element represents <https://www.w3.org/TR/html/dom.html#represent> a 
description list of zero or more term-description groups. Each 
term-description group 
<https://www.w3.org/TR/html/grouping-content.html#term-description-groups> 
consists of one or more terms

https://www.w3.org/TR/html/grouping-content.html#the-dl-element

L'exemple 27 présenté sur le lien ci-avant est très proche de celui 
remonté lors de l'audit.



En gros, une liste composée de couples clé/valeur est tout à fait 
adaptée pour être structurée avec  et .



Bien que le fait de demander à remplacer  par  me 
semble un peu strict*, et pas nécessairement indispensable, dans 
l'idéal oui, la liste  est effectivement plus appropriée 
dans ce contexte.
À l'inverse, il est peu probable qu'un autre auditeur puisse 
reprocher l'utilisation de  dans ce contexte.



Accessiblement,
Sébastien.

PS : à propos du "/un peu strict/" : c'est /très /subjectif et lié 
notamment au fait que ça ne changera pas grand chose pour 
l'utilisateur à ce jour car sur la majorité (la totalité ?) des aides 
techniques la liste de description est annoncée comme une simple liste.


Sébastien Delorme
sdelo...@atalan.fr

Tél. 01 45 26 77 89 / Port. 06 10 70 16 01



Atalan
Accessibilité numérique et sensibilisation au handicap
www.atalan.fr  


Atalan est coordinateur des projets AcceDe Web et AcceDe PDF
www.accede.info
Le 11/12/2018 à 15:41, ROSA Giuseppe (93) a écrit :

Bonjour la liste,

Suite à un audit d'accessibilité sur certains de nos sites, le 
récapitulatif d'un formulaire de demande est présenté sous la forme 
d'une liste non ordonnée (ul > li).

Par exemple :

Récapitulatif de votre demande:


Nom : Dupont
Prénom : Patrick
Date et heure d'arrivé : mardi 11 décembre 2018 à 18 heures
Date et heure de départ : jeudi 13 décembre 2018 à 13 
heures



Dans la restitution d'audit, il a été demandé de présenter cette 
liste sous la forme d'une liste de définition.
Cette demande m'a assez surpris d'une part, je ne considère pas que 
"Dupont" soit une définition du mot "Nom" et je pensais réserver 
essentiellement les listes de définitions (dl / dt / dd) à des 
glossaires essentiellement.


A titre d'exemple : sur le site du RGAA 3 (critères) nous avons :
Méthode de validationLe niveau de conformité est établi 
au niveau des critères selon ces statuts: Conforme (C): l'ensemble des tests applicables sont 
réussis; Non Conforme (NC): un test applicable est échoué, au 
moins; Non Applicable (NA): il n'y a pas de contenu concerné par 
le critère. RGAA propose, en plus de ces trois statuts de validation, 
deux sta

Re: [Liste GTA] Différences RGAA par rapport aux WCAG

[ROSA Giuseppe (93)]

Bonjour la liste,

Je prends connaissance de cette question et je vois que personne n'a 
répondu.

Je me permets donc de donner mon avis à Marie.

Le RGAA s'appuie sur les critères et techniques proposés par le WCAG. 
Aucun critère ou test du RGAA va à l'encontre du WCAG. Si on respecte le 
RGAA on respecte le WCAG 2.0.


Par contre :

 * Certaines techniques proposées par le WCAG n'ont pas été retenues
   par le RGAA. Celles-ci sont conformes au WCAG mais ne le sera peut
   être pas du point de vu RGAA. Il n'y a pas à ma connaissance une
   liste, diffusée pour le moins, de techniques WCAG qui ne sont pas
   reprises par le RGAA.
 * Le RGAA est parfois plus strict que le WCAG. Je ne sais pas si c'est
   un bon exemple, mais pour le critère 10.4, une note correspondant à
   la taille des caractères
   
(https://references.modernisation.gouv.fr/rgaa-accessibilite/glossaire.html#taille-des-caractres)
   mentionne "l'utilisation du pixel (|px|) est proscrite". Je ne suis
   pas sur que le WCAG soit aussi catégorique : la technique F80
   (https://www.w3.org/TR/WCAG-TECHS/F80.html) demande de vérifier que
   le texte s’agrandisse de la même manière que le reste de la page, à
   200% si on zoom à 200%, sans interdire strictement le pixel.


J'espère avoir répondu à ta question Marie et ne pas avoir dit de bêtises.

Bonne vacances à ceux qui sont encore concernés.

Cordialement,

DGFiP   Giuseppe ROSA
MOE en charge du projet SACRE EAI

Bureau SI-1C
Division des Recoupements et du Patrimoine (DRP)

Tél : 01.573.37.858
Pièce : 5261

Bâtiment A
4, avenue Montaigne
93468 Noisy-le-Grand Cédex



 Message original 
*Sujet :* [Liste GTA] Différences RGAA par rapport aux WCAG
*De :* Marie Hanotte 
*Pour :* Liste Gta 

*Date :* Vendredi 13 Juillet 2018, 12:04


Bonjour la liste,

Dans le guide d'accompagnement du RGAA, il est indiqué : "Il est 
important de comprendre que si le RGAA est entièrement compatible avec 
les WCAG 2.0, l'inverse n'est pas forcément vrai.".


Si je comprends bien cette phrase, le RGAA couvre l'ensemble des WCAG, 
mais il demande des critères/tests supplémentaires.
Si c'est le cas, auriez-vous déjà vu une liste détaillée de ce 
périmètre supplémentaire ?
J'ai déjà cherché un peu sur le web mais rien trouvé d'assez précis à 
ce sujet.


Pour comprendre un peu le contexte de ma question : nous mettons en 
place un système de tests de développement, qui est basé sur les WCAG.

Cela ne prend bien sûr en compte que ce qui est automatisable à tester.
Comme notre objectif est la compatibilité RGAA, nous nous demandions 
donc si nous devions ajouter des tests customs, qui ne seraient pas 
dans ceux WCAG fournis par l'outil.
Pour ça nous aurions besoin de savoir quels critères/tests du RGAA ne 
seraient pas dans les WCAG (et après ce sera bien sûr à nous de voir 
ce qui est automatisable ou non).


Merci d'avance pour votre retour !

Marie Hanotte
https://twitter.com/mh_nichts


___
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

[ROSA Giuseppe (93)]

Bonjour Audrey et Olivier,

Je vous remercie tous les deux pour vos retours. Je vais essayer de
faire au moins ajouter le id/for qui pourrait ne pas être trop coûteux
pour le projet (et je croise les doigts 
;-)   (clin d'oeil).


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] Input entre balises label
De : Olivier Nourry <olv.nou...@gmail.com>
Pour : liste_gta@list.accessiweb.org
<liste_gta@list.accessiweb.org>
Date : 03/10/2017 16:15

  
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 <aman...@access42.net>
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,
  

  


  
  
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

Re: [Liste GTA] Input entre balises label

[ROSA Giuseppe (93)]

Merci Alex pour ces précisions.

Un rapide essai avec NVDA et Firefox ESR52 ne présente pas de problème
de vocalisation pour les cases à cocher et les boutons radio, ni en
mode consultation, ni en mode formulaire.

J'espère qu'avec le WCAG 2.1 le W3C fera un peu de ménage car il va
être difficile d'inciter à la modification du code pour des versions
obsolètes de navigateurs (IE6 et Firefox 1.5).


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] Input entre balises label
De : Alex Bernier <alex.bern...@braillenet.org>
Pour : liste_gta@list.accessiweb.org
Date : 03/10/2017 16:04

  On Tue, Oct 03, 2017 at 03:35:39PM +0200, ROSA Giuseppe (93) wrote:
  
  
   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...) ?

  
  
C'est WCAG qui le dit dans une note technique liée à la technique H44 (cf http://www.w3.org/WAI/WCAG20/Techniques/ua-notes/html#H44 ): « The HTML and XHTML specifications allow both implicit and explicit labels. However, some assistive technologies do not correctly handle implicit labels (for example, First name ). »

(Cela dit, les versions des AT concernées sont très anciennes et les contextes d'utilisation très spécifiques...)

Alex

  
  
   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 : [1]http://si1a.intranet.dgfip/soda
   RGAA : [2]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

Références

   1. http://si1a.intranet.dgfip/soda
   2. http://si1a.intranet.dgfip/rgaa

  
  
  
  
___
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] Input entre balises label

[ROSA Giuseppe (93)]

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

Re: [Liste GTA] courriel

[ROSA Giuseppe (93)]

Merci Marie, 

J'ai lu avec grand intérêt les articles que tu nous a transmis. Merci,
cela répond tout à fait à mes attentes.


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] courriel
De : Marie Hanotte <m.hano...@acti.fr>
Pour : liste_gta@list.accessiweb.org
Date : 17/07/2017 09:31

  
  
  
  
  
  
  
  
  

  


  

  
  Bonjour
Giuseppe et Steven,
  


  
  Pour ma part
j'avais mis de côté ces liens pour référence sur les e-mails
accessibles :
  
  https://www.campaignmonitor.com/resources/guides/accessibility/
  http://blog.gorebel.com/accessibility-in-email/
  http://blog.gorebel.com/accessibility-in-email-part-ii/
  Globalement
il s'agit d'avoir les mêmes bonnes pratiques que sur les sites, entre
autres mettre un role="presentation" sur les tableaux qui ne servent
qu'à la mise en forme.
  Je suis
preneuse aussi d'autres ressources sur le sujet si quelqu'un en a !
  
  Cordialement,
  


  
  

  

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

  

  
  

  

   
  

  
  


  
  
  Info
congÉs //  Je serai en congés le 13 juillet,
du 14 au 18 août et du 28 août au 1er
septembre. 
En mon absence, pour toute question, je vous invite à contacter
l'équipe acti au 04
37 37 25 10. 
Pour information : l'agence sera fermée le 14 août.
Toute l’équipe d’acti vous souhaite un excellent été 2017.
  
  

  


  
  


  

  

  


  

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

  


  

  
  

  
  
  
  
 
  

  
  

  


  
 


  

  

  


  


  
  
  Le 13/07/2017 à 09:49, ROSA Giuseppe
(93) a écrit :
  
  

Merci Steven, 

Cela correspond totalement à la réponse que j'ai moi-même fait aux
équipes, soulignant également la problématique des tableaux.

Comme toi, je serais intéressé par un retour d'expérience sur le sujet,
si quelqu'un à déjà pris en compte ce type de problème, hors du fait
d'envoyer sur une page d'un site en cas de difficultés d'affichage.
 
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] courriel
De : Steven Mouret <steven.mou...@gmail.com>
Pour : liste_gta@list.accessiweb.org
Date : 13/07/2017 09:34

  Bonjour Rosa,
  
  
  Voici un paragraphe de l'article
47 de la loi du 11 février 2005 modifiée par la loi du 7 octobre
2016.
  
  
  "L'accessibilité
des services de communication au public en ligne concerne l'accès à tout
type d'information sous forme numérique, quels que soient le moyen
d'accès, les contenus et le mode de consultation et concerne notamment
les sites internet, intranet, extranet, les applications mobiles, les
progiciels et le mobilier urbain num

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

[ROSA Giuseppe (93)]

Bonjour la liste,

Pour ma part, il me semble possible d'avoir plusieurs ligne d'en-tête,
par exemple, avec des cellules th fusionnées sur la première ligne
d'en-tête et d'utiliser l'attribut scope, la cellule th portant bien
sur l'ensemble de sa colonne ici.

Par exemple dans l'exemple fictif ci-dessous :


    Nombre de participants, hommes et femmes, de moins
de 20 ans et de plus de 20 ans
    
        
            Année
            moins de 20
ans
            20 ans ou
plus
        
        
            Homme
            Femme
            Homme
            Femme
        
    
    
        
            2016
            30
            25
            47
            33
        
        
            2015
            28
            27
            45
            25
        
    



la cellule d'en-tête "moins de 20 ans" s'applique sur la totalité de la
colonne, aussi bien sur la sous-colonne "Homme" que celle
"Femme".
Avec NVDA l'attribut scope permet bien de rattacher chacune des
colonnes d'en-tête car par exemple, sur la première cellule de donnée
"30" j'ai le message "Homme moins de 20 ans  colonne 2 30" (copie de la
visionneuse de parole).

S'il y a une faille dans mon interprétation, je suis preneur.


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]  utilisation de l'attribut scope sur un tableau
à double entrée ?
De : Xavier Vigilant 
Pour : liste_gta@list.accessiweb.org
Date : 10/02/2017 10:38

  
  
  Bonjour Philippe,
  
  
Je m'assure d'avoir bien compris ta règle: si une tableau quel qu’il
soit possède un attribut rowspan ou colspan, on ne peut pas utiliser
scope ? 
  
  
Xavier
  
  
  Le 7 février 2017 à 17:54, Philippe
Vayssière 
a écrit :
  

Bonjour,

variante : s'il n'y a pas d'attributs colspan et rowspan,
tu peux utiliser l'attribut scope sinon non.


Philippe

Le 07/02/2017 à 17:31, Xavier Vigilant a écrit :



  
  
  
  Je confirme, c'est comme ça que j'avais compris
l'utilisation du scope.
  
  
  
  
Cordialement,
  
  
Xavier
  
  
  Le 7 février 2017 à 16:21, Aurélien Levy
  
a écrit :
  

Bonjour
Hervé,

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

Aurélien


  
  
  
  Bonjour,
   
  Pouvez-vous, svp, m'ôter un doute ?
   
  Pouvez-vous me confirmer si on peut
utiliser des attributs scope à la fois sur les entêtes de colonnes et
sur les entêtes de lignes d'un tableau (simple) à double entrée ?
  (bien sûr dans le cas où le scope
s'applique bien à toute la colonne ou à toute la ligne)
   
  En relisant le RGAA 3, je pense que oui
mais ce qui me met le doute ce sont de vieilles notes datant
d'AccessiWeb V1 dans lesquelles je m'étais noté que scope était réservé
aux tableaux à simple entête (on ne pouvait mettre que du scope="row"
ou que du scope="col" dans un même tableau mais pas les deux à la fois).
   
  Je ne sais pas si c'est une consigne qui
effectivement était valable en AccessiWeb V1 ou si c'est une erreur
dans mes notes.
   
  Merci pour votre éclairage.
   
  Hervé
CHUZEVILLE
   
  
  
  


  
  
  



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

  
  
  
  
  

___
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.4] balise abbr avec title sous NVDA

[ROSA Giuseppe (93)]

Bonjour et merci à tous les deux pour vos réponses.

En effet, l'idéal serait de répéter le texte en toute lettres.
Sur les travaux en cours, je propose effectivement l'affichage d'un
tooltip qui s'affiche au clavier, d'où ma déception en constatant qu'il
n'y avait pas de vocalisation sur les balises abbr (abréviation).
Par contre je me demandais s'il y aurait intérêt à faire une moulinette
_javascript_ qui lorsqu'il rencontre une balise abbr (abréviation) avec
un title il ajoute un texte caché lisible par les vocalisateur (type
classe .sr-only).

par exemple :
RGAA deviendrait : 
RGAARéférentiel
Générale d'Accessibilité pour les administrations">RGAA

bien sur avec un title qui s'affiche au clavier


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 9.4] balise abbr avec title sous NVDA
De : COUSQUER Christian <christian.cousq...@upmc.fr>
Pour : liste_gta@list.accessiweb.org
<liste_gta@list.accessiweb.org>
Date : 20/01/2017 12:37

  
  

  
  
  Bonjour,
   
  D’autant plus que certaines synthèse vocale ajoutent de
l’intelligence par-dessus.
  J’ai eu le cas sous VoiceOver d’un splendide : « 15.00
Grande-Bretagne » pour 15.00 Go ( écrit « 15.00 GB »).
   
  Cordialement
  Christian
   
  
  
  De : liste_gta [mailto:liste_gta-boun...@list.accessiweb.org]
  De la part de Sylvie Duchateau
  Envoyé : vendredi 20 janvier 2017 10:47
  À : liste_gta@list.accessiweb.org
  Objet : Re: [Liste GTA] [critère 9.4] balise abbr avec title
sous NVDA
  
  
   
  Bonjour Giuseppe et la liste, 
  Malheureusement, la restitution des abréviations par les lecteurs
d'écran n'est pas idéale.
  
  J'avais réussi à faire vocaliser par nVDA une abréviation avec
title, mais par hasard, et cela ne marche plus. Les développeurs de
NVDA indiquaient que développer les abréviations n'était pas leur
préoccupation.
  VoiceOver ne vocalise rien du tout non plus. 
  Quant à Jaws, cela se paramètre dans les options de verbosité.
Mais on doit choisir si Jaws développe l'abréviation ou ne la développe
pas. Soit on entendra RGAA, par exemple, soit Référentiel Générale
d'Accessibilité pour les administrations.
  Il n'est donc pas possible de comprendre la relation entre les
deux.
  Le seul lecteur d'écran qui avait compris l'utilisation des
abréviations était window-eyes, pas utilisé chez nous. Lorsqu'il
rencontrait une abréviation, il l'indiquait et la développait.
  Voici un échange à ce sujet sur la liste webaim, en anglais, qui
détaille ce problème.
  Des développeurs expliquent qu'ils ont tenté d'utiliser ARIA, des
textes cachés, etc, mais que ce n'est pas satisfaisant.
  Ils expliquent que l'inconvénient du title dans abbr et qu'il
n'est pas utilisable au clavier, à moins de rajouter un tooltip
permettant d'afficher le title à la tabulation.
  La conclusion est de préférer l'écriture en toutes lettres de la
signification de l'abréviation la première fois qu'elle apparaît. Utile
pour les lecteurs d'écran, ceux qui n'ont pas de souris.
  Voir la discussion
sur la liste de Webaim.
  Bonne journée
  Sylvie
  Le 19/01/2017 à 13:48, ROSA Giuseppe (93) a
écrit :
  
  
  
Bonjour la liste
et bonne année à tous.

Ma question concerne un critère AAA.
La dernière condition du test 9.4.1 valide par l'ajout d'un title sur
la balise abbr, le critère 9.4 demandant de connaître (pour la première
occurrence) la signification d'une abréviation.

Par contre dans mes différents essais, le title n'est pas vocalisé avec
NVDA, ni sous Firefox ni sous IE11 (je n'ai pas testé avec JAWS ni avec
Voice Over).

Je conseille actuellement de mettre en œuvre une autre solution
(afficher en toutes lettres masqué ou non à l'écran) mais par contre je
me vois obligé de valider le critère bien qu'il ne soit pas restitué.

Remarque : aria-label, aria-labelledby et aria-describedby ne sont pas
non plus restitués dans une balise abbr (Firefox 46 /NVDA 2016.3).

Avez-vous constaté ce dysfonctionnement avec NVDA et la même chose avec
JAWS et VoiceOver ?



-- 

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

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

[ROSA Giuseppe (93)]

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

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

[ROSA Giuseppe (93)]

Re-bonjour,

Ceux concerant la version 3.0 ne le sont malheureusement plus.


Giuseppe



 Message original 
Sujet : Re: [Liste GTA] RGAA 3 2016 balise object et embed
De : Jean-Pierre Villain <jpvill...@access42.net>
Pour : liste_gta@list.accessiweb.org
Date : 28/07/2016 11:48

  
  Bonjour,
  Il s'agit de traitement d'issues, certaines sont publiques sur le
dépot github géré par la Dinsic.
  JPV
  
  
  
  
  Le 28/07/2016 à 11:42, ROSA Giuseppe
(93) a écrit :
  
  

Merci Jean-Pierre pour ces précisions.

Ces débats ou réflexions ont-ils fait l'objet d'écrits ? Ces derniers
pourraient être très enrichissant à consulter.
 
Cordialement,

Giuseppe



 Message original 
Sujet : Re: [Liste GTA] RGAA 3 2016 balise object et embed
De : Jean-Pierre Villain <jpvill...@access42.net>
Pour : liste_gta@list.accessiweb.org
Date : 28/07/2016 11:23

  
  [edit ] désolé du spam, thunderbird à des hoquets.
  La réponse complète est ci-dessous
  JPV
  
  
  
  Bonjour,
  Ce n'est pas un bug mais une application du raisonnement
suivant :
  1. title ou les liaisons Aria sur des objets (object et embed)
peuvent ne pas être restitués sur certaines AT, donc on ne peux pas les
utiliser comme alternative, d'où leur absence en 1.3.4 et 1.3.6
  2. mais ces alternatives peuvent être présentes, donc il faut
bien s'assurer que si elles sont présentes elle correspondent bien au
fonctionnement proposé par le calcul du nom accessible.
  Les tests 1.3.5 et 1.3.7 sont donc uniquement destinés à
vérifier ça.
  Nous n'avons pas besoin de vérifier la pertinence du title ou
des liaisons ARIA puisque l'alternative en 1.3.4 ou 1.3.6 est
obligatoire. 
  
  On pourrait objecter que dans ce cas il faut s'assurer que les
contenus proposés via title ou les propriété ARIA sont pertinents,
c'est à dire identiques à l'alternative rendu obligatoire en 1.3.4 et
1.3.6.
  
  Nous ne l'avons pas fait pour la raison suivante : les images
objet ne possédant pas de dispositif permettant d'associer une
description courte à une description détaillée (comme les image avec
ALT et LONGDESC ou son équivalent via un lien ou une description
adjacente) il pourrait être jugé utile par les auteurs d'utiliser un
title ou une propriété ARIA pour reproduire ce mécanisme pour les AT
les prenant en charge. Donc il n'est pas possible de demander que les
textes liés soient identiques à l'alternative ce qui tuerait cette
utilisation pas complètement accessible mais néanmoins possible.
  
  L'autre solution aurait été d'interdire la présence d'un title
ou de propriété ARIA sur les images objets ce qui est naturellement
impossible.
  Nous avons donc essayé de trouver le meilleur compromis et
celui qui laisse le plus de souplesse à des auteurs qui voudraient,
éventuellement, utiliser ce type de mécanisme.
  Plus généralement :
  Cette problématique de l'utilisation de propriétés en
surcharge ou en complément de dispositifs natifs est particulièrement
complexe à implémenter avec des effets de bords nombreux en termes de
complexité du référentiel, de compréhension par les auteurs et de
gestion de la conformité.
  Dans le cas présent, la conformité est assurée par la présence
de l'alternative obligatoire en 1.3.4, 1.3.6 et les tests 1.3.5 et
1.3.7 contrôle un effet de bord possible de l'utilisation d'ARIA.
  Du point de vue de l'utilisateur le service est bien rendu :
l'alternative est présente et sa pertinence est vérifiée et nous
garantissons que l'utilisation éventuelle d'ARIA est correctement
implémentée quelque soit les contenus effectivement proposés par ces
dispositifs.
  Il est difficile de savoir si ce type d'approche est efficace,
nous le saurons avec les retours et si nécessaire cela sera adapté lors
de la prochaine mise à jour.
  Quoi qu'il en soit : l'utilisation et la présence de ces
attributs ne veux pas dire qu'ils peuvent être utilisés comme
alternative, de ce point de vue le référentiel est clair et univoque.
  JPV
  
  Le 28/07/2016 à 10:20, ROSA Giuseppe
(93) a écrit :
  
  

Bonjour Aurélien,

Je me doutais bien que tu étais Goetsu 
;-)  (clin d'œil). 

D'après ce que je comprends, aria-label et aria-labelledby ne figurent
pas comme alternative car ils ne répondent pas à tous les cas de figure
(ou d'handicap). 

Mais effectivement, je te rejoints sur tes remarques, et je pense que
les tests correspondant (1.3.5, 1.37) devraient peut-être préciser "également
une propriété aria-label..." et ajouter la vérification de
la cohérence (et donc la pertinence) avec l'alternative répondant
respectivement aux tests 1.3.4 et 1.3.6.
 
Giuseppe


 Message original 
Sujet : Re: [Liste GTA] RGAA 3 2016 balise object et embed
De : Aurélien Levy <aurelien.l...@temesis.com>
Pour : l

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

[ROSA Giuseppe (93)]

Merci Jean-Pierre pour ces précisions.

Ces débats ou réflexions ont-ils fait l'objet d'écrits ? Ces derniers
pourraient être très enrichissant à consulter.


Cordialement,

Giuseppe



 Message original 
Sujet : Re: [Liste GTA] RGAA 3 2016 balise object et embed
De : Jean-Pierre Villain <jpvill...@access42.net>
Pour : liste_gta@list.accessiweb.org
Date : 28/07/2016 11:23

  
  [edit ] désolé du spam, thunderbird à des hoquets.
  La réponse complète est ci-dessous
  JPV
  
  
  
  Bonjour,
  Ce n'est pas un bug mais une application du raisonnement suivant :
  1. title ou les liaisons Aria sur des objets (object et embed)
peuvent ne pas être restitués sur certaines AT, donc on ne peux pas les
utiliser comme alternative, d'où leur absence en 1.3.4 et 1.3.6
  2. mais ces alternatives peuvent être présentes, donc il faut bien
s'assurer que si elles sont présentes elle correspondent bien au
fonctionnement proposé par le calcul du nom accessible.
  Les tests 1.3.5 et 1.3.7 sont donc uniquement destinés à vérifier
ça.
  Nous n'avons pas besoin de vérifier la pertinence du title ou des
liaisons ARIA puisque l'alternative en 1.3.4 ou 1.3.6 est obligatoire. 
  
  On pourrait objecter que dans ce cas il faut s'assurer que les
contenus proposés via title ou les propriété ARIA sont pertinents,
c'est à dire identiques à l'alternative rendu obligatoire en 1.3.4 et
1.3.6.
  
  Nous ne l'avons pas fait pour la raison suivante : les images
objet ne possédant pas de dispositif permettant d'associer une
description courte à une description détaillée (comme les image avec
ALT et LONGDESC ou son équivalent via un lien ou une description
adjacente) il pourrait être jugé utile par les auteurs d'utiliser un
title ou une propriété ARIA pour reproduire ce mécanisme pour les AT
les prenant en charge. Donc il n'est pas possible de demander que les
textes liés soient identiques à l'alternative ce qui tuerait cette
utilisation pas complètement accessible mais néanmoins possible.
  
  L'autre solution aurait été d'interdire la présence d'un title ou
de propriété ARIA sur les images objets ce qui est naturellement
impossible.
  Nous avons donc essayé de trouver le meilleur compromis et celui
qui laisse le plus de souplesse à des auteurs qui voudraient,
éventuellement, utiliser ce type de mécanisme.
  Plus généralement :
  Cette problématique de l'utilisation de propriétés en surcharge ou
en complément de dispositifs natifs est particulièrement complexe à
implémenter avec des effets de bords nombreux en termes de complexité
du référentiel, de compréhension par les auteurs et de gestion de la
conformité.
  Dans le cas présent, la conformité est assurée par la présence de
l'alternative obligatoire en 1.3.4, 1.3.6 et les tests 1.3.5 et 1.3.7
contrôle un effet de bord possible de l'utilisation d'ARIA.
  Du point de vue de l'utilisateur le service est bien rendu :
l'alternative est présente et sa pertinence est vérifiée et nous
garantissons que l'utilisation éventuelle d'ARIA est correctement
implémentée quelque soit les contenus effectivement proposés par ces
dispositifs.
  Il est difficile de savoir si ce type d'approche est efficace,
nous le saurons avec les retours et si nécessaire cela sera adapté lors
de la prochaine mise à jour.
  Quoi qu'il en soit : l'utilisation et la présence de ces attributs
ne veux pas dire qu'ils peuvent être utilisés comme alternative, de ce
point de vue le référentiel est clair et univoque.
  JPV
  
  Le 28/07/2016 à 10:20, ROSA Giuseppe
(93) a écrit :
  
  

Bonjour Aurélien,

Je me doutais bien que tu étais Goetsu 
;-)  (clin d'œil). 

D'après ce que je comprends, aria-label et aria-labelledby ne figurent
pas comme alternative car ils ne répondent pas à tous les cas de figure
(ou d'handicap). 

Mais effectivement, je te rejoints sur tes remarques, et je pense que
les tests correspondant (1.3.5, 1.37) devraient peut-être préciser "également
une propriété aria-label..." et ajouter la vérification de la
cohérence (et donc la pertinence) avec l'alternative répondant
respectivement aux tests 1.3.4 et 1.3.6.
 
Giuseppe


 Message original 
Sujet : Re: [Liste GTA] RGAA 3 2016 balise object et embed
De : Aurélien Levy <aurelien.l...@temesis.com>
Pour : liste_gta@list.accessiweb.org
Date : 28/07/2016 09:54

  
  Bonjour,
  
je pense que cela fait parti des bugs que j'ai remonté :
  https://github.com/DISIC/rgaa_referentiel_3-2016/issues/5
  
en gros pas très logique de demander de tester title identique à
aria-label et aria-labelledby car ni title ni aria-label ni
aria-describedby ne sont autorisés pour donner une alternative sur ces
éléments. 
  
Sinon cela revient à dire que ces 3 techniques restituent bien qqchose
et donc que ce qqchose devrait être pertinent hors le test ne vérifie
pas la pertinence mais juste que les 3 sont identiques.
  
Aurélien
  
  
  

  

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

[ROSA Giuseppe (93)]

Bonjour Aurélien,

Je me doutais bien que tu étais Goetsu 
;-)  (clin d'œil). 

D'après ce que je comprends, aria-label et aria-labelledby ne figurent
pas comme alternative car ils ne répondent pas à tous les cas de figure
(ou d'handicap). 

Mais effectivement, je te rejoints sur tes remarques, et je pense que
les tests correspondant (1.3.5, 1.37) devraient peut-être préciser "également
une propriété aria-label..." et ajouter la vérification de la
cohérence (et donc la pertinence) avec l'alternative répondant
respectivement aux tests 1.3.4 et 1.3.6.


Giuseppe


 Message original 
Sujet : Re: [Liste GTA] RGAA 3 2016 balise object et embed
De : Aurélien Levy <aurelien.l...@temesis.com>
Pour : liste_gta@list.accessiweb.org
Date : 28/07/2016 09:54

  
  Bonjour,
  
je pense que cela fait parti des bugs que j'ai remonté :
  https://github.com/DISIC/rgaa_referentiel_3-2016/issues/5
  
en gros pas très logique de demander de tester title identique à
aria-label et aria-labelledby car ni title ni aria-label ni
aria-describedby ne sont autorisés pour donner une alternative sur ces
éléments. 
  
Sinon cela revient à dire que ces 3 techniques restituent bien qqchose
et donc que ce qqchose devrait être pertinent hors le test ne vérifie
pas la pertinence mais juste que les 3 sont identiques.
  
Aurélien
  
  
  

Bonjour Giuseppe,

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


Bien cordialement,





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



clamo...@jouve.fr


02 43 08 39 97 


1, rue du docteur Sauvé, 53101 Mayenne CEDEX
www.jouve.com 

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


  
Bonjour la liste,
  
Je prends un peu de temps pour lire la version 2016 du RGAA. 
  
Je bute actuellement sur la compréhension des tests 1.3.4/1.3.5 et
1.3.6/1.3.7. concernant les images porteuses d'information, les deux
premiers via une balise object et les deux suivants via une balise
embed.
  
J'ai l'impression en lisant ces tests, que les propriétés aria-label et
aria-labeledby ne sont pas des alternatives aux images object ou embed,
mais qu'ils peuvent uniquement être utilisés en "surcharge" à une
alternative préconisée respectivement dans les tests 1.3.4 et 1.3.6.
  
Mon analyse est-elle selon vous correcte ?
  
Merci par avance et bonne soirée.
  
  
Cordialement,
  

  


  
  
DGFiP
Giuseppe ROSA
Inspecteur Analyste
Atelier SODA - bureau SI-1A
Site SODA : http://si1a.intranet.dgfip/soda

tel :
01.573.36.997
pièce : 2388
   

  

  
  
  

  


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

  

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





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

  
  
  
  
  -- 
Aurélien Levy

Temesis
  

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




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

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

[ROSA Giuseppe (93)]

Merci Cyril pour cette réponse.

Elle confirme mon 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] RGAA 3 2016 balise object et embed
De : Cyril Lamotte <clamo...@jouve.fr>
Pour : liste_gta@list.accessiweb.org
Date : 28/07/2016 09:00

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

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

  
  clamo...@jouve.fr
  
  
02 43 08 39 97 
  
  
  1, rue du docteur Sauvé, 53101 Mayenne CEDEX
  www.jouve.com 
  

  




  

  
  
  
   

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

Bonjour la liste,

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

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

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

Mon analyse est-elle selon vous correcte ?

Merci par avance et bonne soirée.


Cordialement,

  

  
  


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

  



  

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

  







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

  
  
  

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




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

[Liste GTA] RGAA 3 2016 balise object et embed

[ROSA Giuseppe (93)]

Bonjour la liste,

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

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

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

Mon analyse est-elle selon vous correcte ?

Merci par avance et bonne soirée.


Cordialement,

  

  
  


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

  



  

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

  







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

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

[ROSA Giuseppe (93)]

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 
Pour : 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.
  
  
  
  
  
  
  
  
  

  
 
  
  



  

  
  Olivier Nourry
  about.me/oliviernourry
  


  
  
  

  

  

  
  
 
  

  
  
  
  
  
  
  
  
  Le 11 mai 2016 à 10:20, Webmaster 
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.
 
 

  

  
  
  
  
  Marc-Antoine
Bonnet
  Webmaster
Internet/Intranet
Expert accessibilité Web (EAE AccessiWeb)
  Email :
  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
  


  
   
  
  
  
  

  

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

Re: [Liste GTA] SVG et alternative

[ROSA Giuseppe (93)]

Merci Aurélien, cela conforte mon impression.


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] SVG et alternative
De : Aurélien Levy 
Pour : liste_gta@list.accessiweb.org
Date : 04/02/2016 10:59

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

Bonjour le groupe,

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

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

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

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

Par avance merci.
 
Cordialement,

  

  
  


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

  



  

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

  






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

  
  
  
  -- 
Aurélien Levy

Temesis
  

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





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

[Liste GTA] SVG et alternative

[ROSA Giuseppe (93)]

Bonjour le groupe,

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

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

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

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

Par avance merci.
 
Cordialement,

  

  
  


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

  



  

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

  






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

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

[ROSA Giuseppe (93)]

  
  Olivier Nourry
  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>
Pour : 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
  
  



  

  
  Olivier Nourry
  about.me/oliviernourry
  


  
  
  

  

  

  
  
 
  

  
  
  
  
  
  
  
  
  Le 2 novemb

[Liste GTA] Alternative aux Captchas

[ROSA Giuseppe (93)]

Bonjour à tous,

j'essaie de faire perdre la malheureuse habitude d'utiliser des
captchas utilisés pour "déjouer" les robots.

Auriez-vous des suggestions permettant de les remplacer sans utiliser
l'artillerie lourde (mailing list, SMS...).


Bien cordialement,
Giuseppe Rosa




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

[Liste GTA] table role="grid"

[ROSA Giuseppe (93)]

Bonjour la liste,

J'ai un "client" qui par l'utilisation de framework Java, génère des
tableaux avec role="grid" ().
Ce sont des tableaux susceptibles de subir des traitements, des
cellules risquent dans le futur d'être modifiables, des éléments pour
trier le tableau sont ou seront ajoutés... Par conséquent l'utilisation
d'un role="grid" me semble justifiable ou du moins je n'ai pas pour le
moment d'argument pour leur demander de faire autrement. 

En testant avec NVDA sur Firefox, les en-têtes sont restitués notamment
par l'utilisation de role="columnheader" pour les en-tête et role="gridcell" pour les cellules de
données.

Remarque : J'ai trouvé un vieux ticket sur l'utilisation
des
role="grid" à la place d'une table mais qui ne répondait pas
directement à ma question.

Ma question porte essentiellement sur le fait de la surcharge avec un role="grid"
et des conséquences...
Doit-on encore l'envisager comme un tableau de données : d'où
normalement utilisation de la balise caption et surtout de  bien que ce rôle soit déjà joué avec
role="columnheader", ou au contraire on ne le considère plus comme un
tableau de données (donc plus de  mais comment ajouter un
role="presentation" puisqu'il a déjà un role="grid" et à ma
connaissance on n'ajoute pas 2 role à un même élément).

A priori, si j'en crois le draft du W3C
http://www.w3.org/TR/aria-in-html/#use-of-role-presentation
je devrais demander de traiter cela comme un tableau de présentation
( et l'encapsuler dans une )

Si vous avez un avis ou des avis tiers je suis preneur, merci d'avance.


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

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

[ROSA Giuseppe (93)]

Merci pour ces précisions. Je pense que l'argument RWD peut notamment
jouer en la faveur de la solution que tu proposes. Il faut juste que je
trouve le temps de m'y plonger. Si je ne propose pas un proto
fonctionnel je n'arriverai pas à faire adopter cette solution.

Encore merci, ainsi qu'à Romain du temps consacré pour vos conseils.


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>
Pour : liste_gta@list.accessiweb.org
<liste_gta@list.accessiweb.org>
Date : 02/11/2015 14:03

  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.
  
  
  
  
  
  
  
  
  
  
  
  

  
 
  
  



  

  
  Olivier Nourry
  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>
Pour : 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 

[Liste GTA] Champ de formulaires & cellules de tableaux

[ROSA Giuseppe (93)]

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

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

[ROSA Giuseppe (93)]

Merci à tous les deux, je pense que chaque solution à ces avantages et
ces inconvénients.

Merci aussi Olivier pour le lien sur les display table

Merci aussi Romain pour le renseignement sur la différence de
restitutions des vocalisateurs sur les fieldset/legend


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 : Romain Gervois <cont...@romaingervois.fr>
Pour : GTA <liste_gta@list.accessiweb.org>
Date : 02/11/2015 14:32

  
  
  
  Considérer des tableaux de mise en forme comme du détournement
revient à les interdire (même dans les différents textes, personne
n'ose le faire). On peut bien sur revenir aux pratiques anciennes où
les table/tr/td sont devenus des div/span... Perso, je préfère un
tableau de mise en forme assumé et bien implémenté que de passer par
des solutions bancales et chiantes full CSS.
  
  
Olivier écrit :
  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!
  
  
Il faudrait faire des tests plus large ; en tout cas, sous VO OS X
(avec role presentation) le tableau est totalement omis. Et en fait, je
vois même pas le problème selon le mode de navigation choisit et la
façon dont l'utilisateur va utilisé son lecteur ça va dépendre...
  
  
Olivier écrit :
  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.
  
  
  Sur l'implémentation, ça ne changera effectivement rien. Par
contre dire que c'est impossible avec un tableau, c'est une erreur. On
peut jouer avec la propriété display pour réadapter comme on veut.
D'ailleurs, fieldset et legend sont détestés par nos amis intégrateurs
lors de l'application de styles (donc tu vas devoir retomber sur des
div/span pour faire ce que tu veux faire).
  
  
  Enfin pour finir, le support de fieldset et legend est très
inégal. Par exemple, VO ne vocalise pas la légende du regroupement, les
versions (certaines ? toutes ?) des JAWS restituent à chaque champ la
légende... Donc entre l'implé de rêve (full CSS, sémantique et cie) et
la pratique, par moment, il faut savoir faire quelques écarts.
  
  
  Romain
  
  
  
  
  
  
  
  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.












  

   


  
  
  

  

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

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

[ROSA Giuseppe (93)]

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



  

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

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

[ROSA Giuseppe (93)]

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] (sans objet)

[ROSA Giuseppe (93)]

Bonjour,

Je voulais savoir si quelqu'un avait entendu parler d'une plainte d'un
fonctionnaire contre l'administration suite au déploiement d'une
nouvelle application qui ne serait pas accessible et ne permettrait
plus à certaines personnes d'occuper leur emploi du fait d'un handicap.

Lors du forum européen de l'an dernier, une association avait indiqué
qu'elle voulait faire appel au représentant des droits, on m'a reparlé
de ce cas il y a peu de temps mais je n'ai pas réussit à avoir
confirmation ou infirmation.

Si vous avez des informations vérifiables sur le sujet (article ou
autre) je suis intéressé.

Par avance merci


Cordialement,

  

  
  


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

  



  

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

  






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

[Liste GTA] test 5.1.1 HTML4 attribut summary et caption

[ROSA Giuseppe (93)]

Bonjour la liste,

Si un site est encore en html4, l'attribut summary n'est pas obsolète
pour cette version.

Comment devrait-on traiter le " Test 5.1.1 : Pour chaque tableau
de données complexe (balise table)
un résumé est-il disponible dans la balise caption ? "

dans le cas où c'est l'attribut summary qui porte le résumé et non la
balise caption ?


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

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

[ROSA Giuseppe (93)]

Bonjour la liste,

Je profite de la question sur le critère 6.5 pour demander une
précision sur ce critère :

Critère 6.5 [A] Dans chaque page Web,
chaque lien,
à l'exception des ancres,
a-t-il un intitulé
? 


   Test 6.5.1 Dans chaque page Web, chaque lien
(balise a avec un attribut href), à
l'exception des ancres,
a-t-il un intitulé
entre a et /a ?


La définition de l'ancre étant (cf. glossaire) : 
une ancre (appelée aussi signet) est constituée d'une
balise a avec l'attribut id et dépourvue de href,
a id="contenu"/a
  

Par conséquent, je ne comprend pas la précision : "à l'exception des
ancres" puisqu'un lien comporte forcément un attribut href alors que
l'ancre en est dépourvue.

Y-a-t-il une subtilité que je n'aurai pas compris ?


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

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

[ROSA Giuseppe (93)]

Merci pour cette réponse


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] RGAA v3 Critère 6.5 et ancres
De : Jean-Pierre Villain jpvill...@access42.net
Pour : liste_gta@list.accessiweb.org
Date : 04/06/2015 10:49

  
Bonjour,
  
  Aucune, c'est une redondance qui a été maintenue pour des raisons
de clarté, beaucoup ignorant la notion d'ancre et quelques outils
automatiques faisant également la confusion.
  
JPV
  
  Le 04/06/2015 10:34, ROSA Giuseppe (93)
a écrit :
  
  

Bonjour la liste,

Je profite de la question sur le critère 6.5 pour demander une
précision sur ce critère :

Critère 6.5 [A] Dans chaque page
Web, chaque lien,
à l'exception des ancres,
a-t-il un intitulé
? 


   Test 6.5.1 Dans chaque page Web, chaque lien
(balise a avec un attribut href), à
l'exception des ancres,
a-t-il un intitulé
entre a et /a ?


La définition de l'ancre étant (cf. glossaire) : 
une ancre (appelée aussi signet) est constituée d'une
balise a avec l'attribut id et dépourvue de href,
a id="contenu"/a
  

Par conséquent, je ne comprend pas la précision : "à l'exception des
ancres" puisqu'un lien comporte forcément un attribut href alors que
l'ancre en est dépourvue.

Y-a-t-il une subtilité que je n'aurai pas compris ?


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

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

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





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

Re: [Liste GTA] balise object type image

[ROSA Giuseppe (93)]

Merci Jean-Pierre pour ces explications (et désolé pour la réponse
tardive, je rentre de congé). Il s'agissait effectivement de la balise
object que je ne maîtrisait pas.


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] balise object type image
De : Jean-Pierre Villain jpvill...@access42.net
Pour : liste_gta@list.accessiweb.org
Date : 23/04/2015 01:42

  
Bonjour Giuseppe,
  
Tu interprète mal le comportement de l'alternative à object.
  
Le texte alternatif dans la balise object ne sera restitué que si le
navigateur ne supporte pas object ou que l'utilisateur en désactive
manuellement le support.
  
Le test vise simplement à s'assurer, dans ce cas, que les image-object
de décoration ne restituent rien (pas de texte affiché) si le support
d'object est inactif.
  
Cela n'a donc aucun rapport avec le fait que tu obtiennes une
restitution avec un title lorsque object est activé.
  
Me dire si ce n'est pas suffisamment clair.
  
JPV
  
  Le 22/04/2015 15:35, ROSA Giuseppe (93)
a écrit :
  
   Bonjour la liste,

Je m'interroge sur le test 
Test 1.2.3 : Pour chaque image objet sans légende
(balise object avec l'attribut type="image/...")
non porteuse d'information, l'alternative textuelle entre object
et /object est-elle vide 


Et j'ai du mal à comprendre l'impact. Il est vrai que je ne teste
qu'avec NVDA pour le moment, sous Firefox en général et que
probablement le comportement est différent sur d'autres navigateur/AT

Ce que je ne comprend pas c'est que

1/  lorsque j'inscris du code tel que :
PHere's a closeup of the Grand Canyon:
OBJECT data="" type="image/png"
This is a EMcloseup/EM of the Grand Canyon.
/OBJECT

NVDA ne me restitue rien (idem si je mets une balise img avec un
alt="This is a closeup of the Grand Canyon" par exemple). Par
conséquent, je ne vois pas l'intérêt du test.

2/ Par contre, si dans la balise object je mets un attribut title
(OBJECT title="This is a closeup of the Grand
Canyon".../OBJECT par exemple...), cette fois le title est
restitué par NVDA (graphique this is ...).

Même si je ne maîtrise pas trop les OBJECT type="image/..." le point 2
m'inquiète car je ne pourrais pas invalider cet élément.

Tous mes remerciements pour des éventuels éclairages.

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

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

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





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

Re: [Liste GTA] Différences RGAA 2 / RGAA 3

[ROSA Giuseppe (93)]

Super et Merci Aurlien.

Je comptais galement attaquer ce sujet d'ici quelques semaines. Je te
remercie donc du temps que tu me fais gagner.


Bien cordialement,

  

  
  


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

  



  

  
  
Adoptez
l'co-attitude. 
  N'imprimez ce mail
que si c'est vraiment ncessaire
  

  




 Message original 
Sujet: [Liste GTA] Diffrences RGAA 2 / RGAA 3
De: Aurlien Levy aurelien.l...@temesis.com
Pour: Liste GTA liste_gta@list.accessiweb.org
Date: 28/04/2015 18:18
Bonjour
 tous,
  
  
Pour information nous avons publi aujourd'hui un billet voquant les
diffrences entre RGAA 2 et RGAA 3.
  
Un fichier dtaill sous licence CC-BY-SA est galement mis 
disposition.
  
J'espre que cela pourra vous tre utile.
  
  
http://blog.temesis.com/post/2015/04/28/Les-differences-entre-RGAA-2-et-RGAA-3
  
  
A bientt
  
  





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

[Liste GTA] balise object type image

[ROSA Giuseppe (93)]

Bonjour la liste,

Je m'interroge sur le test 
Test 1.2.3 : Pour chaque image objet sans lgende
(balise object avec l'attribut type="image/...")
non porteuse d'information, l'alternative textuelle entre object
et /object est-elle vide 


Et j'ai du mal  comprendre l'impact. Il est vrai que je ne teste
qu'avec NVDA pour le moment, sous Firefox en gnral et que
probablement le comportement est diffrent sur d'autres navigateur/AT

Ce que je ne comprend pas c'est que

1/ lorsque j'inscris du code tel que :
PHere's a closeup of the Grand Canyon:
OBJECT data="" type="image/png"
This is a EMcloseup/EM of the Grand Canyon.
/OBJECT

NVDA ne me restitue rien (idem si je mets une balise img avec un
alt="This is a closeup of the Grand Canyon" par exemple). Par
consquent, je ne vois pas l'intrt du test.

2/ Par contre, si dans la balise object je mets un attribut title
(OBJECT title="This is a closeup of the Grand
Canyon".../OBJECT par exemple...), cette fois le title est
restitu par NVDA (graphique this is ...).

Mme si je ne matrise pas trop les OBJECT type="image/..." le point 2
m'inquite car je ne pourrais pas invalider cet lment.

Tous mes remerciements pour des ventuels clairages.

-- 


Cordialement,

  

  
  


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

  



  

  
  
Adoptez
l'co-attitude. 
  N'imprimez ce mail
que si c'est vraiment ncessaire
  

  





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

Re: [Liste GTA] CMS

[ROSA Giuseppe (93)]

Merci, j'étudierai cela avec intérêt.


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] CMS
De : Rosenberg Nathalie nathalie_rosenb...@yahoo.fr
Pour : liste_gta@list.accessiweb.org
liste_gta@list.accessiweb.org
Date : 28/10/2014 20:49

  
  
  
  
  Bonjour
  
  
  Oui
l'étude portait sur l'accessibilité des principaux CMS open source du
marché (Typo3, Spip, EZ Publish, Dotclear, Drupal, Wordpress et
Joomla). 
  
J'ai mis les 5 mémoires sur Dropbox pour ceux qui le souhaitent
  Public
  
  
  
  

  

 

  
  

 





 


 


 


 


 

  
  


Public
Partagé
avec Dropbox



  
  


  
  

Afficher
sur www.dropbox...


Aperçu
par Yahoo

  
  


  
  

 

  

  
  
    
   
  
  
  
  
  
Le Mardi 28 octobre 2014 14h37, Victor Brito
liste-...@victor-brito.fr a écrit :
   
  
  
  
  
  
  
  
  Bonjour, Giuseppe, bonjour, la liste,
  
  Vaste question.
  
  Cela dit, avant de se pencher sur
l'accessibilité des CMS (aussi bien au niveau de l'interface
d'administration que des gabarits produits), il faut déjà trier les CMS
en fonction des besoins du portail.
  
  Pour revenir à la question, il y a deux ou
trois ans, lors d'une formation expert accessibilité dispensée par
Temesis, Nathalie Rosenberg a présenté un travail à ce sujet. Si elle
passe par ici, peut-être pourra-t-elle te donner des pistes.
  
  Victor
  
  
  
  
  
  Victor Brito Intégrateur XHTML
/ CSS – Expert Accessiweb en
évaluation 
  
   39
rue Charles Laffitte 92200 Neuilly-sur-Seine  Tél.  : +33 6 03 15 89 57 
  
SIRET  : 789 766 334 00013
  Consulter
le site Web professionnel de Victor Brito
  
  Sur
les réseaux sociaux
  
Suivre
Victor Brito sur Twitter

Suivre
Victor Brito sur Diaspora

  
  Sans
oublier
  
La
fiche de membre du Groupe de Travail Accessiweb

Halte
à la balkanisation du Web !

Un
seul Web

Profession
intégrateur (X)HTML / CSS

Tuyaux
de l'accessibilité

  
  
  
Le 28/10/2014 14:29, ROSA Giuseppe (93) a écrit :
  
  
  
  
   Bonjour la liste,

Selon vos expériences, quels seraient les CMS les plus accessibles ?

Il s'agit de créer un nouveau portail. RWD serait un plus.

Je crois que le sujet à déjà été abordé, mais les CMS évoluant...

-- 

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

[ROSA Giuseppe (93)]

Bonjour Victor et bien sur la liste,

Je souhaitais justement voir si on pouvait prendre le problme dans
l'autre sens, c'est  dire, voir si les CMS considrs comme les plus
accessibles peuvent rpondre aux autres besoins. Sinon les mmes
erreurs seront reproduites, c'est  dire prendre en considration les
autres besoins et si la solution est accessible tant mieux.

Besoins fonctionnels :

  Du point de vue accessibilit, en priorit les gabarits produits,
si l'interface contributeur est accessible, cela serait encore mieux
mais le contenu n'voluera pas normment
  RWD pour des versions tablettes et smartphones,
  la compatibilit avec les navigateurs (dont IE  partir de la
version 8)
  moteur de recherche
  restitution des statistiques

Contraintes techniques :

  s'intgrer avec les briques d'authentification et les DAC (
Discretionnary Access Control  Contrle d'accs discrtionnaire),
  intgrer un espace unique, scuris, hbergeant les contenus
publis, ainsi que les archives, et ceux en instance de publication,
compatible avec tous les formats,
  performance (temps de rponse attendus infrieurs  3 secondes)
  capacit d'absorption des pics de charge
  possibilit d'intgration avec d'autres systmes, notamment
intgration d'application java
  



Cordialement,

  

  
  


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

  



  

  
  
Adoptez
l'co-attitude. 
  N'imprimez ce mail
que si c'est vraiment ncessaire
  

  




 Message original 
Sujet: Re: [Liste GTA] CMS
De: Victor Brito liste-...@victor-brito.fr
Pour: liste_gta@list.accessiweb.org
Date: 28/10/2014 14:37

  
  
  Bonjour, Giuseppe, bonjour, la liste,
  
  Vaste question.
  
  Cela dit, avant de se pencher sur l'accessibilit des CMS (aussi
bien au niveau de l'interface d'administration que des gabarits
produits), il faut dj trier les CMS en fonction des besoins du
portail.
  
  Pour revenir  la question, il y a deux ou trois ans, lors d'une
formation expert accessibilit dispense par Temesis, Nathalie
Rosenberg a prsent un travail  ce sujet. Si elle passe par ici,
peut-tre pourra-t-elle te donner des pistes.
  
  Victor
  
  
  
  
  
  Victor Brito Intgrateur XHTML
/ CSS
 Expert Accessiweb en valuation 
39 rue Charles Laffitte 92200 Neuilly-sur-Seine
   Tl.:
  +33 6 03 15 89 57 
  SIRET: 789 766 334 00013
  Consulter
le site Web professionnel de Victor Brito
  
  Sur
les rseaux sociaux
  
Suivre
Victor Brito sur Twitter
Suivre
Victor Brito sur Diaspora
  
  Sans
oublier
  
La
fiche de membre du Groupe de Travail Accessiweb
Halte
 la balkanisation du Web!
Un
seul Web
Profession
intgrateur (X)HTML / CSS
Tuyaux
de l'accessibilit
  
  
  
Le 28/10/2014 14:29, ROSA Giuseppe (93) a crit:
  
   Bonjour la liste,

Selon vos expriences, quels seraient les CMS les plus accessibles ?

Il s'agit de crer un nouveau portail. RWD serait un plus.

Je crois que le sujet  dj t abord, mais les CMS voluant...

-- 
 
Cordialement,

  

  
  


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

  



  

  
  
   
  Adoptez l'co-attitude. 
  N'imprimez ce mail que si c'est
vraiment ncessaire
  

  





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

[ROSA Giuseppe (93)]

Merci à Aude et Audrey.


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] CMS
De : Aude JOLY aj...@e-magineurs.com
Pour : liste_gta@list.accessiweb.org
Date : 28/10/2014 17:07

  
  

  
  
  Bonjour
la liste,
   
  Nous
travaillons avec TYPO3 qui permet de respecter un niveau AA s’il est
correctement utilisé et paramétré ;).
  En fait
je redirais à peu près la même chose qu’Audrey, cela s’applique à TYPO3.
   
  Aude 
   
  Aude
JOLY
  Chef
de projet technique
  Experte
TYPO3 - TYPO3 Certified Integrator
  Experte
Accessiweb en évaluation
   
   
  De :
liste_gta [mailto:liste_gta-boun...@list.accessiweb.org] De la part
de Audrey Vittecoq-Laporte
  Envoyé : mardi 28 octobre 2014 15:42
  À : liste_gta@list.accessiweb.org
  Objet : Re: [Liste GTA] CMS
   
  
  Bonjour Giuseppe,
  
   
  
  
  Nous utilisons WordPress et Drupal. Chacun ont
des plugins/modules plus ou moins accessibles et fort d'une communauté
importante et motivée. 
  
  
   
  
  
  Le travail consiste donc à bien choisir ces
plugins qui vont constituer le CMS. Ensuite chaque module peut être
hooké pour corriger les points non accessibles.
  
  
   
  
  
  Le travail le plus important demeure dans la
formation faite au client pour l'intégration des contenus et respecter
les bonnes pratiques.
  
  
   
  
  
  Bien cordialement,
  
  
  Audrey Vittecoq-Laporte
  
  
  
   
  
  Le 28 octobre 2014 15:28, ROSA Giuseppe (93) giuseppe.r...@dgfip.finances.gouv.fr
a écrit :
  
  Bonjour Ariane et merci pour ces retours.
  
"Pas d'infos à donner sur d'autres CMS, je suis mariée à Joomla!" 
= Tous mes voeux de bonheurs ! ;-) 
  
  
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] CMS
De : Ariane Andurand ariane.c...@gmail.com
Pour : liste_gta@list.accessiweb.org
Date : 28/10/2014 15:15
  
  
  
  
  
  
  
  
  
  Bonjour, Giuseppe,
bonjour, la liste,
  
  A utiliser Joomla!
tous les jours, je pense qu'il peut devenir accessible en le tordant
dans tous les sens au niveau des templates. Du travail en perspective
pour tes intégrateurs et développeurs.
  
  
  Mes connaissances sur joomla! :
  
  - Tu as un très bon travail d'un italien sur
GitHub https://github.com/elpaso/joomla-fap-25
, pour la version 2.5 de Joomla! qui est déjà obsolète selon la note
d'information du CERTA de l'Agence nationale de la sécurité des
systèmes d'information. La version Joomla! 3.X va très prochainement
passer à Bootstrap 3 natif ce qui facilitera la création à mon sens
d'un template RWD accessible sur le base du travail d'Elpaso sur Github.
  
  - Un autre template
dit accessible est en ligne, d'un italien : http://www.accessibletemplate.com/zhong/free-download
. Pour l'avoir testé en 2.5 et Joomla!3 il est très élégant et
intéressant. Par contre il n'est pas RWD mais fluide.
  
  
  Pas d'infos à
donner sur d'autres CMS, je suis mariée à Joomla!
  
  
  Ariane
  
   
  
  
  
   
  
  
  
  
  
   
  
  Le 28 octobre 2014 14:37, Victor Brito liste-...@victor-brito.fr a écrit :
  
  
  Bonjour, Giuseppe, bonjour, la liste,
  Vaste question.
  Cela dit, avant de se pencher sur l'accessibilité des CMS (aussi
bien au niveau de l'interface d'administration que des gabarits
produits), il faut déjà trier les CMS en fonction des besoins du
portail.
  Pour revenir à la question, il y a deux ou trois ans, lors d'une
formation expert accessibilité dispensée par Temesis, Nathalie
Rosenberg a présenté un travail à ce sujet. Si elle passe par ici,
peut-être pourra-t-elle te donner des pistes.
  Victor
  
  
  
  Victor
Brito Intégrateur XHTML / CSS – Expert Accessiweb en évaluation 
  39 rue Charles Laffitte 92200
Neuilly-sur-Seine Tél. : +33 6 03 15
89 57 
  SIRET : 789 766 334 00013
  Consulter le site
Web professionnel de Victor Brito
  
  Sur
les réseaux sociaux
  ·
  Suivre Victor
Brito sur Twitter
  ·
  Suivre
Victor Brito sur Diaspora
  Sans
oublier
  ·
  La fiche de membre du Groupe de Travail Accessiweb
  ·
  Halte
à la balkanisation du Web !
  ·
  Un seul Web
  ·
  Profession
intégrateur (X)

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

[ROSA Giuseppe (93)]

Merci pour vos rponses.

C'est effectivement du point de vue ergonomique que j'ai contest la
solution propose, mais n'tant pas ergonome j'esprais pouvoir trouver
un levier dans l'accessibilit domaine sur lequel j'ai une lgitimit.


Cordialement,

  

  
  


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

  



  

  
  
Adoptez
l'co-attitude. 
  N'imprimez ce mail
que si c'est vraiment ncessaire
  

  




 Message original 
Sujet: Re: [Liste GTA] Etiquette de champ de saisie de formulaire
De: san...@free.fr
Pour: liste gta liste_gta@list.accessiweb.org
Date: 21/07/2014 22:28

  bonsoir,
juste pour ajouter un gravier  l'difice, ne mettre que des title aux champs de formulaire et s'appuyer sur un place holder, voil pourquoi c'est mal :
le support (interoprabilit) du title dans les input est bon, mais c'est ergnomie, en fait, l'utilisabilit d'une telle solution sur de multiples champs (notamment dan un contexte d'appli mtier), qui est catastrophique, on doit toujours se demander :"que doit je remplir dans ce champ ?". Mme avec un placeholder, la question reste entire ds qu'on rentre dans le champ et que le placeholder disparait !
Ici, ce n'est pas que de l'accessibilit, c'est du bon sens ergonomique : trs souvent, si personne n'a encore fait a, ce n'est pas parce qu'on a eu une ide de gnie, mais c'est que c'est une trs mauvaise ide !
donc, faites de l'accessibilit, oui, bien sr, c'est essentiel (en fait juste le respect de la loi dans votre cas ;)!)mais couplez la  de l'ergo (ct utilisabilit) pour viter de telles aberrations,
bonsoir

- Mail original -
De: "ROSA Giuseppe (93)" giuseppe.r...@dgfip.finances.gouv.fr
: "liste gta" liste_gta@list.accessiweb.org
Envoy: Lundi 21 Juillet 2014 18:56:34
Objet: Re: [Liste GTA] Etiquette de champ de saisie de formulaire


Merci Aurlien, 

Tu confirmes donc ce que je craignais. J'ai en fait un peu de mal  pousser l'accessibilit lorsqu'il ne s'agit pas de respecter des contraintes clairement identifies. 

Dans le cas de figure cit, le souhait de la moa, sur des applications mtiers, tait de remplacer des labels de champs de saisie en les remplaant par des placeholders, mais de conserver la rfrence. 
Pour donner une analogie, par exemple lorsqu'on dclare ses impts, chaque champ  un rfrence, AC05 , ainsi qu'un intitul, Dclarant 1 - Cotisation syndicale (la rfrence et l'intitul sont ici invents). 
D'o pour avoir de beaux formulaires, bien aligns, l'ide de ne conserver que la rfrence sur 4 caractres. 


Cordialement, 
	

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



	
	Adoptez l'co-attitude. 
N'imprimez ce mail que si c'est vraiment ncessaire 


 Message original  
Sujet : Re: [Liste GTA] Etiquette de champ de saisie de formulaire 
De : Aurlien Levy aurelien.l...@temesis.com 
Pour : liste_gta@list.accessiweb.org 
Date : 21/07/2014 18:31 



Bonjour Giuseppe, 

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

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

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

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

Tout dpend donc de l'objectif (conformit / accessibilit) et de la phase  laquelle tu interviens (conception, cration, intgration, recette, correction) 

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

Aurlien 


Bonjour  tous, 

Dans l'administration nous avons normment de formulaire. Je tente donc de pousser  l'adoption de bonnes pratiques notamment sur cette thmatique. 
Toutefois j'ai un soucis concernant : 
Critre 11.1 [A] Chaque champ de formulaire a-t-il une tiquette ? 
Test 11.1.1 : Chaque champ de formulaire vrifie-t-il une de ces conditions ? 

* Le champ de formulaire possde un at

[Liste GTA] Etiquette de champ de saisie de formulaire

[ROSA Giuseppe (93)]

Bonjour  tous,

Dans l'administration nous avons normment de formulaire. Je tente
donc de pousser  l'adoption de bonnes pratiques notamment sur cette
thmatique.
Toutefois j'ai un soucis concernant :
Critre 11.1 [A]
Chaque champ
de formulaire a-t-il une tiquette
?
Test 11.1.1 : Chaque champ
de formulaire vrifie-t-il une de ces conditions ?

   Le champ de formulaire possde un attribut title


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

...
input id="madame" name="genre" type="radio" title="Madame"
/input id="mademoiselle" name="genre" type="radio"
title="Mademoiselle" /input id="monsieur" name="genre"
type="radio" title="Monsieur"/br /
input id="nom" type="texte" title="Saisir le Nom"
value=""/inputbr /
input id="prenom" type="texte" title="Saisir le Prnom"
value=""/inputbr /

...
Si c'est le cas, j'ai des difficult  comprendre comment des
utilisateurs exclusifs du clavier (mais voyant) auront accs 
l'information (si des lments de type placeholder ou autres ne sont
pas utiliss).

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

Merci pour vos lumires.

-- 


Cordialement,

  

  
  


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

  



  

  
  
Adoptez
l'co-attitude. 
  N'imprimez ce mail
que si c'est vraiment ncessaire
  

  






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

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

[ROSA Giuseppe (93)]

Merci Aurlien,

Tu confirmes donc ce que je craignais. J'ai en fait un peu de mal 
pousser l'accessibilit lorsqu'il ne s'agit pas de respecter des
contraintes clairement identifies.

Dans le cas de figure cit, le souhait de la moa, sur des applications
mtiers, tait de remplacer des labels de champs de saisie en les
remplaant par des placeholders, mais de conserver la rfrence.
Pour donner une analogie, par exemple lorsqu'on dclare ses impts,
chaque champ  un rfrence, AC05, ainsi qu'un intitul, Dclarant
1 - Cotisation syndicale (la rfrence et l'intitul sont ici
invents). 
D'o pour avoir de beaux formulaires, bien aligns, l'ide de ne
conserver que la rfrence sur 4 caractres.


Cordialement,

  

  
  


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

  



  

  
  
Adoptez
l'co-attitude. 
  N'imprimez ce mail
que si c'est vraiment ncessaire
  

  




 Message original 
Sujet: Re: [Liste GTA] Etiquette de champ de saisie de formulaire
De: Aurlien Levy aurelien.l...@temesis.com
Pour: liste_gta@list.accessiweb.org
Date: 21/07/2014 18:31

  
  Bonjour Giuseppe,
  
c'est effectivement formellement possible, a serait donc conforme
(mais clairement pas la solution la plus accessible).
  
Il y a deux techniques wcag qui permettent de dire que les titles sont
une solution utilisables. La technique h33 pour les liens et la
technique h65 pour les formulaires http://www.w3.org/TR/WCAG20-TECHS/H65.html
  
Dans la technique h33 on peut notamment lire "Because of the extensive
user agent limitations in supporting access to the title attribute,
authors should use caution in applying this technique"
et une bonne partie des problmes signals dans notes agents
utilisateur du h33 s'appliquent galement http://www.w3.org/WAI/WCAG20/Techniques/ua-notes/html#H33
au cas du h65
  
Par ailleurs, la technique h65 dit bien "to label form controls when
the visual design cannot accommodate the label", il s'agit donc bien
d'un choix  faire cot design rattrapable  coup de title niveau
technique et non de la solution  privilgier.
  
Tout dpend donc de l'objectif (conformit / accessibilit) et de la
phase  laquelle tu interviens (conception, cration, intgration,
recette, correction)
  
Si tu interviens en conception / cration d'un nouveau service il faut
demander  ton designer de justifier pourquoi il ne peut pas mettre un
label (autrement que par "c'est pas beau!" ou "c'est pas la mode" si
possible)
  
Aurlien
  
   Bonjour  tous,

Dans l'administration nous avons normment de formulaire. Je tente
donc de pousser  l'adoption de bonnes pratiques notamment sur cette
thmatique.
Toutefois j'ai un soucis concernant :
Critre 11.1 [A] Chaque champ
de formulaire a-t-il une tiquette
?
Test 11.1.1 : Chaque champ
de formulaire vrifie-t-il une de ces conditions ?

   Le champ de formulaire possde un attribut title


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

...
input id="madame" name="genre" type="radio" title="Madame"
/input id="mademoiselle" name="genre" type="radio"
title="Mademoiselle" /input id="monsieur" name="genre"
type="radio" title="Monsieur"/br /
input id="nom" type="texte" title="Saisir le Nom"
value=""/inputbr /
input id="prenom" type="texte" title="Saisir le Prnom"
value=""/inputbr /

...
Si c'est le cas, j'ai des difficult  comprendre comment des
utilisateurs exclusifs du clavier (mais voyant) auront accs 
l'information (si des lments de type placeholder ou autres ne sont
pas utiliss).

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

Merci pour vos lumires.

-- 
 
Cordialement,

  

  
  


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

  



  

  
  
   
  Adoptez l'co-attitude. 
  N'imprimez ce mail que si c'est
vraiment ncessaire
  

  





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

  
  
  
  -- 
Aurlien Levy

Temesis