Bei einer **barrierefreien Bewerbung** können Kandidatinnen und Kandidaten jeden Schritt mit der Tastatur und assistiven Technologien abschließen. Bedienelemente brauchen eindeutige Beschriftungen, der Fokus muss logisch geführt und gut sichtbar sein, und Fehlermeldungen müssen sich leicht beheben lassen. Ebenso wichtig sind Alternativen zum Ziehen, der Erhalt bereits eingegebener Daten und eine leicht auffindbare Möglichkeit, angemessene Anpassungen anzufordern. WCAG 2.2 AA ist eine praxistaugliche Grundlage. Ob der Ablauf wirklich funktioniert, zeigt jedoch erst ein Test des gesamten Bewerbungsprozesses.

Jeder Abschnitt zählt. Eine Karriereseite kann einen automatisierten Test bestehen, während der Upload des Lebenslaufs, die Datumsauswahl, die Zeitzonenauswahl, eine externe Anmeldung oder die Bestätigungsseite eine Bewerbung unmöglich macht.

## Warum ist die Tastaturbedienung eine Recruiting-Frage und keine Vorliebe von Power-Usern?

**Die Tastaturbedienung entscheidet darüber, ob manche qualifizierten Kandidaten überhaupt in Ihre Pipeline gelangen.** Sie ist nicht bloß eine schnellere Navigationsmethode für erfahrene Nutzer grafischer Oberflächen.

Ein kürzlich veröffentlichter Essay mit der These, [grafische Oberflächen sollten vollständig per Tastatur bedienbar sein](https://ckardaris.com/blog/2026/08/28/keyboard-driven-guis.html), löste auf Hacker News eine lebhafte Debatte aus. Für das Recruiting lässt sich daraus eine konkretere Lehre ziehen: Jede erforderliche Aktion in einer Bewerbung sollte ohne präzise Mausbewegung möglich sein. Außerdem muss jederzeit erkennbar sein, wo der Fokus liegt.

Das hilft blinden Menschen, Menschen mit eingeschränktem Sehvermögen, Menschen, die Spracheingabe nutzen, sowie Menschen mit eingeschränkter Feinmotorik oder ohne Zeigegerät. Fassen Sie diese unterschiedlichen Bedürfnisse aber nicht pauschal unter „Barrierefreiheit verbessert die Bedienbarkeit“ zusammen. Eine Funktion kann für einen Menschen unverzichtbar sein, auch wenn die meisten Kandidaten sie nie bewusst wahrnehmen.

Recruiting-Teams beurteilen Hürden im Bewerbungsprozess häufig anhand der Formularlänge und der Abschlussquote. Bei der Barrierefreiheit zählt eine andere Frage. Fragen Sie nicht nur: „Wie viele Personen haben die Bewerbung abgeschlossen?“, sondern auch: „Konnte eine Person mit dieser Eingabemethode den Vorgang selbstständig abschließen?“ Wer an einer Barriere scheitert, taucht in Ihrem Bewerbertrichter gar nicht erst auf. Übliche Pipeline-Analysen zeigen deshalb nicht, wer nie bei Ihnen angekommen ist.

Das Risiko endet nicht beim ersten Formular. Ein Kandidat muss vielleicht einen Magic Link (Anmeldelink) öffnen, einen fehlerhaften Upload korrigieren, einen Interviewtermin wählen, die Zeitzone ändern, eine Portfoliodatei entfernen, eine externe Authentifizierung abschließen und anschließend an die richtige Stelle zurückkehren. Ihr [Bewerbererlebnis](/docs/the-candidate-experience) ist die Summe dieser Übergänge – nicht der optische Feinschliff des ersten Bildschirms.

## Wie viele Onlinebewerbungen funktionieren mit Screenreadern?

**In einer von Fachleuten begutachteten Studie mit 90 Bewerbungsversuchen konnten erfahrene Screenreader-Nutzer 50 Versuche – also 55,6 % – selbstständig abschließen.** Das Ergebnis gilt für die untersuchten Fortune-500-Websites und Technikkombinationen, nicht für jedes Kandidatenportal oder jeden Menschen mit Behinderung.

[Reuschel, McDonnall und Burton](https://pmc.ncbi.nlm.nih.gov/articles/PMC10961918/) wählten 30 Fortune-500-Arbeitgeber aus. Drei blinde Experten bewarben sich auf jeder Website jeweils einmal und nutzten dabei drei verschiedene Kombinationen aus Browser und Screenreader. Auf 23 der 30 Websites scheiterte mindestens eine Kombination. Nur auf 23,3 % der Websites ließ sich die Bewerbung mit allen drei Kombinationen abschließen.

Die Forscher erfassten 694 Probleme mit der Barrierefreiheit oder Bedienbarkeit, darunter 73 blockierende oder kritische Probleme. Drei Kategorien machten 75 % aller erfassten Probleme aus: Tastaturbedienung, Informationen und Beziehungen sowie Beschriftungen. Probleme mit der Tastaturbedienung traten bei 53 % der blockierenden Fehler auf, Datumsauswahl und Kombinationsfelder bei 34 %.

Diese Zahlen liefern die stärkste Faktenbasis für eine Prüfung der ATS-Barrierefreiheit. Sie bedeuten nicht, dass 44,4 % der Kandidaten eine Bewerbung abgebrochen haben. Die 40 erfolglosen Versuche belegten, dass die Bewerbung unter den jeweiligen Testbedingungen nicht selbstständig abgeschlossen werden konnte – nicht, dass sich jemand freiwillig gegen das Fortsetzen entschied.

Die Studie stellte auch Fortschritte fest. Die Abschlussquote stieg von 28,1 % in einer Vorgängerstudie aus dem Jahr 2011 auf 55,6 %. 26 von 30 Websites funktionierten mit mindestens einer getesteten Kombination. Das eigentliche Problem ist die **mangelnde Zuverlässigkeit über verschiedene Konfigurationen hinweg**. Ein Ablauf kann mit einer Kombination gelingen und mit einer anderen scheitern.

Dabei gelten wichtige Einschränkungen. An der Studie nahmen drei erfahrene blinde Nutzer teil, jeweils einer pro Kombination. Untersucht wurden Portale großer Unternehmen. Erfahrene Nutzer können Mängel umgehen, an denen weniger geübte Menschen scheitern. Die Ergebnisse beziehen sich direkt auf die Screenreader-Nutzung. Stellen Sie sie daher nicht als allgemeine Fehlerquote für eine reine Tastaturbedienung dar.

## Was bedeutet WCAG 2.2 AA für ein Kandidatenportal?

**WCAG 2.2 AA ist eine praxistaugliche technische Grundlage für die Barrierefreiheit von Kandidatenportalen, aber kein weltweit einheitlich geltendes Gesetz.** Bei der Tastaturbedienung geht es darum, ob jede Funktion ohne Zeigegerät erreichbar ist, der Fokus einer sinnvollen Reihenfolge folgt und das fokussierte Bedienelement sichtbar und nutzbar bleibt.

Die [Web Content Accessibility Guidelines 2.2](https://www.w3.org/TR/WCAG22/) übersetzen allgemeine Ziele in prüfbare Kriterien. Für einen Bewerbungsprozess ergibt sich daraus Folgendes:

| WCAG-Kriterium | Was Sie im Bewerbungsablauf prüfen sollten |
|---|---|
| **2.1.1 Tastatur (A)** | Bewerben, hochladen, auswählen, planen, absenden und abbrechen – ohne Maus und ohne zeitkritische Tastenfolgen. |
| **2.1.2 Keine Tastaturfalle (A)** | Dialoge, Kalender, Menüs, Upload-Widgets und eingebettete Werkzeuge mit den erwarteten Tasten öffnen und wieder verlassen. |
| **2.4.3 Fokus-Reihenfolge (A)** | Die Seite in einer Reihenfolge durchlaufen, die den Sinn des Formulars erhält und eingeblendete Fehler oder Bereiche berücksichtigt. |
| **2.4.7 Fokus sichtbar (AA)** | Links, Felder, Schaltflächen, Optionsfelder und benutzerdefinierte Bedienelemente mit einer klaren Fokusmarkierung versehen. |
| **2.4.11 Fokus nicht verdeckt (AA)** | Verhindern, dass fokussierte Elemente hinter fixierten Bewerbungsleisten, Cookie-Bannern oder Dialogen verschwinden. |
| **2.5.1 Zeigergesten (A)** | Eine einfache Alternative zu Mehrpunkt- oder pfadbasierten Gesten anbieten, sofern die Geste nicht unverzichtbar ist. |
| **2.5.7 Ziehbewegungen (AA)** | Für Uploads, Sortierungen und ähnliche Aktionen Schaltflächen oder eine andere Methode ohne Ziehen anbieten. |
| **2.5.8 Zielgröße (AA)** | Ziele für Zeiger mindestens 24 × 24 CSS-Pixel groß gestalten oder die Ausnahmen des Kriteriums für Abstand beziehungsweise gleichwertige Bedienelemente erfüllen. |

Tastaturunterstützung und Screenreader-Unterstützung sind nicht dasselbe. Eine benutzerdefinierte Datumsauswahl kann auf Pfeiltasten reagieren, ohne das gewählte Datum anzusagen. Eine neu eingeblendete Liste mit Interviewterminen kann technisch erreichbar sein, aber keine hörbare Rückmeldung über die Änderung geben. Deshalb sind neben der Tastenbedienung auch semantische Namen, Rollen, Zustände, Beziehungen und Statusmeldungen erforderlich.

Native HTML-Bedienelemente bringen vieles von dem Verhalten mit, das Sie sonst selbst nachbilden müssten. Eine vollständige Lösung sind sie dennoch nicht. Auch ein Eingabefeld kann eine unbrauchbare Beschriftung haben. Und selbst ein sauber beschriftetes Formular kann nach einem einzigen Validierungsfehler sämtliche Antworten löschen.

## So führen Sie den 12-Punkte-Check für barrierefreie Bewerbungen durch

**Prüfen Sie diese 12 Punkte von der Stellenanzeige über das Absenden und den Portalzugang bis zur Interviewplanung.** Testen Sie sowohl den regulären Ablauf als auch Fehlerzustände. Vor allem Validierung, Uploads, dynamische Bereiche und Übergaben an Drittsysteme bringen ansonsten ausgereifte Formulare häufig zum Scheitern.

### 1. Native Bedienelemente vor benutzerdefinierten Widgets einsetzen

Verwenden Sie native Textfelder, Optionsfelder, Kontrollkästchen, Schaltflächen, Links und Dateieingaben, sofern ein benutzerdefiniertes Bedienelement keine notwendige Zusatzfunktion bietet. Native Elemente bringen Tastaturverhalten und Barrierefreiheitssemantik mit, die ein gestaltetes `div` nicht besitzt.

Dokumentieren Sie für jedes benutzerdefinierte Kombinationsfeld, jeden Kalender und jeden modalen Dialog die erwarteten Tasten und angesagten Zustände.

### 2. Jedem Bedienelement einen aussagekräftigen zugänglichen Namen geben

Jedes Feld und jede reine Symbolschaltfläche braucht einen Namen, der den Zweck beschreibt. „Portfoliodatei entfernen“ ist hilfreich, „Schaltfläche“ oder ein unbeschriftetes Papierkorbsymbol ist es nicht. Fassen Sie zusammengehörige Optionsfelder und Kontrollkästchen unter einer aussagekräftigen Frage zusammen.

Verwenden Sie Platzhaltertext nicht als Beschriftung. Pflichtangaben, Formatanforderungen und Hilfetexte sollten programmatisch mit dem Feld verbunden sein, das sie erläutern.

### 3. Eine logische Fokus-Reihenfolge sicherstellen

Navigieren Sie mit der Tabulatortaste vom Seitenkopf bis zur letzten Aktion und anschließend mit Umschalt+Tabulator wieder zurück. Der Fokus sollte der Lese- und Aufgabenreihenfolge folgen. Das gilt auch für bedingte Fragen, die nach einer Antwort eingeblendet werden.

Vermeiden Sie positive `tabindex`-Werte, die eine zweite Reihenfolge für die Seite erzeugen. Wenn eine Zusammenfassung oder ein modaler Dialog geöffnet wird, setzen Sie den Fokus gezielt. Nach dem Schließen gehört er zurück auf ein stabiles Bedienelement.

### 4. Tastaturfokus sichtbar und unverdeckt halten

Bei jedem Schritt sollte eindeutig erkennbar sein, welches Element fokussiert ist. Entfernen Sie die Fokusmarkierung des Browsers nur, wenn Sie sie durch eine ebenso deutliche Markierung auf allen Hintergründen und in allen Zuständen ersetzen.

Prüfen Sie fixierte Kopfzeilen, Einwilligungsbanner und feste Bewerbungsleisten in schmalen und vergrößerten Layouts. WCAG 2.2 hat das Kriterium „Fokus nicht verdeckt“ auf Stufe AA ergänzt, denn ein verdeckter Fokus ist nutzlos.

### 5. Tastaturfallen beseitigen

Öffnen Sie jeden Dialog, jede Datumsauswahl, jedes Menü und jedes Widget eines Drittanbieters. Verlassen Sie es anschließend mit den erwarteten Tastaturbefehlen. Testen Sie die Escape-Taste, wo sie üblich ist. Ein nicht dokumentiertes Tastenkürzel darf jedoch nie der einzige Ausweg sein.

Wiederholen Sie die Prüfung nach einem Validierungsfehler. Fallen entstehen häufig erst, wenn ein Bedienelement seinen Zustand ändert.

### 6. Fehler leicht auffindbar und korrigierbar machen

Setzen Sie den Fokus nach dem Absenden auf eine knappe Fehlerübersicht mit Links zu den betroffenen Feldern. Bei jedem Feld sollte der jeweilige Fehler stehen, der eingegebene Wert erhalten bleiben und die nötige Korrektur klar erklärt werden.

Melden Sie nicht nur „ungültig“. Erklären Sie, was das Feld erwartet. Prüfen Sie anschließend, ob ein Screenreader die Zusammenfassung vorliest und deren Links auf den richtigen Bedienelementen landen.

### 7. Dynamische Zustandsänderungen ansagen

Wenn ein Kandidat ein Datum wählt und neue Zeitfenster erscheinen, kennzeichnen Sie die Auswahl programmatisch und sagen Sie die Änderung an. Dasselbe gilt, wenn ein Upload abgeschlossen, eine Datei entfernt, ein Bereich aufgeklappt oder eine asynchrone Prüfung fehlschlägt.

Sagen Sie an, was der Kandidat zum Fortfahren wissen muss. Verschieben Sie den Fokus nur, wenn der Ablauf sofortige Aufmerksamkeit verlangt.

### 8. Uploads von Lebenslauf und Portfolio bedienbar machen

Behalten Sie eine gewöhnliche Schaltfläche zur Dateiauswahl bei, auch wenn Sie zusätzlich Drag-and-drop anbieten. Zeigen Sie zulässige Formate und Größenbeschränkungen vor der Auswahl an, melden Sie Fortschritt und Fehler und versehen Sie jede hochgeladene Datei mit einer zugänglichen Aktion zum Entfernen.

Setzen Sie den Fokus nach dem Entfernen an eine vorhersehbare Stelle. Testen Sie eine abgelehnte Datei, einen unterbrochenen Upload, eine bereits vorhandene Datei gleichen Namens und einen erneuten Versuch.

### 9. Alternativen zu Ziehen und Präzisionsgesten anbieten

Für jede Sortierfunktion per Ziehen braucht es Schaltflächen zum Verschieben nach oben und unten oder eine gleichwertige Methode. Datumskarussells sollten Schaltflächen oder gewöhnliche Eingabefelder bereitstellen, statt eine Wischgeste vorauszusetzen. Kleine Ziele für Zeiger müssen die WCAG-Regeln zu Mindestgröße oder Abstand erfüllen.

Zeigerbedienung betrifft auch Menschen, die Touchscreens, Schaltersteuerungen oder andere Eingabemethoden verwenden.

### 10. Eingegebene Daten bei Fehlern und Übergaben erhalten

Ein Kandidat sollte eine Bewerbung nicht noch einmal ausfüllen müssen, weil ein einzelnes Feld fehlerhaft war, die Sitzung abgelaufen ist oder eine externe Autorisierung abgebrochen wurde. Bewahren Sie gültige Eingaben und hochgeladene Arbeitsproben auf, soweit dies sicher möglich ist. Erklären Sie, was wiederholt werden muss.

Hartwell, Orr und Edwards stellten fest, dass [der Wegfall einer erneuten Eingabe von Lebenslaufdaten die Abbruchquote senkte](https://onlinelibrary.wiley.com/doi/abs/10.1111/ijsa.12282), ohne Einbußen bei der Bewerberqualität. Die öffentliche Zusammenfassung nennt weder eine Effektgröße noch eine Untergruppe nach Behinderung. Leiten Sie daraus deshalb keinen unbelegten Effekt auf die Abschlussquote ab.

### 11. Unerwartete Zeitbegrenzungen vermeiden

Lassen Sie eine Bewerbung nicht ohne Vorwarnung ablaufen. Ist ein Zeitlimit notwendig, sollte der Kandidat es im Rahmen der einschlägigen WCAG-Ausnahmen verlängern können. Bewahren Sie den bisherigen Stand auf und erklären Sie, wie die Bewerbung fortgesetzt werden kann.

Testen Sie den abgelaufenen Zustand mit Tastatur und Screenreader. Der Hinweis zum Fortsetzen muss erreichbar und verständlich sein.

### 12. Eine persönliche Anlaufstelle für Unterstützungs- und Anpassungsbedarf nennen

Platzieren Sie vor der ersten möglichen Barriere einen klaren Hinweis wie „Benötigen Sie Unterstützung oder eine Anpassung für Ihre Bewerbung?“. Nennen Sie eine regelmäßig betreute E-Mail-Adresse oder eine andere barrierefreie Möglichkeit zur Kontaktaufnahme, geben Sie die voraussichtliche Antwortzeit an und bieten Sie eine alternative Form der Bewerbung.

Verlangen Sie weder detaillierte medizinische Angaben noch, dass Betroffene zunächst den fehlerhaften Ablauf abschließen. Dieses Sicherheitsnetz ersetzt nicht die Reparatur des Portals.

## Warum Sie den gesamten Ablauf testen sollten, statt einem Siegel zu vertrauen

**Automatisierte Tests, Overlays, Siegel und Konformitätsdokumente liefern Anhaltspunkte – sie beweisen nicht, dass Kandidaten sich bewerben können.** Laut W3C können Prüfwerkzeuge nicht jeden Aspekt der Barrierefreiheit prüfen und die Barrierefreiheit nicht allein feststellen.

Die [W3C-Leitlinien zur Auswahl von Prüfwerkzeugen](https://www.w3.org/WAI/test-evaluate/tools/selecting/) empfehlen zusätzlich zu den Werkzeugen eine sachkundige menschliche Bewertung. Ein Scanner erkennt fehlende Beschriftungen, manche Kontrastfehler und ungültiges Markup schnell. Er kann aber nicht zuverlässig beurteilen, ob der Fokus nach einem Fehler an einer sinnvollen Stelle landet, ob die Ansage neuer Zeitfenster verständlich ist oder ob eine externe Anmeldung den Kandidaten in den richtigen Kontext zurückführt.

Die Reuschel-Studie liefert eine weitere praktische Warnung: Selbst Portale, die auf denselben grundlegenden Systemen eines Anbieters basierten, führten zu unterschiedlichen Ergebnissen. Ihre Konfiguration, benutzerdefinierten Fragen, Gestaltungsebene, Skripte, Drittanbieterkomponenten und Integrationen können die Barrierefreiheit nach der Beschaffung verändern. Die Aussage eines Anbieters beweist nicht, dass Ihr konfigurierter Bewerbungsprozess barrierefrei ist.

Arbeiten Sie stattdessen mit einer kleinen, wiederholbaren Testmatrix:

1. Erfassen Sie die entscheidenden Abläufe: eine Stelle finden, sich bewerben, Dateien hochladen, einen Validierungsfehler auslösen, Fehler korrigieren, die Bewerbung absenden, die Eingangsbestätigung sichern, das Portal öffnen, einen Termin planen und verschieben sowie externe Übergaben abschließen.
2. Durchlaufen Sie jeden Ablauf mit Tabulator, Umschalt+Tabulator, Eingabetaste, Leertaste, Pfeiltasten und – wo erwartet – Escape.
3. Testen Sie mehrere Kombinationen assistiver Technologien. Protokollieren Sie Browser, Screenreader, Version, Datum und Ergebnis. Sinnvolle Ausgangspunkte sind NVDA mit Chrome oder Firefox, JAWS mit Chrome oder Edge, sofern verfügbar, sowie VoiceOver mit Safari.
4. Testen Sie gezielt Fehlerfälle: ungültige Dateien, nicht verfügbare Zeitfenster, abgelaufene Sitzungen, fehlgeschlagene Netzwerkanfragen und abgebrochene Autorisierungen.
5. Beziehen Sie Menschen mit Behinderungen in aufgabenbezogene Tests ein. Dokumentieren Sie die einbezogenen Nutzergruppen und Technikkombinationen, ohne die Ergebnisse über diesen Umfang hinaus zu verallgemeinern.

Halten Sie Bewerbungsablauf, Technikkombination, Ergebnis, blockierenden Fehler, verantwortliche Person, Korrektur und Datum des erneuten Tests fest. Führen Sie Tastaturprüfungen bei jedem relevanten Release aus. Wiederholen Sie die Tests mit mehreren Kombinationen nach Änderungen an Formularen, Terminplanung, Authentifizierung, Uploads oder Übersetzungen. Die [Unterstützung mehrerer Sprachen](/docs/multi-language-support) hilft Kandidaten, eine angebotene Sprache zu verwenden. Übersetzung und Barrierefreiheit bleiben jedoch getrennte Testbereiche.

## Was verlangen die Vorschriften in den USA und der EU tatsächlich?

**Es gibt keine einheitliche Vorschrift, die WCAG 2.2 AA für jedes Recruiting-Portal verbindlich macht.** Mitarbeiterzahl, öffentlicher oder privater Status, Art der Dienstleistung, Vertrag und Rechtsraum spielen eine Rolle. Verstehen Sie diesen Abschnitt daher als praktische Orientierung und nicht als Rechtsberatung.

In den USA gilt Title I des ADA für Bewerbungsverfahren bei Arbeitgebern, die dem Gesetz unterliegen, in der Regel ab 15 Beschäftigten. Laut den [Hinweisen der EEOC für Arbeitgeber](https://www.eeoc.gov/publications/ada-your-responsibilities-employer) haben qualifizierte Bewerber Anspruch auf angemessene Anpassungen im Bewerbungsverfahren, sofern dadurch keine unzumutbare Belastung entsteht. Die Auslagerung des Portals hebt die Verantwortung des Arbeitgebers nicht auf.

Für die Webregel des US-Justizministeriums zu Title II gilt etwas anderes. Sie übernimmt **WCAG 2.1 AA**, nicht 2.2, für Webinhalte und mobile Apps, die staatliche und kommunale öffentliche Stellen selbst oder über Anbieter bereitstellen. Die [aktuellen Hinweise des US-Justizministeriums](https://www.ada.gov/resources/web-rule-first-steps/) nennen je nach Größe und Art der öffentlichen Stelle den 26. April 2027 oder den 26. April 2028 als Frist. Daraus entsteht keine pauschale Vorschrift für Websites privater Arbeitgeber.

In der Europäischen Union erfasst der European Accessibility Act ausgewählte Produkte und Dienstleistungen. Seine Definition des elektronischen Geschäftsverkehrs betrifft Dienstleistungen, die auf den Abschluss eines Verbrauchervertrags ausgerichtet sind. Es wäre daher falsch, diese Richtlinie als allgemeine Vorgabe für Recruiting-Portale darzustellen. Websites des öffentlichen Sektors können unter eine eigene Richtlinie fallen. Nationale Gleichbehandlungs-, Arbeits-, Vergabe- und Barrierefreiheitsvorschriften können weitere Pflichten begründen.

Nutzen Sie WCAG 2.2 AA, weil diese Fassung eine aktuelle, praxistaugliche Grundlage bietet und hilfreiche Kriterien wie unverdeckten Fokus, Alternativen zum Ziehen und eine Mindestzielgröße enthält. Stellen Sie diese technische Entscheidung nicht als weltweit geltendes Recht dar. Lassen Sie sich zu den Rechtsordnungen beraten, die für die von Ihnen betreuten Arbeitgeber, Branchen und Länder gelten.

## Wie geht Kit die Barrierefreiheit des Kandidatenportals an?

**Kit versteht das Bewerbererlebnis als durchgängigen Prozess und nicht bloß als Abschluss eines Formulars.** Die aktuelle Umsetzung bietet nützliche Grundlagen für Barrierefreiheit. Kit hat jedoch noch keine vollständige öffentliche Prüfung abgeschlossen und erhebt keinen Anspruch auf Konformität mit WCAG 2.2 AA.

Der Bewerbungsablauf verwendet für die wichtigsten Felder native Beschriftungen und Bedienelemente. Bei einer fehlgeschlagenen Übermittlung erscheint eine fokussierbare Fehlerübersicht mit Links zu den betroffenen Feldern. Eingegebene Werte und der hochgeladene Lebenslauf bleiben gegebenenfalls erhalten, sodass Kandidaten Fehler korrigieren können, statt von vorn zu beginnen. Nach einer erfolgreichen Bewerbung erhalten sie eine dauerhafte, nur lesbare Eingangsbestätigung mit einer Referenznummer, die sie aufbewahren können.

Die [Interviewplanung](/docs/interview-scheduling) verwendet Datumsschaltflächen, native Optionsfelder für Zeitfenster, sichtbare Fokusmarkierungen und einen nativen Dialog zur Terminverschiebung mit einem zugänglichen Namen. Browsertests prüfen die Tastaturbedienung im getesteten Bereich der Terminplanung. Kandidatenseiten können außerdem Sprachoptionen für Englisch, Deutsch, Französisch, Spanisch und Polnisch anbieten.

Einige Arbeiten stehen noch aus. Das Kandidatenportal braucht einen Sprunglink und ein fokussierbares Hauptziel. Eingeblendete Datumsbereiche benötigen eine deutlichere Fokusführung oder Live-Region-Ansagen. Die dynamisch erzeugte Schaltfläche zum Entfernen einer Datei braucht einen zugänglichen Namen; danach muss der Fokus gezielt zurückgesetzt werden. Auch die erweiterte Zeitzonenauswahl und die Rückkehr nach einer GitHub-Autorisierung müssen noch vollständig mit Tastatur und Screenreader in allen unterstützten Technikkombinationen getestet werden.

Gerade deshalb leiten wir aus einigen soliden Komponenten keine pauschale Aussage zur Barrierefreiheit ab. Als Nächstes gilt es, diese Lücken zu schließen, den Ablauf mit mehreren Technikkombinationen zu prüfen, Menschen mit Behinderungen einzubeziehen, den geprüften Umfang zu veröffentlichen und die daraus entstandenen Tests dauerhaft in den Release-Prozess aufzunehmen.

<div class="blog-inline-cta">
  <p><strong>Möchten Sie den Bewerbungsprozess selbst prüfen?</strong> Sehen Sie sich das Bewerbungsformular von Kit mit eindeutigen Beschriftungen, die Fehlerübersicht mit Feldlinks, die dauerhafte Eingangsbestätigung und die per Tastatur getestete Terminplanung an. Prüfen Sie uns anschließend anhand derselben 12 Punkte.</p>
  <p><a href="/users/sign_up">Kostenlos testen</a></p>
</div>

Eine barrierefreie Bewerbung ist kein Siegel, das Sie einmal kaufen. Der gesamte Prozess muss auch nach Änderungen an Formularen, Integrationen, Sprachen und Phasen im Recruiting bedienbar bleiben. Testen Sie alle Schritte, dokumentieren Sie Hindernisse, bieten Sie eine persönliche Anlaufstelle und beheben Sie alles, was qualifizierte Menschen davon abhält, Ihr Team zu erreichen.