Zugänglichkeit an der konkreten Aufgabe prüfen

Barrierefreies Webdesign für nutzbare Aufgaben und klare Rückmeldungen

Eine Website muss sich auch ohne Maus, mit Vergrößerung und mit assistiven Technologien verständlich bedienen lassen. Eloquin verbindet Gestaltung, semantische Umsetzung und manuelle Aufgabenprüfungen. Wir vereinbaren, welche Seiten, Komponenten und Zustände bearbeitet werden und woran ihre Abnahme erkennbar ist.

Zugänglichkeit besprechen Aufgabenplan lesen

Gestaltung und Umsetzung

Die wichtigen Wege prüfen, statt nur einzelne Farben zu ändern

Neue Komponenten planen

Navigation, Dialoge, Formulare und Inhaltsbausteine erhalten verständliche Strukturen, erkennbare Zustände und passende Bedienregeln. Zugänglichkeit wird im Entwurf mitgedacht und im umgesetzten Zustand geprüft.

Bestehende Hindernisse bearbeiten

Wir verfolgen eine Aufgabe vom Einstieg bis zur Rückmeldung. Kritische Blockaden, wiederverwendete Komponenten und redaktionelle Ursachen werden getrennt priorisiert; nicht jede Einzelkorrektur verlangt einen neuen Gesamtauftritt.

Prüfumfang nachvollziehbar machen

Seitentypen, Zustände, Browser und Hilfsmittel werden benannt. Automatische Befunde, manuelle Prüfungen, behobene Probleme und verbleibende Grenzen bleiben im Protokoll unterscheidbar.

Die Usability-Optimierung betrachtet Verständlichkeit und Aufgabenerfolg breiter. Hier stehen Zugänglichkeit und technische Bedienbarkeit im vereinbarten Umfang im Mittelpunkt. Die Einordnung eines Barrierefreiheits-Widgets ist eine eigene Entscheidung; eine zusätzliche Werkzeugleiste repariert nicht automatisch den zugrunde liegenden Ablauf.

Ein vollständig formulierter Prüfauftrag

Eine Reparaturanfrage mit Tastatur bis zur verständlichen Rückmeldung führen

Das Beispiel verbindet sichtbare Texte mit konkreter Bedienung. Damit lässt sich die spätere Abnahme beauftragen, ohne aus einem Scanwert eine vollständige Zusicherung abzuleiten.

Illustratives Aufgabenmodell · kein ausgeführtes Kundenaudit

Aufgabe: Bei einem fiktiven Reparaturdienst eine Reparatur anfragen. Das Muster ist eine Spezifikation, kein zusätzliches Formular auf dieser Seite.
Felder: Name, E-Mail-Adresse und Reparaturanliegen sind im Modell erforderlich; Telefon ist freiwillig. Labels bleiben sichtbar. Pflichtangaben und erwartete Inhalte stehen vor der Eingabe fest.
Handlung: Der Button lautet „Reparatur anfragen“. Er verspricht weder eine Terminbuchung noch die erfolgreiche Zustellung einer E-Mail.
Ausgabe: Aufgabenplan, konkrete Zustandsregeln, Prüfkriterien und Restpunktliste. Eine Prüfung wird später mit Datum, Umgebung und tatsächlichem Ergebnis protokolliert.

1 · Einstieg und Fokus

Bedienregel: Mit Tastatur die Hauptnavigation überspringen und die Inhaltsüberschrift erreichen. Die Eingabereihenfolge folgt Name, E-Mail, Telefon, Anliegen und Anfragebutton; erläuternde Texte werden nicht künstlich zu Tabstopps.
Abnahme: Alle Bedienelemente lassen sich ohne Maus nutzen. Der Fokus ist erkennbar; fixierte Navigation und Hinweise verdecken das fokussierte Element im festgelegten Prüffall nicht. Es entsteht keine Tastaturfalle.

2 · E-Mail fehlt

Ausformulierter Text: „Bitte geben Sie eine E-Mail-Adresse ein, unter der wir auf Ihr Anliegen antworten können.“ Die Meldung steht am betroffenen Feld; die Zusammenfassung nennt die E-Mail-Adresse als fehlende Angabe.
Abnahme: Der Fehler ist nicht nur farbig markiert. Feldname, Fehlerzustand und zugehöriger Hinweis sind mit dem vereinbarten Screenreader auffindbar. Bereits gültige Eingaben bleiben erhalten; eine Korrektur ist mit Tastatur möglich.

3 · Bearbeitung läuft oder scheitert

Rückmeldung: Während der Verarbeitung heißt der Zustand „Anfrage wird verarbeitet“. Bei fehlgeschlagener Speicherung: „Die Anfrage konnte nicht gespeichert werden. Ihre Angaben bleiben erhalten. Bitte versuchen Sie es erneut.“
Abnahme: Eine sichtbare Ladeanzeige ist auch für die vereinbarte Hilfsmittelnutzung verständlich. Nach einem Fehler wird der Anfragebutton wieder nutzbar; das Formular bleibt erreichbar und es erscheint keine Erfolgsmeldung.

4 · Technisch angenommen

Ausformulierter Text: „Ihre Reparaturanfrage wurde angenommen. Ein Reparaturtermin ist damit noch nicht bestätigt.“ Die Aussage erscheint erst nach entsprechender Backendantwort.
Abnahme: Die Rückmeldung wird sichtbar und für assistive Technologie wahrnehmbar ausgegeben. Ob eine Statusmeldung ohne Fokuswechsel angekündigt oder ein neuer Bestätigungsbereich gezielt fokussiert wird, ist als konsistentes Verhalten festgelegt und manuell geprüft.

Sechs Aufgaben für die spätere Abnahme

Nur Tastatur: Einstieg, alle Felder, Fehlerrückkehr und erneutes Absenden in einer nachvollziehbaren Reihenfolge durchlaufen.
Mit Screenreader: Labels, Pflichtstatus, Hinweise und Fehlermeldung mit der vereinbarten Browser-/Screenreader-Kombination prüfen und diese im Bericht nennen.
Vergrößerung: Textvergrößerung auf 200 Prozent prüfen. Für den normalen vertikal gelesenen Formularinhalt zusätzlich den Umbruch bei einer Breite entsprechend 320 CSS-Pixeln kontrollieren; Angaben und Bedienung dürfen dabei nicht verloren gehen.
Erkennbare Zustände: Fokus, Fehler und Buttonzustände dürfen nicht allein durch eine schwer erkennbare Farbänderung vermittelt werden. Kontraste werden an den tatsächlichen Komponenten gemessen.
Fehlerpfad: Leere E-Mail und einen kontrollierten Speicherfehler mit Testdaten auslösen; Werterhalt, Korrektur und erneute Bedienung prüfen.
Annahmepfad: Technische Annahme mit Testtransport prüfen. Rückmeldung und etwaige Benachrichtigung getrennt bewerten; keine echte Reparaturanfrage versenden.

Das ist ein ausgearbeiteter Prüfplan. Die Fälle wurden hier nicht als Kundentest ausgeführt; sie decken auch nicht alle Anforderungen an eine Website ab.

Prüfmaßstab und Grenzen

Einzelne Kriterien sind kein pauschales Gütesiegel

Die WCAG 2.2 des W3C enthalten überprüfbare Anforderungen. Im Modell sind unter anderem Tastaturbedienung, sichtbarer Fokus und dessen Verdeckung relevant. Welche Konformitätsstufe und welcher vollständige Umfang für Ihr Vorhaben gelten sollen, wird ausdrücklich vereinbart.

Die Erläuterungen zu Fehlererkennung, Statusmeldungen und Umbruch bei Vergrößerung helfen, die Modellfälle zu verstehen. Sie ersetzen weder die übrigen Kriterien noch eine Prüfung aller vereinbarten Seitentypen und vollständigen Prozesse.

Auch das W3C beschreibt Grenzen automatischer Prüfwerkzeuge. Fremdkomponenten, Dokumente, Videos und später ergänzte Inhalte brauchen eine eigene Vereinbarung. Rechtlicher Anwendungsbereich und gegebenenfalls erforderliche Nachweise werden gesondert geklärt; es wird keine pauschale Rechtskonformität zugesagt.

Vom Umfang zur erneuten Prüfung

Sie erhalten einen nachvollziehbaren Korrekturauftrag

Aufgaben und Grundlage

URLs, Komponenten, Inhalte und vorhandene Berichte aufnehmen. Normbezug, Stichprobe und unterstützte Nutzungsumgebungen festlegen.

Gestalten und umsetzen

Barrieren in Design, Markup und Zustandslogik bearbeiten. Redaktionelle Regeln und die Behandlung externer Bausteine dokumentieren.

Nachprüfen und übergeben

Die geänderten Aufgaben erneut prüfen. Befunde, Restpunkte und Zuständigkeiten übergeben; zukünftige Inhalts- und Komponentenänderungen in die Pflege aufnehmen.

Die Webentwicklung setzt die vereinbarten Komponenten um. Unter eigene Arbeitsbeispiele ist der öffentliche Eloquin-Auftritt einsehbar; daraus wird keine abgeschlossene Barrierefreiheitszertifizierung abgeleitet.

Gut zu wissen

Fragen zu Barrierefreies Webdesign

Ist die Website nach einem automatischen Scan barrierefrei?

Nein. Automatische Werkzeuge liefern Befunde für einen Teil der Anforderungen. Ob sich Navigation, Formulare und Zustandswechsel mit Tastatur und den vereinbarten Hilfsmitteln tatsächlich bewältigen lassen, muss zusätzlich manuell geprüft werden. Eine Stichprobe ist keine vollständige Konformitätsprüfung der ganzen Website.

Ersetzt ein Barrierefreiheits-Widget die Arbeit am Webdesign?

Ein Widget kann zusätzliche Darstellungsoptionen anbieten. Fehlende Beschriftungen, unzugängliche Bedienelemente oder fehlerhafte Abläufe müssen jedoch an Inhalt, Struktur und Technik bearbeitet werden. Ein vorhandenes Widget wird auf Nutzen und mögliche Konflikte geprüft; sein Einbau allein ist keine Abnahme.

Wird eine pauschale Rechtskonformität bestätigt?

Nein. Anwendungsbereich, geforderte Norm und gewünschter Nachweis werden vor dem Auftrag geklärt. Ein vereinbarter technischer Prüfumfang, etwa anhand ausgewählter WCAG-2.2-Kriterien, ist von einer vollständigen Konformitätsbewertung und rechtlichen Einordnung zu unterscheiden. Eine Zertifizierung wird hier nicht angeboten oder behauptet.

Können vorhandene Seiten gezielt verbessert werden?

Ja. Wir erfassen zuerst die kritischen Nutzeraufgaben und betroffenen Komponenten. Sie erhalten einen abgegrenzten Korrektur- und Prüfauftrag mit Prioritäten, dokumentierten Restpunkten und erneuter Prüfung der geänderten Zustände. Ein kompletter Relaunch ist daraus nicht automatisch erforderlich.

Ihr Vorhaben einordnen

Welche Aufgabe ist auf Ihrer Website schwer zugänglich?

Nennen Sie die betroffene URL, die gewünschte Nutzeraufgabe und bekannte Hindernisse. Wenn es bereits Prüfberichte oder ein vereinbartes Konformitätsziel gibt, beschreiben Sie diese kurz. Zugangsdaten und sensible Nutzerdaten gehören nicht in die erste Anfrage.

Zugänglichkeit besprechenUmfang und Voraussetzungen gemeinsam klären