2. Juli 2026 · 2 Min. Lesezeit
Barrierefreiheit in Web-Apps für die öffentliche Hand
Barrierefreiheit ist kein kosmetischer Zusatz. Für öffentliche Auftraggeber entscheidet sie darüber, ob digitale Services wirklich nutzbar sind.

Tillmann
Gründer von TFLIT

Digitale Verwaltung soll Wege verkürzen. Das gelingt nur, wenn die Anwendung für möglichst viele Menschen bedienbar ist: mit Tastatur, Screenreader, mobilen Geräten, geringer Erfahrung mit Formularen oder eingeschränktem Sehvermögen. Barrierefreiheit ist deshalb kein Design-Extra, sondern Teil der fachlichen Qualität.
Für die öffentliche Hand kommen zusätzlich rechtliche Anforderungen hinzu, unter anderem aus BITV und WCAG-orientierten Vorgaben. Der bessere Grund bleibt trotzdem praktisch: Ein barrierearmer Service produziert weniger Abbrüche, weniger Rückfragen und weniger Frust.
Was Barrierefreiheit konkret bedeutet
Viele denken zuerst an Kontraste. Die sind wichtig, aber nur ein Teil. Gute barrierearme Web-Apps achten auf mehrere Ebenen:
- Tastaturbedienung: Alle Funktionen sind ohne Maus erreichbar.
- Semantik: Überschriften, Labels und Formularfelder sind korrekt ausgezeichnet.
- Kontrast und Lesbarkeit: Text ist ausreichend groß, klar und gut unterscheidbar.
- Fehlermeldungen: Nutzer verstehen, was fehlt und wie sie es korrigieren.
- Screenreader-Kompatibilität: Statusänderungen und Formularlogik sind wahrnehmbar.
- Einfache Sprache im Prozess: Hinweise erklären Entscheidungen, statt Amtsdeutsch zu reproduzieren.
Gerade bei Antragsstrecken entscheidet diese Kombination darüber, ob Menschen den Vorgang abschließen.
Barrierefreiheit muss früh in die Architektur
Nachträglich barrierefrei machen ist teuer. Wenn Komponenten, Formulare und Navigation von Anfang an sauber aufgebaut sind, bleibt der Aufwand kontrollierbar. Das betrifft nicht nur UI-Design, sondern auch technische Entscheidungen: modale Dialoge, dynamische Fehlermeldungen, mehrstufige Formulare und Datei-Uploads müssen zugänglich geplant werden.
Ein häufiger Fehler ist, erst am Ende mit einem Check zu testen. Dann findet man Probleme, die tief in der Struktur liegen. Besser ist ein laufender Prüfpunkt in jeder Entwicklungsstufe.
Was Auftraggeber vorbereiten können
Öffentliche Auftraggeber müssen nicht jedes technische Detail kennen. Hilfreich ist aber, Barrierefreiheit konkret in die Anforderungen aufzunehmen.
- Welche Nutzergruppen müssen sicher erreicht werden?
- Welche Geräte und Hilfsmittel sind wahrscheinlich?
- Welche Formularschritte sind besonders kritisch?
- Gibt es interne Vorgaben oder Prüfstellen?
- Soll eine formale Barrierefreiheitsprüfung eingeplant werden?
Je früher diese Fragen geklärt sind, desto weniger Überraschungen gibt es bei Abnahme und Betrieb.
Fazit
Barrierefreiheit ist bei Web-Apps für die öffentliche Hand kein Haken auf einer Liste, sondern ein Qualitätsmerkmal. Sie macht Services robuster, verständlicher und für mehr Menschen nutzbar. Wer sie früh einplant, spart Nacharbeit und bekommt eine digitale Lösung, die ihrem Anspruch gerecht wird.

Tillmann · TFLIT
Entwickelt Software für Unternehmen, Hochschulen und die öffentliche Hand in Baden-Württemberg.


