Modèles, composants et systèmes de conception

De nombreuses personnes utilisent le développement piloté par les composants à l'aide de guides de style de modèles, de bibliothèques de composants ou de systèmes de conception complets dans leur workflow de développement. Même si vous n'avez pas utilisé ces outils officiellement, vous utiliserez probablement un processus similaire pour décomposer une conception volumineuse d'un site Web, d'une application ou d'un autre produit numérique en éléments gérables.

Comme pour la construction d'une structure physique, il est important de construire une pièce à la fois. D'abord, les fondations, la structure, les murs, les fenêtres, le toit et tout ce qui se trouve entre les deux. Les outils de développement pilotés par composants nous permettent de le faire pour les sites Web, les applications et d'autres produits numériques.

Certains avantages du développement piloté par composants incluent la décomposition des éléments en éléments gérables, ce qui réduit le temps de développement avec ces composants réutilisables. Il permet aux concepteurs, aux développeurs d'interface et de backend et au contrôle qualité de travailler simultanément. Les clients, les concepteurs, les chefs de projet et plus encore l'apprécient car ils peuvent prévisualiser le processus de compilation et utiliser un guide de style vivant comme référence après le lancement du site Web.

Cependant, lorsque nous examinons les modèles, les composants et les systèmes de conception en tenant compte de l'accessibilité, certaines questions se posent. Comment savoir quels modèles sont les meilleurs en matière d'accessibilité ? Devez-vous utiliser un modèle/une bibliothèque établi(e) ou en créer d'autres ? Comment savoir si ces modèles aideront réellement vos utilisateurs ?

Avec la multitude de choix disponibles, il est facile de se perdre rapidement sur ce sujet. Ce module vise à vous donner des informations générales sur la façon d'évaluer les modèles, les composants et les systèmes de conception à des fins d'accessibilité. Il constitue également un point de départ pour vous aider à faire des choix plus accessibles.

Faites preuve d'esprit critique

Choisir un modèle, un composant ou un système de conception accessible n'est pas une mince affaire, mais cela prend du temps et nécessite un esprit critique. En fait, il n'existe pas de "modèle parfait", mais il peut potentiellement y avoir de nombreuses options qui pourraient fonctionner. Il s'agit ici d'apprendre à choisir la meilleure option en fonction de votre situation.

Dans les modules de test suivants, vous découvrirez les techniques et les méthodes permettant d'évaluer les modèles, les composants et les systèmes de conception pour l'accessibilité. Mais avant cette étape, vous devez prendre du recul et vous poser quelques questions fondamentales, telles que:

  • Un modèle, un composant ou un système de conception accessible établi existe-t-il déjà ?
  • Quels sont les navigateurs et les technologies d'assistance que je prends en charge ?
  • Existe-t-il des limites au niveau du code/du framework, ou d'autres intégrations/facteurs/besoins utilisateur dont je dois tenir compte ?

En fonction de votre environnement de développement et des besoins de vos utilisateurs, vous pourriez avoir des questions supplémentaires ou différentes. Considérez ces questions comme votre point de départ pour évaluer l'accessibilité.

Ressources établies

Avant de créer quelque chose de nouveau, faites vos preuves de diligence raisonnable et examinez ce qui existe déjà en termes de modèles, de composants et de systèmes de conception accessibles. Avec seulement quelques recherches, vous pourriez être surpris de trouver une ou plusieurs solutions qui répondent à vos besoins.

Voici quelques excellentes ressources pour les modèles, les composants et les systèmes de conception accessibles:

Pour les frameworks JavaScript, les ressources suivantes sont assez accessibles par défaut ou faciles à personnaliser pour des raisons d'accessibilité:

Cependant, et nous n'insisterons jamais suffisamment sur ce point, vous ne devez jamais simplement copier-coller du code en partant du principe qu'il s'adapte à votre environnement et répond automatiquement aux besoins de vos utilisateurs. Cela est vrai pour tous les modèles, composants et systèmes de conception, même s'ils sont étiquetés comme entièrement accessibles.

Toutes les ressources doivent être considérées comme un point de départ. N'oubliez pas de tout tester !

Compatibilité avec les navigateurs et les technologies d'assistance (TA)

Après avoir étudié quelques modèles de base, composants ou système de conception complet susceptibles de fonctionner pour votre environnement de développement, vous pouvez passer à l'assistance pour les technologies d'assistance. Les lecteurs d'écran sont l'un des principaux types de TA sur lesquels vous devrez vous concentrer lors de l'évaluation des modèles, des composants et des systèmes de conception.

Les lecteurs d'écran ont été conçus pour des navigateurs spécifiques et fonctionnent mieux lorsqu'ils sont associés à ces navigateurs. Nous aborderons ce sujet beaucoup plus en détail dans le module sur les tests de TA, mais à des fins d'évaluation des modèles, il est utile de comprendre l'existence de ces combinaisons. Vous saurez ainsi ce dont vous avez besoin en termes d'assistance.

Lecteur d'écran OS Compatibilité du navigateur Coût
Job Access with Speech (JAWS) Windows Chrome, Firefox, Edge Licence requise (une version sans frais de 40 minutes existe)
NVDA (Non-Visual Desktop Access) Windows Chrome et Firefox Sans frais (téléchargement requis)
Narrateur Windows Périphérie Sans frais (intégré aux machines Windows)
VoiceOver macOS Safari Sans frais (intégré aux machines macOS)
Orque Linux Firefox Sans frais (intégré dans les distributions basées sur Gnome)
TalkBack Android Chrome et Firefox Sans frais (intégré à certaines versions de l'OS Android)
VoiceOver iOS Safari Sans frais (intégré aux appareils iOS)

La prise en charge des navigateurs est généralement complexe, et les choses deviennent encore plus délicates lorsque vous ajoutez des appareils AT et ARIA à la fois.

Mais ce n'est pas une mauvaise nouvelle. Heureusement, d'excellentes ressources telles que l'accessibilité HTML5, l'assistance pour l'accessibilité et la checklist de développement accessible par le contrôle personnalisé des WCAG nous aident à mieux comprendre la compatibilité actuelle avec les navigateurs et les appareils TA, et même à utiliser les flux ARIA.

Ces ressources décrivent les différents sous-éléments des formats HTML et ARIA disponibles, y compris les tests de la communauté Open Source. Vous pouvez également consulter quelques exemples de modèles, pour les navigateurs pour ordinateurs de bureau et les navigateurs mobiles/les appareils de TA. Ainsi, ces ressources peuvent vous aider à prendre des décisions plus accessibles concernant les modèles, les composants et les systèmes de conception que vous souhaiterez peut-être utiliser.

Autres points à prendre en compte

Une fois que vous avez choisi quelques modèles ou composants de base accessibles et pris en compte la compatibilité des navigateurs et des appareils TA, vous pouvez passer à des questions contextuelles plus spécifiques sur le modèle, les composants, le système de conception et l'environnement de développement.

Par exemple, si vous travaillez dans un système de gestion (CMS) ou si vous disposez d'un ancien code, les modèles que vous pouvez utiliser peuvent être limités. Après examen, plusieurs choix de modèles peuvent rapidement être réduits à une ou deux options.

De nombreux frameworks JavaScript permettent aux développeurs d'utiliser presque tous les modèles de leur choix. Dans de tels cas, vous pouvez appliquer moins de restrictions et choisir l'option de format la plus accessible.

D'autres considérations sont à prendre en compte lors du choix d'un modèle, d'un composant ou d'un système de conception, tels que:

  • Performances
  • Sécurité
  • Référencement naturel
  • Assistance pour la traduction
  • Intégrations tierces

Ces facteurs vont sans aucun doute jouer un rôle dans le choix du modèle, mais vous devez également tenir compte des personnes qui créent le contenu et le code lui-même. Le modèle que vous choisissez doit être suffisamment robuste pour gérer les limitations potentielles liées au contenu généré par l'éditeur ou par l'utilisateur, et être conçu de manière à ce que les développeurs, quel que soit leur niveau de connaissances en accessibilité, puissent utiliser.

Testez vos connaissances

Tester vos connaissances sur les modèles

Les composants accessibles restent-ils toujours accessibles aux utilisateurs ?

Oui, vous pouvez utiliser ces composants sans effort supplémentaire de votre part.
Bien qu'une ressource conçue pour l'accessibilité soit plus susceptible de fonctionner automatiquement que d'autres, il est essentiel d'effectuer tout de même des tests d'accessibilité pour vous assurer que ces composants fonctionnent pour vos utilisateurs.
Non, vous devez d'abord tester vos composants.
Même les composants et les modèles conçus pour l’accessibilité doivent être testés. Il est possible qu'il soit inaccessible en combinaison avec d'autres composants existants.