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.
Häufige Fragen zu diesem Thema
Was bedeutet Barrierefreiheit bei Web-Apps konkret?+
Barrierefreiheit umfasst deutlich mehr als gute Kontraste. Barrierearme Web-Apps achten auf mehrere Ebenen gleichzeitig: Alle Funktionen sind per Tastatur erreichbar, also ohne Maus bedienbar. Überschriften, Labels und Formularfelder sind semantisch korrekt ausgezeichnet. Texte sind ausreichend groß, klar und gut unterscheidbar. Fehlermeldungen erklären, was fehlt und wie es korrigiert werden kann. Statusänderungen und Formularlogik sind für Screenreader wahrnehmbar. Und Hinweise im Prozess erklären Entscheidungen in einfacher Sprache, statt Amtsdeutsch zu reproduzieren. Gerade bei Antragsstrecken entscheidet diese Kombination darüber, ob Menschen den Vorgang wirklich abschließen können: mit Tastatur, Screenreader, mobilen Geräten, geringer Formularerfahrung oder eingeschränktem Sehvermögen.
Wann sollte Barrierefreiheit in einem Softwareprojekt eingeplant werden?+
So früh wie möglich, am besten von Anfang an in der Architektur. Nachträglich barrierefrei machen ist teuer, weil Probleme dann oft tief in der Struktur liegen. Wenn Komponenten, Formulare und Navigation von Beginn an sauber aufgebaut sind, bleibt der Aufwand kontrollierbar. Das betrifft nicht nur das 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. Besser ist ein laufender Prüfpunkt in jeder Entwicklungsstufe. So werden Barrieren gefunden, solange sie noch günstig zu beheben sind, und die Abnahme bringt keine bösen Überraschungen.
Was können öffentliche Auftraggeber für Barrierefreiheit vorbereiten?+
Öffentliche Auftraggeber müssen nicht jedes technische Detail kennen, sollten Barrierefreiheit aber konkret in die Anforderungen aufnehmen. Hilfreiche Fragen sind: 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? Und soll eine formale Barrierefreiheitsprüfung eingeplant werden? Dazu kommen rechtliche Anforderungen, unter anderem aus BITV und WCAG-orientierten Vorgaben. Der praktische Grund bleibt aber mindestens genauso wichtig: Ein barrierearmer Service produziert weniger Abbrüche, weniger Rückfragen und weniger Frust. Je früher diese Fragen geklärt sind, desto weniger Überraschungen gibt es bei Abnahme und Betrieb.
Tillmann · TFLIT
Entwickelt Software für Unternehmen, Hochschulen und die öffentliche Hand in Baden-Württemberg.
