- From: Jérôme Bonnet <adresse@cachée>
- To: adresse@cachée
- Subject: Re: [rgaa] Critère 8.2 RGAA et frameworks web
- Date: Thu, 17 Feb 2022 13:55:43 +0400
Le 04/02/2022 à 21:59, Remi Saintot
(via rgaa Mailing List) a écrit :
Bonjour à toutes
et à tous,
Sans être
spécialiste de la question, j'ai déjà rencontré ce type de
problème, peut-être pas avec ce framework précis, mais disons,
avec un framework équivalent/concurrent.
Je serais moins
catégorique que les autres personnes ayant répondu sur la
question, j'ai un doute sérieux quant à la validation du critère
8.2 pour des sites web utilisant ces technologies.
J'explique
ci-dessous mes arguments, qui n'engagent que moi.
Tout d'abord, si
le site se présente comme un DOCTYPE HTML et qu'on trouve dans
le code généré des balises & attributs non html, c'est fort
délicat de répondre oui, le code généré est valable, parce qu'à
moins d'une analyse poussée, on n'en sait rien et on ne peut pas
en être sûr.
Les balises
générées par ces frameworks héritent probablement leurs
propriétés des objets standard d'HTML 5, sauf que l'utilisation
des balises étendues propres à ces framework rends le code
source illisible, difficilement auditable et impropre à une
analyse automatique par des validateurs HTML du W3C.
Il y a également
un détail important dans la formulation du critère 8.2 RGAA : on
y parle bien du code source généré, pas du code source
de la page web. Le code source généré, c'est bien la
représentation dynamique interne du navigateur, à savoir le DOM.
Bref, il ne suffit
pas de faire un copier/coller du code source statique de la page
web dans un validateur HTML 5, dans ce cas on analyserait
seulement le code source statique, non généré.
C'est la
représentation interne du code source généré qu'il faut
analyser, pas sa version statique et non encore interprétée par
le moteur ECMAScript du navigateur.
Je précise ce
point car si l'analyse du code source "statique" peut être
parfaitement valide dans un validateur HTML 5, on obtient
parfois un résultat fort différent si on teste le code
réellement généré dans le navigateur. Par exemple, on peut
n'avoir aucune erreur sur la version statique et des centaines
d'erreurs sur un snapshot de la version générée.
Bref, si le
document prétend être un DOCTYPE HTML 5 et qu'il contient des
balises non HTML, ça pose un réel problème, en tout cas pour
auditer le site.
Difficile
d'affirmer que ces éléments custom n’influeront en rien le rendu
par un lecteur d'écran, on en sait juste rien et par conséquent
l'évaluation à "Non conforme" pour le critère 8.2 me semble la
plus honnête des réponses qui soient.
Une dernière
information, puisque je vois que le projet consiste à réaliser
une migration technique vers un Angular plus récent, je cite la
page web de Wikipédia sur AngularJS et j'y lis :
"AngularJS ne
sera plus développé par Google à partir de décembre
2021. Il convient donc d'envisager une
migration rapide du code des projets basé sur cette
technologie.
"
À mes yeux, c'est
un réel problème concernant ce type de framework : autant HTML
bénéficie d'un consensus général & durable, autant ces
framework restent sous l'autorité d'une seule entreprise, qui
peut décider du jour au lendemain de mettre fin au support de
telle ou telle version de leurs frameworks (Vous souvenez vous
de flash, ce magnifique "plugin" ?).
Ça n'est pas idéal
à bien des points de vue, du moins lorsque l'on souhaite mettre
en place des systèmes durables, robustes & accessibles.
Sans parler des
coûts financiers & humains que cela engendre, le jour où
l'on se retrouve contraint de migrer d'urgence ses sites parce
que Google a décidé que Angular JS version 1 disparait en
décembre 2021, et que la version qui lui succède ne sera pas
rétrocompatible du tout.
Bref, il faut bien
réfléchir avant d'accepter tel ou tel framework sur ses sites
web, ça a des conséquences et des coûts cachés sur lesquels bien
peu de prestataires web attireront votre attention.
Et de fait, ces
frameworks facilitent le travail des intégrateurs et des agences
web, le bénéfice réel pour le client, je ne le vois pas trop.
On peut
probablement obtenir toutes les fonctionnalités de ces
frameworks en respectant seulement les standards du web, le gain
réel se situe pour les développeurs, mais pas pour leurs clients
et encore moins pour les utilisateurs finaux.
Cordialement.
Bonjour,
Je travaille sur une application de l'Education Nationale qui
doit évoluer pour atteindre la conformité RGAA.
Pour la partie front-end, nous utilisons le framework Angular
JS (= Angular 1) et nous sommes en train d'organiser une
migration technique vers Angular 12.
Nous avons déjà fait un Audit RGAA externe sur quelques pages
représentatives de notre application (donc actuellement basées
sur Angular JS), et pour toutes nous avons obtenu le résultat
"Non conforme" pour le critère 8.2.
Ce critère est défini officiellement de la manière suivante :
"Pour chaque page web, le code source généré est-il valide
selon le type de document spécifié (hors cas particuliers)
?"
L'explication donnée dans le rapport d'Audit pour ce résultat
"Non conforme" est la présence dans le DOM de balises et
d'attributs non standard pour le HTML. Ils sont en fait générés
et ajoutés par le framework Angular JS.
De tels éléments custom seront encore présents quand nous
aurons migré vers Angular 12, qui repose sur le même
fonctionnement.
Après discussion avec des spécialistes et certains de mes
supérieurs, nous pensons que nous pouvons passer outre ce
résultat, car ces éléments custom n'auront pas d'impact sur le
rendu fait par un lecteur d'écran, ou sur tout autre outil
utilisé pour l'accessibilité.
Pouvez-vous nous aider en répondant à ces questions ?
> Cet évaluation à "Non conforme" vous semble-t-elle
justifiée ?
> Avez-vous des retours sur l'utilisation d'Angular ou
d'autres frameworks web et sur les éventuels problèmes que
cela engendrerait pour les lecteurs d'écran ou tout autre
technologie d'accessibilité ?
Merci d'avance pour votre aide et vos réponses.
Cordialement,
Remi
--
Jérôme Bonnet
司書 Agent DAMAN
Pôle
Excellence et Rayonnement
Université de La
Réunion
ToIP : en cours | ID
Zoom (réunion personnelle) | Mobile :
+262 692 41 27 38
You'll find us
clap the pirate's gospel - Alela Diane
Archives gérées par MHonArc 2.6.19+.
