Foire aux questions - Accessibilité Web

• Devons-nous soumettre une demande chaque fois que nous apportons une modification à nos applications ?

  Un audit d'accessibilité est requis lorsque l'interface utilisateur a été modifiée.

• Quelles sont les normes d'accessibilité actuelles et futures ?

  Normes actuelles

  • WCAG 2.1 (A et AA) supporté par
  • Lignes directrices pour rendre les technologies de l'information utilisables par tous
  • Norme sur l'accessibilité Web (actuellement en cours de rafraichissement)
  • La norme européenne d'accessibilité numérique (EU EN 301 549 v2.1.2) en anglais seulement

  Normes futures

  • WCAG 2.2 (A et AA) (Probablement au cours de l'année fiscale 2023-2024)

    Sera pris en charge par la dernière mise à jour de la Norme sur l'accessibilité des sites Web ou l'une des politiques d'accessibilité numérique à venir.

  • WCAG 3.0 (cote d'argent) (date de publication estimée vers 2025) (en anglais seulement)

    On ne sait pas encore comment cela sera soutenu, mais très probablement par le biais d'un instrument de politique mis à jour du SCT. WCAG 3.0 sera un changement complet dans la façon dont les tests de conformité sont effectués.

• Comment valider des pages web internes avec Nu Html Checker ?

  Pour valider une page interne, vous pouvez utiliser le signet "Vérifier le DOM sérialisé pour la page en cours" et le signet "Parsing WCAG" pour filtrer le résultat. Pour les essayer, veuillez suivre les étapes ci-dessous :

  1. Enregistrez la vérification DOM sérialisée pour la page actuelle.
  2. Enregistrez l'analyse WCAG uniquement en tant que signet.
  3. Utilisez la vérification DOM sérialisée du signet de la page actuelle pour vérifier une page (page de test).
  4. Une fois la page de résultats affichée, activez le signet "WCAG Parsing".
  5. Les résultats seront filtrés pour fournir un sous-ensemble approximatif de résultats de validation qui représentent WCAG 2.x 4.1.1 L'analyse échoue.

  Source: WCAG 2.1 Parsing Error Bookmarklet(en anglais seulement)

  Vérifiez le DOM sérialisé pour le code de signet actuel

  JavaScript

  Le code commence

  javascript:(function(){function%20c(a,b){var%20c=document.createElement("textarea");c.name=a;c.value=b;d.appendChild(c)}var%20e=function(a){for(var%20b="",a=a.firstChild;a;){switch(a.nodeType){case%20Node.ELEMENT_NODE:b+=a.outerHTML;break;case%20Node.TEXT_NODE:b+=a.nodeValue;break;case%20Node.CDATA_SECTION_NODE:b+="<![CDATA["+a.nodeValue+"]]\>";break;case%20Node.COMMENT_NODE:b+="<\!--"+a.nodeValue+"--\>";break;case%20Node.DOCUMENT_TYPE_NODE:b+="<!DOCTYPE%20"+a.name+">\n"}a=a.nextSibling}return%20b}(document),d=document.createElement("form");d.method="POST";d.action="http://validator.w3.org/nu/";d.enctype="multipart/form-data";d.target="_blank";d.acceptCharset="utf-8";c("showsource","yes");c("showoutline","yes");c("content",e);document.body.appendChild(d);d.submit()})();

  Le code se termine

  La source: Signet d'erreur d'analyse WCAG 2.1

  Signet pour l'analyseur WCAG

  JavaScript

  Le code commence

  javascript:(function(){var removeNg=true;var filterStrings=["tag seen","Stray end tag","Bad start tag","violates nesting","Duplicate ID","first occurrence of ID","Unclosed element","not allowed as child of","unclosed elements","not allowed on element","unquoted attribute value","Duplicate attribute","tabindex must not", "not appear as a descendant of"];var filterRE,root,results,result,resultText,i,cnt=0;filterRE=filterStrings.join("|");root=document.getElementById("results");if(!root){alert("No results container found.");return}results=root.getElementsByTagName("li");for(i=0;i<results.length;i++){result=results[i];if(result.className!==""){resultText=(result.innerText!==undefined?result.innerText:result.textContent)+"";if(resultText.match(filterRE)===null){result.style.display="none";result.className=result.className+" steveNoLike";cnt++}else if(removeNg==true){if(resultText.indexOf("not allowed on element")!==-1&&(resultText.indexOf("ng-")!==-1&&resultText.indexOf("ng-")<resultText.indexOf("not allowed on element"))){result.style.display="none";result.className=result.className+" steveNoLike";cnt++}}}}alert("Complete. "+cnt+" items removed.")})();

  Le code se termine

• Comment coder les adresses de courriel ?

  En règle générale, il est recommandé de fournir l'adresse de courriel complète comme texte de lien. Par exemple : "Veuillez contacter le bureau de l'accessibilité des TI pour plus d'informations : edsc.ti-it.a11y.esdc@hrsdc-rhdcc.gc.ca"

  Veuillez écrire l'adresse de courriel en minuscules comme recommandé par le Guide de style de contenu Canada.ca.

• Plugiciels de navigateur approuvés

  • Plugiciels de navigateur approuvés (en anglais seulement) Lien interne
• Comment rendre un nuage de mots accessible?

  Un nuage de mots est une image complexe et, à ce titre, une description longue doit être fournie en dessous. Veuillez noter que le texte de remplacement doit inclure « Description longue ci-dessous ». Voici quelques exemples :

  • Concevoir des images accessibles
  • Texte de remplacement accessible pour le Wolds Word Cloud (en anglais seulement)
• Lignes directrices sur l'accessibilité pour les tableaux de bord

  Power BI est la plateforme qu'utilisent la plupart des employés d'EDSC. Au Bureau de l'accessibilité des TI, nous recommandons habituellement le format HTML, car il s'agit du format le plus accessible.

  Vous trouverez ci-dessous des lignes directrices pour la création de tableaux de bord accessibles :

  1. Assurez-vous que le contraste des couleurs entre le titre, l'étiquette de l'axe et le texte de l'étiquette de données et l'arrière-plan est d'au moins 4,5:1.
  2. Assurez-vous que le rapport de contraste des composants actifs de l'interface utilisateur et les objets graphiques comme les icônes et les graphiques est d'au moins 3:1 par rapport aux couleurs adjacentes.
  3. Évitez de vous fier sur la couleur comme seul moyen de transmettre l'information. Utilisez du texte ou des icônes pour compléter ou remplacer la couleur.
  4. Remplacez le jargon ou les acronymes inutiles.
  5. Lorsque vous utilisez des images pour afficher des points de données, employez des équivalents textuels pour expliquer ce qui est communiqué.
  6. Assurez-vous d'ajouter des équivalents textuels à tous les éléments visuels non décoratifs de la page.
  7. Réglez l'ordre des onglets. Désactivez l'ordre des onglets (fixez l'élément comme étant masqué) pour tous les éléments décoratifs.

  
  

  Fournissez un équivalent textuel HTML accessible (p. ex. tableaux de données). Voir les liens ci-dessous pour des exemples de tableau des résultats en HTML :

  • Sondage éclair auprès des employés Lien interne
  • Sondage de 2020 auprès des fonctionnaires fédéraux

  
  

  Fournissez une liste de points saillants ou un résumé des données dans le texte. Voir les liens ci-dessous pour des exemples :

  • Points saillants : Sondage de 2020 auprès des fonctionnaires fédéraux
  • Infographie du sondage éclair auprès des employés – Description longue

  
  

  Source:

  • Liste de vérification de l'accessibilité des rapports Microsoft Power BI
  • Comprendre le critère de succès 1.4.11 : Contraste non textuel. (en anglais seulement)
  • Créer des visualisations de données et des tableaux de bord plus accessibles (en anglais seulement)

  
  

  Autres ressources :

  Directives de Microsoft pour créer des rapports Power BI :

  • Vue d'ensemble de l'accessibilité dans Power BI
  • Créer des rapports Power BI accessibles
  • Accessibilité pour votre solution intégrée (en anglais seulement)
  • Liste de contrôle de l'accessibilité
• Directives sur les champs obligatoires

  Au Bureau de l'accessibilité des TI, nous recommandons toujours de suivre les instructions du guide de style de la Boîte à outils de l'expérience Web (BOEW). Par contre, lorsqu' il n'y a pas assez d'espace pour signaler tous les champs obligatoires comme tel que recommandé, nous acceptons la stratégie suivante :

  Marquez les champs obligatoires avec seulement un astérisque et ajoutez l'avis suivant en haut du formulaire : Tous les champs marqués d'un astérisque « * » sont obligatoires.. Ajoutez aria-required="true" aux champs de saisie obligatoires. Cela permettra aux lecteurs d'écran d'annoncer les champs obligatoires.

• Élément de tableau : l'attribut scope comparativement aux attributs id/headers

  Pour les tableaux simples, il est recommandé d'utiliser l'attribut scope. Les id/headers sont utilisés pour les tableaux complexes; toutefois, selon les recommandations de la section 5.3 du Guide de rédaction du contenu du site Canada.ca, les tableaux complexes doivent être convertis en un ou plusieurs tableaux simples. De plus, il est recommandé de convertir un tableau en liste si les données sont simples. Donc, d'habitude, le Bureau de l'accessibilité des TI recommande habituellement d'utiliser des tableaux simples avec l'attribut scope dans la mesure du possible, car ils sont plus facilement utilisables pour le grand public (lecteurs d'écran, clavier seulement, lecteurs d'écran mobiles, etc.). Dans certains cas, la technique id/headers est utilisée pour les tableaux complexes même s'ils peuvent être difficiles à coder et à tenir à jour.

• Une page d'accueil est-elle requise pour ma demande?

  Cela dépend du contexte :

  • Est-ce une application Internet ou intranet?
  • Est-ce une application Web bilingue?
  • Où les données seront-elles hébergées?

  
  

  Par exemple, MDSC n'a pas de page d'accueil; il n'a qu'un commutateur de langue parce qu'il est hébergé sur Canada.ca, qui a une page d'accueil. Selon les Spécifications techniques pour la présence Web et mobile, il existe deux exceptions pour la page d'accueil :

  • Les sites Web et les applications Web qui ont une adresse de site Web unilingue ne déploient pas d'écrans d'accueil.
  • Les applications pour appareils mobiles mettent en œuvre des écrans de lancement d'applications plutôt que des écrans d'accueil.

  
  

  Voici d'autres ressources :

  • • Spécifications du contenu et de l'architecture de l'information pour Canada.ca
  • Solution de gabarits à déploiement centralisé (SGDC)
  • Page d'entrée de la Boîte à outils de l'expérience Web
  • • Intranet - Solution de gabarits à déploiement centralisé (SGDC)
• Puis-je avoir plusieurs balises H1 sur une page? La page est-elle conforme à la norme WCAG?

  Le fait d'avoir plusieurs balises H1 sur une page n'est pas une non-conformité aux WCAG, mais le Bureau de l'accessibilité des TI ne recommande pas d'utiliser plusieurs balises H1 sur une page lorsque cela n'est pas nécessaire. En général, il est recommandé d'utiliser une balise H1 par page, qui correspond généralement au titre de la page.

• Puis-je utiliser des images d'arrière-plan?

  En général, les images d'arrière-plan ne transmettent pas d'information et, si elles le font, elles ne doivent pas être utilisées comme images d'arrière-plan.
  
  Toute image utilisée pour transmettre de l'information doit comporter un équivalent textuel.
  
  Par exemple, les images de titre pourraient avoir alt=”” si elles sont utilisées comme décoratives et n'ont pas de fonction ou si l'image est fournie dans le titre.
  
  

  Voici d'autres ressources :

  • WebAIM : Alternative Text (en anglais seulement)