Composants Blazor pilotés par les tests d'accessibilité

L'utilisation du développement piloté par les tests avec un accent sur l'accessibilité améliore la qualité des composants Blazor.

Le modèle de composants de Blazor est l'un des plus grands atouts du framework. La création de composants dans le framework est intuitive et créative. La plupart du temps, les choses « fonctionnent ». Combinez l'architecture des composants avec un riche ensemble d'outils de test et vous constaterez que Blazor offre une expérience de développeur productive qui ne ressemble à rien d'autre. Bien que ce dernier morceau puisse sembler sensationnel, ma dernière expérience le rend justifié.

Dans un effort pour en savoir plus sur l'accessibilité sur le Web, j'ai décidé d'expérimenter une idée. J'ai entrepris de créer un composant en utilisant le développement piloté par les tests (TDD), mais cette fois en mettant l'accent sur l'accessibilité. Bien que je ne pense pas que ce soit une idée particulièrement unique, j'ai eu du mal à trouver des ressources ou des conseils sur le sujet. Cependant, j'ai pu trouver quelques exemples génériques de meilleures pratiques pour guider le chemin.

Lorsque l'expérience a été terminée, j'avais un exemple complet qui a été soigneusement testé selon les spécifications. La meilleure partie était tout ce que j'ai appris sur l'accessibilité, la navigation au clavier et les composants de test unitaire. Dans cet article, je décrirai les concepts clés et les conclusions du processus et comment les appliquer dans votre prochaine application.

Blazor dispose d'un écosystème de test assez étendu qui comprend : bUnit, xUnit, Visual Studio et autres. Étant donné que Blazor est écrit à l'aide de .NET, certains de ces outils ont évolué au cours de la vie de la plate-forme, tandis que d'autres, comme bUnit, ont été nouvellement créés pour tester exclusivement les composants Blazor.

bUnit est une bibliothèque de test pour les composants Blazor. Son objectif est de faciliter l'écriture de tests unitaires complets et stables.

Citant directement le site Web bUnit« bUnit est une bibliothèque de test pour les composants Blazor. Son objectif est de faciliter l'écriture de tests unitaires complets et stables. bUnit est développé par un membre de la communauté .NET Egil Hansen et le projet est le standard de facto des tests unitaires de composants pour Blazor.

bUnit fonctionne avec des frameworks de test populaires tels que : xUnit, NUnit et MSTest . Ces frameworks configurent l'environnement de test, tandis que bUnit se concentre sur le rendu et la navigation des composants et leur balisage rendu.

Dans cette expérience, nous utiliserons xUnit et bUnit, avec l'ajout d'une troisième bibliothèque d'aide appelée FluentAssertions. FluentAssertions n'est pas nécessaire ici, mais il améliore considérablement la lisibilité du code de test en fournissant une syntaxe facile à suivre lors de l'écriture d'assertions.

L'installation, les instructions de configuration et la documentation sont faciles à trouver et à suivre sur le site Web de bUnit. Une fois le projet de test créé et configuré, les tests bUnit sont écrits en tant que composants Razor. Cette expérience de C# dans le balisage apporte un facteur de facilité d'utilisation aux tests de composants en éliminant presque le besoin d'échapper au HTML lors de la composition des tests.

Jetons un coup d'œil à un scénario de test simple dans le code ci-dessous. Les tests peuvent être exécutés avec Visual Studio ou la commande CLI dotnet test. Nous allons prendre un composant simple qui restitue une balise h3 avec du texte, et nous appellerons ce composant à tester Example.razor.

Example.razor[19659013]Example

Pour tester le composant, nous allons créer un appareil de test appelé Example_Tests.razor. Il utilisera également l'extension .razor pour pouvoir utiliser la syntaxe razor. Nous pouvons éventuellement hériter de TestContextce qui nous donne un accès rapide aux API de test.

Ensuite, nous utiliserons xUnit pour définir un Factun type de méthode de test. Ensuite, le composant à tester (cut) est rendu par bUnit en utilisant la méthode Render. Une fois rendu, nous pouvons affirmer que le balisage du composant a été rendu correctement en appelant MarkupMatches.

Example_Tests.razor

@inherits TestContext
@code {

    [Fact]
    public void ShouldRunTests()
    {
        var ctx = Rendu(@);
        ctx.MarkupMatches(@
Exemple
);
    }
}

C'est le principe de base du test avec bUnit. Plus tard, nous utiliserons des techniques plus avancées pour affirmer des valeurs d'attribut HTML spécifiques et déclencher des événements de composant. Par exemple, nous pouvons utiliser bUnit et FluentAssertions pour valider l'id d'un bouton à l'aide de l'instruction ci-dessous.

// Cette div a-t-elle l'identifiant attendu ?
cut.Find("div").Id.Should().Be(value);

Maintenant que nous sommes prêts à écrire des tests, nous devons définir la spécification de notre composant.

Spécification du composant

Créer une spécification pour un composant en mettant l'accent sur l'accessibilité est la partie la plus importante du processus . La spécification va dicter tout ce qui va se passer ensuite, elle doit donc être aussi détaillée que possible.

Le vrai défi ici est de trouver des conseils d'experts si vous (comme moi) n'êtes pas un expert en accessibilité. L'utilisation incorrecte d'éléments sémantiques et d'attributs ARIA peut en fait faire plus de mal que de bien, il est donc important d'être conscient des nuances des technologies d'assistance et de la façon dont elles interprètent les balises et les attributs HTML.

Un bon point de départ si vous en apprenez davantage sur l'accessibilité est WAI-ARIA Authoring Practices by the W3C Working Group . Dans ce document, vous trouverez les spécifications d'un composant accordéonqui sont utilisés dans cette expérience. Les spécifications décrivent un plan détaillé pour la mise en œuvre des attributs de rôle, de propriété, d'état et de tabindex appropriés, ainsi que la prise en charge du clavier. Les tableaux suivants sont inclus sur le site Authoring Practices.

Role, Property, State and Tabindex Attributes

Prise en charge du clavier.

Notre expérience

Pour avoir une idée de quoi est en cours de construction et de test dans cette expérience, voir le Blazor REPL interactif intégré ci-dessous. Cet exemple représente le composant terminé selon les spécifications écrites dans Blazor.

Avec la spécification décrite, l'étape suivante consiste à créer un fichier de test. Personnellement, j'aime utiliser la convention ComponentName_Tests.razormais n'hésitez pas à utiliser une pratique que vous aimez. Pour cet exemple, nous utiliserons AriaAccordion_Tests.razor. Dans le nouveau test, nous allons configurer un appareil de test, puis copier la spécification directement à l'intérieur sous forme de commentaires.

AriaAccordion_Tests.razor

@inherits TestContext
@code {

    // Tests d'attributs
    
    // Élément qui sert d'en-tête d'accordéon.
    // Chaque élément d'en-tête accordéon contient un bouton qui contrôle la visibilité de son panneau de contenu.
    // L'exemple utilise le niveau d'en-tête 3 afin qu'il s'intègre correctement dans le contour de la page ; l'exemple est contenu dans une section intitulée avec un titre de niveau 2.
    
    // bouton aria-expanded="true"
    // Défini sur true lorsque le panneau Accordéon est développé, sinon défini sur false.
    
    ... les spécifications ont continué
    
    // Finir
    // Lorsque le focus est sur un en-tête d'accordéon, déplace le focus vers le dernier en-tête d'accordéon.
}

Tests de rendu

Comme pour tout processus TDD, il y a un peu un moment de poule et d'œuf où les tests doivent être définis, mais il n'y a rien à tester. Selon la façon dont votre processus est piloté par les tests, vous souhaiterez peut-être écrire des tests avant de définir des composants.

Actuellement, nous avons un appareil de test vide avec 13 spécifications d'accessibilité. Ces spécifications ne suffisent pas à elles seules pour commencer – nous aurons également besoin d'un balisage de base pour le rendu. À ce stade, nous avons suffisamment d'informations pour écrire un test de balisage attendu avant de passer à des tests plus ciblés. C'est un peu un exercice d'équilibrage lorsque nous soustrayons le composant et ses sous-composants pour atteindre certaines fonctionnalités de base.

C'est un peu un exercice d'équilibrage lorsque nous soustrayons le composant et ses sous-composants pour atteindre certaines fonctionnalités de base.

Commençons par la structure HTML de base fournie dans la spécification . À l'aide du code HTML, nous allons créer deux composants : AriaAccordion et AccordionPanel. Les composants sont ajoutés au projet pour servir de blocs de construction de base. Leur utilisation est décrite dans l'extrait ci-dessous.

Utilisation des composants

  
    
Mon contenu pour le panneau A
  
  
    
Mon contenu pour le panneau B
  

Voir un exemple entièrement interactif ci-dessous utilisant Telerik REPL pour Blazor.

Notre premier test unitaire validera l'état de rendu initial du composant. Pour cela, nous allons écrire un test qui utilise Render et MarkupMatches.

[Fact]
public void FirstRenderMarkupCorrect()
{
    var cut = Render(@
                     
                       
Contenu P1
                     
                     
                       
Contenu P2
                     
                   );
                
    cut.MarkupMatches(
    @

    

        
            P1
                
            
        
    
    

        

            
Contenu P1
        
    
   ... html du deuxième panneau
);

Maintenant que nous avons un test fonctionnel et des composants, nous pouvons commencer à ajouter des fonctionnalités.

Tests d'attributs

Lors de la rédaction de nos tests, nous allons travailler sur les éléments dans un ordre logique. Dans le cas de notre accordéon, nous avons besoin de fonctionnalités pour développer et réduire les panneaux avant que d'autres fonctionnalités puissent être prises en compte. Commençons par la spécification de aria-expanded car elle est directement liée à la fonctionnalité que nous devons implémenter en premier.

Pour cette spécification, nous allons d'abord mettre à jour notre test FirstRenderMarkupCorrect pour inclure l'état par défaut de deux panneaux lorsqu'ils sont rendus pour la première fois. Cela garantira qu'un nouvel accordéon sera rendu dans l'état par défaut attendu avant que les modifications ne soient appliquées. L'assertion MarkupMatches est mise à jour de sorte que le premier bouton a l'attribut aria-expanded="true"et le deuxième panneau a l'attribut hidden.

cut.MarkupMatches(@

    ... html du premier panneau
    
    ... html du deuxième panneau
    
        ...);


Nous devons nous assurer que les relations entre les éléments sont formées lorsque le composant est rendu et qu'elles renvoient les attributs id corrects avec les attributs aria appropriés. Dans les tests suivants, nous allons configurer un accordéon à panneau unique en tant que coupe. Ensuite, nous allons localiser la valeur de l'attribut aria de l'élément et la comparer à la valeur de l'attribut id de l'élément respectif. L'assertion fluide Should().Be() est utilisée pour effectuer la comparaison.
// bouton aria-controls="ID"
[Fact(DisplayName = 
    "aria-controls=ID Points to the ID of the panel which the header controls.")]
public void AriaControlsAttribute()
{
    RenderTree.Add();

    var cut = Render(@CONTENU);
    
    var buttonControlsId = cut.Find("button").GetAttribute("aria-controls");
    // div.id == button.aria-controls
    cut.Find("div").Id.Should().Be(buttonControlsId);
}
Les deux tests fonctionnent de la même manière, mais les relations sont inversées.
// aria-labelledby="IDREF" div
[Fact(DisplayName = 
    "aria-labelledby=IDREF References the accordion header button that expands and collapses the region.")]
public void AriaLabelledByAttribute()
{
    RenderTree.Add();

    var cut = Render(@CONTENU);

    var divLabelledById = cut.Find("div").GetAttribute("aria-labelledby");
    // button.id == div.aria-labeledby
    cut.Find("bouton").Id.Should().Be(divLabelledById);
}
 Une observation importante avec ces tests est qu'ils n'ont aucun impact visuel sur le composant ou son fonctionnement. Pour effectuer ces tests manuellement, un lecteur d'écran est nécessaire.
 Une fois ces tests réussis, nous pouvons passer à la mise en œuvre de la navigation au clavier. Le code du composant peut être vu ci-dessous.
Tests de navigation au clavier
Cette section de test garantira que le composant accordéon est facilement navigué avec un clavier. L'accessibilité du clavier est l'un des aspects les plus importants de l'accessibilité Web. Les utilisateurs ayant des besoins moteurs s'appuient sur un clavier. Cela inclut les personnes ayant une utilisation limitée de leurs mains et les utilisateurs avec des claviers modifiés ou tout autre matériel qui imite la fonctionnalité d'un clavier. Les utilisateurs malvoyants utilisent également souvent un clavier pour la navigation.
 La première spécification est un point d'intérêt. La spécification définit l'interaction pour une touche Espace ou Entrée lorsqu'un en-tête d'accordéon a le focus. Dans le navigateur, le comportement par défaut des boutons et de certaines entrées est de déclencher un événement onclick. Parce qu'il s'agit du comportement inhérent et que nous n'avons pas ajouté de code pour gérer ces touches spécifiquement, elles effectueront leur action par défaut.
 De plus, bUnit fonctionne avec un balisage rendu, et les comportements de navigateur par défaut comme celui-ci ne sont pas unit- testable. Au lieu d'écrire un test unitaire, nous devrions reporter ce test à un test d'interface utilisateur fonctionnel basé sur un navigateur avec un outil comme Telerik Test Studio.
Similaire à Space et Enterles spécifications Tab et Shift + Tab appellent le comportement par défaut du navigateur. Les valeurs par défaut semblent être quelque chose que nous pouvons simplement ignorer. Cependant, nous devrions toujours nous en remettre aux tests fonctionnels pour couvrir ces éléments. Bien que nous n'ayons pas l'intention de modifier ces comportements, il est toujours possible que notre code ou notre balisage interrompe involontairement l'action par défaut.
Un tel exemple est lorsque l'attribut tabindex est utilisé. Même l'utilisation correcte de tabindex peut provoquer des effets secondaires qui ont un impact sur la navigation dans l'interface utilisateur des composants voisins.
Même une utilisation correcte de tabindex peut entraîner des effets secondaires qui ont un impact sur la navigation dans l'interface utilisateur des composants voisins.[19659007] Le prochain ensemble de spécifications de clavier n'est pas un comportement par défaut et nécessite un développement supplémentaire pour être mis en œuvre. Les touches flèche vers le haut et flèche vers le bas sont utilisées pour naviguer dans les en-têtes d'accordéon et effectuer un comportement de « bouclage » lorsque le haut et le bas des panneaux sont mis au point. Étant donné que nous allons attacher un gestionnaire d'événements onkeydown à ces éléments, ils peuvent être testés avec bUnit.
 De plus, nous allons définir le focus sur un élément, mais cela comporte une mise en garde. Étant donné que bUnit teste un composant rendu, le focus se comporte différemment. Au lieu de vérifier si un élément  est focalisénous devrons vérifier si l'élément a été  focus. L'assistant JSInterop.VerifyFocusAsyncInvoke dans bUnit fournira un mécanisme pour affirmer si le focus a été donné à une référence d'élément.
// Flèche vers le bas
[Fact(DisplayName = 
    "When focus is on an accordion header, Down Arrow moves focus to the next accordion header.")]
public void DownArrowNavigation()
{
    var cut = RenderAccordionWithTwoPanels();
    var panels = cut.FindComponents();
    var bouton1 = panels[0].Find("bouton");
    var bouton2 = panels[1].Find("bouton");

    button1.KeyDown(Key.Down);

    // Focus a-t-il été appelé, contenait-il un argument pour le bon élément ?
    JSInterop.VerifyFocusAsyncInvoke().Arguments[0].ShouldBeElementReferenceTo(button2);
}
Ensuite, nous testons le comportement en boucle lorsque le dernier élément est mis au point.
[Fact(DisplayName = 
    "When focus is on last accordion header, Down Arrow moves focus to first accordion header.")]
public void DownArrowNavigationLoops()
{
    var cut = RenderAccordionWithTwoPanels();
    var panels = cut.FindComponents();
    var bouton1 = panels[0].Find("bouton");
    var bouton2 = panels[1].Find("bouton");

    button2.KeyDown(Key.Down);
    
    // Focus a-t-il été appelé, contenait-il un argument pour le bon élément ?
    JSInterop.VerifyFocusAsyncInvoke().Arguments[0].ShouldBeElementReferenceTo(button1) ;
}
Par souci de concision, les tests flèche vers le haut ne sont pas affichés car ils sont presque identiques aux tests flèche vers le bas.
Les derniers tests sont pour accueil et fin navigation au clavier. Ces tests sont également similaires aux tests flèche haut/bascependant la configuration est modifiée. Pour éviter tout faux positif, nous aurons besoin de plus de panneaux d'accordéon à tester. Si nous n'utilisons que deux éléments, il est possible que notre logique donne le focus vers le haut ou vers le bas d'un seul élément au lieu de passer directement au premier ou au dernier élément. Nous appellerons également keydown sur un élément du milieu pour nous assurer que les éléments sont ignorés lorsque l'événement focus est appelé.
// Accueil
[Fact(DisplayName = 
    "When focus is on an accordion header, Home moves focus to the first accordion header.")]
public void HomeNavigation()
{
    var cut = RenderAccordionWithFourPanels();
    var panels = cut.FindComponents();
    var bouton3 = panels[2].Find("bouton");
    var bouton1 = panels[0].Find("bouton");

    button3.KeyDown(Key.Home);
    
    // le bouton 3 a-t-il ignoré le focus sur le bouton 1 ?
    JSInterop.VerifyFocusAsyncInvoke().Arguments[0].ShouldBeElementReferenceTo(button1) ;
}
Par souci de concision, les tests clés end ne sont pas affichés car ils sont presque identiques aux tests clés home.
En utilisant ces tests, nous peut écrire le code composant restant. Une fois la navigation au clavier terminée, le composant est pleinement fonctionnel. Étant donné que nous avons une couverture de test complète pour notre composant, la refactorisation peut être effectuée sans se soucier de casser la fonctionnalité.
Cet exemple représente le composant terminé aux spécifications, y compris la navigation au clavier, écrit en Blazor.
Réflexions finales
À travers ce processus, nous avons vu qu'une spécification bien définie peut grandement améliorer l'histoire de test de nos composants. En définissant les spécifications d'accessibilité à l'avance, nous pouvons tester nos composants pour de nombreuses fonctionnalités d'accessibilité à l'aide de TDD. Lorsque les tests intègrent une approche axée sur l'accessibilité, nous pouvons être sûrs que les composants répondront aux normes définies dans les spécifications. Les tests unitaires fournissent un test isolé avec une vérification rapide, qui est effectuée sans exécuter l'application.
 Le processus décrit ici présente certaines faiblesses. Tout d'abord, un expert doit être impliqué dans la rédaction de la spécification pour les fonctionnalités de navigation HTML, ARIA et clavier. Une utilisation incorrecte de ce qui précède peut provoquer des défauts dans l'interface utilisateur. De plus, la couverture des tests doit inclure des tests fonctionnels basés sur un navigateur. Les tests fonctionnels améliorent encore la couverture des tests en s'assurant que les comportements du navigateur sont comme prévu.
 Une dernière observation qui découle de ce processus est la complexité de l'accessibilité. Les composants doivent être construits avec une connaissance approfondie de l'accessibilité afin que les applications puissent être utilisées par tous les utilisateurs. Si vous n'êtes pas un expert et que votre équipe n'y a pas accès, une alternative consiste à utiliser des composants standard tels que  Telerik UI for Blazor qui intègrent déjà des fonctionnalités de clavier et d'accessibilité.[19659135]
 
 Le meilleur outil 2023 pour ta croissance Instagram ! 
 
 
 
   
 
Source link 
Partager :
Cliquez pour partager sur Twitter(ouvre dans une nouvelle fenêtre)
Cliquez pour partager sur Facebook(ouvre dans une nouvelle fenêtre)