[spip-dev] SPIP et RGAA

Dev
1

Bonsoir,

En intégrant des videos via le plugin video accessible pour un site qui doit être 100% valide RGAA (AA),
je me rends compte que ce dernier intègre la balise HTML5

Plus globalement, SPIP3 coté backoffice n’est pas encore totalement RGAA compatible.
Se pose de nombreux problèmes concernant l’interface PRIVE elle même : comme la gestion du zoom sur les pages en mode textuel (éléments CSS fixés en absolu), manque d’information sur le comportement d’actions, des erreurs sur la navigation au clavier, etc…
Et des réflexions seraient à mener sur les ajustements fonctionnels à produire pour permettre une parfaite intégration de sites sous contrainte RGAA (par exemple, pêle-mêle : gestion des fichiers multimédias accessibles : intégration du plugin video accessible en natif ? / gestion des alt sur les images objets / gestion des longdesc / modèles pré-usinés pour permettre la génération d’éléments accessibles / briques JS à minima compatibles WAI-ARIA, … )

Bref, vaste sujet. Comment appréhender ce chantier ?

2

Bonsoir,

En intégrant des videos via le plugin video accessible pour un site qui doit être 100% valide RGAA (AA),
je me rends compte que ce dernier intègre la balise HTML5

Le RGAA impose-t-il le choix de XHTML 1 ?
Sinon, pourquoi ne pas retenir un Doctype HTML 5 ?

Il serait donc assez judicieux d’intégrer nativement dans les modèles du plugin une version XHTML de l’ajout du player via la balise object. En RGAA (AA) la validation du code est un point capital, donc pour tous les sites construits en XHTML le plugin ne rempli pas vraiment sa mission d’accessibilité.

L’utilisation d’une balise vidéo associée à une vidéo au format H264 est ce qui permet la lecture de la vidéo dans le plus de configuration possibles. Réduire la lisibilité de cette vidéo (et donc son accessibilité) pour valider un Doctype et satisfaire au RGAA me semble aller à contre courant du but visé de l’accessibilité.

Plus globalement, SPIP3 coté backoffice n’est pas encore totalement RGAA compatible.
Se pose de nombreux problèmes concernant l’interface PRIVE elle même : comme la gestion du zoom sur les pages en mode textuel (éléments CSS fixés en absolu), manque d’information sur le comportement d’actions, des erreurs sur la navigation au clavier, etc…

Il ne faut pas hésiter à faire de retours précis sur les points bloquants sur cette liste ou via les tickets, que l’on puisse les corriger.

Et des réflexions seraient à mener sur les ajustements fonctionnels à produire pour permettre une parfaite intégration de sites sous contrainte RGAA (par exemple, pêle-mêle : gestion des fichiers multimédias accessibles : intégration du plugin video accessible en natif ? / gestion des alt sur les images objets / gestion des longdesc / modèles pré-usinés pour permettre la génération d’éléments accessibles /

Ce travail d’intégration de composants et plugins tous disponibles peut se faire indépendamment du core de Spip. Notre soucis est avant tout de lever les points de blocage, et de permettre l’existence des plugins qui répondent à ces besoins comme à d’autres.

La pluralité des utilisations et utilisateurs de Spip rendent difficile la prise en compte de tous les besoins dans la distribution par défaut. Mais l’existence de distributions alternatives ciblant besoin ou un profil précis d’utilisation est vivement encouragée.

briques JS à minima compatibles WAI-ARIA, … )

Tu as vu que toutes les prises en charge Ajax natives de Spip (pagination et inclusions Ajax, formulaires Ajax) utilisent déjà ARIA ?

3

La RGAA s’appuie tout de même sur la WCAG2.0, elle n’est pas subitement sortie d’un chapeau de député narquois. Par contre, le décret applicatif est ferme et sans trop de discussion possible. Je suis tout à fait d’accord, le cadre RGAA niveau AA et AAA entraine des contraintes très strictes, qui ne peuvent être imposées à tous les usages. La question est justement de savoir comment rendre SPIP 100% compatible WCAG2.0/RGAA sans trop cloisonner la distrib native. En effet, malheureusement data-player ne passera pas le cap de la validation xhtml, ni en transitional et encore moins en strict. Il serait nécessaire de créer une alternative conditionnée par la DTD (ou un modèle bis video_acc) avec la balise OBJECT. cette phrase ne doit pas du tout être perçue comme un début de reproche. Je voulais seulement un peu dédramatiser ce sujet qui peut être perçu comme pesant au regard d’autres développements plus ludiques. Je n’en doute pas, justement j’interroge la liste sur le comment faire et le comment avancer sur ce point d’accessibilité dans un cadre légale.

4

Salut

juste un point de vue sur l’accessibilité : rendre un site 100% accessible est impossible, est un voeu pieu.

Ce doit être une démarche, un état d’esprit, une façon de travailler, qui va de la charte graphique à l’élaboration des contenus, la partie technique est un maillon de la chaîne, mais la complexité (et parfois les incohérences et/ou le manque de clarté) des textes rend les choses difficiles.

Comme un site n’est jamais fini, un site n’est jamais 100% accessible…

Laurent

5

Bonjour,

pour réagir au message initiale, depuis que l'interface d'admin est en squelette j'envisage sérieusement de me pencher sur la question de son accessibilité. Mon principale problème est de savoir comment s'organiser pour bosser sur ce chantier, plugin ? dans mon coin ? sur la zone ?.

Concernant le player vidéo accessible. De mémoire le html5 ne doit s'afficher que si il n'y a pas flash car de toute façon le player html5 n'est pas accessible (en tout cas pas autant que le player flash)

Enfin concernant la validation html et le respect du rgaa, il est tout à possible d'etre conforme rgaa et d'utiliser la balise video. En effet, le test correspondant sanctionne la mauvaise imbrication des balises et la syntaxe des attributs existant dans la dtd utilisée et non l'usage d'éléments ou d'attributs non existant dans la dtd. Il est donc tout à fait possible d'utiliser l'élément video ou des role ARIA par exemple

Cordialement,

Aurélien Levy

6

Hello,

Bonjour,

pour réagir au message initiale, depuis que l'interface d'admin est en squelette j'envisage sérieusement de me pencher sur la question de son accessibilité. Mon principale problème est de savoir comment s'organiser pour bosser sur ce chantier, plugin ? dans mon coin ? sur la zone ?.

je dirai plugin sur la zone, c'est la meilleure solution pour participer à plusieurs et tester des trucs que l'on peut ensuite intégrer.
A ce sujet j'ai dans ma todo le merge des modeles documents du plugin accessibilité avec ceux par défaut de SPIP, mais je n'ai pas encore réussi à prendre le temps de le faire sereinement :frowning:

Concernant le player vidéo accessible. De mémoire le html5 ne doit s'afficher que si il n'y a pas flash car de toute façon le player html5 n'est pas accessible (en tout cas pas autant que le player flash)

Tout a fait, le player HTML5 ne se déclenche que sur des périphériques sans flash

Enfin concernant la validation html et le respect du rgaa, il est tout à possible d'etre conforme rgaa et d'utiliser la balise video. En effet, le test correspondant sanctionne la mauvaise imbrication des balises et la syntaxe des attributs existant dans la dtd utilisée et non l'usage d'éléments ou d'attributs non existant dans la dtd. Il est donc tout à fait possible d'utiliser l'élément video ou des role ARIA par exemple

Merci beaucoup de cette précision !

Cédric

7

Oui c’est bien ça : plugin intégrant toutes les contraintes accessibilités, ou intégration directe dans une distrib SPIP accessibilité stricte. visiblement non. le code produit en embarquant une video youtube(donc flash) est le suivant : Hors ce code provoque forcement des erreurs de validation sur DTD xhtml. c’est bon à savoir mais visiblement ce point n’est pas interprété de la même chez tous les experts de Temesis :slight_smile:

8

Oui c’est bien ça : plugin intégrant toutes les contraintes accessibilités, ou intégration directe dans une distrib SPIP accessibilité stricte. visiblement non. le code produit en embarquant une video youtube(donc flash) est le suivant :

Je refais donc l’explication :

  • le plugin envoie un markup HTML5
  • le plugin envoie ensuite le JS du player, qui supprime ce markup et le remplace par le lecteur flash (si flash est disponible), ou par une version HTML5 du player (balise video enrichie de l’interface de contrôle du JWPlayer).

Donc OUI on a bien un markup

  • Player Flash JWPlayer si possible (Flash et JS)
  • Player HTML5 JWPlayer sinon (JS uniquement)
  • Player natif du navigateur sinon (ni Flash ni JS)
  • une vignette de la vidéo (ni Flash ni JS ni support de

Hors ce code provoque forcement des erreurs de validation sur DTD xhtml.

Enfin concernant la validation html et le respect du rgaa, il est tout à possible d’etre conforme rgaa et d’utiliser la balise video. En effet, le test correspondant sanctionne la mauvaise imbrication des balises et la syntaxe des attributs existant dans la dtd utilisée et non l’usage d’éléments ou d’attributs non existant dans la dtd. Il est donc tout à fait possible d’utiliser l’élément video ou des role ARIA par exemple

c’est bon à savoir mais visiblement ce point n’est pas interprété de la même chez tous les experts de Temesis :slight_smile:

Je rebondis en remarquant que si l’attribut data-player est interdit alors toutes les prises en charge ajax native de SPIP sont également non compatibles du RGAA puisqu’elle recourent à des attributs data-xxx également (et quid des rôles ARIA donc ?)

Cédric

9

* Cédric Morin tapuscrivait, le 03/07/2012 15:29:

Je rebondis en remarquant que si l'attribut data-player est interdit alors toutes les prises en charge ajax native de SPIP sont également non compatibles du RGAA puisqu'elle recourent à des attributs data-xxx également (et quid des rôles ARIA donc ?)

Sur la validation W3C + Aria, en gros c'est mort en xhtml parce qu'Aria est arrivé après xhtml.
Donc, plus de mise à jour de la DTD.
Plus de lecture : How Can I Validate (X)HTML + ARIA? - TPGi

10

Le 03/07/2012 15:29, Cédric Morin disait :

Je rebondis en remarquant que si l'attribut data-player est interdit
alors toutes les prises en charge ajax native de SPIP sont également non
compatibles du RGAA puisqu'elle recourent à des attributs data-xxx
également (et quid des rôles ARIA donc ?)

Je rebondis longuement après la bataille, mais :

1. effectivement les attributs data-* ne sont pas valides en XHTML

mais :

2. aucune obligation à ma connaissance de faire du XHTML1 pour faire de l'accessibilité (point 4.1.1. de http://references.modernisation.gouv.fr/sites/default/files/RGAA-v2.2_Annexe1-Criteres.pdf :

<blockquote>
- Pour chaque page HTML ou XHTML, déclarer l'utilisation d'une DTD par l'instruction !DOCTYPE,
- Effectuer cette déclaration avant la balise html,
- Utiliser une syntaxe de déclaration validée par le W3C (Voir la liste des DTD recommandée (en anglais) ),
- Vérifier la validité du document en regard de la déclaration utilisée. La validité des documents HTML/ XHTML peut être vérifiée grâce au validateur HTML

</blockquote>

et donc :

3. en HTML5 quand on le formate comme du XHTML, on a un code très strict qui fait plaisir à voir :wink: et on peut utiliser autant d'attributs data-* que l'on veut.