Praktische Barrierefreiheit in der Webentwicklung

Inhaltsverzeichnis

(This article is also available in English.)

Im Juli 2021 trat in Deutschland das Barrierefreiheitsstärkungsgesetz (BFSG) in Kraft, das den European Accessibility Act (EAA) umsetzt. Das BFSG definiert Anforderungen an die Barrierefreiheit von Produkten und Dienstleistungen, die nach dem 28. Juni 2025 auf den europäischen Markt kommen oder den Verbrauchern angeboten werden. Dazu gehören unter anderem der gesamte E-Commerce-Bereich, Hard- und Software, aber auch der nationale Personenverkehr oder Bankdienstleistungen. Das Gesetz betrifft demnach auch Webentwicklerinnen und Webentwickler, die Anwendungen für den Privatsektor implementieren. Auf ihrem Weg zu barrierefreien Anwendungen können sie auf eine Vielzahl unterstützender Tools und Techniken zurückgreifen.

Potenzielle Bußgelder bei EAA-Verstößen

Der European Accessibility Act ist nicht nur ein wichtiger und notwendiger Schritt, um das Internet für alle zugänglicher zu machen, sondern kann auch eine ernsthafte Gefahr darstellen, wenn er nicht eingehalten wird. Wenn ein Produkt oder eine Dienstleistung die Anforderungen an die Barrierefreiheit nicht erfüllt, können die deutschen Marktüberwachungsbehörden einen Rückruf oder die Einstellung anordnen. Darüber hinaus drohen Bußgelder von bis zu 100.000 Euro. Ausnahmen gelten nur für kleine Unternehmen mit weniger als zehn Beschäftigten, einem Jahresumsatz von weniger als zwei Millionen Euro oder einer Jahresbilanzsumme von weniger als zwei Millionen Euro.

Der Stand der Web-Accessibility und der IT-Projekte kurz vor 2025 wird voraussichtlich wie folgt aussehen:

• Viele IT-Projekte laufen bereits oder stehen kurz vor ihrem Beginn, ohne dass ein spezielles Budget für Barrierefreiheit zur Verfügung steht. Das bedeutet, dass die Inklusivität des Produkts mit geringen Kosten erreicht werden soll – in Bezug auf Geld und geistigen Aufwand.
• Teams verfügen noch nicht über das nötige Accessibility-Know-how. Idealerweise sollte das Tooling daher auch Anfängern eine Anleitung bieten.

Accessibility sollte eine regelmäßige Praxis sein, keine Einmalaktion. "Man führt sie einmal ein, und dann ist man barrierefrei" ist ein Mythos. Das bedeutet, dass Entwicklerinnen und Entwickler sich regelmäßig darum kümmern sollten, sowohl bei der Arbeit an neuen Features als auch bei der Wartung bestehender Features. Es gibt zwar verschiedene Accessibility-Checklisten, aber Selbstaudits funktionieren kaum dauerhaft, wenn sie nicht automatisiert oder gut in den Entwicklungsprozess integriert sind.

Darüber hinaus ist es derzeit eine unrealistische Erwartung, eine Website zu hundert Prozent barrierefrei zu gestalten. Web-Accessibility ist ein Kontinuum, weshalb Entwicklerinnen und Entwickler sie nicht mit einer "Alles oder nichts"-Haltung behandeln sollten. Stattdessen sollte der Schwerpunkt darauf liegen, ob Websites mehr oder weniger zugänglich sind. Es lohnt sich jeder einzelne Schritt, um eine Website inklusiver zu machen – und darüber zu sprechen. Auf dieser Grundlage bieten sich einige pragmatische Tipps und Tricks an, wie Webentwickler Accessibility-Features in ihre tägliche Programmierroutine integrieren können. Diese leicht durchführbaren Maßnahmen lassen sich mit sofortiger Wirkung und fast ohne Kosten umsetzen. Die folgenden Tools machen eine Website nicht vollständig barrierefrei, aber wie das Sprichwort sagt: Der Weg ist das Ziel.

Accessibility-Audits leicht gemacht durch Erweiterungen

Zwei Aspekte machen aus manuellem Accessibility-Testing ein teures und umständliches Unterfangen: Erstens benötigen die Testerinnen und Tester Kenntnisse über alle Anforderungen, und zweitens müssen sie die gesamte Website Zeile für Zeile nach Accessibility-Verstößen durchsuchen. Um diesen Aufwand deutlich zu reduzieren, stehen hilfreiche Browsererweiterungen bereit.

Eine dieser Erweiterungen ist Lighthouse, das vor allem für seine Performance-Analyse bekannt ist. Lighthouse lässt sich jedoch auch nutzen, um die Web-Accessibility zu bewerten und zu verbessern. Es ist direkt in Google Chrome integriert und ermöglicht es Entwicklern, ihre Websites im Hinblick auf potenzielle Accessibility-Probleme zu beurteilen und Einblicke in verbesserungsbedürftige Bereiche zu erhalten.

Nach Abschluss der Prüfung präsentiert Lighthouse einen umfassenden Bericht, der eine Bewertung der Barrierefreiheit, eine Liste der erfolgreich bestandenen Audits und spezifische Empfehlungen zum Beheben der festgestellten Probleme enthält (siehe Kasten "Lighthouse Accessibility Score"). Die Vorschläge basieren auf den Web Content Accessibility Guidelines (WCAG) (siehe Kasten "WCAG") und sind entsprechend den Auswirkungen auf die User gewichtet. Zu den kritischen Regeln zählen:

• [user-scalable="no"] darf nicht im Element <meta name="viewport"> vorhanden sein und das Attribut [maximum-scale] muss größer 5 sein. Wenn die Website gegen diese Regel verstößt, bedeutet das, dass sie entweder das Zoomen deaktiviert oder einschränkt, wie stark sich der Inhalt der Website vergrößern lässt. Das ist problematisch für Menschen mit Sehschwäche, die auf Bildschirmlupen angewiesen sind.
• <video>-Elemente enthalten ein <track>-Element mit dem Attribut [kind="captions"] zum Anzeigen von Untertiteln. Diese Prüfung ist für gehörlose Nutzerinnen und Nutzer wichtig, die sonst nur begrenzten oder keinen Zugang zu den Informationen in einem Video hätten. Personen, die eine Fremdsprache lernen, profitieren ebenfalls von Untertiteln.

Lighthouse Accessibility Score

Lighthouse liefert einen Lighthouse Accessibility Score zwischen 0 und 100, basierend auf der Anzahl der bestandenen beziehungsweise nicht bestandenen Audits, wobei 100 den bestmöglichen Wert darstellt. Jede Barriere kann eine potenzielle Auswirkung auf die Nutzer haben, beispielsweise „kritisch“, „schwerwiegend“, „mäßig“ oder „geringfügig“, je nachdem, wie stark sie das Verwenden der Website beeinträchtigen könnte. Das Tool beurteilt die Auswirkungen auf die User, und Entwickler können diese Beurteilungen nutzen, um die Barrierefreiheit der Webseite zu verbessern, was wiederum den Lighthouse Accessibility Score positiv beeinflussen kann.

Die Vorteile von Lighthouse sind, dass es in Google Chrome enthalten ist und messbare Einblicke liefert. Allerdings stützt es sich auf die Testregeln der axe-core-Bibliothek, einer etablierten Engine für das Accessibility-Testing von Web-User-Interfaces, und führt nur einen begrenzten Teil dieser Regeln aus. Für ein vollständiges Audit empfiehlt sich daher die Installation der Erweiterung axe DevTools, die auch für die Browser Mozilla Firefox und Microsoft Edge verfügbar ist. Zum Beispiel erreicht die Website "State of JavaScript" in Lighthouse ein solides Ergebnis von 89 Punkten (Abbildung 1). Wenn man sie jedoch mit der Erweiterung axe DevTools testet, erscheinen 13 zusätzliche Empfehlungen im Vergleich zu Lighthouse (Abbildung 2).

Zu den zahlreichen weiteren Browsererweiterungen gehören WAVE, Siteimprove Accessibility Checker, Accessibility Insights und Tenon. Diese Tools bieten den Vorteil, dass sie verwertbare Erkenntnisse liefern, ohne umfangreiche Kenntnisse über Barrierefreiheit vorauszusetzen. Eine etablierte Option ist axe-core, aber ein Entwicklungsteam muss selbst entscheiden, welches Tool seinen Bedürfnissen am ehesten entspricht. Verlässt man sich jedoch ausschließlich auf Browsererweiterungen für Accessibility-Tests, kann das Einschränkungen für den Entwicklungs-Workflow mit sich bringen.

Wenn Browsererweiterungen nur während der Testphase und nicht während der gesamten Feature-Implementierung zum Einsatz kommen, können Accessibility-Probleme bis zu späteren Phasen des Entwicklungsprozesses unentdeckt bleiben. Browsererweiterungen testen in der Regel Seite für Seite, was sich bei der Arbeit an umfangreichen oder komplexen Websites als zeitaufwändig und umständlich erweisen kann. Außerdem bieten die Erweiterungen unter Umständen nur eingeschränkte Konfigurationsmöglichkeiten oder testen nur nach einem vorgegebenen Regelwerk, wodurch sie projektspezifische Anforderungen übersehen können. Automatisierte Unit- und End-to-End-Tests können einigen dieser Einschränkungen entgegenwirken.

Automatisierte Accessibility-Testing-Tools

Automatisierte Tests sind programmierte Evaluationen einzelner Komponenten und kompletter Anwendungs-Workflows, die zum Gewährleisten konsistenter und effizienter Tests ohne manuelle Eingriffe ablaufen. Sie lassen sich in bestehende Test-Frameworks und Versionsverwaltungssysteme integrieren, was den Arbeitsablauf optimiert und einen konsistenteren und besser nachvollziehbaren Ansatz für die Barrierefreiheit fördert.

Allgemeine Testbibliotheken lassen sich auch für Accessibility-Tests verwenden, etwa um sicherzustellen, dass eine Schaltfläche sowohl auf Klick- als auch auf Eingabetasten-Ereignisse reagiert und dass User per Tastatur dorthin navigieren können (WCAG 2.1 Keyboard Accessible). Anstatt das Rad neu zu erfinden und sich die notwendigen Testfälle auszudenken, können Entwicklerinnen und Entwickler stattdessen auf die Vorteile spezieller Accessibility-Bibliotheken setzen, die sich auf gängige Accessibility-Anforderungen beziehen. Die folgenden Beispiele zeigen verschiedene Bibliotheken, Test-Engines und -Tools, und wie sie den Testing-Prozess unterstützen.

Testing Library und zugehörige Erweiterung

Testing Library bietet drei Funktionen für Accessibility-Testing: getRoles(), logRoles() und isInaccessible(). Es setzt auf Tests, die der realen Nutzung von Webseiten sehr nahe kommen, und legt den Fokus auf Queries, die visuelle/Maus-Benutzer ebenso berücksichtigen wie jene, die assistive Technologien verwenden, beispielsweise getByRole(), getByLabelText() und getByPlaceholderText(). Zusätzlich lässt sich eine Erweiterung für das Keyboard-Testing verwenden, um das Verhalten von Usern zu simulieren, die ausschließlich per Tastatur arbeiten.

Accessibility Testing Engines and Integrationen

Accessibility-Regelsätze sind das Herzstück mehrerer Testwerkzeuge. Die Grundlage dafür bilden Standards wie WCAG und Accessible Rich Internet Applications (ARIA). Am bekanntesten ist axe-core von Deque Systems, eine weit verbreitete Accessibility Engine für das Testen von Web-User-Interfaces. axe-core lässt sich mit verschiedenen Test Runnern und Frameworks wie Jest (jest-axe), Ember (ember-a11y-testing), React (axe-core/react) und Vue (vue-axe) integrieren. Das Verwenden von axe-core ist auch in End-to-End-Tests mit Tools wie Cypress (cypress-axe), Selenium (axe-core-selenium) und Playwright (axe-core/playwright) möglich.

Die Tests profitieren von einer umfangreichen und anpassbaren Regelsammlung und sind für bestimmte WCAG-Versionen und die Konformitätsstufen A, AA oder AAA konfigurierbar (siehe Infokasten "WCAG"). Zu den weiteren Accessibility Testing Engines und Accessibility-Regelsätzen zählen die Accessibility Checker Engine von IBM, die WAVE Stand-alone API and Testing Engine von WebAIM, die Tenon/Access Engine von Level Access, ARC von TGPi und der Alfa Accessibility Checker der Softwarefirma Siteimprove.

Web Content Accessibility Guidelines (WCAG)

Die Web Content Accessibility Guidelines (WCAG) 2.1 sehen drei Abstufungen vor, um eine Bandbreite von Nutzergruppen und Situationen abzudecken. Diese Stufen umfassen Stufe A (basic), Stufe AA (intermediate) und Stufe AAA (advanced). Jede höhere Stufe bedeutet die Zugänglichkeit für breitere Nutzergruppen und erfüllt demnach auch die Anforderungen der niedrigeren Stufen. Entspricht eine Webseite beispielsweise der Stufe AA, erfüllt sie automatisch die Standards sowohl von Stufe A als auch von Stufe AA. Für Stufe A müssen 25 Kriterien erfüllt sein, für Stufe AA sind 13 zusätzliche Kriterien erforderlich. Stufe AAA ist mit 23 weiteren Kriterien die Königsdisziplin.

Screenreader-Treiber

Guidepup ist ein Screenreader-Treiber für VoiceOver (macOS) und NVDA (NonVisual Desktop Access, Windows). Er ist darauf ausgelegt, Entwicklern dabei zu helfen, mit Screenreadern so zu navigieren, wie es ein User tun würde und hilft, auf automatisierte Weise festzustellen, was Nutzer von Screenreadern wirklich hören. Weitere Tools in dieser Gruppe sind JAWS Inspect, die Screen Reader Testing Library für NVDA und Assistive-Webdriver (JAWS und NVDA). Das korrekte Schreiben von Testaussagen setzt allerdings ein gewisses Verständnis der Funktionsweise von Screenreadern voraus. Die größte Einschränkung der genannten Tests und Browsererweiterungen besteht darin, dass Entwickler die Audits manuell auslösen müssen. Mit anderen Worten: Der Code ist in Ordnung, solange ihn niemand testet. Linter können dieses Defizit beheben.

Mit Accessibility Lintern zu einem inklusiveren Web – Zeile für Zeile

Ein Linter ist ein statisches Tool zur Codeanalyse, das Entwicklerinnen und Entwicklern hilft, potenzielle Probleme in ihrem Code zu erkennen, indem es ihn anhand einer Reihe vordefinierter Regeln oder Best Practices überprüft. Linter lassen sich in den Entwicklungs-Workflow integrieren, wo sie automatisch beim Speichern von Änderungen oder als Teil einer Continuous-Integration-(CI)-Pipeline ausgeführt werden.

Es gibt mehrere Accessibility Linter, von denen jeder seinen eigenen Regeln und Best Practices folgt. Einige Beispiele sind:

• Mehrere Plug-ins für ESLint auf der Grundlage des axe-core-Regelsatzes: für JSX (eslint-plugin-jsx-a11y), Vue (eslint-plugin-vuejs-accessibility), Lit (eslint-plugin-lit-a11y) und CoffeeScript (eslint-plugin-coffee)
• ASLint-Validierungsdienstprogramm auf der Grundlage des Tenon/Access-Engine-Regelsatzes
• ESLint mit angular-eslint/eslint-plugin: ein Accessibility-Checker für Angular-Anwendungen mit eigenem Regelwerk
• ESLint mit ember-template-lint: ein Accessibility-Checker für Ember- oder Handlebars-Vorlagen
• ESLint mit dem HTML-Linter: ein allgemeines Regelwerk für HTML-Linting, einschließlich Best Practices, SEO, Barrierefreiheit und Styles
• Stylelint mit dem Plug-in stylelint-a11y: Stylelint ist ein beliebter CSS-Linter, der sich durch Plug-ins erweitern lässt. Das stylelint-a11y-Plug-in konzentriert sich auf Barrierefreiheitsprobleme in CSS-Code.
• storybook-addon-a11y: Dieses Add-on ist streng genommen kein Linter, sondern integriert Accessibility-Checks unmittelbar in die Komponentenbibliothek und bietet visuelles Feedback innerhalb der Storybook-Oberfläche.

Ein Blick auf die Regelsätze der Linter wirft ein Licht auf die bewährten Verfahren für barrierefreie Websites. Mehrere Linter, die auf unterschiedlichen Regelsätzen basieren, haben sich zum Beispiel für die Implementierung einer no-positive-tabindex-Regel entschieden. Diese Regel verlangt, dass alle Elemente, die die Eigenschaft tabindex verwenden, diese auf 0 oder negative Werte setzen. Das ist deshalb wichtig, weil Elemente mit einem positiven tabindex die ersten Elemente sind, die Benutzer auf einer Webseite ansteuern. In diesem Fall würden sich die Tastaturnavigation und die Screenreader-Ansagen von der visuellen (und logischen) Reihenfolge der Elemente unterscheiden, was Benutzer verwirren könnte.

Eine weitere, in mehreren Lintern implementierte Regel betrifft die Verwendung von Autofokus. Die automatische Fokussierung eines Formularsteuerelements kann sehbeeinträchtigte Menschen, die Screenreader verwenden, und Menschen mit kognitiven Beeinträchtigungen verwirren. Wenn der Autofokus zugewiesen ist, "teleportieren" Screenreader ihre Benutzer auf das Formularsteuerelement, ohne sie zuvor zu warnen.

Zudem kontrollieren viele Regeln die Implementierung von Accessible Rich Internet Applications (ARIA), wie aria-roles, aria-props und aria-unsupported-elements. Diese Regeln kontrollieren die Verwendung von ARIA-Attributen, indem sie sicherstellen, dass die richtigen Werte und Wertetypen vorhanden sind.

Linter können Entwicklerinnen und Entwickler zwar vor Accessibility-Problemen warnen, aber sie können nicht verhindern, dass sie diese Warnungen ignorieren und den Code dennoch in Produktion geben. Der nächste Schritt, um eine barrierefreie Implementierung zu gewährleisten, wäre, das Linting in den Pre-Commit-Hook zu integrieren und damit Commits mit erkannten Problemen zu blockieren. Task-Runner und npm-Skripte können die gleiche Funktion erfüllen. Es gibt mehrere Plug-ins für Gulp und Grunt, die auf den Tenon- und axe-core-Regelsätzen basieren.

Während ein Entwicklungsteam selbst entscheiden könnte, ob es Browsererweiterungen und Linter verwenden möchte, erfordert der nächste Schritt eine erste kleine Änderung in der Priorisierung von Accessibility-Problemen. Können sie ein Grund für einen Aufschub des Release sein? Wenn ja, mit welchen Tools lässt sich das durchsetzen?

Continuous Integration und Accessibility

Bei der Continuous Integration (CI) werden Codeänderungen regelmäßig in ein gemeinsames Repository integriert, um sicherzustellen, dass der Code stets in einem veröffentlichungsfähigen Zustand ist. Die Integration von Barrierefreiheitsprüfungen in die CI-Pipeline trägt dazu bei, Accessibility-Probleme frühzeitig zu erkennen und zu verhindern, dass sie die Produktion erreichen. Je nach verwendeten Tools und Diensten gibt es verschiedene Möglichkeiten, Barrierefreiheitsprüfungen in eine CI-Pipeline einzubinden.

• AccessLint und axe Linter für GitHub Actions überprüfen Codeänderungen in Pull Requests und hinterlassen einen Kommentar bei neu entdeckten Accessibility-Problemen, die auf den axe-core Assertions basieren. Wird das Auflösen von Kommentaren zu einem Pflichtkriterium für den Merge, ist die (teilweise) Automatisierung der Barrierefreiheit geboren! Einziger Nachteil: Es ist nur für persönliche Open-Source-Projekte kostenlos verfügbar.
• Im Allgemeinen lassen sich GitHub Actions, GitLab CI, Jenkins und weitere CI/CD-Dienste nutzen, um einen benutzerdefinierten Workflow zu erstellen, der Accessibility-Prüfungen mit Tools wie Lighthouse CI, axe-linter-action, accessibility-insights-scan oder Pa11y beinhaltet. Die in den vorangegangenen Abschnitten erwähnten Linter und automatisierten Testwerkzeuge können ebenfalls Teil dieses Workflows sein. Ein umfassendes Beispiel findet sich in Adrián Bolonios Artikel "Automating the accessibility tests of your source code with GitHub Actions".

Die Integration von Accessibility-Checks in die CI/CD-Pipeline ist entscheidend für das frühzeitige Erkennen von Problemen und das Aufrechterhalten einer inklusiven User Experience. Es ist jedoch wichtig, die potenziellen Auswirkungen auf die Performance zu berücksichtigen, etwa die Zeit vom Commit bis zur Veröffentlichung (Commit to Publish, C2P). Anfängliche Implementierungen automatisierter Accessibility-Tests können sich negativ auf die C2P auswirken, sodass sich die Ausführungszeiten einiger Tests mehr als verdoppeln. Um die Auswirkungen auf die Leistung zu minimieren, sollte man Assertions bewusst einsetzen und sie auf bestimmte Bildschirmsegmente beschränken, wobei der Schwerpunkt auf wichtigen und oft benutzten Transaktionspfaden liegt. Es ist wichtig zu bedenken, dass eine hundertprozentige Abdeckung von Accessibility-Tests nicht das Ziel ist; Tests sind nur ein Werkzeug im Werkzeugkasten der Barrierefreiheit.

Optimierte Konfigurationseinstellungen, das Weglassen leistungsschwacher Regeln mit geringer Auswirkung und verteilte Testjobs können die Leistung erheblich verbessern. Alternativ können dedizierte Jobs Assertions parallel ausführen, um die C2P-Zeit niedrig zu halten und eine reibungslose CI/CD-Pipeline sicherzustellen.

Die nächsten Schritte: vom Verständnis zur Praxis

Allen bisher beschriebenen Tools und Lösungen lag die eingangs erwähnte Annahme zugrunde, dass es Teams an internem Know-how in Bezug auf Accessibility-Anforderungen und Best Practices mangelt. Das lässt sich leicht mit Workshops, Kursen, E-Learnings und Ähnlichem beheben. Es gibt eine Vielzahl kostenloser Ressourcen, die das Projektbudget schonen. Zu den bekanntesten gehören:

• Die MDN Accessibility Learning Area
• Learn Accessibility von Google Developers
• Digital Accessibility Foundations von der W3C Web Accessibility Initiative

Browsererweiterungen und Linter bieten erste Anhaltspunkte für die Barrierefreiheit im Web, aber die richtige Interpretation der Ergebnisse ist entscheidend. Diese Tools zeichnen sich durch eine hervorragende Syntaxprüfung aus, verfolgen aber einen "Einheitsansatz", der für alles gilt. So sollten beispielsweise alt-Attribute nicht leer sein, aber nicht alle Bilder benötigen Textalternativen. Dekorative Bilder tragen nicht zum Inhalt bei und sollten daher nicht angekündigt werden. Das sture Befolgen von Audit-Aktionselementen kann die Benutzerfreundlichkeit von Screenreadern verschlechtern.

Das Verständnis von ARIA-Rollen, -Bezeichnungen und -Attributen ist für die Barrierefreiheit entscheidend. Im ARIA Authoring Practices Guide (APG) heißt es: "Kein ARIA ist besser als schlechtes ARIA." Ein falscher Gebrauch von ARIA kann die Nutzerfreundlichkeit stark beeinträchtigen, etwa wenn man unsachgemäß einem <div>-Tag eine Rolle hinzufügt, ohne die erwarteten Tastaturinteraktionen zu implementieren.

Mangelndes Verständnis von Accessibility-Anforderungen bedeutet auch, dass Entwicklerinnen und Entwickler möglicherweise wesentliche Funktionen nicht kennen, die das Benutzererlebnis verbessern können. Beispielsweise ist die Funktion "zum Hauptinhalt springen" ein wertvolles Accessibility-Feature. Damit können Benutzer, die auf die Tastaturnavigation angewiesen sind, sich wiederholende Navigationselemente umgehen und direkt auf den Hauptinhalt einer Seite zugreifen.

Darüber hinaus ist es sehr hilfreich zu wissen, wie die WCAG zu navigieren und zu interpretieren sind, da sie weithin als Goldstandard für die Barrierefreiheit im Web gelten. Neben den Anforderungen bieten die WCAG auch wertvolle Techniken und Best Practices, die die Compliance erleichtern. Die Richtlinie "2.4 Navigable" enthält beispielsweise ein Erfolgskriterium mit der zugehörigen Technik H25, "Bereitstellung eines Titels unter Verwendung des Elements title". Diese Technik liefert ein Code-Snippet und Testszenarien zur Vereinfachung der Implementierung.

Die Schulung eines Entwicklungsteams ist ein nachhaltigerer Ansatz als die Installation von Lintern und die Integration von Barrierefreiheit in eine CI/CD-Pipeline, aber sie ist nicht der letzte Schritt. Die Einführung eines inklusiven Designprozesses in all seinen Facetten erfordert ein Umdenken in Unternehmen und hat eine enorme transformative Kraft. Das würde jedoch den Rahmen dieses Artikels sprengen.

Über das Tooling hinaus: Annehmen eines Accessibility-Mindsets

Zusammenfassend ist zu sagen, dass der Weg zu einem barrierefreieren Web ein fortlaufender Prozess ist, der konsequente Anstrengungen und Aufmerksamkeit von Webentwicklerinnen und Webentwicklern erfordert. Eine Reihe von Tools und Techniken wie Browsererweiterungen, automatisierte Testtools und Linter sowie die Integration von Accessibility-Checks in CI/CD-Pipelines ermöglichen es Entwicklern, inklusivere Online-Erfahrungen zu schaffen. Allerdings ist zu beachten, dass automatische Barrierefreiheitstests nur 30 bis 50 Prozent aller Accessibility-Probleme identifizieren können.

Es ist von entscheidender Bedeutung, ein tieferes Verständnis für Barrierefreiheitsanforderungen zu entwickeln und eine Haltung anzunehmen, die Barrierefreiheit als Praxis und nicht als einmaliges Feature betrachtet, da wir uns den durch das Barrierefreiheitsstärkungsgesetz und den European Accessibility Act festgelegten Fristen nähern.

Die in diesem Artikel vorgestellten Tools und Strategien dienen als pragmatische Ausgangspunkte für Entwickler auf diesem wichtigen Weg, aber man sollte sich mit Ressourcen wie dem Accessibility Automation Tracker und der Web Accessibility Evaluation Tools List über Aktualisierungen auf dem Laufenden halten.

Jeder Schritt auf dem Weg zu einem barrierefreieren Web ist ein Schritt, der es wert ist, gefeiert zu werden, und gemeinsam können wir die digitale Welt für alle zugänglicher machen. Es ist wichtig zu bedenken, dass automatisierte Tools zwar eine wertvolle Hilfestellung sein können, dass aber eine Kombination aus dem Verständnis der Accessibility-Prinzipien, manuellen Tests und User-Feedback letztendlich dazu beitragen wird, wahrhaft zugängliche und inklusive Webanwendungen zu schaffen.

Maria Korneeva
ist Frontend Technology Lead und Google Developer Expert mit Fokus auf Angular. Sie schreibt für ng-conf und spricht auf Tech-Meetups und Konferenzen. In ihren Tweets und Artikeln teilt Maria gerne ihre Erkenntnisse aus dem Programmieralltag. Fun Fact: Sie illustriert ihre Geschichten selbst, weil sie gerne zeichnet.

(mai)