Merci pour cette réponse rapide !
Effectivement nous préparons un modèle de site WordPress que nous allons proposer aux différentes communes (département 34 et 11) dans le cadre de notre Syndicat Mixte.
Actuellement nous faisons un audit d’accessibilité via Asqatasun (Audit de site OpenSource) de notre modèle WordPress. Nous utilisons par contre un serveur virtuel dédié, non accessible sur le web, avec une instance d’Asqatasun. Une fois l’audit terminé je verrai avec ma direction pour vous faire parvenir les infos concernant Co-marquage.
Il vous est aussi possible d’avoir directement un aper?u de l’audit via la page https://adullact.org/service-en-ligne-asqatasun. Pour avoir accès au service, il faut envoyer un mail à l’adresse [email protected], comprenant votre nom, votre prénom, le nom de votre collectivité ou le but la demande, l’adresse email qui servira d’identifiant, et le nom du ou des sites web que vous souhaitez analyser. Vous obtiendrez ainsi une connexion privée et gratuite pour analyser les pages/sites que vous voulez.
Pour votre information aux premiers résultats les changements pour valider l’accessibilité de co-marquage sont plut?t mineurs, on aurait 5 ou 6 points maximum :
– les pages générées présentent 2 titres H1, puis des H3. les titres doivent “se suivre”, on ne peut pas passer au H3 s’il n’y a pas de H2. Deplus WordPress générant le H1 de la page, il faudrait que le H1 co-marquage soit un H2 (et les titres H3 seraient du coup validés, arrivant après un H2)
– l’image logo Service Public présente ne possède pas de balise “alt” ou d’attribut “ARIA”. Il faudrait par exemple qu’elle signale alt=”Logo Service Public” ou dans le cas des images purement décorative (visuel) mais ne devant pas être lu par un lecteur d’écran d’accessibilité, il faut préciser l’attribut aria-hidden.
– les logos et icones décoratifs sont en SVG mais leur balise SVG ne possède pas d’attribut de r?le ou ARIA pour préciser ce qu’ils font. De ce fait les robots et lecteurs d’écran essaient de parser le SVG pour trouver des informations même si ce n’est qu’un visuel. On utilisera alors l’attribut role=”img” sur la balise SVG dans le cas d’un élément visuel, sinon on ajoutera l’attribut aria-labelledby=”” pour définir le label du SVG et laisser le lecteur parser l’information contenue.
– les liens téléphoniques n’ont pas d’attribut title (ex: title=”lien du Service xxx”)
– les liens sur les logos SVG/Img (ex: logo de la maison en haut à gauche pour revenir à l’accueil). Il faudrait spécifier un aria-label=”Retour à l’accueil” pour la balise lien et un aria-hidden pour la balise image.
– le formulaire de recherche n’a pas d’attribut Title ou aria-label, et la balise input n’a pas de label, donc les lecteurs d’écran ne comprennent pas sa fonction.
Cela parait un peu confus mais je vous ai fait cette liste rapide car au premier coup d’oeil ce sont les seuls éléments qui seraient obligatoires pour que les pages du plugin co-marquage soient valide RGAA 3.0 (norme AA). Ce qui est vraiment peu (moins de 5% des modifications total de notre modèle WordPress pour référence).
Bref, je verrai avec ma direction pour vous extraire l’analyse d’accessibilité concrète concernant le plugin co-marquage, qui aura l’avantage d’être bien présentée, avec toutes les infos et explications utiles plut?t que étalage ci-dessus.
En vous remerciant de votre implication,
Bonne journée
Et pour revenir au plugin lui-même, il est juste parfait pour notre utilisation !
Je tenais tout de même à le signaler et à vous remercier pour celui-ci.
