Conception/architecture

WEB-27

WEB-27: Toutes les agences doivent afficher la bannière du Commonwealth telle qu'elle est définie par le système de conception du COV. 

Comprendre WEB-27  

Le Commonwealth Branding Bar aide les citoyens à identifier les sites web officiels des organisations gouvernementales du Commonwealth de Virginie. Il aide également les visiteurs à comprendre que le site sur lequel ils se trouvent est officiel et sécurisé. La nouvelle barre de marque sert également de portail de navigation pour les visiteurs du site web, qui peuvent ainsi facilement naviguer entre les agences gouvernementales et rechercher des informations sur l'ensemble du Commonwealth, sans avoir à retourner sur Virginia.gov. 

La barre de marquage est facile à installer, et des instructions et un code peuvent être trouvés pour que les agences les placent sur leurs sites web sous Get the Commonwealth Branding Bar (Obtenir la barre de marquage du Commonwealth). Cette page présente des instructions étape par étape pour générer un code à placer dans la balise head du site web d'une agence. Les agences ont également la possibilité de choisir entre des barres de marquage grises et blanches pour mieux s'adapter à la thématique des couleurs de leurs sites web. 

Chaque barre de marque générée contient : 

  • Le logo de l'État de Virginie 
  • Le nom de l'agence ou de l'entité gouvernementale de Virginie, dont les générateurs doivent écrire le nom en toutes lettres. 
  • Une signature indiquant "Un site officiel du Commonwealth de Virginie" et un menu déroulant indiquant "Voici comment vous le savez". 
  • Le menu déroulant contient des informations sur le logo du Commonwealth de Virginie et les certificats HTTPS. 
  • Un sous-menu intitulé "Find a Commonwealth Resource" (Trouver une ressource du Commonwealth) qui, lorsqu'il est cliqué, permet aux utilisateurs de rechercher des agences ou des entités gouvernementales de Virginie, ainsi que des services et des ressources du Commonwealth couramment utilisés, triés par domaine de service de l'agence. 

Le code généré doit être utilisé tel quel et ne doit pas être modifié de quelque manière que ce soit. Toute difficulté d'installation doit être signalée à l'équipe Enterprise Web Services de VITA par courrier électronique à l'adresse suivante Le code généré doit être utilisé tel quel et ne doit pas être modifié de quelque manière que ce soit. Toute difficulté d'installation doit être signalée à l'équipe Enterprise Web Services de VITA en envoyant un courriel à developer@vita.virginia.gov. 

WEB-28

WEB-28: Les systèmes web du COV doivent fournir une boîte de recherche sur le site de l'agence qui doit apparaître sur chaque page et être affichée conformément aux directives du système de conception du COV. 

Comprendre WEB-28

La présence d'une boîte de recherche sur chaque site et page de l'agence permet aux utilisateurs d'accéder plus rapidement à l'information en tapant des mots-clés et des termes de recherche pertinents qui les renvoient à une liste de liens pertinents.  Une agence ne peut pas dépendre uniquement de la navigation primaire ou secondaire pour diriger les utilisateurs vers les informations pertinentes.  

Étant donné que les boîtes de recherche deviennent de plus en plus essentielles pour les sites web qui contiennent de grandes quantités de contenu et d'informations, en particulier en ce qui concerne les politiques, les procédures ou les services aux citoyens, les boîtes de recherche doivent être affichées de manière visible sur chaque page et doivent être facilement repérables par les utilisateurs. 

En outre, les boîtes de recherche doivent respecter les meilleures pratiques suivantes : 

  • La recherche, dans la mesure du possible, doit conserver un champ d'interrogation en texte libre avec un texte de remplacement intitulé "recherche" ou avec des instructions plus contextuelles limitées à quelques mots dans lesquels l'utilisateur peut taper des requêtes. 
  • Les boîtes de recherche doivent être accompagnées d'une icône de loupe avec le moins de détails possible.s possible (simple lineart). Les utilisateurs reconnaissent universellement la loupe comme le symbole de la fonctionnalité de recherche. 
  • Dans la mesure du possible, cette icône ne doit pas masquer la fonctionnalité de recherche, car elle augmente le coût de l'interaction (plus de clics) et rend la fonctionnalité de recherche moins distincte. 
  • En cas de doute, faites comme Google. 
  • Les requêtes de recherche doivent être confirmées en appuyant sur la touche "Entrée". Les requêtes de recherche peuvent également être confirmées en appuyant sur un bouton de confirmation si vous le souhaitez, bien que l'interaction consistant à appuyer sur la touche "Entrée" dans le champ de recherche doive être conservée. 
  • Si vous ajoutez un bouton de confirmation, sa taille et son emplacement doivent être appropriés (généralement la hauteur de la boîte de recherche elle-même, placée à droite du champ d'interrogation en texte libre). Ce bouton de recherche doit avoir une taille minimale de 45 x 45 pixels pour respecter les meilleures pratiques en matière d'accessibilité. 
  • Le champ de saisie doit être suffisamment large pour contenir au minimum 27 caractères (définis à l'aide d'ems). 
  • Dans la mesure du possible, la boîte de recherche doit être placée dans le coin supérieur droit du site web de l'agence, sous la barre de marque du Commonwealth. 
  • Un champ déroulant d'auto-suggestion de moins de 10 éléments peut aider les utilisateurs à trouver plus rapidement ce qu'ils recherchent, mais les agences qui l'utilisent doivent s'assurer que les suggestions générées automatiquement par le champ sont pertinentes par rapport aux termes de recherche saisis dans le champ de saisie. 
  • Une fois que l'utilisateur a appuyé sur la touche "Entrée", le terme de recherche initial doit rester dans le champ, sauf si l'utilisateur l'efface, et l'utilisateur doit se voir présenter une page de résultats affichant les résultats de sa recherche. 
  • Si une recherche ne donne aucun résultat, les utilisateurs doivent recevoir des informations indiquant clairement qu'il n'y a pas de résultats correspondants. 

WEB-29

WEB-29: Les systèmes web du COV comprennent un plan du site (sitemap) pour permettre aux moteurs de recherche d'explorer plus efficacement un site web. Des exemples seront fournis dans le système de conception COV.

Comprendre WEB-29

Un plan du site est un fichier qui permet aux moteurs de recherche de découvrir la majeure partie de votre site en parcourant son contenu. 

Les sitemaps doivent être au format XML, qui permet aux moteurs de recherche d'indexer non seulement les fichiers HTML, mais aussi les données relatives aux images, aux vidéos, au contenu des actualités et aux versions localisées des pages web de l'agence. 

Pour en savoir plus sur la manière de créer des sitemaps au format XML, veuillez consulter le site Web de la Commission européenne. Documentation sur le format XML de Sitemaps sur sitemaps.org. 

VITA recommande de suivre les meilleures pratiques suivantes en matière de sitemap, telles qu'elles sont exposées sur le site developers.google.com : 

  • Un sitemap unique doit être limité à 50MB non compressé. Si le fichier sitemap de votre agence est plus volumineux, veuillez diviser votre sitemap en plusieurs sitemaps. 
  • Les fichiers Sitemap doivent être codés en UTF-8. 
  • Il est recommandé d'héberger vos sitemaps à la racine du site. 
  • Utilisez des URL absolues et pleinement qualifiées dans votre sitemap, par exemple, utilisez https://www.myvaagency.gov/agencypage.html plutôt que /agencypage.html. 

WEB-30

WEB-30: Les systèmes web du COV garantissent que chaque page comporte un pied de page contenant, au minimum, les informations suivantes : 

  • Nom de l'agence 
  • Informations sur les droits d'auteur 
  • Texte ou lien iconique approuvé indiquant la conformité à l'initiative pour l'accessibilité du Web (WAI).
  • Lien vers la déclaration de politique de confidentialité sur Internet de l'agence.
  • Lien vers l'information sur la liberté d'information
  • Traduction et clause de non-responsabilité
  • Une page de contact
  • Autres éléments définis par le système de conception COV 

Comprendre WEB-30

Le pied de page d'un site web est un modèle d'interface utilisateur statique qui apparaît tout en bas de toutes les pages du site d'une agence. WEB-30 prévoit que les éléments suivants soient affichés dans le pied de page de chaque page : 

  • Nom de l'agence : Le nom complet de l'agence doit être affiché 
  • Informations sur les droits d'auteur : Affiché en tant que droit d'auteur © Nom complet de l'agence [année en cours] 
  • Texte ou lien iconique approuvé indiquant l'initiative pour l'accessibilité du Web (WAI) : Rédigé en tant qu'initiative pour l'accessibilité du Web et lié à la page WCAG 2.0 AA Conformance. Les agences peuvent également établir un lien avec le WAI en utilisant le logo du WAI. Les lignes directrices et le code d'utilisation du logo peuvent être consultés sur le site suivant la page du W3C sur l'ajout du logo de conformité aux WCAG. 
  • Il est important que les agences s'efforcent de respecter la conformité AA telle qu'elle est définie dans WCAG 2.0 lorsqu'elles utilisent ce lien. 
  • Lien vers la déclaration de politique de confidentialité sur Internet de l'agence : Les politiques de confidentialité sont propres à chaque agence, mais elles doivent au moins expliquer comment une agence utilise et collecte les informations d'un utilisateur lorsqu'il accède au site, quelles sont les informations collectées, en quoi elles sont conformes à la loi de Virginie, où l'utilisateur peut s'adresser pour obtenir plus d'informations, la politique en matière de cookies et d'autres informations relatives à l'utilisation des données de l'utilisateur. Un exemple peut être trouvé sur virginia.gov. 
  • Lien vers l'information sur la FOIA : Les informations relatives à la FOIA sont spécifiques à chaque agence et doivent contenir des informations en langage clair sur la loi sur la liberté d'information de Virginie, les droits d'un utilisateur en matière de FOIA, la manière dont un utilisateur peut demander des documents, l'endroit où envoyer la demande et les responsabilités d'une agence lorsqu'elle reçoit une demande. Vous trouverez de plus amples informations sur la FOIA dans la rubrique Code de Virginie, chapitre 37. 
  • Avis de non-responsabilité concernant la traduction : un avis de non-responsabilité concernant la traduction indique qu'une tierce partie (généralement Google translate) est disponible pour localiser les pages. Cette clause de non-responsabilité doit mentionner le nom du tiers, ainsi qu'un verbiage indiquant que l'option est fournie pour aider les utilisateurs à consulter le site web dans des langues autres que l'anglais, mais qu'aucune traduction automatique n'est parfaite et que le service tiers est fourni "en l'état". Un exemple peut être trouvé sur Page de l'avis de non-responsabilité de VITA en matière de traduction. 
  • Une page de contact : Une page de contact doit être incluse dans le pied de page. Veuillez consulter WEB-31 pour de plus amples informations. 

En outre, le système de conception COV recommande que tous les pieds de page 

  • Travailler sur le mobile 
  • Les liens supplémentaires dans le pied de page doivent être choisis en fonction de leur objectif (fréquemment utilisés, mini sitemap, etc.). 
  • contenir des liens/icônes de médias sociaux, mais pas de flux sociaux entiers 
  • Est clair et lisible avec un minimum ou pas d'images 
  • Les appels à l'action doivent être brefs, avec une direction et un objectif clairs s'ils sont utilisés. 

WEB-31

WEB-31: Les systèmes web du COV doivent fournir une page "Contactez-nous" qui doit inclure, au minimum, les coordonnées de l'agence : 

  • Adresse postale
  • Numéro de fax, si disponible
  • Numéro de téléphone, y compris un numéro gratuit et/ou un numéro ATS le cas échéant
  • Envoyez un lien ou un formulaire de contact par courriel à un contact de l'agence. 
  • La page "Contactez-nous" doit être accessible à partir du pied de page.  

Comprendre WEB-31

Note Les agences doivent utiliser des adresses électroniques génériques et éviter d'associer les liens de contact de l'agence à des personnes spécifiques. 

Une page "Contactez-nous" permet aux utilisateurs de contacter l'agence pour toute question ou préoccupation par différents moyens afin de répondre aux besoins des différents utilisateurs. 

  • Les adresses postales doivent être l'adresse physique de l'agence et non une boîte postale, formatée comme suit : 
     Nom complet de l'agence 
    123 Adresse de la rue Route, numéro de bureau 456 
    Ville, VA Code postal 
     
  • Numéro de fax, si disponible, formaté ainsi : 
    123-555-5555 (Fax)
  • Numéro de téléphone, y compris un numéro gratuit et/ou un numéro ATS le cas échéant, ainsi formaté : 
    1-123-555-5555 (téléphone) 
    1-800-555-5555 (gratuit) 
    1-123-555-5555 (TTY) 
  • Des instructions supplémentaires peuvent être fournies, si nécessaire, sur la manière d'utiliser les services ATS ou de relais, s'ils sont disponibles. 
  • Un lien générique doit être utilisé pour éviter d'associer le contact de l'agence à une personne spécifique et doit être formaté de la manière suivante : 
     
    contact@agency.virginia.gov 
     
    Un formulaire de contact destiné à un contact de l'agence est une alternative à l'adresse électronique. Si vous utilisez un formulaire, celui-ci doit comporter au minimum les champs suivants, obligatoires pour la réponse, avec un étiquetage approprié :
  • Prénom
  • Nom de famille ( ? Le nom de famille est-il vraiment nécessaire ? selon le principe du moindre)
  • Courriel ou numéro de téléphone
  • Champ pour message ou commentaire 

WEB-36

WEB-36: Les systèmes web de la plate-forme COV, y compris les systèmes commerciaux prêts à l'emploi (COTS), prennent en charge la marque blanche pour une utilisation transparente de l'image de marque du Commonwealth, telle que définie par le système de conception COV.

Comprendre WEB-36

Les systèmes de plateforme web sont définis par l'EA comme suit : 

Tout système web offrant des capacités de niveau entreprise pour des implémentations à grande échelle ou multitenant, y compris les systèmes de gestion des ressources humaines (HRMS), les solutions de gestion financière (FMS), la gestion de la chaîne d'approvisionnement (SCM), la gestion de la relation client (CRM), la gestion de la performance de l'entreprise (EPM), et les systèmes de gestion de contenu (CMS). 

Ces systèmes devraient permettre aux agences de la COVA de changer leur apparence pour correspondre aux normes du système d'apparence et de conception de l'EA (également connu sous le nom de marque blanche) lorsqu'elles sont présentées à l'extérieur ou qu'elles sont en contact avec le public. Au minimum, un système web de plateforme accessible aux utilisateurs publics doit afficher la barre de marque du Commonwealth en haut de la page. 

Accessibilité

WEB-39

WEB-39: Les systèmes web du COV fournissent les informations nécessaires en matière d'accessibilité, qui sont affichées conformément aux directives du système de conception du COV, afin que l'utilisateur sache immédiatement comment naviguer au mieux sur le site web.

Comprendre WEB-39

Les systèmes web du COV affichent clairement la conformité des sites web en matière d'accessibilité, conformément à la30 liste WEB-,, notamment pour informer les utilisateurs des stratégies nécessaires pour naviguer sur le site web, quelles que soient leurs capacités. Enoutre, les agences doivent inclure une déclaration d'accessibilité qui indique les efforts déployés par l'agence pour développer un site web accessible, la manière dont elles assurent le suivi de l'accessibilité et les personnes à qui les utilisateurs peuvent faire part de leurs préoccupations en matière d'accessibilité.

WEB-40 - WEB-43

Exigences visuelles (WEB-40 - WEB-43)

Comprendre WEB-40 - WEB-43

Les conseils relatifs aux couleurs contrastées sont basés sur le critère de réussite des WCAG 1.4.3. Contraste (minimum), qui stipule : 

La présentation visuelle des texte et images du texte a une rapport de contraste d'au moins 4.5:1, sauf dans les cas suivants : 

  • A grande échelle le texte et les images du texte à grande échelle ont un rapport de contraste d'au moins 3:1 ;
  • Texte ou images de texte faisant partie d'un document inactif composant de l'interface utilisateurqui sont pure décorationLes images qui ne sont visibles par personne ou qui font partie d'une image contenant d'autres éléments visuels importants n'ont pas d'exigence en matière de contraste.
  • Le texte qui fait partie d'un logo ou d'une marque n'a pas besoin d'être contrasté. 

Les rapports de contraste des couleurs peuvent être déterminés à l'aide d'un outil d'audit tel que SiteImprove ou de vérificateurs en ligne tels que WebAIM. 

Les indications relatives aux signaux audio sont basées sur le critère de réussite des WCAG 1.2.2 Sous-titres (préenregistrés), qui stipule : 

Des sous-titres sont fournis pour tous les contenus audio préenregistrés dans des médias synchronisés, sauf lorsque le média est un média alternatif au texte et qu'il est clairement identifié comme tel. 

Des conseils sur les meilleures pratiques en matière de sous-titrage sont disponibles sur le site suivant Site recommandé par les WCAG, joeclark.org et le Site web du programme de description et de sous-titrage des médias. 

En outre, tous les utilisateurs ne peuvent pas comprendre ou percevoir la couleur, l'imagerie ou d'autres indices visuels en raison de handicaps affectant la vision, tels que la cécité ou le daltonisme chez les utilisateurs non voyants. WEB-41 est basé sur le critère de réussite des WCAG 1.4.1 Utilisation de la couleur, qui stipule 

La couleur n'est pas utilisée comme le seul moyen visuel de transmettre une information, d'indiquer une action, de susciter une réponse ou de distinguer un élément visuel. 

Par exemple, si un formulaire de contact comporte un bouton vert pour "soumettre" et un bouton gris pour "effacer le formulaire".,", les boutons et les instructions de soumission doivent être clairement identifiés. Dans ce cas, le bouton vert doit être étiqueté "soumettre" et le bouton rouge doit être étiqueté "effacer"..". Les instructions doivent indiquer aux utilisateurs de "cliquer sur le bouton d'envoi pour confirmer l'envoi du formulaire ou de cliquer sur le bouton d'effacement du formulaire pour effacer le formulaire et recommencer". 

L'étiquetage doit être clair et descriptif afin d'éviter toute confusion chez l'utilisateur, mais suffisamment concis pour que les utilisateurs puissent le lire rapidement et pour aider les utilisateurs souffrant de troubles de la lecture ou d'autres handicaps cognitifs. 

Les agences ne doivent pas utiliser uniquement la couleur pour indiquer les liens hypertextes sur leurs sites web. Les agences devraient chercher à utiliser cohérentLes hyperliens internes et externes sont signalés par des modèles de conception facilement reconnaissables, tels que les sous-jacents, les états de survol CSS et les icônes (en particulier dans le cas d'un hyperlien externe). 

En outre, les champs marqués comme obligatoires ou les champs pour lesquels des erreurs de saisie se produisent doivent présenter ces informations d'une manière qui ne soit pas seulement identifiée par l'utilisation de couleurs. Par exemple, un champ ne peut pas être simplement entouré d'un bord rouge ou avoir un astérisque rouge à côté de lui. Les agences devraient plutôt envisager des identifiants tels que "First Name Required" ou "First Name*" et un notificateur indiquant "* = champ obligatoire". 

Vous trouverez des exemples visuels et codés des meilleures pratiques en matière de champs obligatoires sur le site suivant L'anatomie des formulaires accessibles deDeque :Champs obligatoires desformulaires. 

Pour les erreurs saisies par l'utilisateur, l'erreur doit être facilement identifiable et faire l'objet d'une description claire et concise. Chaque message d'erreur doit également répondre aux critères suivants : 

  • identifier chaque champ en erreur
  • fournir des suggestions (lorsqu'elles sont connues) pour corriger les erreurs,
  • exposer correctement ces informations aux technologies d'assistance. 

Pour plus d'informations et d'exemples sur la manière de formater les champs de formulaire accessibles avec des erreurs, veuillez consulter le site suivant Level Access'Comment fournir un formulaire accessible Page d'identification des erreurs. 

Exigences ARIA

WEB-44 - WEB-53

WEB-44 - WEB-53: Exigences ARIA

Comprendre WEB-44 - WEB-53

HTML 5 contient une plus grande variété de balises HTML plus descriptives pour aider les développeurs et la technologie accessible à comprendre plus facilement la structure, le contenu et l'organisation d'une page web. Les agences doivent s'assurer que leurs sites web utilisent correctement le langage HTML sémantique afin d'aider les développeurs, les utilisateurs et les technologies accessibles à accéder au contenu de leur site web de manière appropriée. En outre, le balisage sémantique de HTML5 permet de limiter l'utilisation d'ARIA dans le code HTML. Pour plus d'informations sur le balisage sémantique en HTML 5 et son rôle dans l'accessibilité, veuillez consulter le site suivant Le HTMLde Mozilla :Une bonne base pour l'accessibilité des pages web. 

ARIA, ou Accessible Rich Internet Applications, est un ensemble de rôles et d'attributs ajoutés au code HTML pour rendre un site web plus accessible aux utilisateurs utilisant des technologies d'assistance. Si vous avez la possibilité d'utiliser un élément HTML dont la sémantique et le comportement sont déjà intégrés, utilisez cet élément HTML plutôt que AIRA. Les agences doivent utiliser ARIA avec un élément HTML s'il n'y a pas d'autre élément HTML qui décrit ou fonctionne de manière native, sémantique ou comportementale, ce qu'il fait. Lorsque les agences choisissent d'utiliser ARIA, elles doivent être conscientes qu'elles sont responsables de la création d'une expérience native appropriée et similaire pour les technologies d'assistance web (telles que l'ordre des tabulations du clavier). 

WEB-44 - WEB-53 indique spécifiquement les exigences relatives à l'utilisation d'ARIA si les agences se trouvent dans une situation où il n'y a pas de balisage sémantique équivalent. Les développeurs peuvent se référer au Applications Internet riches accessibles du W3C (WAI-ARIA) 1.3 pour plus de détails sur les normes ARIA, tandis que les concepteurs peuvent se référer à la section Guide des pratiques de création ARIA du W3C (APG) pour obtenir des informations sur les modèles de conception courants et sur la manière de concevoir des interactions qui fonctionnent au mieux avec l'utilisation d'ARIA. 

Interaction de l'utilisateur avec la présentation

WEB-54 - WEB-102

WEB-54 - WEB-102: Interaction de l'utilisateur avec la mise en page

Comprendre WEB-54 - WEB-102

Lorsque les agences créent des sites web, elles ne doivent pas se limiter à l'utilisateur "le plus courant", mais concevoir un design adapté à une grande variété de types d'utilisateurs et d'expériences vécues. Ces groupes sont généralement répartis dans les catégories suivantes : 

  • Visuel
  • Auditoire
  • Moteur
  • Cognitif 

Les agences doivent donc s'assurer que leurs sites web peuvent être consultés et utilisés par ces cinq groupes d'utilisateurs et que d'autres variantes des interactions de leur site web sont disponibles. Si un lien est accessible à l'aide d'un pointeur de souris, par exemple, il doit également être accessible au clavier par l'ordre des tabulations, aux lecteurs d'écran par le balisage sémantique, et être signalé visuellement, et pas seulement par la couleur. En outre, les agences devraient envisager de décrire les supports visuels (tels que les images) au moyen d'un texte alt et d'un texte descriptif ou équivalent pour les indices auditifs.  

Les agences doivent permettre aux utilisateurs de contrôler entièrement la page web si elle contient des médias joués (auditifs et/ou visuels) et éviter les images clignotantes et défilantes pour les utilisateurs susceptibles de déclencher des crises d'épilepsie ou de migraine. 

En cas de doute, restez simple ! 

Les développeurs et les agences peuvent se référer à la Normes WCAG Web 2.1 pour les normes web les plus récentes et les plus approuvées, s'ils souhaitent approfondir la question. Cependant, L'université de Harvard a élaboré un guide simple et facile à lire sur les 10 éléments essentiels que les développeurs doivent prendre en compte en matière d'accessibilité. qui couvre la plupart des sujets abordés dans les cours WEB-54 - WEB-71. 

WEB-72 - WEB-102 se concentre spécifiquement sur la création de sites web perceptible, utilisable, et robuste. Il s'agit de trois des quatre principes énoncés dans le document Les quatre principes d'accessibilité des WCAG. 

Selon les WCAG, ces quatre principes sont les suivants : 

  • Perceptible - Les informations et les composants de l'interface utilisateur doivent être présentés aux utilisateurs de manière à ce qu'ils puissent les percevoir. Cela signifie que les utilisateurs doivent être en mesure de percevoir les informations présentées (elles ne doivent pas être invisibles pour tous leurs sens). 
  • Opérationnel - Les composants de l'interface utilisateur et la navigation doivent être opérationnels. Cela signifie que les utilisateurs doivent être en mesure d'utiliser l'interface (l'interface ne peut pas exiger une interaction qu'un utilisateur ne peut pas réaliser). 
  • Compréhensible - Les informations et le fonctionnement de l'interface utilisateur doivent être compréhensibles. Cela signifie que les utilisateurs doivent être en mesure de comprendre les informations ainsi que le fonctionnement de l'interface utilisateur (le contenu ou le fonctionnement ne doit pas être hors de leur portée). 
  • Robuste - Le contenu doit être suffisamment robuste pour pouvoir être interprété de manière fiable par une grande variété d'agents utilisateurs, y compris les technologies d'assistance. Cela signifie que les utilisateurs doivent pouvoir accéder au contenu au fur et à mesure que les technologies progressent (le contenu doit rester accessible au fur et à mesure de l'évolution des technologies et des agents utilisateurs). 

Ces quatre principes constituent l'épine dorsale des normes modernes d'accessibilité au web. 

En outre, WEB-72 stipule que les sites web des agences doivent contenir au moins les éléments suivants deux des éléments suivants : 

  • Liste des pages connexes  
  • Table des matières 
  • Plan du site 
  • Recherche 
  • Liste de toutes les pages 

Pour obtenir de plus amples informations de manière concise et simplifiée, les agences peuvent se référer aux documents suivants Principes de l'Université d'Harvard sur le site de l'Initiative pour l'accessibilité numérique (Digital Accessibility Initiative). 

Navigation dans l'appareil de l'utilisateur

WEB-103 - WEB-120

WEB-103 - WEB-120: Navigation dans l'appareil de l'utilisateur

Comprendre WEB-103 - WEB-120

WEB-103 - WEB-120 se concentre spécifiquement sur les différentes façons de naviguer sur un site web. Il est important de savoir que tous les utilisateurs ne se servent pas d'un périphérique d'entrée utilisant un pointeur de souris. Les dispositifs d'entrée alternatifs peuvent inclure des lecteurs d'écran, des commandes vocales, des bâtonnets buccaux, des sirops et des bouffées, ainsi que les touches de tabulation et d'entrée des claviers d'ordinateur, pour n'en citer que quelques-uns. 

Les agences peuvent en savoir plus sur les technologies d'assistance en consultant le site web de la Commission européenne. Page web de l'université de Berkeley sur les types de technologies d'assistance. 

En outre, cette section de l'évaluation environnementale fait également référence à la fonction de contrôle moteur des utilisateurs potentiels sur les appareils mobiles, en précisant que 

Les systèmes web COV ne doivent pas nécessiter de gestes multipoints ou basés sur la trajectoire, tels que le pincement, le glissement ou le déplacement. pour la fonctionnalité, sauf si le geste est essentiel à la fonctionnalité. 

Cela signifie que sur les écrans tactiles, les utilisateurs doivent pouvoir zoomer, agrandir le texte ou effectuer des interactions de base sur une page web sans avoir besoin d'un contrôle gestuel, et que les sites web doivent être développés pour répondre de manière native aux différentes tailles d'écran et aux différents appareils. 

Les agences peuvent trouver une ventilation des techniques d'accessibilité supplémentaires, y compris celles de la section, dans Page web de l'Université de Harvard sur les techniques d'assistance. 

Contenu AV

WEB-121 - WEB-128

Contenu AV : WEB-121 - WEB-128

Comprendre WEB-121 - WEB-128

Tous les supports audio et visuels doivent être accessibles et formatés de manière appropriée pour les utilisateurs sur le web. Cette section de l'évaluation environnementale fait spécifiquement référence aux éléments suivants WCAG Guideline 1.2 - Médias temporelsqui indique comment le contenu AV des sites web doit être rendu accessible. Il convient de se référer aux normes 1.2.1 et 1.2.5 qui suivent : 

  • Une alternative pour les médias temporels est proposée, qui présente des informations équivalentes pour les contenus audio ou vidéo préenregistrés.  
  • Des sous-titres sont fournis pour tous les contenus audio préenregistrés dans les médias synchronisés. 
  • Une alternative aux médias temporels ou à la description audio du contenu vidéo préenregistré est fournie pour les médias synchronisés, 
  • Des sous-titres sont fournis pour tous les contenus audio en direct dans les médias synchronisés. 
  • La description audio est fournie pour tous les contenus vidéo préenregistrés dans les médias synchronisés. 

En outre, tous les contenus en direct, tels que les webinaires et les webcasts hébergés sur les sites web ou les applications des agences, doivent également fournir des sous-titres précis et ponctuels (tels que le sous-titrage en temps réel et/ou la transcription CART). 

Les utilisateurs doivent également avoir la possibilité de mettre en pause, de lire et d'arrêter le média à tout moment, et le média ne doit pas être lu automatiquement lorsque l'utilisateur visite la page.