Test d'accessibilité

Dans l'application Jutro, nous testons l'accessibilité (a11y) à l'aide de la bibliothèque jest-axe qui est encapsulée dans une fonction appelée checkA11yViolations. Nous traitons à ce titre les tests a11y comme une forme de test d'unité.

Que couvre jest-axe ?

La bibliothèque jest-axe ne couvre pas toutes les exigences des règles WCAG (Web Content Accessibility Guidelines), mais vérifie simplement les violations potentielles qui peuvent être vérifiées de manière automatisée. Elle couvre donc un sous-ensemble d'exigences WCAG.

Comme l'indique la bibliothèque jest-axe, ces tests ne garantissent pas que votre application soit accessible à 100 %. Elle analyse uniquement votre balisage et trouve les problèmes dans ce contexte.

Pourquoi exécuter des tests sur des pages ?

Nous exécutons le test sur une page avec un rendu complet. Cela permet de concilier efficacement couverture et charge de travail. L'exécution du test sur un composant individuel pourrait omettre certains problèmes qui n'apparaissent que dans un contexte donné.

Par exemple, le contenu d'un composant avec un arrière-plan transparent peut devenir illisible lorsqu'il apparaît au-dessus d'un composant avec un arrière-plan coloré.

D'un autre côté, la rédaction de tests a11y pour chaque état possible de chaque composant représenterait une charge de travail supplémentaire qui n'est probablement pas nécessaire.

Cela garantit-il que mon application est entièrement accessible ?

Les tests automatisés ne garantissent pas l'accessibilité de votre application. Nous vous recommandons vivement d'effectuer des tests manuels au clavier, avec et sans lecteur d'écran. C'est la seule façon d'optimiser la fiabilité de la qualité d'accès de la page avec un rendu complet.

De même, si vous implémenter un grand nombre d'animations personnalisées ou d'autres comportements imprévisibles, pensez à rédiger des tests pour couvrir certains cas supplémentaires.

Comment rédiger des tests d'accessibilité

Note: Lorsque vous testez des composants de page dans l'application Jutro, les composants doivent être encapsulés dans une balise main, sinon cette règle est violée. Dans une application Jutro type, les pages sont rendues dans un AppFloorPlan qui les encapsule dans main. La règle est donc respectée. L'exemple suivant montre comment le faire manuellement :

import { checkA11yViolations } from '@jutro/test';

it('has no a11y violations', async () => {
  checkA11yViolations(
    <main>
      <CodelessForm />
    </main>
  );
});

Si le test détecte des violations, il les imprime sur la console, ainsi qu'un lien vers des explications supplémentaires. Par exemple :

Personnalisation des tests jest-axe

jest-axe est personnalisable, ce qui vous permet de désactiver certains contrôles (globalement ou localement) et d'ajouter des contrôles personnalisés. Pour ce faire, importez et utilisez des utilitaires directement à partir de jest-axe.

Vous trouverez plus d'informations dans la documentation de jest-ax.

Test d'un bouton désactivé

Du point de vue de l'accessibilité, un utilisateur doit pouvoir accéder par tabulation à un bouton, même s'il est désactivé. Cela permet à l'utilisateur de voir qu'il y a un bouton sur lequel il peut cliquer une fois toutes les conditions remplies, par exemple une fois le formulaire rempli.

Notez qu'un bouton Jutro désactivé ne dit pas à l'utilisateur quelles sont les conditions pour l'activer. Tout ce que l'utilisateur sait, c'est que le bouton est « grisé » (sous Mac OS), ou quelque chose de similaire à cet effet. Nous suggérons ici que l'utilisateur peut déduire qu'il y a certaines conditions à remplir.

Par exemple, supposons que vous ayez le composant suivant qui contient trois boutons :

export default function ActionBar() {
  return (
    <>
      <Button>First button</Button>
      <Button>Second button</Button>
      <Button disabled>Third button (disabled)</Button>
    </>
  );
}

Pour tester cela, vous devez simuler la configuration qui active la tabulation sur les boutons désactivés.

Ajouter le fichier suivant en tant que src/__mocks__/@jutro/config.js. Cela vous permet d'utiliser les boutons désactivés dans les tests Jest.

src/__mocks__/@jutro/config.js

const actual = jest.requireActual('@jutro/config');

module.exports = {
  ...actual,
  getConfigValue: (path, defaultValue) => {
    if (
      path === 'accessibleDisabled.all' ||
      path === 'accessibleDisabled.button'
    ) {
      return true;
    }

    return actual.getConfigValue(path, defaultValue);
  },
};

Rédigez ensuite le test suivant :

import { render, screen } from '@jutro/test';
import userEvent from '@testing-library/user-event';
import ActionBar from 'components/ActionBar/ActionBar';

describe('Action Bar', () => {
  it('disabled button is not skipped when tabbing', async () => {
    render(<ActionBar />);
    const [firstButton, secondButton, disabledButton] =
      screen.getAllByRole('button');
    firstButton.focus();
    await userEvent.tab();
    expect(secondButton).toHaveFocus();
    await userEvent.tab();
    //after focusing on first button and pressing tab two times,
    // the last button (the disabled one) receives the focus
    expect(disabledButton).toHaveFocus();
  });
});