Bildquelle: Pexels / https://www.pexels.com/photo/man-using-a-braille-6981098/
Wenn Serviceportale Barrieren bauen, wandern Anfragen zurück in Telefon und Mail
Self-Service gilt in vielen IT-Organisationen als Hebel gegen Ticketstau, Medienbrüche und unnötige manuelle Freigaben. In der Praxis kippt dieser Effekt jedoch schnell, wenn das Portal selbst Hürden aufbaut. Dann endet der angeblich digitale Standardweg wieder bei Anrufen, Sammelpostfächern oder individuellen Chat-Nachrichten an den Service Desk. Das ist kein Randthema für Designliebhaber, sondern eine operative Frage von Erreichbarkeit, Datenqualität und Kosten.
Besonders tückisch ist: Viele Portale wirken auf den ersten Blick modern, sind aber in entscheidenden Situationen nicht belastbar. Die Anmeldung fordert umständliche Eingaben, Formulare laufen in Timeouts, Fehlermeldungen erscheinen nur visuell, Uploads bleiben unklar und Statuswechsel sind für assistive Technologien nicht sauber erkennbar. Genau dort verliert Self-Service seine Skalierungswirkung.
Für ITSM-Teams ist Barrierefreiheit deshalb kein Zusatzmodul, das man nach einem Relaunch abhakt. Sie entscheidet ganz direkt darüber, ob Nutzer Anträge selbst durchbekommen, ob Statusinformationen verstanden werden und ob ein Portal wirklich Anfragen kanalisiert oder nur einen weiteren Frustpunkt im Betriebsmodell erzeugt.
Self-Service scheitert oft nicht am Katalog, sondern an der Benutzbarkeit
Viele Teams investieren viel Zeit in Servicekataloge, Automatisierung und Freigabelogik. Der Engpass liegt dann trotzdem an einer unscheinbaren Stelle: Die Nutzerschnittstelle verlangt Fähigkeiten, Geduld oder Zusatzschritte, die im Alltag nicht zuverlässig funktionieren. Wer eine Leistung nur beantragen kann, wenn er kleine Statushinweise sieht, komplexe Feldgruppen korrekt interpretiert oder Session-Timeouts rechtzeitig bemerkt, wird den Prozess im Zweifel abbrechen.
Die betriebliche Folge ist messbar. Aus einem strukturierten Request werden unvollständige E-Mails. Aus standardisierten Pflichtangaben werden Rückfragen. Aus einem skalierbaren Formularprozess wird ein Sonderfall im First Level. Gerade in großen Organisationen tauchen diese Verluste nicht sofort als Accessibility-Problem auf, sondern als diffuse Mehrlast im Service Desk, schlechtere Datenqualität im Ticket und sinkende Akzeptanz für Self-Service.
Deshalb sollten IT-Leitungen Barrierefreiheit nicht nur unter Compliance oder Corporate Design verbuchen. Sie ist ein Faktor für Kanalsteuerung. Ein Portal, das nur für einen Teil der Nutzer zuverlässig bedienbar ist, erzeugt parallel laufende Schattenkanäle – und damit genau die Intransparenz, die man durch Self-Service eigentlich abbauen wollte.
Anmeldung und MFA sind der erste harte Bruch
Die WCAG-2.2-Erläuterung zu „Accessible Authentication“ macht einen Punkt besonders klar: Authentifizierung darf Menschen nicht unnötig zum Merken, Rätseln oder Abtippen zwingen. Für Serviceportale ist das hochrelevant, weil viele Anfragen heute schon vor dem eigentlichen Formular scheitern. Wenn Login, Kennwortwechsel, Einmalcodes oder Recovery-Prozesse kognitiv unnötig anstrengend sind, erreicht der Nutzer den Servicekatalog gar nicht erst.
Praktisch bedeutet das für IT-Portale: Copy-and-paste darf nicht künstlich blockiert werden. Ein alternativer Anmeldeweg ohne visuelle oder kognitive Hürde sollte vorhanden sein. Und auch der Recovery-Pfad gehört zur Prüfung, nicht nur der normale Happy Path. Denn gerade bei Gerätewechsel, Passwort-Reset oder zweitem Faktor zeigt sich, ob ein Portal für den Alltag gebaut wurde oder nur für idealisierte Standardfälle.
Für ITSM ist das mehr als UX. Ein unzugänglicher Login verschiebt Arbeit direkt zurück in den Support: „Ich komme nicht rein“, „Der Code funktioniert nicht“, „Ich sehe nicht, was erwartet wird“, „Nach dem Ablauf der Session ist alles weg“. Solche Kontakte sind teuer, wiederholen sich häufig und unterlaufen die versprochene Effizienz des digitalen Kanals.
Formulare, Timeouts und Pflichtfelder erzeugen den größten Reibungsverlust
W3C verweist im Formular-Tutorial darauf, dass Formulare häufig für Login, Registrierung, Kommentare oder Kaufprozesse genutzt werden und deshalb sauber, kurz und verständlich sein müssen. Genau diese Logik gilt eins zu eins für Serviceportale. Je mehr unnötige Felder, verschachtelte Auswahlregeln und schlecht beschriftete Eingaben ein Request enthält, desto höher die Abbruchwahrscheinlichkeit.
Kritisch sind vor allem drei Muster. Erstens: unklare Pflichtfelder oder Feldbeziehungen, die nur farblich oder räumlich erklärt werden. Zweitens: Zeitlimits, die ohne Vorwarnung zuschlagen oder sich nicht verlängern lassen. Drittens: Fehlermeldungen, die zwar irgendwo auf der Seite erscheinen, aber weder Fokus noch assistive Technologien zuverlässig erreichen. Dann weiß der Nutzer oft nicht, warum ein Antrag nicht weitergeht.
Für den Betrieb heißt das: Gute Formulare fragen nur das wirklich Nötige ab, erklären Datenbedarf verständlich und lassen sich ohne Hektik vervollständigen. Wenn Sicherheits- oder Prozessgründe ein Timeout erzwingen, braucht es eine saubere Vorwarnung und eine reale Verlängerungsoption. Sonst vernichtet das Portal in wenigen Minuten genau die Datenqualität, die es eigentlich standardisieren sollte.
Statusmeldungen entscheiden über Vertrauen in den Prozess
Ein zweiter häufig unterschätzter Punkt sind Statusmeldungen. WCAG 4.1.3 fordert sinngemäß, dass wichtige Zustandsänderungen für assistive Technologien erkennbar sein müssen, ohne den Nutzer unnötig aus dem Arbeitsfluss zu reißen. In Serviceportalen betrifft das fast jeden Schritt: „Ticket erfolgreich erstellt“, „Upload abgeschlossen“, „Pflichtfeld fehlt“, „Genehmigung ausstehend“, „System beschäftigt“ oder „Antrag wurde gespeichert“.
Wenn diese Meldungen nur optisch in einer Ecke aufblinken, entsteht operative Unsicherheit. Nutzer senden Formulare mehrfach, laden Anhänge erneut hoch oder wechseln frustriert auf E-Mail, weil sie dem Portalstatus nicht trauen. Der Effekt ist im Backend sofort sichtbar: Dubletten, Nacharbeiten und Rückfragen.
Gerade Service- und Workflow-Teams sollten deshalb Statuskommunikation als Teil des Prozessdesigns behandeln. Ein Request ist nicht fertig, nur weil der API-Call erfolgreich war. Er ist erst dann belastbar, wenn der Nutzer seinen Fortschritt, Fehlerzustand oder Abschluss auch tatsächlich nachvollziehen kann – unabhängig davon, ob er Maus, Tastatur, Screenreader oder vergrößerte Darstellung nutzt.
Wissensartikel, Anhänge und Prozesswechsel gehören mit in den Scope
Viele Portale bestehen nicht nur aus einem Formular. Dahinter liegen Wissensartikel, Download-Dokumente, Upload-Schritte, Terminbuchungen, Chat-Widgets oder Wechsel in andere Systeme. Genau an diesen Übergaben reißt Barrierefreiheit oft ab. Ein sauber zugängliches Startformular nützt wenig, wenn der Pflichtanhang nur als schlecht lesbares PDF bereitsteht oder der nachgelagerte Freigabeschritt in einem eingebetteten Fremdtool nicht per Tastatur bedienbar ist.
Für ITSM ist das ein klassischer Übergabefehler. Teams testen den Hauptscreen, aber nicht den realen Nutzungspfad. Dabei entsteht die eigentliche Servicequalität erst entlang der gesamten Strecke: Einstieg, Identifikation, Datenerfassung, Bestätigung, Statusverfolgung und gegebenenfalls Wissensnutzung oder Rückfrage. Wer nur den ersten Bildschirm optimiert, aber die Prozesskette nicht prüft, baut ein formal hübsches und operativ schwaches Portal.
Worauf ITSM- und Portal-Teams jetzt konkret achten sollten
- Login und Recovery zusammen testen: Nicht nur den Standard-Login prüfen, sondern auch Passwortwechsel, Gerätewechsel, MFA-Alternativen und Wiederherstellung.
- Formulare entschlacken: Nur notwendige Angaben abfragen, Pflichtfelder klar kennzeichnen und Hilfetexte nicht allein visuell vermitteln.
- Timeouts ernst nehmen: Vorwarnung, Verlängerung und Zwischenspeicherung sind im Servicekontext wichtiger als bei Marketing-Formularen.
- Statusmeldungen als Betriebsfunktion behandeln: Erfolg, Fehler, Warten und Fortschritt müssen zuverlässig wahrnehmbar sein.
- Ende-zu-Ende testen: Wissensartikel, Anhänge, Fremdtools und Genehmigungsschritte gehören in dieselbe Prüfung wie das Portal selbst.
- Fallback-Daten auswerten: Telefon- und Mail-Eingänge sollten darauf untersucht werden, welche Portalhürden sie ausgelöst haben.
Fazit
Barrierefreiheit im Serviceportal ist kein Randthema und kein reiner Compliance-Check. Sie entscheidet darüber, ob Self-Service Anfragen wirklich kanalisiert oder ob Nutzer zurück in Telefon, Mail und manuelle Sonderwege gedrängt werden. Für ITSM-Organisationen ist das eine Frage von Betriebsqualität, Steuerbarkeit und Kosten.
Wer Portalbarrieren abbaut, verbessert nicht nur die Nutzbarkeit für Menschen mit Einschränkungen. Er reduziert ganz allgemein Reibung in Anmeldung, Formularen, Statuskommunikation und Übergaben. Genau dort entsteht am Ende der Unterschied zwischen einem Portal, das auf Folien gut aussieht, und einem Portal, das im Alltag tatsächlich Last aus dem Service nimmt.
