enter JS – Accessibility Day

Hier lernst du unter anderem, worauf du beim Entwickeln barrierefreier Websites achten solltest und wie du die Accessibility testen kannst.

<p>Die Website barrierefrei machen? Bei dem Thema winken viele Unternehmen ab. Für wen denn? Ist doch auch viel zu teuer! Das sind Argumente, die man häufig hört. In diesem Artikel möchte ich darauf eingehen und 3 wichtige Argumente dafür liefern, sein Unternehmen mit einer barrierefreien Website zu repräsentieren.</p><h2>1. Die Gesetzeslage <span> </span></h2><p>In den vergangenen Jahren haben sich die Gesetze zur Barrierefreiheit verschärft. In Deutschland trat 2019 eine neue Version der BITV in Kraft, die die Barrierefreiheit von Anwendungen öffentlicher Stellen regelt. Dabei geht es nicht nur um externe Websites, sondern auch um interne Apps. Stichtag dabei war der 23. Juni 2021.</p><p>Auch auf die Privatwirtschaft kommen Verschärfungen zu. Die EU-Richtlinie 2019/882 sieht weitreichende Regelungen zur Barrierefreiheit von Websites privater Anbieter vor. Die Richtlinie ist allerdings noch nicht in deutsches Recht überführt; man hat hier noch ein paar Jahre Luft.</p><p>In den anderen Ländern der EU sieht es ähnlich aus; Grossbritannien und die USA haben sogar schärfere Gesetze.</p><p>Es lohnt sich also, sich um die Barrierefreiheit seiner Anwendung zu bemühen, um für die Gesetzeslage gewappnet zu sein.</p><h2>2. Breitere Nutzerbasis erschließen</h2><p>Viele Leute haben die Vorstellung, dass Barrierefreiheit nur eine kleine Gruppe von Menschen betrifft. Dabei profitieren viel mehr Nutzer von einer barrierefreien Seite als man denkt. In der EU gibt es ca. 80 Millionen Menschen mit einer Beeinträchtigung, die auf vielfältige Weise Probleme mit einer Website oder Webanwendung haben können.<span> </span></p><p>Dazu kommen viele ältere Nutzer, die vielfältige Einschränkungen haben können, ohne dass sie offiziell als beeinträchtigt gelten. Ca. 1/5 der Einwohner der EU ist mittlerweile 65 Jahre oder älter; mit steigender Tendenz.</p><p>Mit einer barrierefreien Website kann man sich also einen großen Kreis neuer Nutzer und potentieller Kunden erschließen.</p><h2>3. Bessere Nutzbarkeit für alle Nutzer</h2><p>Hartnäckig hält sich das Gerücht, dass barrierefreie Websites häßlich und altmodisch sind. Geschuldet ist das älteren Websites, die unter Barrierefreiheit vor allem extremen Kontrast und riesige Schrift verstehen. Bei modernen Websites sieht das anders aus.</p><p>Die Anforderungen an die Barrierefreiheit einer Website sind in weithin anerkannten Richtlinien definiert: den <a href="https://www.w3.org/WAI/standards-guidelines/wcag/"><span>WCAG</span></a> . Diese bilden auch die Grundlage für die weiter oben erwähnten Gesetze. Dabei werden die Belange von Nutzern mit verschiedenen Beeinträchtigungen berücksichtigt.</p><p>Viele der Richtlinien sind aber auch für “Normalos” ein Gewinn:</p><p>Ein gutes Beispiel dafür ist der Kontrast. Eine barrierefreie Website muss bestimmte Kontrastkriterien erfüllen. Auch ohne Sehbeeinträchtigung ist das nützlich, wenn man z.B. die Website auf dem Smartphone im Sonnenlicht betrachtet.</p><p>Untertitel in Videos helfen Menschen mit Hör- oder kognitiven Problemen. Aber viele Menschen schalten auch Untertitel ein, wenn sie in einer lauten Umgebung sind, oder wenn sie die Sprache nicht gut beherrschen.</p><p>Viele der Anforderungen für Nutzer mit kognitiven Einschränkungen reduzieren die Komplexität der Seite. Dazu gehören klare Strukturen und Navigation, Erklärungen für Formularfelder und vorhersehbares Verhalten. All das verbessert auch die allgemeine Benutzbarkeit der Seite.</p><p>Barrierefreiheit geht also Hand in Hand mit der Benutzerfreundlichkeit der Website.</p><h2>Die Kosten</h2><p>Das gewichtigste Argument dagegen, eine Website barrierefrei zu machen, sind die Kosten. Je nach Zustand und Größe der Seite, können die Kosten tatsächlich beträchtlich sein. Am billigsten ist es, wenn man Barrierefreiheit von Anfang an berücksichtigt. Aber auch bei höheren Kosten überwiegt der Nutzen: <a href="https://bighack.org/business-case-accessibility-6-companies-who-boosted-business-with-accessibility/">verschiedene Studien</a>  haben gezeigt, dass Firmen ihren Profit mit einer barrierefreien Website oder Anwendung nachweislich steigern konnten.</p><h2><b>Fazit</b></h2><p>Barrierefreiheit ist ein komplexes Thema, das immer wichtiger wird. Um es richtig anzugehen, ist es unumgänglich, sich mit Richtlinien und Nutzerbedürfnissen auseinander zu setzen. Doch es lohnt sich: Eine barrierefreie Website funktioniert unter den unterschiedlichsten Bedingungen und ist einfach zu bedienen. Deswegen profitieren am Ende alle Nutzer davon.<span> </span></p><p> </p>

3 gute Gründe für eine barrierefreie Website

<p>Beschäftigt man sich mit dem Thema Barrierefreiheit im Netz, kommt man an den <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">Web Content Accessibility Guidelines (WCAG)</a>  nicht vorbei. Sie sind <strong>DIE</strong> Standardrichtlinien für Barrierefreiheit im Netz. Außerdem sind sie die Basis für Gesetze über Barrierefreiheit weltweit und sogar <a href="https://www.iso.org/standard/58625.html"><span>ISO-zertifiziert</span></a> .</p><p>Leider sind sie auch sehr umfangreich und nicht einfach zu lesen. Der folgende Artikel bietet einen Einstieg in den Inhalt. <span> </span></p><h2><b>Hintergrund</b></h2><p>Die WCAG werden von der Web Accessibility Initiative (WAI) des World Wide Web Consortiums (W3C) herausgegeben. Das W3C erkannte den Bedarf für den Abbau von Barrieren schon sehr früh: Die Version WCAG 1.0. wurde im Mai 1999 publiziert. Die schnelle technische Weiterentwicklung machte bald eine Überarbeitung nötig: Version 2.0 erschien im Dezember 2008, und wurde im Juni 2018 mit Version 2.1 erweitert. Die Version 2.2 wird 2022 erwartet.</p><h2><b>Aufbau der Richtlinien</b></h2><p>Die Gliederung der WCAG erfolgt in mehreren Schritten:<span> </span></p><p>Auf oberster Ebene<span>  </span>gibt es die vier Prinzipien <em>wahrnehmbar</em>, <em>bedienbar</em>, <em>verständlich</em> und <em>robust</em>. Diese sind weiter unterteilt in insgesamt 13 Richtlinien. Zur Erfüllung dieser Richtlinien gibt es dann insgesamt 78 Erfolgskriterien (in WCAG 2.1). Zusätzlich gibt es zu jedem Erfolgskriterium sogenannte „Techniken”: Vorschläge zur konkreten Umsetzung.<span> </span></p><p>Auf den ersten Blick ist die Menge an Kriterien also ziemlich erschlagend. Damit eine Website als barrierefrei gilt, müssen allerdings nicht immer alle Erfolgskriterien erfüllt werden. Die Kriterien sind in drei Konformitätsstufen (A, AA und AAA) unterteilt. Je nachdem, welche Konformitätsstufe erreicht werden soll, müssen nur die entsprechenden Kriterien der Stufe und den darunter liegenden Stufen erfüllt werden.</p><p>Stufe A stellt dabei die Mindestanforderungen für Barrierefreiheit dar. Mit<span>  </span>Stufe AA kann man einen akzeptablen Level der Barrierefreiheit erreichen, und Stufe AAA ist das Maximum.<span> </span></p><p>Im Allgemeinen wird Stufe AA angestrebt. Diese Stufe wird auch in der EU-Norm 301 549 erwähnt, welche die Grundlage für Gesetze wie das <a href="https://www.gesetze-im-internet.de/bitv_2_0/BJNR184300011.html"><span>BITV</span></a>  darstellt.</p><p>Nach so viel Theorie zu den WCAG schauen wir uns jetzt endlich konkret an, worum es in den Richtlinien überhaupt geht.</p><h2><b>Prinzip 1: Wahrnehmbar</b></h2><p>Im ersten Prinzip der WCAG geht es darum, dass alle Informationen auf einer Website jedem Nutzer zugänglich gemacht werden. Es zielt also vor allem auf die Darstellung ab.<span> </span></p><p>Zwei der enthaltenen Richtlinien (1.1, 1.2) drehen sich um die Bereitstellung von Alternativen zu nicht-textuellen Inhalten wie Captchas, Bildern, Videos oder Audio.<span> </span></p><p>In 1.3 geht es um die Anpassung der Darstellung. Alle Informationen sollen auch noch wahrnehmbar und verständlich gegliedert sein, wenn man die Website mit technischen Hilfsmitteln wie einem Screenreader abruft.</p><p>Die letzte Richtlinie, 1.4, bezieht sich auf die Unterscheidbarkeit der dargestellten Elemente. Darunter fallen unterschiedliche Erfolgskriterien, wie die Festlegung von Minimalkontrast und Minimalauflösung, Möglichkeiten, die Textgröße zu ändern oder automatisch abspielendes Audio anzuhalten.</p><h2><b>Prinzip 2: Bedienbar</b></h2><p>Das Prinzip „Bedienbar” besagt, dass alle Komponenten der Benutzeroberfläche für alle Nutzer bedienbar sein sollen.</p><p>Hierunter fällt zum Einen die Bedienbarkeit mit dem Keyboard (2.1): jeglicher Inhalt und jegliche Interaktion muss mit dem Keyboard erreichbar sein. Weiterhin müssen langsamere Nutzer genug Zeit bekommen, um mit der Website zu interagieren (2.2). Inhalte, die physische Reaktionen hervorrufen können, müssen vermieden werden (2.3). Darüber hinaus muss die Website auf verschiedene Weise navigierbar sein (2.4) und es dem Nutzer leicht machen, sie mit verschiedenen Zeigegeräten (Maus, Touch, Spracheingabe) zu bedienen (2.5).</p><h2><b>Prinzip 3: Verständlich</b></h2><p>Bei dem Prinzip „Verständlich” geht es um die Verständlichkeit der Website. Der Nutzer muss nicht nur die Inhalte, sondern auch die Struktur und Navigation verstehen können.</p><p>Dafür gibt es drei Richtlinien. 3.1 besagt, dass die Sprache der Inhalte erkennbar sein soll und es Hilfestellung für ungewöhnliche Wörter, Abkürzungen usw. gibt. Weiterhin sollen die Interaktionen mit der Website vorhersehbar sein (3.2): z.B. sollen Nutzer nicht unbewusst ein Formular absenden. Die dritte Richtlinie, 3.3, zielt darauf ab, Nutzern die Eingabe von Daten möglichst einfach zu machen. Dazu gehören klare Labels an Formularfeldern und die Verhinderung von Fehleingaben.</p><h2><b>Prinzip 4: Robust</b></h2><p>Im letzten Prinzip geht darum, dass die Website mit gängigen Browsern und assistierenden Technologien kompatibel ist. Natürlich sind diese Technologien im ständigen Wandel. Deswegen zielt das Prinzip nicht auf vollständige Kompatibilität ab. Nur ein Maximum soll erreicht werden. Die Erfolgskriterien unter diesem Prinzip (4.1.1 – 4.1.3) schreiben vor, dass das HTML semantisch und valide sein sollte.</p><h2><b>Zusammenfassung</b></h2><p>In diesem Artikel habe ich die WCAG, die wichtigsten Richtlinien für Barrierefreiheit im Netz, kurz vorgestellt. Zur tiefergehenden Beschäftigung mit dem Thema empfehle ich die Projektseiten des W3C, insbesondere die <a href="https://www.w3.org/WAI/WCAG21/quickref/"><span>Schnellreferenz</span></a> .</p>

WCAG – Die Richtlinien für Barrierefreiheit erklärt

Machen wir uns nichts vor - eine Website barrierefrei zu gestalten ist nicht trivial. Das Thema ist hochkomplex, und muss von allen Seiten mitgedacht werden. Und so ist es leider auch beim Testen: ein großer Teil muss manuell getestet werden, weil die automatisierten Tests bis jetzt nicht in der Lage sind, alles abzudecken. Aber trotzdem können wir Einiges tun, um unsere Testabdeckung in Bezug auf Barrierefreiheit zu optimieren. 

## Automatische Prüfung

Es gibt einige Tools für die automatische Prüfung auf Barrierefreiheit. Sie orientieren sich an den anerkannten Standards, den Web Content Accessibility Guidelines ([WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/)). 

Die Effizienz der Tools ist umstritten. Im Allgemeinen wird angenommen, dass diese Tools nur 20-30% der Verstöße gegen die WCAG erkennen können. Immer wieder gibt es auch Untersuchungen, so wie [diese von Adrian Roselli](https://adrianroselli.com/2023/01/comparing-manual-and-free-automated-wcag-reviews.html), die auf eine noch geringere Erfolgsquote kommen. Auf der anderen Seite gibt es Hersteller, die eine weit höhere Abdeckung angeben. So wie Deque mit seiner Testing-Engine axe-core. Der Hersteller behauptet hier, dass die durchschnittliche Abdeckung 57% beträgt. Für diese Berechnung wurde aber schlicht eine andere Metrik angewandt – nachzulesen in [diesem Blogpost von Deque](https://www.deque.com/automated-accessibility-testing-coverage/).

Trotzdem sind automatisierte Tests ein sinnvolles Tool, um die Barrierefreiheit einer Website abzusichern. Testing-Engines wie Axe-core sind in vielen Tools verbaut, auch in Entwicklertools zum Testen von Frontend-Anwendungen, wie zum Beispiel jest oder cypress. Am Beispiel von @axe-core/playwright
schauen wir uns die Benutzung an.

## Automatische Prüfung mit @axe-core/playwright

Wie der Name schon impliziert, ist @axe-core/playwright eine Bibliothek, die die axe-core
Testing-Engine in das End-to-End-Testing Framework Playwright einbindet. Die Installation erfolgt dabei einfach über npm.

`npm install --save-dev @axe-core/playwright`

Nach der Installation können wir axe in Tests verwenden. Es läuft dabei grundsätzlich so ab, dass wir zuerst die Seite vollständig laden, und sie danach mit der Testing-Engine analysieren. Der Test ist bestanden, wenn es keine Regelverstöße gibt.

```typescript
await page.goto("/");
const accessibilityScanResults = await new AxeBuilder({ page }).analyze();
expect(accessibilityScanResults.violations).toEqual([]);
```

Axe kann auch nur auf einen Teil der Seite angewendet werden. Weiterhin können wir Elemente oder Regeln explizit ausnehmen. So können wir auch Seiten testen, bei denen noch Baustellen im Bezug auf Barrierefreiheit bekannt sind. Weiter Infos dazu findet ihr auf der [Seite von Playwright](https://playwright.dev/docs/accessibility-testing).

Die Regeln von axe beziehen sich auf verschiedene Erfolgskriterien von WCAG 2.0 bis 2.2.
Bis auf wenige Ausnahmen wird dabei nur auf die Konformitätslevel A und AA abgezielt. Zusätzlich gibt es Regeln für Best Practices und experimentelle Regeln. Alle Regeln können individuell ein- und
ausgeschaltet werden. Hier findet ihr eine [Komplettübersicht](https://github.com/dequelabs/axe-core/blob/6699ee404b4a0d52d32b96851d1a52d76d4867e8/doc/rule-descriptions.md).

Alleine ein Blick auf diese Übersicht macht aber klar, dass längst nicht alle Erfolgskriterien abgedeckt sind. Selbst wenn sie abgedeckt sind, gibt es keine Garantie, dass alle möglichen Verstöße gegen ein Kriterium erkannt werden kann. Automatische Überprüfungen sollten also nur als Baseline angesehen werden. 

## Tests für Keyboardnavigation

Wenn wir Tests schreiben, klicken wir uns normalerweise virtuell durch das Interface. Eine [Reihe wichtiger Erfolgskriterien der WCAG](https://www.w3.org/WAI/WCAG22/quickref/#keyboard-accessible) legt aber fest, dass die Website auch mit dem Keyboard benutzt werden kann. Deswegen ist es sinnvoll, auch entsprechende Tests in die E2E-Testsuite mit aufzunehmen.

Schauen wir uns dazu ein Beispiel mit Playwright an. Playwright exponiert das Keyboard
über die Property **keyboard** in der **page**. Mit 

```typescript
await page.keyboard.press("Tab");
```

kann zum Beispiel das nächste Element in der Tabreihenfolge angesteuert werden. Danach sollte überprüft werden, ob das richtige Element fokussiert ist. Das fokussierte Element kann über den Selektor „*:focus-visible“ ausgewählt werden:

```typescript
await expect(page.locator("*:focus-visible")).toContainText("Homepage");
```

Auf diese Art und Weise kann überprüft werden, ob alle Elemente angesteuert werden können, und zwar auch in der richtigen Reihenfolge. 

In Cypress ist das Ganze ein bisschen komplizierter. Stand heute (Juni 2024) gibt es in Cypress keine Möglichkeit, den Tab-Key auszulösen. Der Grund ist wohl, dass Cypress emulierte Events verwendet statt der nativen Browser Events. Siehe dazu das entsprechende [Github-Issue](https://github.com/cypress-io/cypress/issues/299).

Ein Workaround ist das Plugin [cypress-real-events](https://github.com/dmtrKovalenko/cypress-real-events), mit dem richtige Browser-Events ausgelöst werden können. Mit dieser Unterstützung sieht der Testcode für die Keyboardnavigation so aus:

```typescript
cy.get("nav a").first().focus(); 
cy.realPress("Tab");
cy.focused().should("contain.text", "All");
```

Ein wichtiger Punkt beim Testen ist, dass wir initial - aus Sicht von Cypress - keinen Fokus in der Seite haben. Damit die Tab-Navigation funktioniert, muss erst ein Element mit Cypress fokussiert werden (Zeile 1). Sobald wir einmal den Fokus haben, funktioniert es aber wie erwartet – jedoch leider nur in Chrome. Andere Browser werden von dem Plugin nicht unterstützt. Die Unterstützung für Tab-Navigation ist in Cypress also ausbaufähig.

## Tests auf semantische Namen

Alle interaktiven Komponenten des Interfaces brauchen einen Namen, der programmatisch erkannt werden kann ([WCAG Erfolgskriterium 4.1.2](https://www.w3.org/WAI/WCAG22/quickref/#name-role-value)). Das ist ein Kriterium, das relativ leicht automatisiert getestet werden kann.

Playwright unterstützt uns dabei: Die Assertion [**toHaveAccessibleName**](https://playwright.dev/docs/api/class-locatorassertions#locator-assertions-to-have-accessible-name) ist neu in Playwright 1.44 und liefert den Namen, unter dem ein Element im Accessibility Tree sichtbar ist. Damit können wir die Assertion aus dem obigen Beispiel wie folgt umschreiben:

```typescript
await expect(page.locator("*:focus-visible")).toHaveAccessibleName("Homepage");
```

Der Accessibility Tree wird vom Browser auf Basis des DOM-Trees erstellt und ist die semantische Repräsentation einer Seite. Für Screenreader, Spracherkennungssoftware und andere assistive Technologien ist er eine wichtige Informationsquelle. Der accessible Name eines Elements wird abgeleitet von sichtbaren oder unsichtbaren Labeln. Ein sichtbares Label für ein Formularfeld ist zum Beispiel Text in einem label-Tag, dass mit dem Formularfeld verknüpft ist. Ein Beispiel für ein unsichtbares Label ist der Wert des alt-Attributs eines Bildes. 

Mit der Nutzung dieser Assertion, und der ähnlich gestrickten Assertion [**toHaveAccessibleDescription**](https://playwright.dev/docs/api/class-locatorassertions#locator-assertions-to-have-accessible-description) können wir sicherstellen, dass wir semantisch korrekte Namen vergeben.

Die Nutzer von Cypress müssen etwas mehr Aufwand betreiben, und sich bei jedem Element genauer überlegen, wie der accessible Name zustande kommt. Je nachdem wird das label-Tag, oder das entspreche  Attributs eines Elements überprüft. Allerdings gibt es in Cypress keine Möglichkeit zu testen, dass dies auch tatsächlich der accessible Name ist, der im Accessibility Tree auftaucht.

## Tests von semantischen Rollen 

Das oben erwähnte Erfolgskriterium 4.1.2 der WCAG legt auch fest, dass semantische Rollen  programmatisch erkannt werden müssen. Die Rollen können implizit sein (zum Beispiel ist h1 implizit eine Überschrift Ebene 1), oder explizit vergeben werden mit dem role-Attribut. Die Korrektheit einer semantische Rolle können wir in E2E-Tests recht einfach überprüfen, indem wir unsere Elemente anhand ihrer Rolle auswählen. 

In Playwright funktioniert das mit dem Locator [**getByRole**](https://playwright.dev/docs/api/class-locator#locator-get-by-role). Damit kann man Elemente anhand ihrer Rolle auswählen, und auch nach accessible Name oder Zustand filtern.  

```typescript
await expect(page.getByRole("heading", { level: 1 })).toContainText("Welcome");
await page.getByRole("link", { name: "Homepage" });
await page.getByRole("button", { disabled: false });
```

Für Formularfelder kann der Locator [**getByLabel**](https://playwright.dev/docs/api/class-locator#locator-get-by-label) verwendet werden. Damit werden Felder anhand ihres semantischen Labels selektiert. 

```typescript
await page.getByLabel("Search");
```

Für die Benutzer von Cypress führt der Weg über die Testing Library. Die Testing Library ist eine Sammlung von Testing Utilities für verschiedene Test Frameworks. Ein Grundprinzip ist das Auswählen von Elementen über die semantische Rolle. 
Deswegen können mit der [Cypress Testing Library](https://testing-library.com/docs/cypress-testing-library/intro) Elemente analog zu Playwright über findByRole bzw. findByLabelText ausgewählt werden.

```typescript
cy.findByRole("heading", { level: 1 }).should("contain.text", "Welcome");
cy.findByLabelText("Search");
```

## Zusammenfassung

Wir haben viele Instrumente an der Hand, um die Barrierefreiheit einer Website
automatisiert zu testen. Die Standard Testing-Engines der einschlägigen Hersteller sind ein wichtiger Baustein, aber können uns nur eine Basis bieten. Durch gezieltes Einbauen von semantischen Selektoren und Keyboardtests können wir unsere Frontend-Tests in dieser Hinsicht weiter verbessern. Manuelles Testen kann dadurch aber nicht komplett ersetzt werden.







Frontend-Tests für Barrierefreiheit

Anna als eine unserer Expertinnen für Barrierefreiheit und Elke als Treiberin des Website Relaunch haben die Accessibility-Brille aufgesetzt und die Überarbeitung der eigenen Website beleuchtet:\nEs wäre wirklich schön, wenn wir unsere Website als leuchtendes Beispiel für Barrierefreiheit herzeigen könnten. Leider ist das im Moment (noch) nicht der Fall, denn wir sind noch nicht so weit. Warum?  \nWarum überhaupt barrierefrei? \nBei Barrierefreiheit geht es darum, eine Website wirklich allen zugänglich zu machen:\n⁠Dem älteren Mann, der die Schrift extra groß gestellt hat. \nDer Frau mit Karpaltunnelsyndrom, die die Maus nicht gut bedienen kann. \n⁠Dem jungen Mann, der mit dem Handy in der Sonne sitzt. \nAlle diese Menschen und noch viele andere können unsere User sein. Für uns Grund genug, uns mit dem Thema zu beschäftigen. Weitere Gründe dafür, eine Website barrierefrei zu machen, findet ihr \nin diesem Blogartikel\n. \nDoch nun zu unserer Website:\nAuftakt: Website Relaunch\nUnsere alte Website war etwas in die Jahre gekommen und entsprach nicht mehr unseren Anforderungen an Sicherheit, Darstellung unseres Portfolios und dem aufzubringenden Pflegeaufwand. Etwas Frisches musste her. \nAlso ging es ans Werk und wir vertieften uns in die verschiedenen Anforderungen an eine Website und führten Gespräche mit vielen Expert*innen innerhalb der codecentric. Neben der eigentlichen Darstellung des Content ging es vor allem um Architektur und Sicherheit, aber auch um Barrierefreiheit und Nachhaltigkeitsaspekte. Die Herausforderung: allen Anforderungen so weit wie möglich gerecht zu werden, gleichzeitig im Budget zu bleiben und das alles in einem überschaubaren Zeithorizont abzuwickeln.\nWie sind wir also in Hinblick auf Barrierefreiheit vorgegangen?\nDer erste Schritt: Check der Barrierefreiheit am Prototypen\nDie Website war auf einem guten Weg, die Sicherheitsaspekte soweit berücksichtigt, sodass wir uns den Barrierefreiheits-Anforderungen zuwenden konnten. Wir müssen vorausschicken, dass wir der Entwicklung vorab keine Vorgaben mitgegeben hatten. Und so kamen wir zum ersten Learning: Barrierefreiheit ist keineswegs ein Automatismus, der in der Entwicklung automatisch mitgedacht wird.\nEntsprechend negativ fiel der erste Test des Prototypen aus. Hier ein Auszug aus unseren Findings:\nSemantik: Die semantische Struktur der Seite war ziemlich durcheinander und Formularfelder nicht beschriftet.\nKeyboard-Navigation: nicht alles war mit dem Keyboard zu erreichen oder zu bedienen. Vor allem die Ansteuerung der Formulare – der wichtigste funktionale Part der Website – klappte nicht einwandfrei.\nAuflösung: Bei größerer Auflösung war die Seite nicht nutzbar.\nFarben / Kontrast: Unsere Brand-Color ist eine große Herausforderung für uns. Das helle Grün liefert zu wenig Kontrast zu weiß, und so kann die Farbe nicht gut als inhaltstragendes Element eingesetzt werden. Es waren an einigen Designelementen Nacharbeiten notwendig. \nWir hatten also eine Reihe neuer Tickets, die abgearbeitet werden mussten, gleichzeitig aber einen engen Zeitplan bis zum Livegang. Also was tun?\nLetztendlich haben wir uns nach reiflicher Überlegung, Analyse und Check der jeweiligen Auswirkungen für einen Kompromiss entschieden: die relevantesten Tickets wurden direkt erledigt, einige andere in die Phase nach dem Livegang verschoben.  \nHier können wir direkt das zweite Learning anbringen: die Entwicklung einer neuen Website ist letztendlich ein Zusammenspiel verschiedener Gewerke, die in ihrer Priorisierung sehr differenziert zu betrachten sind. Wichtig ist, die eigenen Beweggründe und Entscheidungen transparent zu kommunizieren, damit die Akzeptanz trotzdem gegeben ist. \nLivegang\nWir gingen also live mit einer Seite, bei der wir wussten, dass hinsichtlich Barrierefreiheit noch nicht alle Anforderungen erfüllt waren. Warum? Wie schon erwähnt, mussten wir stetig abwägen zwischen den verschiedenen Anforderungen. Vor allem der Sicherheitsaspekt hat uns getrieben, möglichst zügig Wordpress abzuschalten und durch ein Headless CMS abzulösen.\nEntsprechend sind wir bewusst mit einer – aus Accessibility-Perspektive – suboptimalen Seite gestartet. Dabei haben wir allerdings ein Thema falsch eingeschätzt. Uns war bewusst, dass der Zoom der Website noch nicht funktionierte, und wir wollten dies später beheben. Uns war aber nicht klar, wie viele unserer Kolleg*innen (und daraus lässt sich auch die entsprechende Ableitung für unsere User treffen) mit Setups arbeiten, bei denen sich dies negativ auf das Leseerlebnis auswirkt. Je nach Bildschirmauflösung war die Seite zu klein oder zu groß – und das konnte vom User nicht angepasst werden. Wir haben hier schnellstmöglich reagiert und konnten schon nach kurzer Zeit eine zoomfähige Variante einspielen.\nInteressanterweise trat diese Erkenntnis nicht in unserer – vor dem Livegang durchgeführten – Beta-Phase mit verschiedenen Testusern auf. Können wir hieraus ein Learning ableiten? Klar: die Gruppe der Testuser sollte eine größere Bandbreite abdecken, bezogen auf die unterschiedlichsten Kriterien wie Ausstattung, Rolle im Unternehmen und damit unterschiedlichen Blickwinkeln auf die Website. Dabei sollten wir auch auf Bildschirmauflösungen und Einschränkungen achten.\nAlle noch nicht erledigten Accessibility-Bugs wurden im Backlog priorisiert, um sie in den nächsten Wochen abzuarbeiten. Die Reihenfolge basierte dabei vor allem auf den Auswirkungen auf die Lesefähigkeit der Seiten. \nKontinuierliche Verbesserung\n“Erstens kommt es anders und zweitens als man denkt.”\nIhr kennt das vielleicht auch – bei einer Website ist man nie fertig. Neben eventuell nachträglich auftretenden Bugs kommen bereits neue Anforderungen von verschiedenen Seiten: Der Content muss angepasst und kulturelle und soziale Themen berücksichtigt werden. Außerdem fordert oder ermöglicht die technische Entwicklung weitere Verbesserungen. \nAlso konkurrierten unsere Accessibility-Tickets mit vielen anderen Tickets. Und das tun sie zum Teil immer noch.\nEine Herausforderung war und ist das Zusammenspiel der verschiedenen Akteure und Systeme, was uns teilweise wieder zurückgeworfen hat. Beispiel Überschriften: Für die Inhalte sind Kolleg*innen aus unterschiedlichsten Abteilungen zuständig. Wenn da Überschriftenlevel nicht korrekt gesetzt werden, landen diese 1:1 so in der Website. Wird beispielsweise eine Überschrift Ebene 1 (<h1>) außer im Titel auch noch mitten im Text gesetzt, ist dies sowohl für SEO als auch für die Barrierefreiheit schädlich. Hier muss also noch mehr Aufklärung in Richtung der Content-Lieferanten betrieben werden.\nDie Arbeit an unserer Website basiert auf kontinuierlich wiederkehrenden Ticketpriorisierungen. Dabei steigt aber das Thema Barrierefreiheit mittlerweile in der Priorisierung, denn der Bedarf wird immer größer. Also arbeiten wir stetig weiter und nähern uns langsam aber sicher einem Zustand, mit dem wir zufrieden sein können.\nDa uns barrierefreie Seiten sehr wichtig sind, wird die Website auch in Zukunft wiederholt Checks unterzogen, bei denen es bestimmt wieder neue Erkenntnisse gibt. Dann gibt es neue Tickets, diese werden wieder priorisiert und so weiter – ihr kennt das ja ;-)\nFazit\nDie verschiedenen Learnings haben wir ja schon erwähnt, aber die wichtigsten möchten wir hier noch einmal herausstellen:\nBarrierefreiheit muss von Beginn an mitgedacht werden. 
⁠\nWir hätten uns Arbeit und Kosten sparen können, wenn wir Barrierefreiheit von Anfang an noch besser mitgedacht und einen größeren Fokus darauf gelegt hätten. \nBarrierefreiheit ist komplex und muss nachhaltig von allen mitgedacht werden. 
⁠\nDie Komplexität dieses Themas ist nicht zu unterschätzen. Es ist ein Zusammenspiel von Technik, Content und Design und erfordert entsprechend gute Abstimmungen.\nBarrierefreiheit ist nie fertig. \n
⁠Bei jeglicher Änderung an der Seite muss Barrierefreiheit wieder berücksichtigt werden. \nWir bleiben auf jeden Fall an dem Thema dran. Sollte euch dazu etwas an unserer Website auffallen oder wollt ihr euch zum Thema generell mit uns austauschen, sprecht uns gerne an. \n

Der Weg zur barrierefreien codecentric-Website – Insights und Learnings

Formulare sind oft das wichtigste Element einer Website. Ob Checkout, Newsletter-Registrierung oder Kontaktformular – ohne Formulare geht nichts. Deswegen ist Barrierefreiheit bei Formularen enorm wichtig. Wenn das Checkout-Formular nicht ausgefüllt werden kann, wird auch nichts verkauft. In diesem Artikel zeige ich euch, was ihr tun könnt, um so viele Nutzer*innen wie möglich abzuholen.\nDer Artikel ist in drei Teile aufgeteilt. In Teil Eins geht es um den grundlegenden Aufbau von Barrierefreiheit in Formularen. \nTeil Zwei\n beschäftigt sich mit Nutzereingaben und \nTeil Drei\n mit der Validierung.\nRichtlinien für Barrierefreiheit\nEin bisschen Theorie bevor wir loslegen: Die Empfehlungen, die ich in diesem Artikel ausspreche, basieren zum großen Teil auf den Web Content Accessibility Guidelines (WCAG). Diese Richtlinien sind der internationale Standard für digitale Barrierefreiheit. Für eine grobe Übersicht lest gerne meinen \nBlogartikel über die WCAG\n. In diesem Artikel verweise ich dort, wo es relevant ist, auf die entsprechende Richtlinie.\nSemantische Labels\nJedes Formularfeld muss ein Label haben, damit die Nutzer*innen wissen, was sie eintragen sollen (\nWCAG 3.3.2\n). Klingt nach einer einfachen Regel, oder? So sieht das im Code aus:\n<label for="firstName">Vorname</label>
<input type="text" id="firstName" name="firstName"/>\nWie ihr seht, benutze ich das \nlabel-Tag\n, ein semantisches Attribut. Semantische Attribute helfen dem Browser, die Bedeutung eines Elements zu erfassen und entsprechende Interaktionen anzubieten. Bei einem Button wäre das zum Beispiel die Möglichkeit, darauf zu klicken.\nAußerdem ist das Label über das for-Attribut mit der Textbox verknüpft. Diese Information wird, zusammen mit den anderen semantischen Infos, durch den Browser in den sogenannten Accessibility Tree mit aufgenommen. Diesen Baum stellt der Browser Screenreadern und andere assistive Technologien zur Verfügung. Den Baum könnt ihr euch in den Developer Tools anzeigen lassen, z.B. im Firefox:\n\nIn dem Screenshot sehen wir, dass der Tree ähnlich wie der DOM-Tree aussieht. Der Unterschied ist, dass DOM-Elemente, die keine Bedeutung haben, im Accessibility-Tree nicht auftauchen.\nHervorgehoben habe ich im Screenshot unsere Textbox. Durch die Verknüpfung mit dem Label hat diese einen Namen erhalten: „Vorname“. Nur so bekommen Screenreader-Nutzer*innen überhaupt die Information, für was die Textbox verwendet werden soll. Lasst ihr die Info weg, wird einfach nur „Textbox“ vorgelesen, und die Nutzer*innen müssen raten, was sie eintragen sollen.\nMit diesem semantischen Aufbau unseres Eingabefeldes haben wir \nWCAG 1.3.1\n erfüllt. Diese Richtlinie besagt, dass (unter anderem) Informationen, die durch die visuelle Repräsentation gegeben sind, auch programmatisch transportiert werden müssen.\nKeyboard-Navigation\nManche Nutzer*innen füllen Formulare nur mit dem Keyboard aus. Teilweise sind sie darauf angewiesen, weil sie keine Maus bedienen können. Aber auch viele technik-erfahrene Menschen greifen in Formularen auf das Keyboard zurück, weil es oft schneller ist, als mit der Maus zu klicken.\nDie drei wichtigsten Kriterien für die Keyboard-Navigation in Formularen sind die Folgenden:\nDas Feld muss mit dem Keyboard erreichbar und ausfüllbar sein (\nWCAG 2.1.1\n)\nEs muss immer erkennbar sein, wo sich die Nutzer*innen gerade befinden (\nWCAG 2.4.7\n)\nDie Reihenfolge, in der Elemente angesprungen werden, muss logisch sein (\nWCAG 2.4.3\n)\n\nWenn ihr nur die Standard-HTML-Tags wie input oder select benutzt, sind diese automatisch mit dem Keyboard bedienbar. Aufpassen müsst ihr dann nur mit dem Styling: der Fokus und ggf. die ausgewählten Elemente müssen gut erkennbar sein, wie in WCAG 2.4.7 beschrieben.\nHäufig werden aus Design-Gründen selbstgebaute Formularelemente oder Bibliotheken verwendet statt der Standard-Tags verwendet. Hierbei müsst ihr nicht nur auf die Keyboardnavigation, sondern auch auf die Semantik achten. Ein guter Leitfaden dafür ist der \nAria Authoring Practices Guide\n (APG). Dort gibt es Beispiel-Implementierungen, die auf eine maximale Kompatibilität mit den WCAG abzielen.\nÜber die grundlegende Bedienung hinaus könnt ihr auch einige Erleichterungen für Keyboardnutzer*innen einbauen. Ein klassisches Beispiel ist das Absenden des Formulars mit Enter. Dabei sparen sich Nutzer*innen den Extra-Schritt, zum „Absenden“-Button zu springen.\nDesignanpassungen\nDie Beispiele in diesem Artikel sind durchweg nicht gestylt. Moderne UIs erfordern natürlich auch ein entsprechendes Styling für Formularfelder. Ein wesentlicher Punkt dabei, aus Sicht der Barrierefreiheit, ist der Kontrast: Labels müssen einen Kontrast von mindestens 4.5:1 aufweisen; bei Icons ist es 3:1 (\nWCAG 1.4.3\n). Es gibt eine Vielzahl von Tools zur Überprüfung des Kontrasts, zum Beispiel den \nContrast Checker von WebAIM\n oder das Browser-Plugin \nWCAG Color Contrast Checker\n.\nÜber die Platzierung des Labels solltet ihr euch auch Gedanken machen. Traditionell stehen Labels vor oder über einem Feld. In vielen modernen UIs stehen Labels im Feld und wandern bei Eingabe in den oberen Bereich (das sogenannte “Floating Label”). Ob das so optimal für die Barrierefreiheit ist, darüber gehen die Meinungen auseinander.\nWorin sich alle einig sind: das Placeholder-Attribut darf nicht als Label  verwendet werden. Der Standard-Placeholder hat einen zu geringen Kontrast und verschwindet, wenn man tippt. Damit verstößt er gleich gegen zwei WCAG Kriterien: \n3.3.2\n und \n1.4.3\n. Außerdem sorgt er für einige weitere UX-Probleme. In diesem \nArtikel der Norman-Nielsen-Group\n wird ausführlicher darauf eingegangen.\nFazit und Ausblick\nJetzt kennen wir die grundlegenden Aspekte, auf die wir bei der Barrierefreiheit von Formularen achten müssen:\nSemantik\nKeyboard-Navigation\nKontrast\nIn Teil Zwei werden wir uns damit beschäftigen, wie wir die Nutzer*innen bei der Eingabe unterstützen können. \nDiesen Teil findet ihr hier\n.\n

Barrierefreie Formulare - Teil 1: Der Aufbau

Formulare sind oft das wichtigste Element einer Website. Ob Checkout, Newsletter-Registrierung oder Kontaktformular – ohne Formulare geht nichts. Deswegen ist Barrierefreiheit bei Formularen enorm wichtig. Wenn das Checkout-Formular nicht ausgefüllt werden kann, wird auch nichts verkauft. In diesem Artikel zeige ich euch, was ihr tun könnt, um so viele Nutzer*innen wie möglich abzuholen.

Der Artikel ist in drei Teile aufgeteilt. In [Teil Eins](https://www.codecentric.de/wissens-hub/blog/barrierefreie-formulare-teil-1-der-aufbau) geht es um den grundlegenden Aufbau von Barrierefreiheit in Formularen. In diesem Teil, Teil Zwei, beschäftigen wir uns damit, wie wir unsere Nutzer*innen beim Ausfüllen unterstützen können. Im [dritten Teil](https://www.codecentric.de/wissens-hub/blog/barrierefreie-formulare-teil3-validierung) lernen wir, wie Eingaben barrierefrei validiert werden können.

### Eingaben unterstützen

Das oberste Prinzip bei Formularen ist, Nutzer*innen bestmöglichst bei der Eingabe zu unterstützen. So können Fehler vermieden werden, bevor sie entstehen. Die Menschen kommen dann schneller und vor allem frustfreier durch euer Formular.

### Erforderliche Felder markieren

Damit die Nutzer*innen wissen, welche Felder zwingend ausgefüllt werden müssen, solltet ihr das deutlich markieren. Dabei bleibt es euch überlassen, ob ihr die erforderlichen oder die optionalen Felder oder beides markiert.

Ein Pattern, dass man oft sieht, ist, die erforderlichen Felder mit Stern zu markieren. Doch obwohl es so häufig benutzt wird, solltet ihr nicht davon ausgehen, dass alle Nutzer*innen das verstehen. Besser, ihr schreibt es noch einmal über das Formular:

```html
<span>Mit Stern (*) markierte Felder müssen ausgefüllt werden.</span>
<form>
    <label for="username">Nutzername</label>
    <input type="text" id="username" name="username"/>
    <label for="email">E-Mail*</label>
    <input type="email" id="email" name="email" required aria-required="true"/>
    <button type="submit">Abschicken</button>
</form>
```

In dem Beispiel habe ich auch das HTML-Attribut [required](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/required) verwendet. Das sorgt dafür, dass das Feld auch semantisch als erforderlich markiert wird. Screenreader greifen diese Information auf und teilen sie ihren Nutzer*innen mit. Das andere Attribut, [aria-required](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-required), transportiert die selbe Information. Es kann vereinzelt noch dazu kommen, dass required vom Screenreader nicht unterstützt wird, deswegen ist die aktuelle Empfehlung, beide Attribute zu verwenden.

Wir haben hier erstmals ein Beispiel für den Einsatz von [ARIA](https://www.w3.org/WAI/standards-guidelines/aria/). ARIA steht für Accessible Rich Internet Applications und erweitert HTML um semantische Rollen und Attribute. Es wird an den Stellen eingesetzt, an denen mit HTML keine Semantik definiert werden kann. Zum Beispiel gibt es in HTML kein natives Menü, aber mit Hilfe von ARIA könnt ihr ein selbstprogrammiertes Menü als solches deklarieren. Eine knackige [Einführung in ARIA](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA) findet ihr zum Beispiel in den MDN Docs. Im weiteren Verlauf der Artikelserie werden wir mehr Beispiele für ARIA kennenlernen.

### Hilfestellung bei der Eingabe

Nutzer*innen müssen immer wieder aufs Neue abgeholt werden. Bloß, weil eine Info weiter oben oder auf der vorherigen Seite erwähnt wurde, heißt es nicht, dass sie diese Info noch auf dem Schirm haben.

Ihr könnt nämlich nicht davon ausgehen, dass die Nutzer*innen eurem Formular immer ihre volle Aufmerksamkeit widmen. Sie können beim Ausfüllen auch mal abgelenkt oder unterbrochen werden und dadurch den Kontext verlieren. Manchen fällt es auch schwer, sich länger zu konzentrieren.

Deswegen sollten Hilfen für die Eingabe direkt am entsprechenden Feld stehen und auch programmatisch damit verknüpft sein. Hier kommt wieder [WCAG 3.3.2](https://www.w3.org/WAI/WCAG22/quickref/#labels-or-instructions) zum Tragen, die wir schon im ersten Teil kennengelernt haben: "Labels or instructions are provided when content requires user input."

Im Code sieht es so aus:

```html
<label for="customerNumber">Kundennummer</label>
<input type="text" id="customerNumber" name="customerNumber" aria-describedby="infoCustomerNumber"/>
<span id="infoCustomerNumber">Ihre Kundennummer finden Sie oben rechts auf dem letzten Schreiben</span>
```

Mit [aria-describedby](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-describedby) könnt ihr die Zusatzinformationen auch semantisch mit der Textbox verknüpfen. Das Attribut nimmt dabei eine Liste von ids der entsprechenden Elemente; so können auch mehrere Infos verlinkt werden. Screenreader-Nutzer bekommen die Zusatzinfos zusammen mit dem Feld vorgelesen.

### Automatisches Ausfüllen

Nutzer*innen kommen noch schneller voran, wenn sie gar nicht mehr groß Eingaben tätigen müssen. Das nimmt Einiges an Last ab, vor allem wenn sie kognitiv eingeschränkt sind. Aus diesem Grund ist es auch in den WCAG vorgeschrieben: [WCAG 1.3.5](https://www.w3.org/WAI/WCAG22/quickref/#identify-input-purpose) legt fest, dass der Zweck eines Eingabefelds programmatisch auslesbar sein soll, damit assistive Technologien dem Nutzer Hilfestellung bieten können.

Dafür könnt ihr in HTML das [autocomplete-Attribut](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete) verwenden. Mit dem Wert „given-name“ zum Beispiel legt ihr fest, dass das Feld den Vornamen enthalten soll.

```html
<label for="firstName">Vorname</label>
<input type="text" id="firstName" name="firstName" autocomplete="given-name"/>
```

In diesem Fall ist mit assistive Technologien mal nicht der Screenreader gemeint, sondern eher die Autofill-Funktion des Browsers. Wenn sie aktiv ist, merkt sich der Browser bei der ersten Eingabe eines Feldtyps, was in das Feld kommt, und bietet es der Nutzerin beim nächsten Ausfüllen direkt an. Eine enorme Erleichterung für viele Nutzer*innen.

### Redundanz vermeiden

Bei manchen längeren Formularstrecken kommt es vor, dass Nutzer*innen Informationen erneut eingeben müssen. Zum Beispiel könnte bei einem Checkout-Formular eine zusätzliche Lieferadresse abgefragt werden.

In den WCAG wurde auch das in einem Kriterium festgehalten: [WCAG 3.3.7](https://www.w3.org/WAI/WCAG22/quickref/#redundant-entry) legt fest, dass Nutzer*innen die selbe Eingabe nicht mehrmals tätigen sollten. Dabei gibt es Ausnahmen, zum Beispiel macht es beim Festlegen eines Passworts durchaus Sinn, das Passwort zweimal einzugeben.

Im Beispiel des Checkout könnten wir das Kriterium ganz einfach mit einer Checkbox „Lieferadresse wie Rechnungsadresse“ erfüllen. Die vorher eingegebene Adresse solltet ihr dabei noch einmal anzeigen. Das könnt ihr noch kombinieren mit einer Änderungsoption, falls einer Nutzerin an dieser Stelle ein Fehler in der Adresse auffällt.

Bei richtig langen Formularen könnt ihr auch das Formular auf mehrere Seiten aufteilen. Das macht es den Nutzer*innen einfacher, sich zu fokussieren. Gleichzeitig müssen sie aber noch den Überblick bewahren können, d.h., ihr solltet Zusammenfassungen anzeigen. 

Außerdem müssen die Nutzer*innen sich auch rückwärts bewegen können, um nachträgliche Änderungen zu machen. Das ist deutlich aufwendiger als nur eine Seite Formular. Ob es den Aufwand wert ist, müsst ihr im Einzelfall abwägen.

### Fazit und Ausblick

In diesem Teil haben wir gelernt, wie wir unsere Nutzer*innen beim Ausfüllen eines Formulars unterstützen können. Durch Hilfestellungen, automatisches Ausfüllen und weniger Redundanz sollten sie das Formular schneller und frustfreier ausfüllen können, und dabei weniger Fehler machen.

Trotzdem lassen sich fehlerhafte Eingaben nicht ganz vermeiden vor. Im Teil Drei der Serie zu barrierefreien Formularen erfahrt ihr, wie ihr am Besten damit umgehen könnt. 


Barrierefreie Formulare - Teil 2: Ausfüllen unterstützen

Formulare sind oft das wichtigste Element einer Website. Ob Checkout, Newsletter-Registrierung oder Kontaktformular – ohne Formulare geht nichts. Deswegen ist Barrierefreiheit bei Formularen enorm wichtig. Wenn das Checkout-Formular nicht ausgefüllt werden kann, wird auch nichts verkauft. In diesem Artikel zeige ich euch, was ihr tun könnt, um so viele Nutzer*innen wie möglich abzuholen.

Der Artikel ist in drei Teile aufgeteilt. In [Teil Eins](https://www.codecentric.de/wissens-hub/blog/barrierefreie-formulare-teil-1-der-aufbau) geht es um den grundlegenden Aufbau von Barrierefreiheit in Formularen. In [Teil Zwei](https://www.codecentric.de/wissens-hub/blog/barrierefreie-formulare-teil-2-ausfuellen-unterstuetzen) beschäftigen wir uns damit, wie wir unsere Nutzer*innen beim Ausfüllen unterstützen können. Im diesem Teil, dem letzten Teil, lernen wir, wie Eingaben barrierefrei validiert werden können.

### Validierung: Im Client oder auf dem Server?

Für Nutzer*innen ist es ideal, wenn ihre Eingaben direkt validiert werden. So können sie Fehler sofort korrigieren, solange sie noch im Kontext eines Formularfeldes unterwegs sind. In einer modernen Web-Anwendung ist das auch normalerweise kein Problem. Manche Dinge können allerdings erst nachgelagert nach dem Abschicken des Formulars validiert werden. Diesen Fall betrachten wir weiter unten im Artikel; zuerst schauen wir uns Client-seitige Validierung an.

Die WCAG legt sich nicht eindeutig dazu fest, wo validiert werden soll. In den relevanten Kriterien zur Fehlerbehandlung, [WCAG 3.3.1](https://www.w3.org/WAI/WCAG22/quickref/#error-identification) und [WCAG 3.3.3](https://www.w3.org/WAI/WCAG22/quickref/#error-suggestion) sind allerdings einige Techniken aufgelistet, die nahelegen, das Client-seitige Validierung präferiert wird.

### Browser-Validierung

Browser bieten eine eingebaute Validierung an. Den folgenden Code-Schnipsel hatten wir im vorherigen Teil schon mal in ähnlicher Form:

```html
<span>Mit Stern (*) markierte Felder müssen ausgefüllt werden.</span>
<form>
     <label for="email">E-Mail*</label>
     <input type="email" id="email" name="email" required aria-required="true"/>
     <button type="submit">Abschicken</button>
</form>
```

Durch die Verwendung des [required-Attributs](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/required) erhalten wir automatisch eine Validierung durch den Browser. Sie wird ausgelöst beim Absenden des Formulars und gibt uns eine Fehlermeldung in der eingestellten Browsersprache:

![Validierung1.png](https://media.graphassets.com/tM12pVN1QfWKxSzd67fM)

Darüber hinaus kann der Browser aber noch mehr: wir haben angegeben, dass das Feld vom Typ E-Mail ist. Das führt dazu, dass die Eingabe automatisch auf eine valide E-Mail-Adresse überprüft wird, wie im nächsten Screenshot zu sehen:

![Validierung2.png](https://media.graphassets.com/HhDSimooQIGuFX6tXI7g)

Entsprechende Validierungen existieren auch für andere Feldtypen. Für komplexere Anforderungen existiert das [Attribut "pattern"](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/pattern). Damit könnt ihr reguläre Ausdrücke hinterlegen, gegen die das Feld validiert wird.
Der Nachteil an der Browser-Validierung ist, dass sie erst beim Klick auf den submit-Button ausgelöst wird. Außerdem gibt es keine Möglichkeit, die Fehlermeldung zu stylen: Sie sieht in jedem Browser unterschiedlich aus. In der Praxis geht man also häufig trotzdem hin und benutzt eine Javascript-Bibliothek für die Validierung.

### Validierung mit Javascript

Mit Javascript kann die Validierung schon bei der Eingabe stattfinden. Üblicherweise wird ein invalides Feld in rot gestylt, auch mit einer Fehlermeldung in rot. Hierbei solltet ihr auf den Kontrast achten: in Teil 1 haben wir gelernt, dass der Kontrast von Text zum Hintergrund 4,5:1 betragen sollte ([WCAG 1.4.3](https://www.w3.org/WAI/WCAG22/quickref/#contrast-minimum)) – das gilt auch für Fehlermeldungen.

Um die Fehlermeldung auch semantisch kenntlich zu machen, sind noch einige ARIA-Attribute notwendig. Hier ein Code-Schnipsel, wie der invalide Zustand aussehen könnte (Styling ausgeklammert):

```html
<label for="email">E-Mail</label>
<input type="email" id="email" name="email" autocomplete="email" aria-invalid="true" aria-describedby="email-error" aria-errormessage="email-error"/>
<span id="email-error">Bitte geben Sie eine gültige E-Mail-Adresse an</span>
```

Mit dem Attribut [aria-invalid](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-invalid) kommunizieren wir, dass das Feld nicht valide ist. Die Attribute [aria-describedby](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-describedby) und [aria-errormessage](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-errormessage) verweisen auf die Fehlermeldung. Es wird aktuell empfohlen, beide Attribute zu benutzen, um ein Maximum an Kompatibilität zu erreichen. Diese beiden Attribute sollten auch nur gesetzt werden, wenn das Feld invalide ist.

### Serverseitige Validierung

Auch wenn nach dem Abschicken des Formulars Fehler auftreten, gibt es ein paar Best Practices um Nutzern zu helfen. Zunächst das Wichtigste: nur eine generelle Meldung „Fehler aufgetreten“ ist wenig hilfreich. Fehlermeldungen solltet ihr wie gehabt direkt am entsprechenden Feld anzeigen.
Zusätzliche visuelle Hilfe kann eine Liste von Fehlern oberhalb des Formulars bieten, die alle Fehler auflistet. 

Mittlerweile hat es sich auch eingebürgert, den Keyboardfokus in das erste Feld zu setzen, in dem ein Fehler aufgetreten ist. Das hilft den Nutzer*innen, schnell die richtige Stelle zu finden. Manche Nutzer\*innen können auch nicht das komplette Formular auf einmal betrachten, weil sie eine starke Vergrößerung brauchen. Wenn ihr den Fokus nicht in ein invalides Feld setzt, müssen sie erstmal herumscrollen, um das fehlerhafte Feld zu finden. Solltet ihr trotzdem den Fokus nicht setzen wollen, ist für diese Nutzer\*innen ein Hinweis auf den Fehler an oder neben dem Button zum Abschicken hilfreich.

### Besonderheiten für Screenreader-Nutzer*innen

Wenn Fehlermeldungen dynamisch, ohne ein Reload der Seite, erscheinen, bekommen Screenreader-Nutzer*innen das nicht notwendigerweise mit. Denn der Screenreader lauscht nicht automatisch auf Veränderungen im Dokument. [WCAG 4.1.3](https://www.w3.org/WAI/WCAG22/quickref/#status-messages) besagt, dass auch solche, als „Statusmeldungen“ bezeichnete Änderungen, programmatisch deklariert werden müssen.

Praktisch umsetzen können wir das mit einer Live-Region. Mit Live-Regionen kann man Teile des Dokuments festlegen, die der Screenreader auf Änderungen beobachten soll. Der nächste Code-Schnipsel zeigt wie das bei einer Fehlermeldung aussehen kann:

```html
<label for="email">E-Mail</label>
<input type="email" id="email" name="email" autocomplete="email" aria-invalid="true" aria-describedby="email-error" aria-errormessage="email-error"/>
<div aria-live="assertive" aria-atomic="true">
    <span id="email-error">Bitte geben Sie eine gültige E-Mail-Adresse an</span>
</div>
```

Wir haben jetzt einen zusätzlichen Container um die Fehlermeldung. Das ist unsere Live-Region. Die bleibt immer stehen, auch im validen Fall, während die Fehlermeldung nur auftaucht, wenn die Eingabe invalide ist. Die beiden Attribute [aria-live](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-live) und [aria-atomic](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-atomic) sorgen dafür, dass jegliche Änderung im Container an Screenreader gemeldet wird. Der Wert für aria-live, assertive, bedeutet, dass die Nutzer sofort informiert werden, sobald sich etwas ändert. Es gibt auch noch den Wert polite: damit werden Änderungen erst kommuniziert, wenn der Screenreader gerade nichts anderes spricht. Mit aria-atomic=true stellen wir sicher, dass wir jegliche Änderung mitbekommen.

Um das Beispiel kurz zu halten, habe ich den Container mit der Live-Region direkt um die Fehlermeldung gemacht. In der Praxis würde ich eher das komplette Formular als Live-Region deklarieren. So bekommt der Nutzer jegliche Veränderung mit, auch wenn das Formular abgeschickt wurde.

Das Wichtige bei Live-Regionen: die Live-Region selber kann nicht dynamisch nachgeladen werden, und sollte beim initialen Laden der Seite schon vorhanden sein. Sonst funktioniert die Live-Region nicht. Es kann sein, dass der Screenreader, mit dem ihr testet, trotzdem Updates liefert, aber das ist längst nicht bei jedem Screenreader der Fall.

### Fazit

Bei der barrierefreien Validierung kommt es vor allem darauf an, Nutzer\*innen gut abzuholen. Fehlermeldungen solltet ihr gut sichtbar in die Nähe des Fehlers anzeigen. Bei Fehlern nach dem Abschicken des Formulars solltet ihr eure Nutzer\*innen zur Fehlerquelle leiten. Für Screenreader-Nutzer*innen sind Live-Regionen wichtig um Fehlermeldungen und andere dynamische Änderungen mitzubekommen.

Wir sind jetzt am Ende unserer Artikelserie und ihr habt hoffentlich eine gute Übersicht gewonnen, was barrierefreie Formulare ausmacht. Viel mehr als eine Übersicht ist es auch nicht; das Thema ist so komplex, dass ich noch viel mehr darüber schreiben könnte. Falls ihr weiter einsteigen wollt, findet ihr hier noch eine kurze Liste von weiterführenden Links. Viel Spaß beim Entdecken!

- [Forms Tutorial vom W3C](https://www.w3.org/WAI/tutorials/forms/)
- [Disabled buttons suck](https://axesslab.com/disabled-buttons-suck/)
- [A definitive guide to sensible form validation](https://html.form.guide/best-practices/form-validations-definitive-guide/)
- [What happened to text inputs?](https://briefs.video/videos/what-happened-to-text-inputs/) (video)
- [Why are my live regions not working?](https://tetralogical.com/blog/2024/05/01/why-are-my-live-regions-not-working/)





Barrierefreie Formulare - Teil3: Validierung

Senior IT-Consultant

Talk "Barrierefreiheit automatisiert testen"

Weitere Infos

Details

Barrierefreiheit automatisiert testen

Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Cloud-Native

Data & Machine Learning

Generative KI

Produktentwicklung

IT-Security

Leistungen

Arbeitsweise

Projekte

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Kultur & Karriere Podcast

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

International contact

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Barrierefreiheit automatisiert testen

Details

Weitere Infos

Talk "Barrierefreiheit automatisiert testen"

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten