Prüfung der Barrierefreiheit

In der Jutro-App testen wir die Barrierefreiheit (a11y) mit der jest-axe-Bibliothek, die in einer Funktion namens checkA11yViolations enthalten ist. In diesem Sinne behandeln wir a11y-Tests als eine Form von Unit-Test.

Was wird durch jest-axe abgedeckt?

Die jest-axe-Bibliothek deckt nicht alle Anforderungen der Richtlinien für die Barrierefreiheit von Web-Inhalten (WCAG) ab, sondern prüft vielmehr auf potenzielle Verstöße, die durch Automatisierung überprüft werden können. Sie deckt also eine Teilmenge der WCAG-Anforderungen ab.

Wie die jest-axe-Bibliothek angibt, garantieren diese Tests nicht, dass Ihre Anwendung zu 100 % barrierefrei ist. Diese Bibliothek analysiert nur Ihr Markup und ermittelt in diesem Kontext auftretende Probleme.

Warum Tests für Seiten durchführen?

Wir führen den Test auf einer vollständig gerenderten Seite durch. Dadurch wird ein ausgewogenes Verhältnis zwischen Deckung und Arbeitsauslastung hergestellt. Beim Ausführen des Tests an einer einzelnen Komponente könnten einige Probleme übersehen werden, die nur im Kontext auftreten.

So kann beispielsweise der Inhalt einer Komponente mit transparentem Hintergrund unlesbar werden, wenn er über einer Komponente mit farbigem Hintergrund erscheint.

Andererseits würde das Schreiben von a11y-Tests für jeden möglichen Zustand jeder Komponente eine Menge zusätzlicher Arbeit bedeuten, die höchstwahrscheinlich nicht notwendig ist.

Ist damit garantiert, dass meine Anwendung vollständig barrierefrei ist?

Automatisierte Tests garantieren nicht, dass Ihre App barrierefrei ist. Es wird dringend empfohlen, manuelle Tastaturtests sowohl mit als auch ohne Screenreader durchzuführen. Nur so kann das Vertrauen in die barrierefreie Qualität der vollständig gerenderten Seite erhöht werden.

Wenn Sie viele benutzerdefinierte Animationen oder andere unvorhersehbare Verhaltensweisen implementieren, sollten Sie auch Tests schreiben, um einige zusätzliche Fälle abzudecken.

So schreiben Sie Barrierefreiheitstests

Note: Wenn Sie Seitenkomponenten in der Jutro-App testen, müssen die Komponenten in ein main-Tag eingeschlossen sein, da sonst gegen diese Regel verstoßen wird. In einer typischen Jutro-App werden Seiten in einem AppFloorPlan gerendert, der sie in main umschließt, sodass die Regel nicht verletzt wird. Das folgende Beispiel zeigt, wie dies manuell erledigt werden kann.

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

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

Wenn der Test Verstöße feststellt, werden diese auf der Konsole ausgegeben, zusammen mit einem Link zu weiteren Erläuterungen. Beispiel:

Anpassung von jest-axe-Tests

jest-axe ist anpassbar, sodass Sie einige Prüfungen (global oder lokal) deaktivieren und benutzerdefinierte Prüfungen hinzufügen können. Importieren und verwenden Sie dazu Dienstprogramme direkt aus jest-axe.

Weitere Informationen finden Sie in der jest-axe-Dokumentation.

Testen einer deaktivierten Schaltfläche

Unter dem Gesichtspunkt der Barrierefreiheit muss ein Benutzer in der Lage sein, mit der Tabulatortaste zu einer Schaltfläche zu wechseln, auch wenn diese deaktiviert ist. So kann der Benutzer sehen, dass es eine Schaltfläche gibt, auf die er klicken kann, wenn alle Bedingungen erfüllt sind, z. B. wenn das Formular vollständig ausgefüllt ist.

Beachten Sie, dass eine deaktivierte Jutro-Schaltfläche dem Benutzer nicht mitteilt, welche Bedingungen erfüllt sein müssen, um sie zu aktivieren. Alles, was der Benutzer weiß, ist, dass die Schaltfläche „abgeblendet“ ist (in Mac OS) oder etwas Ähnliches. Wir schlagen hier vor, dass der Benutzer daraus schließen kann, dass es einige Bedingungen gibt, die erfüllt werden müssen.

Nehmen wir zum Beispiel an, Sie haben die folgende Komponente, die drei Schaltflächen enthält:

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

Um dies zu testen, müssen Sie die Konfiguration simulieren, die das Navigieren mit der Tabulatortaste zu deaktivierten Schaltflächen ermöglicht.

Fügen Sie die folgende Datei als src/__mocks__/@jutro/config.js hinzu. Dadurch können Sie deaktivierte Schaltflächen in Jest-Tests verwenden.

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);
  },
};

Schreiben Sie dann den folgenden Test:

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();
  });
});