Menü

Barrierefreiheit beginnt beim UX Engineering

Rückblende aufs technica11y DE 2022-01 mit Dirk Ginader, Accessibility UX Engineering Manager bei Google

veröffentlicht: 08.02.2022 · Franziska Köppe | madiko
aktualisiert: 05.09.2022 · Franziska Köppe | madiko

Zu Lebens- & Arbeitswelten mit Zukunft gehören Informationsfreiheit, Wahlfreiheit, Entscheidungsfreiheit und eigenverantwortliches Handeln. Dazu muss ich Menschen ermächtigen. Alle Menschen. Das bedeutet auch, alltägliche Hürden abzuschaffen oder auf das Minimum zu reduzieren. Bei technica11y schauen wir insbesondere auf die Barrieren und Hindernisse, die sich in Digitalien ergeben. Vermeiden wir sie, beziehungsweise bauen wir diese zurück, hilft das uns allen. Im Januar war Dirk Ginader zu Gast. Er gab uns einen Einblick in die Umsetzung von Barrierefreiheit in der Produktentwicklung bei Google.

Foto: Digitale Transformation: Arbeit am Rechner
lizensiert für madiko // Foto: Khanchit Khirisutchalual

Mitte Januar startete technica11y ins neue Jahr. Es war schön, wieder einmal dabei zu sein. Joschi Kuphal von tollwerk, der den Accessibility Club Deutschland organisiert und moderiert, hatte Dirk Ginader von Google eingeladen.

Seit 2021 ist Dirk Manager eines Teams von UX-Engineers1, die exklusiv daran arbeiten, sämtliche Google-Produkte barrierefrei zu realisieren. Sie bauen damit die Brücke zwischen Gestaltung (design) und technischer Realisierung (engineering). Ihr Ziel: allen Menschen die Bedienung der Programme (ux = user experience) so angenehm und barrierearm wie möglich zu machen. Intern streben sie an, dass alle Designer:innen und Programmierer:innen, Barrierefreiheit in ihrer Komplexität verstehen und antizipieren. Also Accessibility von Beginn an mitdenken und Hand in Hand arbeiten.

[ 1 ] “UX Engineers” scheint auch in Deutschland der gängige Fachbegriff zu sein. UX steht für user experience, also den Erfahrungen, die Nutzer:innen mit einem Produkt oder einer Dienstleistung erleben. Engineers sind diejenigen, die die Leistungen technisch realisieren. So wie ich Dirk in seinem Vortrag verstand, erweitert das neu geschaffene Team mit seiner selbstdefinierten Rolle, die übliche Arbeitsteilung in Unternehmen. Schon allein deswegen könnte sich für Dich die Rede beim technica11y lohnen.

In seinem Impuls stellte Dirk die zentralen Strategien vor und wie sie sie in der Praxis bei Google umsetzen. Der Vortrag war klar, gut strukturiert und informativ. Für mein aktuell größtes Thema erhielt ich ebenfalls erste Anhaltspunkte in der offenen Fragerunde im zweiten Teil unseres Treffens. Dazu unten mehr.

Herzlichen Dank für den Beitrag und die Antworten auf unsere Fragen Dirk. Dir, Joschi, vielen Dank fürs wertschätzende, freundliche Moderieren. Im Folgenden fasse ich für EnjoyWork die zentralen Punkte zusammen:


· Service für Querleser:innen ·

Kapitelübersicht Rückblende:
Barrierefreiheit beginnt beim UX Engineering


  1. Aufzeichnung des Livestreams
  2. User Experience Engineering
    1. Perspektive Gestaltung
    2. Perspektive Technische Realisierung
  3. A11Y – Numeronym und Bewegung für freien Zugang für alle Nutzer:innen
  4. Accessibility im User Experience Engineering
    1. Barrierefreiheit während des Design-Prozesses
    2. Barrierefreiheit während der Programmierung
    3. Nicht das Rad neu erfinden
  5. Barrierefreiheit hilft uns allen
  6. Bedienen mit ausschließlich Tastatur
    1. Sichtbarkeit der Fokus-Anzeige
    2. Erwartete Reihenfolge der Tabulator-Sprünge
  7. Bedienen mit Bildschirm-Lese-Geräten
    1. Erweiterte Funktionalität für das Bedienen mithilfe einer Tastatur
    2. Navigieren mithilfe der Orientierungspunkte, Seiten-Regionen und Seiten-Struktur
  8. Barrierefreiheit in der Bedienführung: Struktur, Ablauf und Elemente
    1. Struktur
      1. Orientierungspunkte & Seiten-Regionen (landmarks)
      2. Überschriften
      3. Barrierefreiheit für nicht-lineare, komplexe Seiteninhalte
    2. Ablauf
      1. Navigation im Ablauf mithilfe der Tabulator-Taste
        1. Fokus auf das zentrale Angebot einer Seite (Suche)
        2. Fokus auf den auszuführenden Arbeitsschritt (Link-Eingabe)
        3. Zusammenspiel von Fokus und Vorbelegen von Speicherplätzen (Kalender Teil I)
        4. Durchlaufen von Schleifen und das Setzen des Fokus nach Abschluss des Bedienschritts (Kalender Teil II)
      2. Navigieren im Ablauf mithilfe der Pfeiltasten
      3. Navigieren im Ablauf mithilfe der Leer- oder Enter-Taste
      4. Anwendungsbeispiel “Content Cards”
    3. Elemente
      1. Etiketten (labels) hinzufügen
      2. Gute ‘label’ formulieren
      3. ARIA-Rollen gezielt definieren
  9. Regelmäßig auf die Maus verzichten
  10. Fazit & Ausblick
  11. Weiterführende Links
    1. WAI-ARIA Authoring Practices
    2. Farbkontraste testen und adaptieren
      1. Für Figma-Nutzer:innen: PlugIn “Contrast”
      2. Für MAC oder Windows: Colour Contrast Analyser (CCA) von TPGi
    3. ALLYcasts – YouTube Serie zu Accessibility

Aufzeichnung des Livestreams

[ 0:00:00 ] Organisatorisches, Warten auf die Teilnehmenden

Small Talk und Plauderei

[ 0:11:40 ] Anmoderation zum Abend / Verhaltenskodex

… von Joschi Kuphal und Einführen in den Verhaltenskodex der Gruppe technica11y DE

[ 0:15:47 ] Einführen ins Thema und Kurzvorstellen von Dirk Ginader

Selbstvorstellung Dirk in seiner neuen Rolle bei Google als Accessibility UX Engineering Manager

[ 0:19:45 ] Vortrag Dirk "Barrierefreiheit beginnt beim UX Design"

[ 0:21:12 ] User Experience Engineer (inkl. Unterscheidung zu einem UX Designer)

[ 0:27:03 ] Wie ich ein UXE bei Google geworden bin

[ 0:33:20 ] Accessibility bei Google

[ 0:39:20 ] Barrierefreiheit hilft uns allen (Formen von Behinderungen)

[ 0:41:47 ] Fallbeispiel “Buchung einer Reise online
aus der Bediener-Erfahrung zweier Persona:

  • [ 0:41:47 ] Bedienen mit Tastatur
  • [ 0:47:07 ] Bedienen mit Bildschirm-Lese-Gerät (Screen Reader)

[ 0:58:00 ] Umsetzen und Dokumentieren von Barrierefreiheit im UX Engineering

  • [ 0:58:54 ] Struktur (Seitenstruktur der Inhaltsbereiche definieren)
  • [ 1:07:54 ] Ablauf (Lineare Reihenfolge für die Interaktion optimieren)
  • [ 1:16:31 ] Elemente (Labels hinzufügen, rein dekorative Elemente markieren und Rollen zuordnen)

[ 1:25:20 ] Link-Tipps zum Mitnehmen

[ 1:30:00 ] Diskussion & Fragerunde
[ 1:45:17 ] Danke & Auf Wiedersehen

User Experience Engineering

Ein User Experience Engineer (UX Engineer) ist ein Developer, der sich auf das Lösen von User Interface Design und Integrationsproblemen von User Interface Features in Google Produkten spezialisiert.

Dirk Ginader

Accessibility UX Engineering Manager bei Google

Die Rolle schließt die Lücke zwischen Gestalten (Design) und Entwickeln (Develop).

technica11y DE 2022-01: Rolle der Unser Experience Engineers (UXE) <br>schließt bei Google die Lücke zwischen Gestalten (Design) und Entwickeln (Develop). Bild: copy Dirk Ginader | Google

technica11y DE 2022-01: Rolle der Unser Experience Engineers (UXE)
schließt bei Google die Lücke zwischen Gestalten (Design) und Entwickeln (Develop)
[ 2022-01-17 Dirk Ginader | Google ]

Designer:innen kümmern sich darum, wie das Programm visuell aussieht (Anmutung, Farben, Formen, Schriften und Schriftbild, Kontraste, usw). Interaction Designer:innen erarbeiten, wie die Programme auf Nutzer:innen-Seite ablaufen und die Nutzer:innen mit dem Programm interagieren.

Dem gegenüber – auf der anderen Seite – arbeiten die Programmierer:innen (Software Engineers) am technischen System. Dazu gehören die zugrundeliegenden Strukturen und Prozesse der Programme (Backend, BE) als auch die Schnittstellen und das technische Umsetzen des Designs (Frontend, FE).

Die Rolle einer Entwicklerin / eines Entwicklers für Nutzungserfahrung (User Experience Engineering) bringt in ihrer Arbeit der Analyse, Konzeption, Design beide Kompetenzen zusammen – das nutzerfreundliche Gestalten und das technisch-effiziente Programmieren. [22’52’‘ ]

Interessant ist, dass Google diese Rolle noch einmal aufsplittet in die zwei Perspektiven:

Perspektive Gestaltung

In diesem Kontext bauen UXE – gemeinsam mit den Visual und Interaction Designer:innen – Design-Prototypen und Werkzeuge, die die direkte Nutzererfahrung verbessern und unterstützen. Diese testen sie zusammen mit Forschern und tragen die Ergebnisse dieser Marktstudien und Beta-Tests zurück ins Design-Team.

Perspektive Technische Realisierung

Im Bezugsrahmen “Technik” bauen UXE – gemeinsam mit den BE und FE Software-Entwickler:innen – die System-Architektur, Arbeitsumgebungen (Frame Works), Bedienoberflächen-Bibliotheken (UI Bibliotheken), Werkzeuge (Tools und Snippets). Also gut getesteten Code in hoher Qualität für die Produktion. Hier geht es um die pixel-genaue Umsetzung und die technische Adaption auf die speziellen Plattformen (z. B. für Arbeitsplatz oder Mobile Browser, für Web-/ Mobile-Applikationen oder neue Techniken wie 3D und virtuelle Realitäten). Auch hier wird der Code also getestet, bevor er von den Software-Entwicklern weiterverbaut und im Live-Betrieb genutzt wird.

UX Ingenieur:innen diskutieren Gestaltung und Programmierung anhand eines Papier-Prototyps. Bild: copy lizensiert für madiko // Foto: Suriyan  Tejasurintr | Skarie20

UX Ingenieur:innen diskutieren Gestaltung und Programmierung anhand eines Papier-Prototyps
[ 2021-03-07 lizensiert für madiko // Foto: Suriyan Tejasurintr | Skarie20 ]

In Summe benötigen UXE also ein solides Verständnis sowohl für gestalterische als auch technische Aspekte von Nutzungserfahrungen. Es braucht strukturiertes, strategisches Denken und Kreativität, Probleme und Herausforderungen gut zu lösen. Und die Fähigkeit zum “Übersetzen” von einer Perspektive in die andere.

Ich selbst würde mich von daher ebenfalls als UX Engineer bezeichnen. Je mehr ich auf beiden Seiten und aus allen Betrachtungswinkeln in die Tiefe gehen kann, desto höher das Potenzial für gute Lösungen. Ich versuche mir – selbst wenn ich mit jedem realisierten (Teil)Projekt professioneller sowohl im Design als auch in der Programmierung werde – stets einen naiven Blick der Nutzenden zu bewahren. Das scheint mir eine ebenso wichtige Herangehensweise für diese Rolle und die damit verbundenen Aufgaben.

Aus dieser Erfahrung heraus würde ich noch ergänzen: Es braucht ein Bewusstsein für Hacking-Ethik. Denn nur, wenn ich mir klar bin über meine Grundannahmen zu Menschen, meinem Weltbild und eine Vorstellung davon habe, wie ich möchte, dass sich Menschen in ihr verhalten (können) – nur dann bin ich in der Lage, diese Welt über meine Arbeit als UX Ingenieur:in zu gestalten.

Womit wir beim zentralen Thema von technica11y wären: Barrierefreiheit.

A11Y – Numeronym und
Bewegung für freien Zugang
für alle Nutzer:innen

technica11y leitet sich ab aus A11Y. A11Y wiederum ist ein Numeronym, eine Abkürzung, die sich mindestens einer Nummer bedient. Sie steht für den englischen Begriff “Accessibility”, wobei die “11” für alle Buchstaben zwischen “a” und “y” steht.

Numeronyme gehen bis auf die Mitte der 1980er Jahre zurück.1 Damals hatte ein Administrator der Firma Digital Equipment Corporation seinem Kollegen Jan Scherpenhuizen eine E-Mail mit s12n@… gegeben. Es war eine humorvolle Lösung für das Problem, dass der Nachname zu lang war, um ein Account-Name zu sein. Dabei griff er auf den Spitznamen zurück, der Jan von vielen seiner Arbeitskollegen verliehen worden war, die sich schwer taten, seinen Nachnamen korrekt auszusprechen. Die Logik dahinter: zwischen dem ersten und letzten Buchstaben von “Scherpenhuizen” liegen 12 Buchstaben.

Aus diesem unternehmensspezifischen Muster entwickelten sich über die Jahrzehnte viele verschiedene dieser Numeronyme, auch außerhalb der Tech-Blase. Zuweilen nutzen sie dieselben Logik wie bei DEC. So steht zum Beispiel “I18n” für “internationalisation”. Manchmal nutzen sie Homophonien, wie beispielsweise die Ziffer 2 (two = zu) bei “F2P” für “Free-to-Play” oder die Ziffer 4 (for = für), wie ganz aktuell “E4F” für “Entrepreneurs For Future”. Zahnärzte freuen sich über K9 (ca-nine = canine = Eckzahn). Dabei bleiben die in Numeronymen verwendeten Homophonien nicht auf die Englische Sprache beschränkt. “K7” (französisch ausgesprochen k-sept) steht für casette.1 Liebe Kinder, das ist eine veraltete Form von Datenspeicher, für den wir in meiner Jugend einen Recorder und Bleistifte brauchten. Lasst es Euch gern von Euren Eltern erklären. ;-)

A11Y sind keine konkreten Gesetze, Richtlinien oder Vorgaben. Vielmehr ist es ein loser Zusammenschluss innerhalb der Technik-Community. Es ist eine Bewegung, die sich zum Ziel setzt, Programme nutzerfreundlicher und zugänglicher zu gestalten.3

Die Digitalisierung durchdringt alle Lebensbereiche. Wir wählen Anfahrtsrouten, kommunizieren mit Freunden, Kollegen, Bekannten. Wir bestellen Verbrauchs-, Gebrauchs- und Investitionsgüter. Wir arbeiten, überwachen, steuern, nutzen mithilfe von Software. Dabei sind wir alle immer wieder mit eigenen Beschränkungen konfrontiert – mal vorübergehend, in Teilen, mal dauerhaft und permanent. Dazu unten gleich mehr. Daher ist es wichtig, Programme bedienerfreundlich zu gestalten und Assistenz-Systeme zur Bedienung anzubieten, wo nötig.

technica11y DE – der monatliche, in deutscher Sprache stattfindende Wissens- und Erfahrungsaustausch des Accessibility Club Deutschland – greift A11Y auf und fokussiert sich insbesondere auf Fragen der Barrierefreiheit im Kontext der Digitalisierung und digitalen Transformation der Gesellschaft. Es geht darum, gemeinsam Praxiserfahrungen auszutauschen. Das Ziel: Freiheit in seiner Vielfalt zu erfassen, zu nutzen und in die tägliche Arbeit einfließen lassen zu können. Denn Accessability und Empowerment sind kein Hexenwerk. Sie lassen sich lernen. Wenn man die entsprechende Offenheit, die humanistische Grundhaltung und das Bewusstsein für Souveränität, Selbstwirksamkeitserwartung und eigenverantwortliche Autonomie mitbringt.


Quellen:
[ 1 ] Nomeronym (via Wikipedia).
[ 2 ] Origin of the abbreviation I18n (by I18nGuy Tex Texin)
[ 3 ] What is A11Y? (Tzvika Shahaf via perfecto.io)

Accessibility
im User Experience Engineering

Nehmen wir zunächst die Überschrift kurz auseinander. Hier zeigt sich bei Dirk, dass er in den letzten Jahren ausschließlich im englischsprachigen Kontext unterwegs war. Und dass die A11Y-Gemeinschaft sich selbst im deutschsprachigen Raum hauptsächlich in Englisch verständigt. Im Folgenden geht es also darum, wie und wann Fragen der Barrierefreiheit in die Arbeit einer Ingenieurin / eines Ingenieurs für Nutzererfahrungen einfließen. Grundsätzlich lässt sich sagen: Immer und überall. Das wird mir bewusster, je intensiver ich mich mit dem Thema auseinandersetze. Dirk spricht in diesem Zusammenhang auch vom Wecken der Empathie für Nutzer:

Wenn man erst einmal verstanden hat, wer seine Nutzer sind, und dass man sehr wahrscheinlich irgendwann einmal selbst sein eigener Nutzer ist, ist der Wille, das Thema Barrierefreiheit anzugehen, ein ganz anderer.

Dirk Ginader

Accessibility UX Engineering Manager bei Google

Barrierefreiheit während des Design-Prozesses

Hierbei geht es beispielsweise um potenzielle Probleme wie Farben, Formen, Strukturen und die Kontraste der Flächen. Es geht um Schriften, Schriftgrößen, Schriftbild und Lesbarkeit. Aber auch um Dinge wie die Bedien-Reihenfolge beim Betätigen des Tabulators beim Navigieren über eine Seite (Bedienen mit Tastatur, ohne Maus). Es geht um gelernte oder zumindest konsistente Muster, die von den Nutzenden wiedererkannt werden. Auch das erleichtert die Bedienung und senkt Hürden für die Anwendung.

Barrierefreiheit während der Programmierung

Neue Produkte bei Google haben keine Ausrede mehr, nicht barrierefrei zu sein. Gleichwohl sind die Infrastruktur des Internet-Riesen als auch die einzelnen Programme “historisch gewachsen”. Dirk spricht von einem breiten Spektrum an Software, die teils drei und teils bis zu 20(!) Jahre alt sein können. Hier gilt es, gemeinsame Standards zu finden und diese nach neuesten Erkenntnissen anzureichern und stetig weiterzuentwickeln.

Nicht das Rad neu erfinden

Für bestehende Komponenten und Design-Muster hat das World Wide Web Consortium (W3C), das Gremium zur Standardisierung der Techniken im World Wide Web, die WAI-ARIA Authoring Practices geschaffen:

Dazu im Folgenden gleich mehr. Lass uns jedoch vorab auf den Nutzen von Barrierefreiheit im UX Engineering schauen:

Barrierefreiheit hilft uns allen

Behinderungen sind divers und können in vielen Formen und Ausprägungen auftreten, beispielsweise können sie sich äußern in Einschränkungen der

  • Sehfähigkeit
  • Hörfähigkeit
  • Beweglichkeit (z. B. in den Händen, Armen, Schultern)
  • kognitiven Fähigkeiten

Behinderungen tauchen in drei Facetten auf: Sie können sein…

  • permanent / dauerhaft
  • partiell / vorübergehend
  • situationsbedingt

Aufbauend auf zahlreichen technischen Errungenschaften haben Menschen eine Vielzahl an Hilfsmitteln entwickelt, wie Programme trotz Einschränkungen bedient werden können. So verwenden beispielsweise Menschen mit einer eingeschränkten Beweglichkeit die Tastatur. Auch ich mache davon regelmäßig Gebrauch, um schneller arbeiten zu können. Ich liebe Short-Cuts! So vermeide ich das Umgreifen von Tastatur auf Maus. Menschen mit verminderten Sehfähigkeiten nutzen ergänzend zur Tastatur Bildschirmlupen und Bildschirm-Lesegeräte (Screen Reader).

User Experience Engineers dokumentieren Hinweise für die Zugänglichkeit bei Bedienkonzepten. Sie übersetzen dabei visuelle Programm-Oberflächen (visual interfaces) in textbasierte, lineare Schnittstellen. Die maschinell interpretierbaren Bausteine können dann nach Bedarf über die Werkzeuge und Geräte ausgegeben werden.

Mit der Rolle einer Ingenieurin für Bedienkonzepte verbindet sich also die einer Übersetzerin. Diese Übersetzungsleistung – und das war Dirk besonders wichtig – ist ein Dialog in beide Richtungen. Je besser das Zusammenspiel aus Gestaltung und technischer Realisierung, desto höher die Bedienfreundlichkeit. Und desto besser ist der Job eines User Experience Engineers umgesetzt worden.

Bedienen
mit ausschließlich Tastatur

Welche Besonderheiten sind in der Gestaltung und technischen Realisierung zu berücksichtigen, wenn Software ausschließlich mit einer Tastatur bedient wird?

Sichtbarkeit der Fokus-Anzeige

Für die visuelle Orientierung ist am allerwichtigsten, dass ich gut – idealerweise auf den ersten Blick – erkennen kann, wo der Fokus aktuell liegt. Beim Weiterspringen sollte diese Fokus-Anzeige konsistent über die gesamte Software verhalten und auch nicht unterwegs verloren gehen.

Erwartete Reihenfolge der Tablulator-Sprünge

Da wäre zunächst die vorgegebene Richtung, denn die Bedienung per Tastatur ist strikt linear. Üblich ist primär von links nach rechts und sekundär von oben nach unten. Die Steuerung folgt also der Linearität von Texten und ihrer makro-typographischen Grundeinheit “Zeile”. Etwa, wie man auch ein Buch liest.

Internationale Besonderheiten wären hier zu beachten, die von diesem Standard abweichen. So dreht sich im asiatischen Raum die Reihenfolge von primär und sekundär: Chinesisch, Japanisch und Koreanisch oder Mongolisch werden traditionell primär von oben nach unten und sekundär von rechts nach links geschrieben und gelesen. Im Unterschied dazu verlaufen semitische Konsonanten-Schriften, wie beispielsweise Arabisch oder Häbräisch, waagerecht linksläufig. Sie werden also primär von rechts nach links abgefasst und interpretiert.

Nutzer:innen erwarten dieselbe Lesefolge beim Betätigen der Tabulator-Taste für die Bedienerfolge der Software-Oberfläche.

Zusätzliche Quelle: Schreibrichtung (via Wikipedia)

Bedienen
mit Bildschirm-Lese-Geräten

Wie auch Menschen mit motorischen Beeinträchtigungen nutzen Menschen mit Sehbehinderung ihre Tastatur, um eine Software zu bedienen. Denkt man darüber nach, ist das logisch. Zusätzlich zu bedenken ist, dass Rückmeldungen nun nicht visuell, sondern akustisch ausgegeben werden. Mithin steht den Benutzer:innen von Screen-Readern eine linear, auditive Bedienerführung zur Verfügung. Und dafür gilt es – neben dem oben Beschriebenen – Folgendes zu beachten:

Erweiterte Funktionalität
für das Bedienen mithilfe einer Tastatur

So liefert jeder Tabulator-Stop für die Bedien-Elemente, Überschriften und Links einer Software-Anzeige über den Screen-Rreader drei und bei Bedarf eine vierte Information(en), nämlich Inhalt, Kontext und Handlungsoptionen:

  • Text des Links, Etikett des Menü-Punktes oder Bedienfeld im Wortlaut
    (im Beispiel ist es der Link-Text des Navigationspunktes, das Label des Buttons bzw. der Alt-tag des Icons)
  • Status des Bedien-Elements
    (im Beispiel ausgewählter Radio-Button oder Texteingabe)
  • Rolle des Bedien-Elements
    (im Beispiel ist es ein Link-Element)
  • Gruppen-Information zur Rolle
    (im Beispiel: der wievielte Link in der Navigation gerade im Fokus steht)

Navigieren mithilfe der Orientierungspunkte, Seiten­regionen und Seitenstruktur

Je nach Komplexität der Seite kann sich das Springen von Tab zu Tab als sehr langwierig und umständlich erweisen. Daher bieten Screen Reader zusätzlich das Navigieren mithilfe der Seitenstruktur an. Diese sogenannten Orientierungspunkte (landmarks) werden mit einem für den jeweiligen Screen Reader spezifischen Tastaturkürzel aufgerufen – sofern sie im Code hinterlegt sind.

Innerhalb dieser einzelnen Orientierungspunkte & Seitenregionen (landmarks) sind Überschriften (headlines) mit ihrer inhärenten Logik der (linearen) Strukturierung und Hierarchisierung ein wichtiger Lotse, der über Screen Reader angesteuert werden kann.

Barrierefreiheit in der Bedienführung:
Struktur, Ablauf und Elemente

Die Struktur organisiert die Anordnung und Aufteilung der Bedienelemente (layout). Der Ablauf regelt die Reihenfolge der Bedienerführung. Die Elemente definieren die Eigenschaften der einzelnen Bausteine, aus denen die Programm-Oberfläche für die Nutzer:innen zusammengebaut sind.

Struktur

technica11y DE 2022-01: Barrierefreiheit in der Bedienführung – Struktur. Bild: copy Dirk Ginader | Google

technica11y DE 2022-01: Barrierefreiheit in der Bedienführung – Struktur
[ 2022-01-17 Dirk Ginader | Google ]

Orientierungspunkte & Seitenregionen (landmarks)

Die Orientierungspunkte & Seitenregionen, in der Fachsprache “landmarks” genannt, fassen Bereiche der Seite zu Blöcken zusammen. Mit Accessible Rich Internet Applications (ARIA) 1.1 wurden im Dezember 2017 von der Web Accessiblity Initiative 8 landmark roles definiert:

Rolle html5
banner < header >
complementary < aside >
contentinfo < footer >
form < form >
main < main >
navigation < nav aria-label="main" >
region < section >
search < form role="search" >

Diese Orientierungspunkte und Seitenregionen werden ausschließlich über die Inhalte definiert – nicht via Layout. Es ist möglich, dass landmarks mehrfach auf einer Website vorkommen, beispielsweise Navigationen (Haupt- / Meta- / Brotkrümelpfad-Navigationen) oder mehr als nur 1 section im Inhaltsbereich (so wie die Rückblende, die Du gerade liest).

Kommen also Seitenregionen mehrfach auf der Seite vor, werden den landmarks zusätzliche Attribute mittels sogenannter aria-labels zugewiesen.

Überschriften

Innerhalb der Seitenregionen ist es dann wichtig, die Inhalte mittels Überschriften zu organisieren und hierarchisch zu strukturieren. Die Überschriften sollten dabei konsequent mit den entsprechenden html-tags versehen werden <h1> bis <h6>. Das hat gleich noch den Zusatznutzen, dass Du diese Attribute über cascading style sheets (css) auch im Design ansteuern und gestalten kannst. Wie Dirk sagt: Barrierefreiheit ist nützlich für alle.

Jede Website hat dabei nur 1 Hauptüberschrift <h1>. Bei mir ist es der Titel ganz oben am Kopf der Seite. Von <h1> gibt es also nur eine Instanz.

Ich unterteile die Seiten-Inhalte dann in mehrere <sections>. Diese haben als oberste Hierarchie <h2>. Du erkennst die einzelnen Kapitel an den kleinen, nach unten gerichteten Dreiecken. Gleichwohl verwende ich sie, um die Inhalte im Überblick (siehe oben) zusammenzubauen.

Dirk verwendet in seinem Vortrag das Bild von verschachtelten Ordnern, das ich gelungen finde. Meine langjährige Erfahrung mit Websites ist zudem, dass man möglichst keine Matrjoschkas bauen sollte. Denn ab der vierten, fünften Hierarchie-Stufe werden Seiten zumeist unübersichtlich. Daher lagere ich in diesen Fällen Inhalte auf weiterführende Unterseiten aus. Der Vorteil von Software ist ja, dass wir im Platz nicht beschränkt sind. Wichtig ist dann, immer wieder Angebote für Nutzer:innen anzubieten, wo sie zum Haupt-Teil des Inhalts zurückfinden können. Beispiele für diese Technik findest Du in der Rubrik “Reportagen”.

Eine weitere Methode, auf die Dirk in seinem Vortrag eingeht, ist das Ausblenden von Überschriften über css, wenn diese für sehende Nutzer:innen nicht relevant sind, für blinde oder sehbehinderte Nutzer:innen mit ihren Screen Readern jedoch als Orientierungspunkt – vor allem im Hinblick auf die hierarchische Ordnung – angeboten werden sollen.

Ablauf

Wie oben geschrieben, erwarten Nutzer:innen den Ablauf, mit dem sie die einzelnen Bedien-Elemente einer Software über die Tabs ansteuern können, primär horizontal von links nach rechts und sekundär vertikal von oben nach unten. Mit der Ausgestaltung der Fokus-Reihenfolge wird der lineare Weg der Nutzer:innen feinjustiert. Dokumentiert werden dabei nur die von der Regel abweichenden Ausnahmen. Also beispielsweise, wie sich das System innerhalb von Komponenten oder Schleifen verhält.

Navigation im Ablauf mithilfe der Tabulator-Taste

Fokus auf das zentrale Angebot einer Seite (Suche)

Dirk nimmt als Beispiel das Produkt Google Suche [1:09’35’‘ ], bei dem – abweichend von der üblichen Vorgehensweise – beim initialen Laden der Seite das Suchfeld direkt angesteuert wird (statt dem ersten Menüpunkt oben links). Ecosia, die von mir bevorzugte Suchmaschine, hat es im Übrigen ebenfalls so gelöst.

Fokus auf den auszuführenden Arbeitsschritt (Link-Eingabe)

Dasselbe gilt für Komponenten in der Bedienung des Programms. Wird beispielsweise ein Pop-up oder Zusatzmenü geöffnet, kann – bei Bedarf und sorgfältig abgewogen – der initiale Fokus auf ein anderes als das erste Element links oben gesetzt werden.

Interessant scheint mir dies vor allem, wenn bei Formularen Felder bereits vom Programm vorausgefüllt werden und man für eine zügigere Eingabe das erste noch offene Bedienelement ansteuert. Dirk nennt als Beispiel das Setzen einer Verlinkung in Google Docs, wenn der Text, der verlinkt werden soll, ausgewählt wurde und lediglich der Link felt [ 1:10’56’‘ ].

UX Engineers sollten sich also stets bewusst sein, was die zentrale Aufgabe ist, die die Nutzer:innen beim Bedienen erledigen wollen. Danach sollten sie Ausnahmen festlegen. Dies scheint mir wieder ein treffendes Beispiel, weswegen Barrierefreiheit für alle Nutzer:innen sinnvoll ist – unabhängig davon, welche Sensoren und Hilfen sie für die Bedienung verwenden.

Zusammenspiel von Fokus und Vorbelegen von Speicherplätzen (Kalender)

Drittes Beispiel von Dirk ist das Bedienen eines Kalenders auf einem Smartphone (Mobile App) [1:11’28’‘ ]. Hier ist nicht nur die Reihenfolge der einzelnen Bedienschritte interessant, sondern auch, dass viele kleine Helferlein über die Technik vorausgewählt sind.

Nur ein mögliches Szenario: Das Datum ist in der Vorselektion auf <heute> gesetzt. Das muss explizit programmiert werden. Uns fällt das zumeist dann auf, wenn es nicht umgesetzt wurde, so stark haben wir uns an dieses Feature bereits gewöhnt. Spannend und durchaus tricky für Programmierer, wenn nun noch das zweite Datum – der Endpunkt einer Zeitspanne – automatisiert in Relation zum vom Bedienenden eingestellten Kalendertag übernommen wird. Da zeigt sich die hohe Kunst der Programmierung. Keine Raketentechnik, dennoch ein klein bisschen Magie und besonderer Service für Nutzer:innen.

Durchlaufen von Schleifen und das Setzen des Fokus nach Abschluss des Bedienschritts

Spannend ist der Aspekt, auf den Dirk als Nächstes in diesem Kontext eingeht: Wohin springt der Fokus, wenn sämtliche Arbeitsschritte in der ausgelagerten Bedienroutine abgeschlossen sind? [ 1:12’07’‘ ] Dirk empfiehlt, Nutzer:innen exakt dorthin zurückzuschicken, wo sie herkamen.

Im Kalender-Beispiel wechselt der Fokus zurück auf das gewählte, nun aktualisierte Datum auf der Hauptseite, von der aus das Untermenü gestartet wurde. Das gibt der Person die Orientierung, wiederzuerkennen, wo sie vorher war und nun den Vorgang fortsetzen kann.

Navigieren im Ablauf mithilfe der Pfeiltasten

Während die Tabulator-Taste der Ansteuerung der Hauptpunkte auf der Bedienoberfläche dient – mit Sprüngen von einem interaktiven Element zum nächsten – können einzelne Steuerelemente innerhalb eines Bedienfeldes über die Pfeiltasten angesteuert werden. Also beispielsweise die Optionen eines Auswahlfeldes oder das Aufklapp-Menü einer Sub-Navigation.

Das bietet zwei Vorteile. Zum einen reduziert sich die Zahl der Tabulatoren, mit der die gesamte Bildschirm-Oberfläche durchlaufen werden kann. Zum Zweiten liegen die Pfeiltasten nah beieinander, was eine schnelle Bedienung innerhalb des Kontext-Menüs ermöglicht.

Navigieren im Ablauf mithilfe der Leer- oder Enter-Taste

Die Enter-Taste bestätigt das Auswählen des gewählten Elements einer Software-Oberfläche. Anschließend springt die Person zum nächsten interaktiven Item der Seite. Auch das kann aktiv genutzt werden, zum Beispiel bei mehrseitigen Formularen oder Ähnlichem.
Die Leertaste wiederum startet und stoppt beispielsweise Audio- und Video-Dateien. In manchen Programmen – ich kenne es beispielsweise aus Graphik-Programmen oder auch kollaborativ-visuellen Arbeitshilfen – dient die Leertaste zudem als Tastaturkürzel, um den Mauszeiger vom Werkzeug “Auswahl” auf “Hand” zu wechseln.

Dirk ging in seinem Vortrag darauf nicht näher ein. Auch das sicher ein Thema, das wir bei technica11y zu gegebener Zeit vertiefen könnten. In Veranstaltungen und Arbeitssitzungen nutze ich gern diese interaktiven Tools. Wäre wichtig zu wissen, wie barrierefrei diese heute sind und worauf man als Moderator:in achten müsste, um allen Menschen gleichermaßen die Chance zur Kollaboration geben zu können.

Anwendungsbeispiel Content Cards

Dirk stellt im Zusammenhang mit dem barrierefreien Gestalten von Bedien-Abläufen im UX-Design noch ein sehr interessantes Anwendungsbeispiel vor: Content Cards [ 1:14’17’‘ ], das sich die Vorteile der heutigen technischen Möglichkeiten bewusst zunutze macht.

Um nämlich Nutzer:innen nicht mit drölftausend Tabs schier endlos durch eine Seite von einem interaktiven Element zum nächsten navigieren zu lassen, werden für die einzelnen “Content Cards” jeweils ARIA Rollen definiert. Dabei wird zunächst eine Klammer um sämtliche Inhaltskarten – eine landmark – gesetzt. Das gibt Nutzer:innen die Chance, den Bereich der “Content Cards” komplett zu überspringen und auf der Seite beispielsweise das darauffolgende Kapitel anzusteuern.

Innerhalb der ARIA für alle Cards erhält dann wiederum jede einzelne Karte ebenfalls eine ARIA-Rolle. Entschließt sich also die:der Nutzer:in, die Karten näher anzuschauen, ist nun automatisch die erste Karte links oben markiert. Von dort kann sie:er nun wieder mit der Tabulator-Taste von Karte zu Karte springen. Ist die fokussierte Karte interessant, kann sie:er mit Enter bestätigen und innerhalb der Karte mithilfe der Pfeiltasten navigieren.

Das scheint mir nicht nur für Menschen mit motorisch eingeschränkten Fähigkeiten ein Gewinn. Ich stelle es mir insbesondere als große Erleichterung für Menschen mit Sehbehinderungen vor, die sich das ja alles auch noch vorlesen lassen (müssen).

technica11y DE 2022-01: Barrierefreiheit in der Bedienführung – Ablauf (Tabulator- und Pfeiltasten). Bild: copy Dirk Ginader | Google

technica11y DE 2022-01: Barrierefreiheit in der Bedienführung – Ablauf (Tabulator- und Pfeiltasten)
[ 2022-01-17 Dirk Ginader | Google ]

Während des Vortrags schwante es mir schon: Das beschriebene Endlos-Tabben ist ein Problem, das für einige meiner eigenen (Übersichts)Seiten zutrifft. Da braucht es dringend eine Lösung. Ich habe bereits eine Idee und hoffe, dass ich das in Kürze umsetzen kann.

Ein weiteres Anwendungsfeld für diese Methode sehe ich für die sich aktuell in Arbeit befindende “EnjoyWork Monitoring-Zentrale”. Diese wird eine Vielzahl an Forschungsdaten zu den 17 Zielen für nachhaltige Entwicklung bzw. zum Stand der Umsetzung in Sachen Einhalten der planetaren Grenzen und des sozialen Fundaments enthalten. Eines der großen Projekte, an denen ich für unsere Bewegung und Kooperative zurzeit arbeite. Ich hatte dies ebenfalls kurz im Rahmen von technica11y DE angesprochen [ nachzuhören ab 1:35’58’‘ ]. Dirks Empfehlung für diesen Fall war, jedem der “Widgets” eine eigene “region” zu geben und die Überschrift des Widgets als Label für die “region” zu nutzen (area-labeledby). Sollten auf einer Seite wieder sehr viele dieser Widgets zusammenkommen (>10 nannte Dirk), empfiehlt es sich, Cluster zu bilden und der Menge an Informationen feingranularere Struktur zu geben. Das leuchtet mir sofort ein und ich war sehr froh, in der Fragerunde am Schluss nachgefragt zu haben.

Elemente

Nachdem nun Struktur und Ablauf näher spezifiziert sind, gilt es, den einzelnen Bauelementen der Software-Oberfläche Beachtung zu schenken. Die Elemente definieren die Eigenschaften der einzelnen Bausteine, aus denen die Programm-Bedienoberfläche für die Nutzer:innen zusammengebaut sind.

technica11y DE 2022-01: Barrierefreiheit in der Bedienführung – Elemente. Bild: copy Dirk Ginader | Google

technica11y DE 2022-01: Barrierefreiheit in der Bedienführung – Elemente
[ 2022-01-17 Dirk Ginader | Google ]

Etiketten (labels) hinzufügen

Etiketten (labels) fügen fehlende Informationen durch Worte hinzu, die sonst rein visuell transportiert werden. Das gilt für Fotos genauso wie für Icons und andere Bedienelemente. Dirk geht im Vortrag auf den Herunterladen-Knopf ein [ 1:16’31’‘ ].

Dabei beschreiben die Etiketten

  • den Zweck,
  • das Verhalten oder
  • den Inhalt des Elements

Um zu entscheiden, was im jeweiligen Kontext das Wichtige ist, das ins Label geschrieben werden soll, stellt sich das UX Engineer-Team bei Google die Frage: Hat das Element Funktionalität oder Bedeutung? Dirk erläutert dies am Beispiel einer mobilen E-Mail-App [ 1:18’15’‘ ] mit sechs verschiedenen Symbolen (icons) und greift sich die Büroklammer heraus. Naheliegend wäre, das label zum Bedienelement auch so zu nennen, also “Büroklammer”. Für Screen Reader-Nutzer:innen ist das jedoch wenig aussagekräftig. “Anhang” wäre ebenfalls nicht hinreichend. Empfohlen wäre in diesem Fall “Datei anhängen”. Damit ist eine klare Aufforderung an die:den Nutzer:in verbunden und sie:er hört zugleich die Rolle des Elements.

Nächstes Beispiel: Alt-Attribut für Bilder [ 1:20’18’‘ ]. Dieser liefert die Bildbeschreibung für das <img> – also ein kurzer Text, was konkret im Bild zu sehen ist und nicht zu verwechseln mit der Bildunterschrift, die eine redaktionelle Ergänzung zum Bild in Textform darstellt.

Interessant ist hier die Frage: Wird die Bildbeschreibung immer und in allen Fällen benötigt? Dirk sagt dazu: Ja, wenn das Bild der Inhalt ist, um den es (zentral) geht. Rein dekorative Elemente hingegen sollten vor Screen Readern versteckt werden. Das gilt in der Regel für News-Übersichten oder auch Artikel-Listen, die neben der Überschrift noch einen Aufmacher enthalten [11:21’02’‘]. In diesen Fällen wäre die Bildbeschreibung eine Wiederholung und fügt keine Bedeutung oder sonstigen Wert für die Bedienung des Angebots aus der Perspektive von Menschen mit Sehbehinderung hinzu.

Technisch kann dies umgesetzt werden, indem beim Bild das <alt-tag> leer-gelassen wird. Dies empfiehlt sich jedoch nicht, da einige Screen Reader dann den Bild-Link vorlesen. Und das will keine:r! Besser ist es, jedem Foto der News die AREA-Rolle ‘decorative’ – bzw. um technisch korrekt zu sein < role="presentation" > oder < role="none" > – zu gegeben.

Letztes ist recht tricky, wann was nun das Geeignete ist. Wer hier genauer nachlesen mag, dem sei zum Einen die den obigen Link ergänzende Anleitung des W3C unter “Intentionally Hiding Semantics with the presentation Role” (EN) und weiterhin der Artikel von Scott O’Hara empfohlen (EN): “Know your ARIA: ‘Hidden’ vs ‘None’”.

Gute ‘label’ formulieren

Wie nun formuliert man die Etiketten möglichst gut? Dirk gibt dafür folgende Tipps [ 1:22’22’‘ ]

Bitte

  • beschreibe die Funktion oder Bedeutung des Bedienelements (nicht das Aussehen).
  • benutze Verben, um zur Aktion einzuladen.
  • formuliere knackig (so wenig wie möglich, so viel wie nötig).
  • bleibe konsistent (mindestens für die fokussierte AREA, idealerweise jedoch durchgehend im gesamten Programm).

Bitte nicht

  • bereits sichtbaren Text nachbeten.
  • Rolle oder Zustand des Elements im Label wiederholen.

Hierzu hatte ich in der Fragerunde nachgehakt [ 1:38:44 ]. Mich interessierte vor allem die Herangehensweise, wenn Icons innerhalb von Auswahlhilfen eine eigene Symbolik mitbringen. Dirk war klar in seiner Antwort: Entscheide Dich! Nicht beides. Entweder nur den Text (dann wieder das oben bei Struktur der Content Cards beschriebene Vorgehen mit area-labeledby headline) oder den jeweilig zusammengehörenden Auswahlbereich der Auswahlhilfe mit dem Icon/Text als Einheit zusammenfassen und etikettieren. Dabei entfällt das label zum Icon (das wäre sonst doppeltgemoppelt). Clever!

Rollen gezielt definieren

Wenn wir von der Norm abweichende Gestaltungselemente einführen, sollten diesen ihre Rollen explizit zugewiesen werden [ 1:24’15’‘ ]. Damit ermöglicht die:der UX Engineer Nutzenden die Information, wie diese mit dem Element interagieren können – also ob es sich beispielsweise um einen Button oder einen weiterführenden Link handelt. Dann kommt es nicht zu Verwirrungen über bestehende Erwartungen bei der Abfolge des Programms.

Regelmäßig auf die Maus verzichten

Dirk legte uns eine Sache besonders ans Herz [1:28’53’‘]: Dass wir es uns zur Gewohnheit machen, ein Mal pro Monat für einen ganzen Tag das Internet – und vor allem die eigenen Webseiten und Applikationen – ausschließlich mit der Tastatur bedienen.

Alles, was wir dabei lernen dann umsetzen und die Fehler nach und nach korrigieren bzw. beim Entwickeln neuer Funktionalitäten und Inhalte von Anfang an Barrierefreiheit in die Gestaltung mit einbeziehen.

Arbeitsplatz Wissensarbeiter:innen: Tastatur, Maus ausstecken. Bild: cc Franziska Köppe | madiko

Arbeitsplatz Wissensarbeiter:innen: Tastatur, Maus ausstecken
[ 2022-01-17 Franziska Köppe | madiko ]

Ich bin sehr gespannt, wie das meine gewohnten Arbeitsweisen verändern wird. Ich muss gestehen, dass es mich Überwindung kostet, die Maus wirklich konsequent auszustöpseln. Und das trotz meiner Liebe für Tastatur-Abkürzungen! Vielleicht schummle ich am Anfang ein wenig, und behalte sie zumindest als letzte Rettung, falls ich mich im Programm hoffnungslos verliere.

In jedem Fall bin ich an Deinen Erfahrungen und Erkenntnissen interessiert. Bitte erzähle sie mir und lass uns dazu in Erfahrungsaustausch bleiben!

Fazit & Ausblick

Was bleibt? Nun, auch auf die Gefahr, mich zu wiederholen: Herzlichen Dank für den Impuls und die Antworten auf unsere Fragen Dirk. Vor allem ist mir in diesem Vortrag das Zusammenspiel von Strukturen + Abläufen + Elementen im Spannungsfeld von Design und technischer Realisierung klarer geworden. Gerade diese Übersetzungsarbeit vermisse ich in vielen Tutorien zur Digitalisierung sehr häufig. Ein besonderer Pluspunkt für diesen Impuls und gern wieder!

Joschi Dir ein Dank fürs wertschätzende, freundliche Moderieren und Organisieren. Ich habe viel mitgenommen und Wissen gefestigt.

Einen Großteil der neuen Erkenntnisse werde ich über eine Verbesserung im Content Management System realisieren können. Da bin ich sehr froh drum. Die Umsetzung wird nicht lange warten müssen, da ich ohnehin aktuell dabei bin, das System auf den neuesten technischen Stand zu bringen. Die Vorarbeiten sind schon weit gediehen. Da geht es in Kürze los.

Den Teil jedoch, der händisch von mir als Redakteurin gepflegt werden muss, werde ich erst nach und nach im Rahmen der weiteren redaktionellen Arbeit angehen und verbessern können. EnjoyWork ist mittlerweile zu groß geworden, um sämtliche, publizierten Artikel komplett nachzuziehen. Dies ginge zulasten erweiterter Inhalte, was dem Projekt nicht dienlich wäre. Ich werde diese Verbesserungen dann sukzessive dort umsetzen, wo ich Seiten aktualisiere und ohnehin redaktionell auf den neuen Stand bringe.

Unten fasse ich die wichtigsten weiterführenden Links zusammen. Lass’ mich gern wissen, welche Fragen Dich zu Barrierefreiheit und Inklusion in der digitalen Transformation interessieren.

Zum Abschluss fehlt nur die Einladung von Joschi, die ich gern weiterreiche: Schließe Dich technica11y DE an: Jeden dritten Montag im Monat ab 17 Uhr. Thema und Impulsgeber:in gibt Joschi zirka 10 Tage vorab bekannt. technica11y international steht Dir natürlich ebenso offen.

In diesem Sinne: Auf ein Wiedersehen in Digitalien und…

bleib neugierig,

Hast Du eine Anregung
für Deine Aufgabe oder Frage gefunden?

Bitte teile diesen Artikel und werfe gern eine selbstgewählte Gabe in meinen virtuellen Hut. Auch ein kleiner Betrag macht den Unterschied!

Neugierig was mit Deinem Geld passiert?
Mit der Schwarmfinanzierung (einmalig via PayPal oder monatlich via steady)
wirst Du aktiver Teil der Bewegung und unternehmerischen Kooperative EnjoyWork. Lebens- & Arbeitswelten mit Zukunft.

Du unterstützt zudem freien, konstruktiven Online-Journalismus und die Moderation der Community. Es ist die Basis für mich, Franziska, Impulsgeber:innen und Vorreiter:innen rund um Lebens- & Arbeitswelten mit Zukunft zu portraitieren, regelmäßig mit Euch, der Community, auf Zukunftsthemen draufrumzudenken und fundiert über unsere Erkenntnisse und Praxiserfahrungen zu berichten.

Weitersagen heißt unterstützen

Ich setze mich für den freien und offenen Zugang zu Wissen ein. Dieser Artikel zahlt auf dieses Ziel ein. Teilst auch Du ihn in Deinem Netzwerk, kann er weitere Verbreitung finden. Danke für Deine Unterstützung!

Vielen Dank!

Was wirst Du als nächstes tun?

Zeit für Taten!

Ob Du noch ganz am Anfang der Transformation stehst, mittendrin bist oder schon durch und an der Weiterentwicklung Deiner Firma / Organisation arbeitest — in unserer Community findest Du Unterstützung für Deinen / Euren weiteren Weg.

Austauschen & Netzwerken

Wir bieten verschiedene Formate, um mit praktizierenden Gleichgesinnten ins Gespräch zu kommen: Ratgeber, Experten, Vorbilder und Transformationskatalysatoren. So fördern wir den interdisziplinären Erfahrungs- und Wissensaustausch.

Informieren & Inspirieren

Impulse, Fragen, Ideen, Fallbeispiele: Wer sinnvoll wirtschaften will und bereit ist, seine Firma darauf auszurichten, sucht Antworten für die alltäglichen Herausforderungen. Wir prüfen unsere Erkenntnisse an der Praxis und erforschen sie wissenschaftlich.