Moin! Ich bin Annika, Junior-Entwicklerin in Team ID, das sich bei T2med um die Online-Dienste kümmert und in diesem Blogbeitrag möchte ich davon berichten, wie wir unsere Online-Terminbuchung in Hinblick auf Barrierefreiheit überarbeitet haben. Zunächst ein paar Worte dazu, wie dieses Projekt entstanden ist: An mein Praktikum, über das ich ebenfalls bereits hier berichtet habe, habe ich in der Firma direkt meine Masterarbeit angeschlossen. Darin habe ich mich mit Tools und Techniken beschäftigt, die einem Unternehmen wie T2med helfen können, zuverlässig barrierefreie Software herzustellen. Das war alles recht theoretisch und es hat mich in den Fingern gejuckt, das Gelernte in der Praxis umzusetzen. Da bei T2med niemand mit guten Ideen aufgehalten werden soll, war somit dieses Projekt geboren.
Barrierefreiheit – Was ist damit überhaupt gemeint?
Bevor ich mich in meiner Masterarbeit intensiv mit dem Thema beschäftigt habe, habe ich bei Barrierefreiheit immer nur an Rampen für Menschen in Rollstühlen gedacht. Inzwischen weiß ich, das Thema ist doch bedeutend größer und auch in der digitalen Welt von Bedeutung. Personen in Rollstühlen haben eher selten Probleme damit, Software zu benutzen (jedenfalls nicht mehr als alle anderen Menschen auch). Anders kann es jedoch aussehen, wenn andere Fähigkeiten oder Sinne eingeschränkt sind. Das kann den Sehsinn von Rot-Grün-Schwäche bis Blindheit betreffen oder auch den Hörsinn von Schwerhörigkeit bis Taubheit. Wenn die Motorik der Hände eingeschränkt ist, ob sie nun zittern, steif sind oder amputiert, wird es auch ungleich schwerer, einen Computer mit einer herkömmlichen Maus zu bedienen. Unterstützen können hier assistive Technologien wie Screenreader (Software, die vorliest, was auf dem Bildschirm steht), Bildschirmlupen und Sprachsteuerung oder auch einfach die Bedienung über die Tastatur. Für die gleichberechtigte Teilhabe aller Menschen – übrigens ein Menschenrecht – ist es entscheidend, dass Software und Webseiten diesen Bedienmethoden keine Barrieren in den Weg stellen und dass Informationen immer auf unterschiedlichen sensorischen Wegen zugänglich sind.
Von Barrierefreiheit profitieren nebenbei gesagt auch mehr Menschen, als man auf den ersten Blick annehmen würde. Das wird sehr schnell deutlich, wenn man in der hellen Sonne versucht, etwas mit schlechtem Kontrast auf dem Handy-Display zu erkennen, die Lesebrille mal wieder verlegt hat oder sich den Arm bricht und temporär auf ihn verzichten muss. Barrierefreiheit betrifft also immer mal wieder jeden und jede von uns.
Umsetzung
Nachdem nun geklärt ist, was mit Barrierefreiheit gemeint ist, ist die nächste spannende Frage die nach der Umsetzung in unserer Online-Terminbuchung. Zunächst war es notwendig, eine Liste aller Barrieren/Defekte zu erstellen. Dafür wurden die 86 Kriterien der Web Content Accessibility Guidelines (WCAG) in der Version 2.2 hinzugezogen. Die WCAG sind der aktuell relevanteste Standard für Barrierefreiheit. Tatsächlich sind sie so relevant, dass sich weltweit verschiedenste Gesetzgebung zu Barrierefreiheit von Webanwendungen und anderer Software auf sie beziehen.
Um die Barrieren zu finden, habe ich Lighthouse eingesetzt, ein im Chrome-Browser integriertes Tool, das automatisiert Probleme feststellen kann. Die meisten Kriterien der WCAG lassen sich jedoch nicht automatisiert testen und daher war ebenfalls eine manuelle Analyse notwendig. Diese habe ich mir mit dem vom W3C bereitgestellten WCAG-EM Report Tool etwas leichter gemacht. Hiermit kann man nacheinander pro Seite alle Kriterien durchgehen und mit Begründung vermerken, ob diese erfüllt sind, nicht zutreffen oder eben einen Defekt darstellen. Die Nutzung von Lighthouse kann ich sehr empfehlen, vor allem, wenn man nicht weiß, wo man starten soll. Um die manuelle Analyse durchführen zu können, ist ein grundlegendes Verständnis der WCAG notwendig und ich werde das hier nicht schönreden: Das war kompliziert, anstrengend und hat nicht immer Spaß gemacht, gerade da die WCAG stellenweise großen Interpretationsspielraum zulassen. Das WCAG-EM Report Tool hat mir dabei geholfen, den Überblick nicht zu verlieren. Außerdem hat sich der Screenreader hier als wertvolles Werkzeug erwiesen - denn er verzeiht so gut wie keine semantischen Fehler und deckt auf diese Weise Barrieren auf, die auch andere assistive Technologien oder die Bedienung durch die Tastatur beeinträchtigen würde.
Danach habe ich aus den gefundenen Barrieren pro Seite oder Komponente Tickets erstellt, die die Anforderungen enthalten, diese mit dem zuständigen Product Owner abgestimmt und zusammen mit dem Team ging es dann in die Umsetzung. Hier haben sich schnell die nächsten Hürden bemerkbar gemacht. Es ist viel leichter, anhand von Kriterien festzustellen, wie etwas nicht gemacht werden sollte, als klar zu sagen, wie es denn richtig wäre und das dann auch noch gut aussehen zu lassen. An einigen Stellen mussten wir also recherchieren und ein wenig experimentieren, bis wir einen Weg gefunden haben, mit dem wir zufrieden waren. An anderen Stellen wurde schnell klar, dass wir auf Input von unserer Designerin Katharina Schluck angewiesen sind, wenn es vernünftig werden soll. Mit ihrer Unterstützung konnten wir noch eine ganze Reihe weitere UX-Schwächen beheben, so dass das Bedienen unserer Online-Terminbuchung nun für alle Patientinnen und Patienten von T2med-Praxen eine bessere Erfahrung sein dürfte. Letztendlich haben wir von initial 35 nicht bestandenen WCAG-Kriterien alle bis auf sechs lösen können und darüber hinaus erstrahlt das Design der Terminbuchung auch noch in neuem Glanz. Von den sechs ungelösten Kriterien befinden sich die meisten auf dem höchsten Level der WCAG und gelten somit ein wenig als Kür. Natürlich haben wir alles, was mit vertretbarem Aufwand auf diesem höchsten Level lösbar war, trotzdem gelöst.
Ein kleiner Teil unserer Arbeit kann in den beiden folgenden Screenshots im Vorher-Nachher-Vergleich betrachtet werden. Zu sehen ist hier z. B., dass wir die Farben leicht angepasst haben, sodass sie nun den Kontrastanforderungen genügen und wo es nötig war, sind Schaltflächen und Schrift größer als zuvor. Das visuelle Layout folgt nun mit der Infobox, die von rechts außen nach oben gewandert ist, auch der Reihenfolge im HTML-Dokument und außerdem zeigt sie standardmäßig nur noch die relevantesten Informationen. Die Fortschrittsanzeige oben ist nun in sinnvollere Schritte gegliedert und darüber hinaus noch zur Navigationsmöglichkeit geworden. In beiden Screenshots liegt der Tastaturfokus auf dem Weiter-Button, wirklich klar erkennbar ist dies aber nur in der überarbeiteten Version.
Herausforderungen
Abgesehen davon, dass es immer herausfordernd ist, etwas zum ersten Mal zu machen, sind ein paar Schwierigkeiten aufgetreten, die ich hier noch etwas detaillierter beschreiben möchte. Beim Entwickeln unter dem Aspekt Barrierefreiheit wirken immer viele Komponenten zusammen. Wenn z. B. der Screenreader etwas nicht sinnvoll vorliest, kann es sehr schwierig sein, festzustellen, ob der gefundene Defekt ein Fehler unserer Software ist, ein Bug im Screenreader selbst ( die Dinger arbeiten manchmal echt nicht für einen) oder im Browser. Denn unterschiedliche Browser präsentieren dem Screenreader die Informationen auf unterschiedliche Art und Weise und nicht alles ist da überall miteinander kompatibel. Dass das Verhalten im Zusammenspiel teilweise so schwer vorherzusagen ist, kann eine sehr frustrierende Erfahrung sein, von der man sich nicht entmutigen lassen sollte.
Eine weitere große Herausforderung bestand darin, dass uns oft unklar war, welches Verhalten nun das erwünschte ist. Wie muss etwas vorgelesen werden, damit es verständlich ist? Wie muss ein Link beschriftet sein, so dass klar ist, wohin er führt, wie muss dieser Button heißen, damit seine Funktion eindeutig ist und wie viel Anleitung ist nötig und ab wann ist sie vielleicht sogar störend? Wir haben all diese Fragen nach bestem Wissen und Gewissen beantwortet, teilweise lange diskutiert und uns mehrfach umentschieden. Ich bin mit dem Ergebnis nun zufrieden, denn wir sind sorgfältig vorgegangen und haben unser Bestes getan, aber mir ist klar, dass es da noch Lücken geben muss. Im Grunde fehlt uns Feedback von Menschen, die es betrifft. Das wäre in Zukunft in der Entwicklung wünschenswert.
Learnings
Ich habe bei diesem Projekt wahnsinnig viel dazu gelernt. Ein paar der Key-Learnings möchte ich hier gerne teilen. Das erste betrifft den Themenkomplex WCAG. Diese sind aktuell die ausführlichste und beste Anleitung zum Schreiben barrierefreier Software, die es gibt. Sie sind im Grunde alternativlos. Gleichzeitig sind sie jedoch schwer zu lesen, kompliziert zu verstehen und teilweise zu abstrakt. Es ist möglich, sie zu befolgen und trotzdem Barrieren einzubauen. Mit dieser Kritik bin ich nicht allein und ich bin gespannt, ob diese Probleme mit den WCAG 3.0 erfolgreich angegangen werden. Denn diese sind bereits in der Entwicklung, auch wenn sie sicherlich noch einige Jahre auf sich warten lassen werden.
Das zweite Learning betrifft das UI/UX-Design. Was Barrierefreiheit angeht, nimmt es eine Schlüsselposition ein. Das heißt, dass sich hier bereits entscheidet, ob die Software oder die Webseite barrierefrei sein kann oder nicht. Als Entwicklerin kann ich darauf achten, dass der technische Unterbau korrekt ist, z. B., dass auch Icon-Buttons einen Text haben, den der Screenreader vorlesen kann usw., aber wenn der Button keinen ausreichenden Kontrast hat oder an einer nicht sinnvollen Stelle sitzt, sind mir die Hände gebunden. Dabei finde ich, dass es uns in diesem Projekt nun sehr gut gelungen ist, schönes Design und Barrierefreiheit miteinander zu vereinen. An vielen Stellen ergänzen sich diese beiden Themengebiete auch hervorragend. An anderen müssen jedoch Kompromisse gefunden werden und ohne gute Kommunikation, gegenseitiges Verständnis und mehrere Schleifen an Kommunikation mit Vorschlägen und Feedback zwischen dem Team und unserer Designerin wäre dies nicht möglich gewesen. Alles in allem war dies ein Prozess, in dem wir alle etwas lernen konnten und der (zumindest mir) großen Spaß bereitet hat, vor allem, wenn dann auch eine elegante Lösung für ein Problem gefunden wurde.
Und da alle guten Dinge drei sind: Mein letztes Learning lautet, dass wir grade erst angefangen haben. Wir haben nun unsere ersten Erfahrungen gesammelt und wollen diese in der Zukunft weiter ausbauen. Wir wissen, dass wir mit unserer Software, die sich an Patientinnen und Patienten richtet, in der Verantwortung sind, allen Menschen einen gleichberechtigten Zugang zum Gesundheitssystem zu ermöglichen. Und wir wissen auch, dass unser APS (das Praxisverwaltungssystem) ebenfalls von Überlegungen zur Barrierefreiheit profitieren kann – denn auch medizinisches Personal kann körperliche oder geistige Einschränkungen haben. Es gibt noch jede Menge Luft nach oben und wir freuen uns darauf, dieses Potenzial ab sofort auszuschöpfen!