Das Konzept

Mithilfe von Adaptern werden die entstehende Anwendung und Komponenten, mit denen kommuniziert werden, logisch abgetrennt. Der Anwendungskern wird von den Schnittstellen entfernt und ist von diesen nicht abhängig – dadurch werden sie einfach austauschbar. Fangen wir mit der einfacheren Seite an – eine Schnittstelle ruft die Anwendung auf. Dies kann zum Beispiel über eine Oberfläche passieren:

In der Umsetzung kann man sich dies einfach vorstellen. Nehmen wir hierzu ein Java-Projekt mit Maven, welches eine Chatanwendung umsetzten soll. Angenommen, es gibt ein chat-core Modul. In diesem liegt unser Anwendungskern. Ein weiteres chat-ui Modul enthält die Webanwendung. Im Kern gibt es die Klasse UiPort, welche eine Methode sendMessage(String message) implementiert. Diese Methode kann nun vom Web-Adapter, welcher in dem UI-Modul liegt, aufgerufen werden. Damit ist der Adapter von dem Anwendungskern abhängig. Bei dieser Art von Schnittstelle spricht man von einem Primary Component (dt. primäre Komponente).

Sehen wir uns das ganze mal anhand einem Java EE-Beispiel an:

/* Diese Klasse ist im chat-core Modul */ 
@ApplicationScoped 
public class UiPort { 
  public void sendMessage(String message) { 
    // Aufruf der Kernlogik zum Nachrichtenversand ... 
  } 
}

/* Diese Klasse ist im chat-ui Modul */ 
@ApplicationScoped 
public class WebAdapter { 
  @Inject UiPort uiPort; // zur Laufzeit wird hier eine Instanz des UiPort eingefügt 
  
  public void enterPressed(String textField) { 
    uiPort.sendmessage(textField); 
  } 
}

In die andere Richtung wird es etwas spannender. Wir führen ein weiteres Modul chat-db ein, welches unsere Chatnachrichten verwalten soll. Würden wir hier wie eben vorgehen, hätte das zur Folge, dass unsere Anwendung von der Datenbank bzw. dessen Adapter abhängig wäre. Gemäß dem SOLID Prinzip Dependency-Inversion darf die Anwendung aber nicht von einer Komponente abhängig sein, selbst wenn diese die Komponente steuert (Inversion of Control).

Die Lösung: die Anwendung enthält den PersistencePort, ein Interface, welches von dem Anwendungskern aufgerufen wird. Dieser enthält die Methode storeMessage(String message). Die Implementierung dieses Interfaces legen wir nun in den Adapter. Diese wird zur Laufzeit bereitgestellt – die Abhängigkeit besteht nun hier auch vom DB-Modul auf den Anwendungskern, da dort das zu implementierende Interface liegt. Der Adapter kommuniziert direkt mit der externen Schnittstelle, z.B. Hibernate mit MariaDB. In diesem Falle würde der Adapter auch für die Umwandlung der Anwendungsobjekten in Entitäten verantwortlich sein.

Um die Implementierung des Adapters ohne eine Abhängigkeit ausgehend vom Anwendungskern verwenden zu können, muss man auf Dependency-Injection oder eine Factory zurückgreifen. Im Java EE-Kontext kann man diese Injection wie folgt umsetzen:

/* Diese Klasse ist im chat-db Modul */ 
@ApplicationScoped 
public class PersistenceAdapter implements PersistencePort { 
  @Override 
  public void storeMessage(String message) { 
    // Logik für die Persistierung ... 
  } 
} 

/* Dieses Interface ist im chat-core Modul */ 
public interface IPersistencePort { 
  public void storeMessage(String message); 
} 

/* Diese Klasse ist im chat-core Modul */ 
@ApplicationScoped 
public class ChatController { 
  @Inject IPersistencePort persistencePort; // zur Laufzeit wird hier eine Instanz des PersistenceAdapter eingefügt 
  
  // hier kann der Port aufgerufen werden, um Nachrichten zu persistieren 
}

Wieso das Ganze?

Die beschriebene Trennung zwischen Anwendung und Komponenten bringt einige Vorteile mit sich:

• Komponenten außerhalb der Anwendung sind vollständig austauschbar. Welche Datenbank verwendet wird, und wie mit dieser kommuniziert wird, ist für die Anwendung nicht relevant.
• Im Falle von Komponenten, die die Anwendung aufrufen (sog. Driving oder Primary Components), können an einem Port mehrere Adapter (und Komponenten) existieren – so kann der UI-Port sowohl über einen Adapter für eine Webanwendung als auch einen Adapter für eine Mobilanwendung angesprochen werden.
• Änderungen an Adaptern beeinflussen die Anwendung nicht, und Änderungen an der Anwendung die Adapter nicht. Nur, wenn die Ports angepasst werden, sind beidseitig Änderungen notwendig.
• Die Anwendung sowie die einzelnen Adapter sind leichter testbar – Testframeworks können einfach einen Adapter oder die Anwendung simulieren, um jeweils das Gegenstück in einer Testumgebung zu testen

Das ist auch schon alles – zumindest in sehr grundlegender Ausführung. Der wahre Umsetzungsaufwand der hexagonalen Architektur entsteht durch das Mapping und dem Erstellen von guten(!) Ports.

Die Adapter benötigen die Daten oft in einem anderen Format, als es von der Anwendung bereitgestellt wird – Objekte müssen für die Datenbank in Entitäten umgewandelt werden, welche in Tabellen persistiert werden können. Eine REST-API arbeitet mit JSON-Objekten, welche zunächst in für die Anwendung verwendbare Objekte umgewandelt werden müssen, und in der Regel ebenfalls eine Umwandlung in die andere Richtung für Antworten der Anwendung.

Geben die Ports den Adaptern zu sehr die Umsetzung vor, kann es wesentlich schneller notwendig sein, diese anzupassen, sobald sich ein Adapter oder die Anwendung verändert. Die Kunst liegt darin, enge Kopplung zu vermeiden, und zukunftsfähige Ports zu entwerfen.

Die Variante der Onion-Architektur

Nun sind Dir die Grundlagen der Ports und Adapters bzw. Hexagonalen Architektur bekannt. Zugleich hast Du nun aber auch fast alle Bausteine der Onion-Architektur gelernt – diese baut nämlich effektiv auf die hier beschriebene Architektur auf, nur dass sie außerdem noch in den Anwendungskern selbst blickt:

Auch hier wird nur die Regel der nach innen zeigenden Dependencies angewandt: Kern-Komponenten (die Domain – grundlegende Elemente wie ein Kunde oder Artikel) der Anwendung haben keine Abhängigkeiten auf die Domain-Services (Logik mit mehreren Objekten aus der Domain – beispielsweise Bestellungen). Diese wiederum haben keine Abhängigkeiten auf die Services der Anwendung, welche Use Cases umsetzen und mit unseren Ports sprechen können.

Die Verknüpfung von Architekturkonzepten kann weitergesponnen werden, indem weitere Konzepte zugezogen werden. Hierzu eine Leseempfehlung: DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together von Herberto Graça – praktisch ein All-Inclusive Modell.

Schlusswort

Ports und Adapters und ihre Verwandten präsentieren einen seriösen Ansatz, wie eine Anwendung sauber aufgebaut werden kann. Das Ganze ist jedoch mit Vorsicht zu genießen: mit der Architektur entsteht signifikanter Umsetzungsaufwand, und kommt nur in mittelgroßen bis großen Anwendungen infrage – wobei letztere möglicherweise mehr von einer dem Anwendungsfall angepassten Variante profitieren. Und wenn die Anwendung mit diesem Konzept umgesetzt werden soll, dann bitte richtig. Nehmt Euch die Zeit, sinnvolle Schnittstellen zu entwerfen, denn das ist eine ganz eigene Philosophie.

Um die Qualität von Software zu gewährleisten, ist ausgiebiges Testen unabdingbar. Idealerweise sollte dazu das Testen bereits von Anfang an in den Entwicklungsprozess integriert werden, um bereits früh Fehler zu identifizieren. Zum Testen von Software gibt es eine Reihe an Möglichkeiten, angefangen bei Unit-Tests zum Testen kleinster Einheiten, über Component und Integration Tests bis hin zum Testen einer Anwendung als Einheit durch End-To-End-Tests (E2E). In der Testlandschaft hat sich dabei ein Framework positioniert, das durch seine Vielseitigkeit überzeugt: Nightwatch.js.

Was ist Nightwatch.js?

Nightwatch.js ist ein Open-Source Projekt, das seit 2014 existiert. Es handelt sich dabei um ein Framework für automatisiertes E2E-Testing, das auf Node.js basiert. Allerdings bietet dieses ebenfalls die Möglichkeit, Unit-, Component- oder Integrationstests zu schreiben.

Mit Nightwatch lassen sich Webanwendungen, Webseiten sowie mobile Applikationen unter Android und iOS testen. Für letztere bedient sich Nightwatch dem Framework Appium, welches ebenfalls der Automatisierung von Tests dient.

Tests lassen sich in allen gängigen Browsern (Chrome, Firefox, Safari und Edge) durchführen. Dazu folgt Nightwatch der WebDriver-Spezifikation des World Wide Web Consortium (W3C), welche einen Standard für das Automatisieren von Browsern darstellt und auf HTTP basiert. Mittels WebDrivern erfolgt die Kommunikation zur Interaktion mit dem Browser, um Tests durchzuführen.

Was bietet Nightwatch alles?

Test-Runner: Mit dem Test-Runner für die Kommandozeile bietet Nightwatch eine einfache Möglichkeit, um Tests auszuführen. Gleichzeitig ermöglicht dies die reibungslose Integration in automatisierte Build- und Deploy-Prozesse.

Parallelisierung: Bei einer Vielzahl an Tests kann es dauern, bis diese sequentiell ausgeführt werden. Dies ist besonders mühsam, wenn eine Anwendung oder Webseite in verschiedenen Browsern getestet wird. Um dieses Problem zu umgehen, bietet Nightwatch Parallelisierung mittels der Integration von Selenium Grid an.

Cloud-Umgebungen: Ein weiterer Punkt ist die Ausführungsumgebung. Nightwatch ermöglicht die Verwendung von Cloud-basierten Testplattformen wie BrowserStack oder SauceLabs. Dadurch kann die zu testende Anwendung oder Webseite in Browserinstanzen in der Cloud getestet werden, sodass lokal keine Testumgebungen erforderlich sind.

Weitere Testarten: Wie bereits erwähnt ermöglicht Nightwatch von E2E bis Unit alle Arten von Testmöglichkeiten. Darüber hinaus bietet das Framework ebenfalls Funktionalität für die folgenden spezifischen Testmöglichkeiten:

Wie ist Nightwatch zu verwenden?

Bei der Verwendung von Nightwatch.js spielt die präzise Auswahl von Elementen eine entscheidende Rolle, um diese Testen zu können. Selektoren ermöglichen es, spezifische HTML-Elemente auf Webseites und in Anwendungen zu identifizieren und mit diesen zu interagieren. Nightwatch.js unterstützt verschiedene Arten von Selektoren, darunter:

• HTML/CSS-Selektoren ermöglichen das Selektieren über Klassen, IDs, HTML-Tags sowie Verschachtelungen beziehungsweise Vater-Kind-Beziehungen
• XPath-Selektoren ermöglichen das Selektieren von Nodes aus XML-Dokumenten
• textbasierte Selektoren ermöglichen die Suche nach Texten für verschiedene UI-Elemente wie beispielsweise Labels, Bilder oder Formularfelder

Selektierte Elemente können auf verschiedenste Arten manipuliert werden, wie beispielsweise das Klicken von Buttons oder das Eintragen von Texten in Formularfeldern. Damit sind mit Nightwatch unzählige Tests denkbar.
Falls die von Nightwatch vorgegebenen Kommandos nicht ausreichen sollten, bietet das Framework zusätzlich die Möglichkeit, eigene Kommandos zu definieren.

Um sicherzustellen, dass die Funktionalitäten der Anwendung wie beabsichtigt funktionieren, kann mittels Assertions festgelegt werden, welche Ergebnisse/Zustände zu erwarten sind. Dazu integriert Nightwatch das Assertion Framework chai.js, womit die Keywords expect, should und assert zur Verfügung stehen. Gleichzeitig bietet chai.js einen sogenannten BDD-Codestil¹, welcher durch seine Verkettung von Füllwörtern nah an menschenlesbare Sprache herankommt und somit die Lesbarkeit und Verständlichkeit verbessert: browser.expect.element('#main').to.be.present;

¹ BDD steht für Behavior Driven Development und stellt einen Ansatz in der agilen Softwareentwicklung dar, der u.a. das Verwenden von menschenlesbaren Beschreibungen von Softwareanforderungen beinhält. Für mehr Informationen siehe https://www.chaijs.com/api/bdd/

Der Nightwatch-Inspektor

Ein einzigartiges Feature von Nightwatch stellt der Nightwatch-Inspektor dar. Mit diesem lassen sich die einzelnen Elemente von Webseiten untersuchen, ähnlich wie mit Entwicklertools von Browsern. Im sogenannten Explore Mode kann ein spezifisches Element angeklickt werden. Zu dem ausgewählten Element wird daraufhin im Inspektor ein Selektor angezeigt, der das Element identifiziert. Dies erleichtert es dem Entwickler, das gewünschte, zu testende Element zu benennen. Zudem besitzt der Inspektor ein Konsolenfeld mit Autocompletion, in dem sich Kommandos ausführen lassen. Mit dem zuvor ermittelten Selektor eines Elements lassen sich so entweder Informationen zu dem gewünschten Element abrufen oder das Element direkt manipulieren. Das Ergebnis der Manipulation wird dem Nutzer angezeigt. Der Inspektor von Nightwatch stellt somit eine Einstiegshilfe dar und bietet Zeitersparnis, was besonders für Anfänger attraktiv sein dürfte.

Setup von Nightwatch

Die Voraussetzung, um Nightwatch zu verwenden, ist eine aktuelle Version von Node. Wenn dies gegeben ist, sehen die Schritte zum Aufsetzen eines Nightwatch-Projekts wie folgt aus:

npm init nightwatch <dir>

? Select testing type to setup for your project: End-to-End testing
? Select language + test runner variant: TypeScript / default
? Select target browsers: Chrome, Firefox, Edge
? Enter source folder where test files are stored: testfiles
? Enter the base_url of the project: http://localhost
? Select where to run Nightwatch tests: On localhost

Daraufhin werden lediglich alle benötigten packages installiert sowie Dateien angelegt, bevor das Setup abgeschlossen ist. Darunter befinden sich auch Beispieltests, welche direkt im Anschluss ausgeführt werden können. Die Testergebnisse werden grafisch aufbereitet in der Konsole dargestellt.

Selenium

Selenium stellt zunächst ein Framework zur Automatisierung von Browsern dar. Den häufigsten Anwendungsfall stellt dabei die Automatisierung für Testzwecke dar. Selenium entstand 2004 und ist wie Nightwatch ebenfalls Open Source.

Initial geschrieben für JavaScript, unterstützt Selenium heute viele Sprachen, darunter Java und Python. Der Entwickler hat mit Selenium also die Freiheit, sich eine Sprache auszusuchen, mit der er gut zurecht kommt.

Was einst als TestRunner für JavaScript begann, hat sich zu einem umfassenden Ökosystem entwickelt. Mit der Weiterentwicklung entstanden neben der Test-API (Selenium Core) weitere Projekte wie das Browser Add-on Selenium IDE zum Aufnehmen von Tests, Selenium Server/Grid für verteilte, parallelisierte Tests oder auch der Selenium WebDriver, der für alle gängigen Browser funktioniert. Das macht Selenium zu einem starken Tool, welches sich in der Praxis bewiesen hat. Doch wie kommt Nightwatch hier ins Spiel?

Wichtig zu verstehen ist, dass Selenium kein Testframework ist, es ermöglicht lediglich die Automatisierung von Browsern. Aus diesem Grund listet Selenium auf seiner offiziellen Webseite eine Reihe an Testframeworks auf, die mit Selenium verwendet werden können, dazu gehört auch Nightwatch.js.

Fazit

Nightwatch zeichnet sich durch seine Benutzerfreundlichkeit und Vielseitigkeit aus. Es ermöglicht das Durchführen einer breiten Palette von Tests, angefangen bei End-to-End-Tests bis hin zu Unit-Tests, und das in unterschiedlichen Umgebungen, sei es mobil oder im Web. Zusätzlich ermöglicht Nightwatch verschiedene Testmöglichkeiten, darunter Accessibility-Tests, visuelle sowie API-Tests.
Außerdem besonders hervorzuheben ist der Nightwatch-Inspektor, der das Identifizieren und Manipulieren von Testelementen im Web erheblich erleichtert.
Darüber hinaus punktet Nightwatch durch die Integration von Selenium Grid für Parallelisierung sowie die Möglichkeit, das Framework mit Cloud-basierten Testplattformen wie BrowserStack und SauceLabs zu verwenden.

Insgesamt präsentiert sich Nightwatch als ein robustes Test-Framework, das umfassende Testmöglichkeiten bietet und sowohl für erfahrene Entwickler als auch für Anfänger attraktiv ist. Nightwatch bietet seine eigene Implementierung des WebDrivers, kann aber durchaus mit Selenium verwendet werden, um Anwendungen und Webseiten automatisiert zu testen.

Mit der zunehmenden Digitalisierung werden Webseiten und Anwendungen zu den zentralen Vermittlern von Informationen. Dabei bieten die Sprachen HTML und CSS, die als Grundbaustein für den Aufbau von Webseiten dienen, großen Spielraum für Gestaltung. Diese Freiheit ermöglicht es allerdings, unsemantische Layouts zu erzeugen, die vor allem eine Herausforderung für Menschen darstellen, die auf assistive Technologien, sei es in Form von Soft- oder Hardware, angewiesen sind. Sofern beim Gestalten von Webinhalten diese Problematik nicht berücksichtigt wird, wird mit hoher Wahrscheinlichkeit die Navigation und Interpretation dieser erschwert und schlussendlich Nutzern der Zugang zu Informationen behindert.
So sind öffentliche Stellen in der EU heute rechtlich verpflichtet, ihre Webseiten und digitalen Anwendungen barrierefrei zu gestalten. In Deutschland dienen das Gesetz zur Gleichstellung von Menschen mit Behinderungen (BGG) sowie die Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (BITV) als rechtliche Grundlagen.

Barrierefreiheit in der Informationstechnik ist allerdings kein rein inklusives Anliegen. Das Berücksichtigen von Aspekten wie semantischer Korrektheit oder auch hinreichender Farbkontraste gewährleistet den Zugang zu Informationen unabhängig von den individuellen Möglichkeiten der einzelnen Person.

In dieser Hinsicht stellt die Bibliothek KoliBri, die vom Informationstechnikzentrum Bund (ITZBund) entwickelt wurde, einen Lösungsansatz für das beschriebene Problem dar. Doch wie genau trägt KoliBri zur Problemlösung bei? Wie lässt sich die Bibliothek implementieren? Wie barrierefrei sind die Komponenten der Bibliothek?

Was ist KoliBri?

Das Akronym KoliBri steht für „Komponentenbibliothek für die Barrierefreiheit”. Die Bibliothek wurde unter Verwendung von TypeScript entwickelt und basiert auf den Leitlinien des World Wide Web Consortium (W3C), den Web Content Accessibility Guidelines (WCAG). Diese Richtlinien sind unabhängig von konkreten Implementierungen und Frameworks und bilden die Grundlage für die Umsetzung von Barrierefreiheit im Web. Zudem hat die Bibliothek den BITV-Test in einer an die Besonderheiten von Web-Komponenten angepassten Form implementiert, um die Barrierefreiheit dieser zu gewährleisten.

KoliBri verfolgt das Ziel, Web-Komponenten bereitzustellen, die ohne große Anpassungen von Grund auf barrierefrei sind.

Die Kompatibilität der Bibliothek ist dabei eines der primären Ziele. So ist sie kompatibel mit gängigen Geräten, Betriebssystemen und Browsern und kann in verschiedenen Umgebungen und Architekturen eingesetzt werden. Ob es sich um statische oder dynamische Webseiten mit oder ohne Frameworks handelt, spielt keine Rolle. Ebenfalls kann KoliBri unabhängig davon eingesetzt werden, ob das Rendern der Webseite vorab (Pre-Rendering), server- (SSR) oder clientseitig (CSR) erfolgt.

Wie funktioniert KoliBri?

KoliBri bietet eine Auswahl an Web-Komponenten, die atomare und wiederverwendbare HTML-Kompositionen darstellen und einfach in Webseiten und Anwendungen integriert werden können. Es handelt sich dabei um gängige UI-Elemente wie Buttons, Eingabefelder oder Dropdown-Menüs. Komponenten haben jeweils einen Namen, Attribute und eine Beschreibung. Sie folgen also einem klaren Muster, um Einheitlichkeit sowie Verständlichkeit zu garantieren. Jede Komponente ist nach der PascalCase-Konvention KolNameDerKomponente (oder alternativ nach KebabCase kol-name-der-komponente) benannt und wird wie ein gewöhnlicher HTML-Tag im Code verwendet. Mittels der Attribute lassen sich Komponenten individuell anpassen. Attribute besitzen stets die Form _attributName und können Werte zugewiesen bekommen (_attributName=”Wert”), um Inhalt, Form sowie (besonders relevant für interaktive Elemente) das Verhalten einer Komponente zu steuern.

Darüber hinaus sind diese Komponenten um gewöhnliche HTML-Tags wie <div> ergänzbar, welche durch zusätzliche Attribute wie slot=footer ihre Semantik erhalten. Ebenfalls lassen sich die bekannten ARIA-Attribute mit den gleichnamigen, durch einen Unterstrich versehenen KoliBri-Attribute (beispielsweise _ariaExpanded aus KoliBri für aria-expanded aus ARIA) weiterhin verwenden, sofern diese in der Bibliothek implementiert wurden.

Das folgende Code-Snippet demonstriert die Funktionsweise von Komponenten am Beispiel der Komponente KolAlert, deren Zweck die Darstellung von Hinweisen ist.

import React from 'react';
import { KolAlert } from "@public-ui/react";

export default function App() {
    return (
        <KolAlert _label="Hinweis" _type="info" _variant="card">
            <p className="m-0">
                Am Freitag, den 15.12.2024 steht die Anwendung von 06:00 bis 12:00 Uhr nicht zur Verfügung.
            </p>
        </KolAlert>
    );
};

Wie können Komponenten visuell gestaltet werden?

Das obige Beispiel zur Komponente KolAlert demonstriert, wie eine Komponente durch ihre Attribute manipuliert werden kann. Dazu stellt sich die Frage, inwiefern Komponenten visuell gestaltet werden können. Nur selten besitzen Komponenten Attribute, die eine visuelle Gestaltung dieser ermöglichen. Aber die visuelle Gestaltung von Webseiten spielt doch eine wesentliche Rolle bei der Benutzererfahrung?
Um die Probleme zu umgehen, die durch die mit CSS gegebenen Freiheiten entstehen können, bietet KoliBri den sogenannten KoliBri-Designer an. Dieses Tool ermöglicht es, beliebige Styleguides und Designs umzusetzen, ohne dabei Layouts zu erzeugen, die sich nicht mit der durch HTML vorgegebenen Semantik decken. So wird ermöglicht, dass mithilfe von assistiven Technologien die Nutzererfahrung sich nicht erheblich von der Erfahrung ohne solche unterscheidet.

Zudem sind in KoliBri bereits Mechanismen integriert, die unzureichende Farbkontraste vermeiden. So kann beispielsweise der Komponente Badge eine Hintergrundfarbe, allerdings keine Textfarbe zugewiesen werden. Die Textfarbe wird basierend auf der spezifizierten Hintergrundfarbe automatisch berechnet und gesetzt, um einen hinreichenden Farbkontrast zu gewährleisten. Dieses Merkmal, dass Komponenten nur begrenzt manipulierbar sind, um deren Barrierefreiheit zu gewährleisten, stellt ein Kernprinzip der Bibliothek dar.

KoliBri löst also die Probleme hinsichtlich der Barrierefreiheit, ohne Kompromisse bei der Gestaltungsfreiheit zu machen.

Wie kann man mit KoliBri entwickeln?

Besonders gut eignet sich KoliBri für JSX/TSX-basierte Frameworks wie React oder Solid, da hier die maximalen Möglichkeiten der Typ-Unterstützung und Autovervollständigung möglich sind. Für Frameworks mit eigenen Template-Sprachen wie Angular und Vue variiert die Unterstützung bei der Entwicklung.

Je nach Anwendungsgebiet und vorliegender Architektur sehen die Schritte zur Integration ein wenig anders aus. Für das Web-Framework React sind die folgenden Schritte notwendig:

npm i @public-ui/components @public-ui/themes @public-ui/react

import React from 'react';
import ReactDOM from 'react-dom';

import { AppComponent } from './components/app/component';

import { register } from '@public-ui/core';
import { defineCustomElements } from '@public-ui/components/dist/loader';
import { DEFAULT } from '@public-ui/themes';

register(DEFAULT, defineCustomElements)
    .then(() => {
        const htmlDivElement: HTMLDivElement | null = document.querySelector<HTMLDivElement>('div#app');
        if (htmlDivElement instanceof HTMLDivElement) {
            const root = createRoot(htmlDivElement);
            root.render(<AppComponent />);
        }
    })
    .catch(console.warn);

import React from 'react';
import { KolSpin } from '@public-ui/react';

export default function Spinner({show}: {show: boolean}) {
    return (
        <KolSpin _show={show} />
    );
};

Für Informationen zu einzelnen Komponenten bietet KoliBri eine umfassende Dokumentation aller verfügbaren Komponenten. Hierdurch erhält der Entwickler Einblicke in:

• den Zweck jeder Komponente
• eine Erklärung zur Funktionsweise
• die Dokumentation aller Attribute
• die visuelle Darstellung
• die Abhängigkeiten zu anderen Komponenten

Testen der Komponenten

Das ITZBund-interne Barrierefreiheitstestteam prüft die Barrierefreiheit von Komponenten durch verschiedene Testmethoden. Dazu gehören unter anderem Unit-Tests, Snapshot-Tests und visuelle Screenshot-Tests. Das Testvorgehen basiert dabei auf einer angepassten Form des BIK BITV-Tests.

So sind Komponenten in der Regel bereits getestet, allerdings kann es vorkommen, dass Tests noch ausstehen.
Die Dokumentation der Komponenten enthält teilweise Informationen darüber, ob einzelne Komponenten nach den Anforderungen des Testvorgehens als vollständig barrierefrei gelten beziehungsweise falls nicht, welche Mängel sie aufweisen. Zudem gibt es eine Liste mit Testergebnissen.

Es ist also davon auszugehen, dass die Komponenten der KoliBri-Bibliothek hinreichend barrierefrei sind. Um die Barrierefreiheit jedoch selbstständig sicherzustellen, bieten sich für Entwickler verschiedene Möglichkeiten.
Neben (meist kostenpflichtigen) Drittanbieter-Services stehen Entwicklern vermehrt kostenlose Tools wie WAVE zur Verfügung, um Barrieren auf Webseiten automatisiert zu erkennen und zu kategorisieren. Im Vergleich zum manuellen Testen mit Checklisten und assistiven Technologien überzeugen automatisierte Tests durch den erheblich verringerten Arbeitsaufwand, um Mängel in der Barrierefreiheit zu ermitteln, wenngleich sie gegebenenfalls nicht so gründlich sind.

Auf Anregung von Janis von Bleichert von experte.de möchten wir zudem den deutschsprachigen Barrierefreiheits-Test von experte.de erwähnen. Der Test überzeugt durch eingebautes Crawling, wodurch sich eine Webseite in nur einem Schritt vollständig auf Barrierefreiheit prüfen lässt.
Zuletzt sei zu erwähnen, dass sich ein Blick auf die Liste der Web Accessibility Initiative lohnt, um einen Überblick über verschiedenste Test-Tools zu gewinnen und eine geeignete Wahl zu treffen.¹

¹Die W3C arbeitet aktuell an einer Aktualisierung der Liste. (Stand November 2023)

Fazit

Die Webseite von React bietet einen Guide für den Umgang mit Barrierefreiheit in React-Projekten an. Obwohl keine aktuelle Version des Artikels gefunden werden konnte, beschreibt der Leitfaden viele Praktiken, die nicht spezifisch für das Framework sind, sondern allgemeine Empfehlungen zur Gewährleistung der Barrierefreiheit von Webseiten darstellen. So verweist der Artikel zu Beginn auf die Bedeutung der WCAG, der ARIA-Attribute als Ergänzung zu HTML sowie die Verwendung von semantischem HTML.

Wie lässt sich Barrierefreiheit im Web umsetzen? Dies kann aufgrund der Vielzahl von Problemen und Ansätzen nicht so konkret definiert werden. KoliBri nimmt einem die Notwendigkeit ab, den Überblick über all diese verschiedenen Punkte zu behalten. Die Bibliothek unterstützt den Entwickler, indem sie diesem Komponenten vorgibt. Durch die Typisierung von Attributen oder Vorgaben, welche Attribute verpflichtend mit Werten zu befüllen sind, stellt KoliBri die Funktionalität und Barrierefreiheit der Komponenten sicher.

Angesichts der Tatsache, dass KoliBri vom ITZBund, dem IT-Dienstleister der deutschen Bundesverwaltung, entwickelt wurde, kann angenommen werden, dass die Bibliothek die Anforderungen an Barrierefreiheit von Webseiten in hohem Maße erfüllt. Dies ist in der gesetzlichen Verpflichtung begründet, die öffentliche Stellen haben, ihre Webseiten barrierefrei zu gestalten.