PhōsPixel

Accessibilité et modèle de code de base pour mes SVG

Lectures et recherches pour créer un code de base pour des SVG dit accessible (aria-label-like)

Avec comme objectif de me créer un modèle de base pour un fichier SVG, j’ai lu les articles Accessible SVGs et Accessible SVGs: Perfect Patterns For Screen Reader Users, qui m’ont davantage embrouillé qu’éclairci ! C’est assez compliqué et j’en conclus que ça dépend beaucoup du contexte d’utilisation :

En gros, j’en retiens que je regarderai à nouveau lorsque j’utiliserai des SVG dans un autre contexte, ou que je serai plus avancée, mais je vais inclure un <title>, lorsque possible, car cela agit comme un aria-lable pour les agents.

Des formes SVG

SVG 1.1 vs SVG 2

Le SVG 2 semble presque adopté par les développeurs et plusieurs articles semblent promouvoir l’adhésion du SVG a utiliser le plus possible les éléments du CSS lorsque qu’ils les ont en commun, tel le <a>. J’avais déjà commencé à adopter cette posture, mauvaise pratique, ou du moins, attention avec certains éléments!

Le SVG 2 n’est toujours qu’en recommendation au W3C. Je retiens d’ailleurs que l’inclusion de plus d’une balise <title> est considéré comme un élément à risque, de même que la description <desc>, alors je l’ai enlevé de mon modèle, contrairement à ce que suggèrais Migliorisi dans son texte sur l’accessibilité, et ce même si c’était buggué à l’époque de son article (Chrome et Firefox).

Éléments dit à risque par le W3C

En plus de plusieurs balises <title> et de l’utilisation du <desc>, les autres éléments considérés à risque par le W3C, car non supporté correctement par les navigateurs sont :

Nested links ?! <a> olalala!

Nested links! Et dire que la base de ma recherche actuelle s’est activé autour de la découverte qu’un SVG peut utilisé le <a>, article sur CSS-TRICKS, et que j’en ai déjà mis amplement (puis retirés depuis).

<a> ou pas ?

Dans l’Appendix M: Attribute Index du SVG 1.1 (Second Edition) – publié le 16 août 2011 par W3C, le <a> n’est pas là. Mais comme il peut être dans du XML, tout cela devient très confondant, de plus que les développeurs semblent largement avoir adopté le SVG 2 même si le W3C ne le reconnait toujours pas. Le groupe du W3C s’occupant du SVG 2 a réécrit un draft en mars 2023. Plusieurs problématiques sont soulevés par rapport au DOM.

Pour le <a>, le problème principal, tel que résumé par MDN :

SVG’s <a> element is a container, which means you can create a link around text (like in HTML) but also around any shape.
[…]
Warning: Since this element shares its tag name with HTML’s <a> element, selecting a with CSS or querySelector may apply to the wrong kind of element. Try the @namespace rule to distinguish the two.

Que faire ?

@namespace est une règle CSS et elle nes semble pas fonctionner si utilisée dans un balise <style> à l’intérieur même du SVG 🙂 Je crois aussi que ça dépend du contexte d’utilisation et de comment est codé un SVG. Ainsi, en donnant un namespace xmlns, des ID et classes uniques, et en continuant d’utilisé le xlink, même si celui-ci sera déprécié en SVG 2 pour se rapprocher du HTML 5, il n’y a pas de raison pour qu’un <a> soit visé, sinon je l’aurais vécu ici sur mon site, comme j’ai constaté avec d’autres éléments et script alors que je les intégrais. Toujours est-il que je vais éviter de mettre des <a> lorsque ce n’est pas nécessaire !

Nomenclature personnalisée

Ayant expérimenté plusieurs problèmes de contamination de code, j’ai dû déterminer un système personnalisé pour nommer mes classes et id. Le problème étant que le namespace ne fait pas en sorte qu’une classe dans une balise style s’appliquera qu’au dit SVG si un autre SVG avec le même nom de classe se retrouve sur une même page HTML. Et, c’est encore pire avec un script, surtout s’il vise une balise générique tel <path> ou <circle>!

Mon système pour nommer classes et ID

nom-itération-jjmmaa

Ainsi, en terminant avec une date, il sera impossible de contaminer quoique ce soit, du moins, les chances sont bien minces.

Base de code pour un SVG XML

Après avoir observé plusieurs SVG sur CodePen et aussi parce que SVG OMG retire l’ouverture <?xml suivi de la version, j’ai décidé de ne plus en ajouter après l’optimisation du code et de me fier à SVG OMG qui semble vraiment faire office de gourou dans le domaine. 

<?xml version='1.0' encoding='UTF-8'?>
<svg version="1.1" id="nom-itération-jjmmaa" xmlns='http://www.w3.org/2000/svg'
      xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" 
      viewBox="0 0 1000 1000" xml:space="preserve">
      
   <title>Titre</title>

      <style>
            /* STYLES DE PRESENTATION */
            /* DANS LA BALISE STYLE OU INLINE SI NON GLOBAL */
            #nom-iteration-jjmmaa {}
            .nom-iteration-jjmmaa {}
      </style>

      <!-- DEFS pour définir des propriétés SVG-->
      <defs>
            <linearGradient id="degrade-1-200224">
                  <stop offset="0%" stop-color="#f8ED34" />
                  <stop offset="50%" stop-color="#FF3966" />
                  <stop offset="100%" stop-color="#33207f" />
            </linearGradient>
      </defs>

      <!-- LES ÉLÉMENTS DU OU DES SVG-->

      <path />

      <!-- SCRIPT TEMPORAIRE POUR CONNAITRE LONGUEUR-->
      <script>
        let chemin = document.getElementById('nom-iteration--jmmaa').getTotalLength();
        console.log(chemin);
      </script>
</svg>