Barrierefreiheit von Windows-Apps — UI Automation und die Pflicht zu angemessenen Vorkehrungen

„Ein Beschäftigter mit Sehbehinderung kann unsere zentrale Auftragserfassungs-App mit einem Screenreader nicht nutzen. Browser und E-Mail beherrscht er, aber in unserer Geschäftsanwendung allein funktionieren die Ansagen nicht.“ Solche Anfragen aus IT-Abteilungen von Kunden hören wir immer häufiger.

Der Ausgangspunkt, dieses Problem zu lösen, ist zu betrachten, was Sie der Hilfstechnologie mitteilen, nicht wie der Bildschirm aussieht. Windows hat UI Automation (UIA), den Mechanismus, über den Screenreader die Informationen einer App lesen. Sobald Sie verstehen, wie er funktioniert, und die Grundlagen von Namen, Tastatur und Farbe abdecken, verbessert sich die Nutzbarkeit einer Geschäftsanwendung wesentlich.¹

Auch rechtlich sind interne Windows-Apps nicht ausgenommen. Die Änderung 2021 des Gesetzes zur Beseitigung der Diskriminierung von Menschen mit Behinderungen trat am 1. April 2024 in Kraft, und auch Unternehmen sind nun verpflichtet, angemessene Vorkehrungen bereitzustellen. Das Beschäftigungsfeld, wie im Eingangsbeispiel, fällt stattdessen unter das Gesetz zur Förderung der Beschäftigung von Menschen mit Behinderungen und ist seit April 2016 eine Arbeitgeberpflicht. Kapitel 2 ordnet diesen Unterschied.²³

Für die Barrierefreiheit von Windows-Desktop-Apps gibt es weniger Informationen als für das Web, und es gibt keinen Weg, sie nachträglich auf einmal zu lösen. Ein großer Teil der nötigen Verbesserungen hebt jedoch die Produktivität jedes Benutzers, mit oder ohne Behinderung.

Dieser Artikel richtet sich an Entwickler japanischer Geschäftsanwendungen und IT-Verantwortliche. Er behandelt den rechtlichen Rahmen und die Normen sowie die Funktionsweise von UIA und geht dann zur Implementierung in WinForms/WPF, zur Tastaturbedienung, zu Farbe und Kontrast, zur Prüfung und zur Priorisierung der Korrekturen über.

flowchart TB
    accTitle: Der Ablauf dieses Artikels
    accDescr: Die Struktur dieses Artikels, der der Reihe nach den rechtlichen Rahmen und die Normen, die Funktionsweise von UI Automation, die Implementierung in WinForms und WPF, die Tastaturbedienung, Farbe und Kontrast, Prüfwerkzeuge und das Setzen von Prioritäten verbindet
    law["Rechtlicher Rahmen und Normen"] --> uia["Funktionsweise von UI Automation"]
    uia --> impl["Implementierung in WinForms/WPF"]
    impl --> kb["Tastaturbedienung"]
    kb --> color["Farbe und Kontrast"]
    color --> verify["Prüfwerkzeuge"]
    verify --> prio["Prioritäten setzen"]

Abbildung 1: Dieser Artikel verbindet rechtlichen Rahmen, Mechanismus, Implementierung, Prüfung und Prioritäten in einem einzigen Ablauf.

1. Zuerst das Fazit

Drei Punkte, die zuerst festzuhalten sind.

1. Trennen Sie individuelle angemessene Vorkehrungen von der vorgezogenen Gestaltung der Umgebung. Angemessene Vorkehrungen sind ein Prozess, auf eine Anfrage im konstruktiven Dialog in einem Rahmen zu antworten, der keine übermäßige Belastung darstellt. Unternehmen sind seit April 2024 verpflichtet, Arbeitgeber im Beschäftigungsfeld seit April 2016. Eine App im Voraus zu korrigieren, fällt unter die „Gestaltung der Umgebung“ (eine Bemühenspflicht) und ist etwas anderes, als jeden Bildschirm von Anfang an perfekt zu machen.²³
2. Die technische Grundlage ist, Informationen an UIA offenzulegen, plus die Grundlagen von Namen, Tastatur und Farbe. Name und ControlType des UIA-Baums sowie Muster wie Invoke, Value und SelectionItem sind das Material für Ansage und Bedienung. Die Benennung kommt zuerst. WinForms erledigt sie mit AccessibleName und der Zuordnung zwischen Label und Tabulatorreihenfolge, WPF mit AutomationProperties.Name/LabeledBy; dazu räumen Sie Tastaturbedienung, ein Farbschema mit einem Kontrastverhältnis von 4,5:1 als Leitlinie und Anzeigen ein, die nicht allein auf Farbe setzen.¹⁴⁵⁶
3. Prüfen und korrigieren Sie ausgehend von der tatsächlichen Arbeit. Kombinieren Sie FastPass in Accessibility Insights mit praktischer Prüfung durch einen Screenreader und arbeiten Sie der Reihe nach die Bildschirme ab, auf die der Benutzer angewiesen ist, dann neue Bildschirme, dann gemeinsame Steuerelemente. Dieselben Verbesserungen helfen auch der UI-Testautomatisierung wie FlaUI, die auf derselben UIA-Grundlage sitzt.⁷

Die technischen Kriterien lassen sich um WCAG ordnen. JIS X 8341-3:2016 ist eine identische Norm mit demselben Inhalt wie WCAG 2.0, und WCAG2ICT gibt Leitlinien zur Anwendung auf Nicht-Web-Software. Abschnitt 2.2 geht ins Detail.⁸⁹

Wenn Sie nach Ihrem Ziel lesen wollen, beginnen Sie beim folgenden Kapitel.

In einem Satz: Barrierefreiheit heißt, „korrekte Namen und Operationen auf dem UIA-Baum offenzulegen und die Grundlagen von Tastatur und Farbe einzuhalten.“

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (16 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Der rechtliche Rahmen und die Normen — was die „Pflicht“ geändert hat

2.1. Das Gesetz zur Beseitigung der Diskriminierung von Menschen mit Behinderungen — seit April 2024 müssen auch Unternehmen angemessene Vorkehrungen bereitstellen

Dieser Abschnitt trennt drei Fragen: was zur Pflicht wurde, wo Vorabkorrekturen einzuordnen sind und welches Gesetz im Beschäftigungsfeld gilt.

Angemessene Vorkehrungen durch Unternehmen wurden von einer Bemühenspflicht zur Pflicht

Das Gesetz zur Beseitigung der Diskriminierung von Menschen mit Behinderungen verbietet Verwaltungsorganen und Unternehmen die „ungerechtfertigte diskriminierende Behandlung“ von Menschen mit Behinderungen und verlangt von ihnen, „angemessene Vorkehrungen bereitzustellen“. Mit der Änderung 2021 (Reiwa 3) wurde die Bereitstellung angemessener Vorkehrungen durch Unternehmen, bis dahin eine Bemühenspflicht, zur Pflicht, und die Änderung trat am 1. April 2024 (Reiwa 6) in Kraft.²

Das Faltblatt des Kabinettsbüros erklärt sie als Antwort in einem Rahmen, der keine übermäßige Belastung darstellt, wenn ein Mensch mit Behinderung den Wunsch äußert, eine Barriere beseitigen zu lassen. Weil die Einzelheiten nach Art der Behinderung, Szene und Lage unterschiedlich sind, ist der „konstruktive Dialog“, in dem die Person und das Unternehmen die Optionen gemeinsam durchsprechen, wichtig. Das Faltblatt stellt ausdrücklich fest, dass die einseitige Verweigerung des Dialogs eine Verletzung der Bereitstellungspflicht darstellen kann.²

Behandeln Sie Vorabkorrekturen der App als „Gestaltung der Umgebung“

Nicht die vollständige Vorabausstattung ist zur Pflicht geworden. Maßnahmen, die im Voraus für eine unbestimmte Zahl von Menschen mit Behinderungen ergriffen werden, etwa die Überarbeitung von Handbüchern, Schulungen und die Barrierefreiheit von Einrichtungen, heißen „Gestaltung der Umgebung“ und sind als Bemühenspflicht eingeordnet.²

Eine Geschäftsanwendung vorab in einen Zustand zu versetzen, den ein Screenreader nutzen kann, lässt sich als Anstrengung auf dieser Seite der Gestaltung der Umgebung verstehen. Je weiter diese Gestaltung fortgeschritten ist, desto leichter fällt die Last, individuelle angemessene Vorkehrungen bereitzustellen.

Wo Beschäftigte betroffen sind, gilt das Gesetz zur Förderung der Beschäftigung von Menschen mit Behinderungen

Beschäftigung und Arbeit fallen unter das Gesetz zur Förderung der Beschäftigung von Menschen mit Behinderungen, nicht unter das Gesetz zur Beseitigung der Diskriminierung von Menschen mit Behinderungen. Das Faltblatt des Kabinettsbüros hält diesen Unterschied ebenfalls fest.²

Unter dem Gesetz zur Förderung der Beschäftigung von Menschen mit Behinderungen verpflichtet die Änderung, die im April 2016 (Heisei 28) in Kraft trat, Arbeitgeber, im Beschäftigungsfeld von Diskriminierung wegen Behinderung abzusehen und angemessene Vorkehrungen in einem Rahmen bereitzustellen, der keine übermäßige Belastung darstellt. Die Eingangsfrage „ein Beschäftigter kann die Geschäftsanwendung nicht nutzen“ liegt daher schon lange vor 2024 im Bereich der Pflicht.³

flowchart TB
    accTitle: Einordnung angemessener Vorkehrungen und der Gestaltung der Umgebung
    accDescr: Die Beziehung zwischen einem allgemeinen Unternehmen und einem Menschen mit Behinderung fällt unter das Gesetz zur Beseitigung der Diskriminierung von Menschen mit Behinderungen, und angemessene Vorkehrungen durch Antwort auf eine individuelle Anfrage im konstruktiven Dialog sind seit April 2024 Pflicht; das Beschäftigungsfeld ist seit April 2016 unter dem Gesetz zur Förderung der Beschäftigung von Menschen mit Behinderungen eine Arbeitgeberpflicht; die Vorabkorrektur einer App fällt unter die Gestaltung der Umgebung, eine Bemühenspflicht
    scene{"Welche Szene?"} -->|Unternehmen und ein Mensch mit Behinderung| kaisho["Gesetz zur Beseitigung der Diskriminierung von Menschen mit Behinderungen"]
    scene -->|Beschäftigung und Arbeit| koyou["Gesetz zur Förderung der Beschäftigung von Menschen mit Behinderungen"]
    kaisho --> moushide["Auf individuelle Anfragen im konstruktiven Dialog antworten"]
    moushide --> hairyo["Bereitstellung angemessener Vorkehrungen (Pflicht seit April 2024)"]
    koyou --> koyougimu["Bereitstellung angemessener Vorkehrungen (Pflicht seit April 2016)"]
    kaisho -.-> kankyo["Vorabkorrektur der App = Gestaltung der Umgebung (Bemühenspflicht)"]
    kankyo -.-> moushide

Abbildung 2: Das maßgebliche Gesetz hängt von der Szene ab; angemessene Vorkehrungen sind Pflicht, Vorabkorrekturen fallen unter die Gestaltung der Umgebung, eine Bemühenspflicht.

Wie ein Einzelfall rechtlich behandelt wird, hängt von der Lage ab. Dieser Artikel geht nicht in die Rechtsauslegung; er geht von dem Standpunkt aus, was eine Ingenieurin oder ein Ingenieur tun kann, wenn um eine Antwort gebeten wird. Als Primärquellen siehe die Unterlagen des Kabinettsbüros und des Ministeriums für Gesundheit, Arbeit und Soziales.²³

2.2. JIS X 8341-3 und WCAG — die „Web-Kriterien“ reichen auch auf Software

Wenn Sie die technischen Kriterien im Detail lesen, gibt die Ordnung um WCAG den klarsten Blick. JIS X 8341-3:2016, WCAG und WCAG2ICT stehen zueinander wie folgt.⁸⁶⁹

Auf die Frage „ist WCAG nicht eine Norm für Webinhalte?“ ist WCAG2ICT die Brücke. Der volle Name lautet Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies.⁹

Ideen wie Textalternativen, Kontrast, Tastaturbedienung und das Nichtvermitteln von Informationen allein durch Farbe gelten für eine Windows-Desktop-App im selben Rahmen. Ab Kapitel 3 setzt dieser Artikel sie in die Implementierung in WinForms/WPF um.

flowchart TB
    accTitle: Die Beziehung zwischen JIS X 8341-3 und WCAG
    accDescr: JIS X 8341-3:2016 ist eine identische Norm mit demselben Inhalt wie WCAG 2.0, und WCAG2ICT zeigt, wie die WCAG-Erfolgskriterien auf Nicht-Web-Software anzuwenden sind, sodass eine Windows-Desktop-App im selben Rahmen geprüft werden kann
    wcag["WCAG 2.0 (W3C)"] ---|Identische Norm mit demselben Inhalt| jis["JIS X 8341-3:2016"]
    wcag --> ict["WCAG2ICT"]
    ict --> soft["Auf Nicht-Web-Software angewendet"]
    soft --> app["Windows-Desktop-Apps"]

Abbildung 3: JIS X 8341-3:2016 ist eine identische Norm zu WCAG 2.0, und WCAG2ICT verlängert dieselben Kriterien auf Desktop-Apps.

3. Wie Hilfstechnologie eine App liest — das Dreigestirn von UI Automation

3.1. Der UIA-Baum, Eigenschaften und Steuerelementmuster

UI Automation (UIA), in Windows eingebaut, ist die Barrierefreiheitsgrundlage, die zwischen App und Hilfstechnologie vermittelt. Die App legt UI-Informationen als „Anbieter“ offen, und Hilfstechnologie wie ein Screenreader bezieht sie als „Client“. UI-Bedienung auf anderen Wegen als der Standardeingabe wird durch denselben Mechanismus möglich.¹

Beginnen Sie damit, es als Dreigestirn zu verstehen: die Struktur des Bildschirms, die Natur jedes Elements und die verfügbaren Operationen.¹

Die Ansage „Auftrag bestätigen, Schaltfläche“, wenn eine Schaltfläche den Fokus erhält, ist grob die Kombination aus Name und Steuerelementtyp. Wenn der Benutzer einen Ausführen-Befehl gibt, drückt die Hilfstechnologie die Schaltfläche über das Invoke-Muster.

Mit anderen Worten: Eine Schaltfläche, die auf dem Bildschirm gezeichnet ist, und eine Schaltfläche, die von Hilfstechnologie lesbar und bedienbar ist, sind zwei verschiedene Dinge. Wenn Name und die Muster nicht korrekt offengelegt sind, ist die Schaltfläche so gut wie nicht vorhanden, auch wenn sie auf dem Bildschirm sichtbar ist.

flowchart TB
    accTitle: Das Dreigestirn von UI Automation
    accDescr: Die App legt als Anbieter die Eigenschaften und Steuerelementmuster jedes Elements auf dem UIA-Baum offen; der Screenreader sagt als Client Name und ControlType an und bedient über Muster wie Invoke
    app["App (Anbieter)"] --> tree["UIA-Baum"]
    tree --> prop["Eigenschaften (Name, ControlType usw.)"]
    tree --> pat["Muster (Invoke, Value usw.)"]
    sr["Screenreader (Client)"] -->|Sagt an| prop
    sr -->|Bedient| pat

Abbildung 4: Der Screenreader nutzt die Eigenschaften und Muster, die die App auf dem UIA-Baum offengelegt hat, für Ansage und Bedienung.

3.2. Ein Screenreader ist ein UIA-Client

Die wichtigsten Screenreader unter Windows sind der eingebaute Narrator, der freie und quelloffene NVDA¹⁰ und PC-Talker, ein in Japan weit verbreitetes kommerzielles Produkt.

Jeder hat seinen eigenen Ansagestil, der primäre Weg, die UI einer Desktop-App zu lesen, ist jedoch in allen Fällen UIA. Die Arbeit auf App-Seite läuft daher auf das Offenlegen korrekter Informationen an UIA hinaus, nicht auf die Ausrichtung auf einen bestimmten Screenreader.

flowchart TB
    accTitle: Der gemeinsame Weg der wichtigsten Screenreader
    accDescr: Wenn die App korrekte Informationen an UIA offenlegt, können Narrator, NVDA und PC-Talker die UI alle über denselben Weg lesen, die Arbeit auf App-Seite zielt also nicht auf einen bestimmten Screenreader, sondern läuft auf das Offenlegen an UIA hinaus
    app["App"] -->|Legt Informationen offen| uia["UI Automation (UIA)"]
    uia --> nar["Narrator"]
    uia --> nvda["NVDA"]
    uia --> pct["PC-Talker"]
    app -.-> goal["Die Arbeit läuft auf das Offenlegen an UIA hinaus"]

Abbildung 5: Die wichtigsten Screenreader gehen alle über UIA, die Arbeit der App läuft also auf das Offenlegen an UIA hinaus.

3.3. Als was wird eine „Schaltfläche mit leerem Name“ angesagt?

Angenommen, eine Symbolleiste hat eine Speichern-Schaltfläche, die nur ein Diskettensymbol zeigt. Auch wenn der Zweck visuell klar ist, sagt der Screenreader nichts weiter als „Schaltfläche“, wenn Name leer bleibt. Sind die benachbarten „Öffnen“ und „Drucken“ im selben Zustand, hört der Benutzer nur „Schaltfläche, Schaltfläche, Schaltfläche“ und kann sie nicht unterscheiden.

Schaltflächen ohne Name und Bilder, die nur als „Image“ angesagt werden, stehen in den Korrekturleitfäden von Microsoft als typische Probleme, die die Arbeit des Benutzers anhalten.⁵

Standardsteuerelemente von WinForms/WPF unterstützen UIA von Anfang an, und bei den meisten wird Name automatisch aus Text oder einem Label abgeleitet. Die drei typischen Wege, auf denen es bricht, sind die folgenden.

Die nächsten zwei Kapitel verbinden diese Triage mit den Korrekturen für WinForms und WPF.

flowchart TB
    accTitle: Drei typische Wege, auf denen die Ansage bricht
    accDescr: Die Ansage bricht, wenn kein Material für einen Namen da ist, weil das Steuerelement nur ein Symbol ist, wenn keine Zuordnung zu einem Label besteht oder wenn eigenes Zeichnen keine Informationen auf den UIA-Baum legt, und das Steuerelement wird nur als Schaltfläche angesagt
    c1["Nur Symbol, kein Material"] --> broken["Name bleibt leer"]
    c2["Keine Labelzuordnung"] --> broken
    c3["Eigenes Zeichnen legt nichts offen"] --> broken
    broken --> result["Nur als Schaltfläche angesagt"]

Abbildung 6: Gebrochene Ansagen laufen meist auf drei Muster hinaus: fehlendes Material für einen Namen, fehlende Zuordnung oder eigenes Zeichnen.

4. Implementierung in WinForms — AccessibleName und Tabulatorreihenfolge

4.1. Steuerelemente, deren Text automatisch zu Name wird, und solche, bei denen das nicht gilt

Zuerst prüfen, ob das Steuerelement eine Art ist, deren Text als Name genutzt wird

In WinForms nutzen selbst unter den Steuerelementen, die Text anzeigen, manche Text als UIA-Name und manche nicht.⁴

Ein Anzeigelabel nutzen und AccessibleName setzen, wo Sie keines platzieren können

Am pflegeleichtesten ist, ein beschreibendes Label in der Tabulatorreihenfolge unmittelbar vor das Zielsteuerelement zu legen. Kommt der TabIndex des Zielsteuerelements direkt nach dem TabIndex des Labels, wird der Text des Labels als UIA-Name genutzt. Anzeige und Ansage stimmen überein, und Sie vermeiden, die Formulierung doppelt zu pflegen.⁴¹¹

Wo Sie kein Label platzieren können, setzen Sie AccessibleName ausdrücklich. Sie können außerdem AccessibleDescription für ergänzende Informationen setzen und AccessibleRole, wenn die Rolle dem entsprechen muss, was das Steuerelement tatsächlich tut.¹²

flowchart TB
    accTitle: Wie der Name eines WinForms-Steuerelements entschieden wird
    accDescr: Bei Button und ähnlichen Steuerelementen wird Text unverändert zum UIA-Name; bei Steuerelementen wie TextBox, deren Text nicht wiederverwendet wird, wird der Text eines in der Tabulatorreihenfolge unmittelbar davor liegenden Labels genutzt; wo kein Label platziert werden kann, wird AccessibleName ausdrücklich gesetzt
    ctrl["Steuerelement"] --> qtext{"Wird Text zu Name?"}
    qtext -->|Ja| usetext["Text wird unverändert als Name genutzt"]
    qtext -->|Nein| qlabel{"Label unmittelbar davor in der Tabulatorreihenfolge?"}
    qlabel -->|Ja| uselabel["Der Text des Labels wird als Name genutzt"]
    qlabel -->|Nein| explicit["AccessibleName ausdrücklich setzen"]

Abbildung 7: Ein WinForms-Name wird in der Reihenfolge Text, das Label unmittelbar davor in der Tabulatorreihenfolge, dann AccessibleName entschieden.

// Nur-Symbol-Symbolleistenschaltfläche: den Namen für die Ansage ausdrücklich setzen
saveToolStripButton.AccessibleName = "Speichern";

// Nur-Bild-Schaltfläche: Name plus ergänzende Beschreibung
btnSearchCustomer.AccessibleName = "Kunden suchen";
btnSearchCustomer.AccessibleDescription = "Durchsucht den Kundenstamm nach Kundencode oder Name";

// Eingabefeld, bei dem kein Label unmittelbar davor in der Tabulatorreihenfolge platziert werden kann: direkt setzen
txtOrderNo.AccessibleName = "Auftragsnummer";

// Als Diagramm umgenutztes PictureBox: die Rolle dem anpassen, was es tatsächlich ist
pictureBoxChart.AccessibleRole = AccessibleRole.Chart;
pictureBoxChart.AccessibleName = "Diagramm der monatlichen Auftragszahlen";

Wenn Sie den Namen gelöscht haben, die Standardansage aber nicht zurückkehrt

Wenn Sie AccessibleName einmal im Eigenschaftenfenster von Visual Studio setzen und dann löschen, kann in der Designerdatei eine Einstellung mit leerer Zeichenfolge zurückbleiben. Wenn diese Einstellung die Standardnamensauflösung blockiert, löschen Sie die Zeile aus der Designerdatei.⁴

flowchart TB
    accTitle: Das Problem einer zurückbleibenden leeren AccessibleName-Zeichenfolge
    accDescr: Wenn Sie AccessibleName einmal im Eigenschaftenfenster setzen und dann löschen, bleibt in der Designerdatei eine Einstellung mit leerer Zeichenfolge und blockiert die Standardnamensauflösung, Sie beheben es, indem Sie die Zeile aus der Designerdatei löschen
    set["AccessibleName setzen"] --> erase["Im Eigenschaftenfenster löschen"]
    erase --> remain["Eine Einstellung mit leerer Zeichenfolge bleibt"]
    remain --> block["Blockiert die Standardnamensauflösung"]
    block -.-> fix["Die Zeile aus der Designerdatei löschen"]

Abbildung 8: Das Löschen im Eigenschaftenfenster hinterlässt eine leere Zeichenfolge, beheben Sie es, indem Sie die Zeile aus der Designerdatei löschen.

4.2. Häufige Verbesserungen auf einem Auftragserfassungsbildschirm

Hier eine Checkliste der Stellen, die wir in Geschäftsanwendungen am häufigsten korrigieren.

Jede Korrektur umfasst nur wenige Zeilen, für einen Screenreader-Benutzer ist sie jedoch der Unterschied zwischen einem Bildschirm, den er nicht nutzen kann, und einem, den er nutzen kann.

5. Implementierung in WPF — AutomationProperties und AutomationPeer

5.1. AutomationProperties.Name / LabeledBy / HelpText

Einer Schaltfläche den Namen über Zeichenfolgen-Content oder eine ausdrückliche Einstellung geben

Bei einem Steuerelement, dessen Content eine Zeichenfolge ist, etwa einem WPF-Button, wird dieser Inhalt als UIA-Name genutzt. Eine Schaltfläche, die nur ein Image oder einen Path enthält, hat dagegen kein Material für einen Namen. Setzen Sie ihn entweder ausdrücklich mit AutomationProperties.Name, oder ordnen Sie ihn, wenn Anzeigetext in der Nähe ist, mit AutomationProperties.LabeledBy zu.⁵

In einer TextBox den „Namen“ vom „Eingabewert“ trennen

Der Text eines TextBlock wird als Name wiederverwendet, der Text einer TextBox wird jedoch auf der UIA-Eigenschaft Value offengelegt und wird nicht zu Name. Auch wenn das Feld einen Wert hält, sagt das allein dem Benutzer nicht, wozu das Feld da ist.¹³

Für ein Eingabefeld ist die erste Wahl, den Anzeigelabel-TextBlock über LabeledBy zuzuordnen. Anzeige und Ansage stimmen überein, und Sie vermeiden, die Formulierung doppelt zu pflegen.¹³

<!-- Eingabefeld: das Anzeigelabel über LabeledBy zuordnen -->
<TextBlock x:Name="OrderNoLabel" Text="Auftragsnummer" />
<TextBox
    AutomationProperties.LabeledBy="{Binding ElementName=OrderNoLabel}"
    AutomationProperties.AutomationId="OrderNoTextBox" />

<!-- Nur-Symbol-Schaltfläche: den Namen ausdrücklich setzen und bei Bedarf eine Ergänzung anfügen -->
<Button
    AutomationProperties.Name="Auftrag bestätigen"
    AutomationProperties.HelpText="Bestätigt den laufenden Auftrag und reserviert den Bestand">
    <Path Data="{StaticResource CheckIconGeometry}" Width="16" Height="16" />
</Button>

flowchart TB
    accTitle: Wie der Name eines WPF-Steuerelements entschieden wird
    accDescr: Ein Steuerelement, dessen Content eine Zeichenfolge ist, nutzt diesen Inhalt als Name; sonst ist die erste Wahl, ein nahes Anzeigelabel über LabeledBy zuzuordnen, und wenn keines da ist, wird AutomationProperties.Name ausdrücklich gesetzt; der Text einer TextBox wird als Value offengelegt, nicht als Name
    ctrl["Steuerelement"] --> qc{"Ist Content eine Zeichenfolge?"}
    qc -->|Ja| auto["Der Inhalt wird zu Name"]
    qc -->|Nein| ql{"Anzeigelabel in der Nähe?"}
    ql -->|Ja| lb["Über LabeledBy zuordnen"]
    ql -->|Nein| nm["Name ausdrücklich setzen"]
    tbx["TextBox-Text"] -.-> val["Als Value offengelegt, nicht als Name"]

Abbildung 9: Ein WPF-Name wird in der Reihenfolge Zeichenfolgen-Content, LabeledBy, dann ausdrückliche Einstellung entschieden; der Text einer TextBox wird nicht zu Name.

HelpText und AutomationId haben andere Rollen als der Name

Ergänzende Informationen, die nicht in Name passen, werden über AutomationProperties.HelpText offengelegt.⁵ AutomationId ist eine Kennung, die auch genutzt wird, um Elemente in der UI-Testautomatisierung zu finden. Eine Namenskonvention schon in der Bildschirmgestaltung festzulegen, zahlt sich in späteren Tests aus.

Kurz: Name ist der Zweck, HelpText die Ergänzung, AutomationId die Kennung. Wie sie in automatisierten Tests genutzt werden, ist ausführlich in „UI-Automatisierungstests für Windows-Desktop-Apps“ behandelt.

5.2. Eigene Steuerelemente brauchen einen AutomationPeer

Ein selbstgezeichnetes Steuerelement kann für sich genommen keine sinnvollen Informationen auf dem UIA-Baum offenlegen. In WPF legen Sie Name, Art und Muster offen, indem Sie OnCreateAutomationPeer auf einer von UIElement abgeleiteten Klasse überschreiben und eine von AutomationPeer abgeleitete Klasse zurückgeben.¹⁴

Wenn Sie von einem bestehenden Steuerelement erben, erben Sie auch vom entsprechenden Peer. Für ButtonBase etwa lässt sich mit ButtonBaseAutomationPeer das bereits implementierte Verhalten übernehmen.¹⁴

flowchart TB
    accTitle: Wie AutomationPeer Informationen offenlegt
    accDescr: Ein eigenes Steuerelement legt Name, Art und Muster offen, indem es OnCreateAutomationPeer überschreibt und eine von AutomationPeer abgeleitete Klasse zurückgibt; wenn es ein bestehendes Steuerelement erbt, erbt es den entsprechenden Peer und übernimmt das bereits implementierte Verhalten
    custom["Eigenes Steuerelement"] --> ov["OnCreateAutomationPeer"]
    ov --> peer["Eine von Peer abgeleitete Klasse zurückgeben"]
    peer --> pub["Name, Art und Muster offenlegen"]
    inherit["Erbt ein bestehendes Steuerelement"] -.-> basepeer["Den entsprechenden Peer erben"]
    basepeer -.-> reuse["Implementiertes Verhalten übernehmen"]

Abbildung 10: Ein eigenes Steuerelement gibt einen Peer aus OnCreateAutomationPeer zurück, um Informationen an UIA offenzulegen.

// Beispiel eines Steuerelements, das den Leitungsstatus als farbige Lampe selbst zeichnet
public class StatusLamp : Control
{
    public static readonly DependencyProperty IsOnlineProperty =
        DependencyProperty.Register(nameof(IsOnline), typeof(bool), typeof(StatusLamp),
            new FrameworkPropertyMetadata(false,
                FrameworkPropertyMetadataOptions.AffectsRender, OnIsOnlineChanged));

    public bool IsOnline
    {
        get => (bool)GetValue(IsOnlineProperty);
        set => SetValue(IsOnlineProperty, value);
    }

    internal static string NameFor(bool isOnline)
        => isOnline ? "Leitungsstatus: online" : "Leitungsstatus: offline";

    private static void OnIsOnlineChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        // Das UIA-Eigenschaftsänderungsereignis im Moment der Wertänderung auslösen. Ohne es
        // behält der Screenreader den alten Namen und merkt die Zustandsänderung nie
        if (UIElementAutomationPeer.FromElement((UIElement)d) is AutomationPeer peer)
        {
            peer.RaisePropertyChangedEvent(
                AutomationElementIdentifiers.NameProperty,
                NameFor((bool)e.OldValue), NameFor((bool)e.NewValue));
        }
    }

    protected override AutomationPeer OnCreateAutomationPeer()
        => new StatusLampAutomationPeer(this);
}

public class StatusLampAutomationPeer : FrameworkElementAutomationPeer
{
    public StatusLampAutomationPeer(StatusLamp owner) : base(owner) { }

    protected override AutomationControlType GetAutomationControlTypeCore()
        => AutomationControlType.Text; // Text ist angemessen für eine Statusanzeige ohne Operationen

    protected override string GetNameCore()
        => StatusLamp.NameFor(((StatusLamp)Owner).IsOnline);
}

Zustandsänderungen mitteilen, nicht nur den aktuellen Namen

Das Beispiel oben kombiniert zwei Dinge: einen Namen zurückzugeben, der den aktuellen Zustand widerspiegelt, und ein Name-Eigenschaftsänderungsereignis auszulösen, wenn IsOnline sich ändert.

Die Aufgabe des Peers ist nicht nur, den Namen zurückzugeben, sondern die Änderung im Moment ihres Eintretens mit einem Ereignis zu signalisieren. Hilfstechnologie hat keinen eigenen Zeitpunkt, einen Wert erneut abzurufen; ohne das Ereignis ist die Implementierung „nur korrekt, wenn erneut gefragt wird“, und Screenreader-Benutzer erfahren nie, dass sich der Zustand geändert hat.

sequenceDiagram
    accTitle: Wie eine Zustandsänderung den Screenreader erreicht
    accDescr: Im Moment der Wertänderung des Steuerelements löst der AutomationPeer ein Name-Eigenschaftsänderungsereignis aus; Hilfstechnologie ruft nicht von selbst erneut ab, ohne das Ereignis behält sie den alten Namen und merkt die Änderung nie
    participant c as Steuerelement
    participant p as AutomationPeer
    participant s as Screenreader
    c->>p: IsOnline-Wert ändert sich
    p->>s: Löst ein Name-Eigenschaftsänderungsereignis aus
    s->>s: Sagt den neuen Zustand an
    Note over s: Ohne das Ereignis bleibt der alte Name

Abbildung 11: Eine Wertänderung erreicht den Screenreader nur, wenn der AutomationPeer sie mit einem Änderungsereignis signalisiert.

Wenn das Steuerelement Operationen hat, die Muster implementieren und in gemeinsame Komponenten legen

Für eigene Steuerelemente, die gedrückt werden können, einen änderbaren Wert haben oder ausgewählt werden können, überschreiben Sie GetPattern und stellen Musterschnittstellen wie IInvokeProvider und IRangeValueProvider bereit.¹⁴

Wenn Sie den Peer in die gemeinsame Steuerelementbibliothek einbauen, wird jeder Bildschirm, der sie nutzt, automatisch konform. Das ist die Grundlage für die Ausbreitung, die Kapitel 9 beschreibt.

6. Lässt sich jede Funktion allein von der Tastatur erreichen?

WCAG-Erfolgskriterium 2.1.1 (Tastatur) verlangt, dass die gesamte Funktionalität über eine Tastaturschnittstelle bedienbar ist.⁶ Screenreader-Benutzer nutzen in der Regel keine Maus, eine Funktion, die von der Tastatur nicht erreichbar ist, ist daher dieselbe wie eine Funktion, die nicht existiert.

6.1. Bewegung, Ausführung und aktuelle Position prüfen

Prüfen Sie nicht nur die Tabulatorreihenfolge, sondern auch, dass die Hauptoperationen ausgeführt werden können und dass der aktuelle Fokus sichtbar ist.

Die WinForms-Barrierefreiheitsanleitung nennt als Grundlagen ebenfalls, ein Label in der Tabulatorreihenfolge unmittelbar vor ein Eingabefeld zu legen und den Steuerelementen und Menüs, zu denen der Benutzer wechseln will, Zugriffstasten zu geben.¹¹

6.2. Tastaturarbeit verbessert auch die Eingabeeffizienz jedes Benutzers

Das ist nicht bloß „ein Zusatzkostenblock für die Unterstützung von Menschen mit Behinderungen“. In Routinearbeit wie der Auftragserfassung entscheidet, ob die Bedienkraft die Eingabe abschließen kann, ohne die Grundstellung zu verlassen, wie viele Vorgänge sie schafft.

Eine durcheinandergebrachte Tabulatorreihenfolge oder eine Operation, die die Maus verlangt, ist ein Mangel, der jedem Benutzer jeden Tag ein Stück Produktivität abschneidet. Arbeit an der Barrierefreiheit und Tastatureffizienz sind zwei Namen für dieselbe Arbeit. Zu Prioritäten nach Nutzungsumgebung siehe auch „Windows-App-UX-Design“.

flowchart TB
    accTitle: Die doppelte Wirkung der Tastaturarbeit
    accDescr: Tabulatorreihenfolge, Zugriffstasten und Fokusanzeige in Ordnung zu bringen, erzeugt zwei Wirkungen zugleich, dass Nutzer von Hilfstechnologie Funktionen erreichen können und die Eingabegeschwindigkeit jeder Bedienkraft, während eine nur mit der Maus nutzbare Funktion dieselbe ist wie eine, die nicht existiert
    seibi["Tastaturbedienung in Ordnung gebracht"] --> a11y["Nutzer von Hilfstechnologie können arbeiten"]
    seibi --> speed["Eingabegeschwindigkeit jeder Bedienkraft"]
    mouse["Nur-Maus-Funktionen"] -.-> none["Gleichbedeutend mit nicht existierenden Funktionen"]

Abbildung 12: Tastaturarbeit liefert Unterstützung der Hilfstechnologie und Effizienz für jeden Benutzer zugleich; eine Nur-Maus-Funktion ist so gut wie nicht vorhanden.

7. Farbe und Kontrast — 4,5:1 und „nicht allein durch Farbe“

7.1. Die Leitlinie für das Kontrastverhältnis ist 4,5:1

WCAG-Erfolgskriterium 1.4.3 (Kontrast (Minimum)) verlangt ein Kontrastverhältnis von mindestens 4,5:1 für Text und Bilder von Text und mindestens 3:1 für großen Text.⁶

Gestaltung, die hellgrauen Text auf weißen Hintergrund setzt, verfehlt dieses Kriterium öfter, als man denkt. Denken Sie an Menschen, deren Sehen und Farbwahrnehmung sich mit dem Alter geändert haben, und an Menschen, die an schlecht beleuchteten Orten wie Fabriken arbeiten, und machen Sie es zur Gewohnheit, bei der Gestaltungsprüfung mit einem Kontrastprüfer zu messen.

7.2. Informationen nicht allein durch Farbe vermitteln

Erfolgskriterium 1.4.1 (Verwendung von Farbe) sagt, dass Farbe nicht das einzige visuelle Mittel sein darf, Informationen zu vermitteln.⁶ Typische Fälle in Geschäftsanwendungen sind die folgenden.

Angesichts der Vielfalt des Farbsehens ist auch das eine Grundlage der Anzeigegestaltung, keine „Sondermaßnahme“.

flowchart TB
    accTitle: Ersetzen von Informationen, die allein durch Farbe vermittelt werden
    accDescr: Eine Anzeige, die Fehler nur in rotem Text zeigt, wird durch ein Fehlersymbol und eine Meldungsspalte daneben ersetzt, eine Anzeige, die Pflichtfelder nur durch Labelfarbe zeigt, erhält eine Pflicht-Markierung, und eine Anzeige, die Status nur durch Lampenfarbe zeigt, wird durch Form oder Text neben der Farbe ersetzt
    err["Fehler nur in rotem Text"] --> erra["Ein Symbol und eine Formulierung ergänzen"]
    req["Pflicht nur durch Labelfarbe"] --> reqa["Eine Pflicht-Markierung ergänzen"]
    lamp["Status nur durch Lampenfarbe"] --> lampa["Farbe mit Form oder Text kombinieren"]

Abbildung 13: Ersetzen Sie die typischen Nur-Farbe-Hinweise durch ein Symbol, eine Markierung oder Form und Text neben der Farbe.

7.3. Kontrastthemen (hoher Kontrast) folgen

Windows-Kontrastthemen (früher hoher Kontrast) sind Farbschemata, die Vordergrund und Hintergrund stark trennen. Die eingebauten Themen sind auf ein Kontrastverhältnis von etwa 7:1 oder mehr ausgelegt, und Benutzer können sie auswählen und bearbeiten.¹⁵

Auf App-Seite codieren Sie Farben nicht fest ein; respektieren Sie die Systemfarben. Was in jedem Framework zu tun ist, folgt.

Zu den konkreten WinForms-Einstellungen siehe die Anleitung von Microsoft, zu den Themenfarben die Dokumentation der Kontrastthemen.¹¹¹⁵

flowchart TB
    accTitle: Kontrastthemen folgen
    accDescr: Stellen, an denen Farben fest eingecodiert sind, brechen beim Wechsel zu einem Kontrastthema, schalten Sie daher auf ein Schema auf Basis von SystemColors um und folgen Sie über das Einstellungsänderungsereignis; wenn Sie Systemfarben referenzieren, folgt die UI den Farben des Benutzers automatisch
    theme["Zu einem Kontrastthema wechseln"] --> qh{"Wie sind Farben angegeben?"}
    qh -->|Fest eingecodiert| broken["Farbschema bricht"]
    qh -->|Referenzen auf Systemfarben| ok["Folgt den Farben des Benutzers automatisch"]
    broken -.-> fix["Auf SystemColors umschalten"]
    fix -.-> ev["Über das Einstellungsänderungsereignis folgen"]

Abbildung 14: Nur fest eingecodierte Farben brechen unter einem Kontrastthema; Referenzen auf Systemfarben folgen automatisch.

Dass die App hohen DPI übersteht, in dieselbe Prüfung aufnehmen

Benutzer mit Sehschwäche arbeiten oft mit einem hohen OS-Skalierungsfaktor (DPI-Skalierung), High-DPI-Unterstützung ist daher ebenfalls Teil der Barrierefreiheit. Eine App, deren Layout bei 125 % bis 200 % bricht, ist in dieser Umgebung unbrauchbar.

Zu den Einzelheiten siehe „High-DPI-Unterstützung in WinForms“ und „High-DPI-Unterstützung in WPF“.

8. Prüfung in der Praxis — Accessibility Insights und praktische Screenreader-Prüfung

8.1. Accessibility Insights for Windows

Microsofts Accessibility Insights for Windows bietet drei Arbeitsweisen, je nach Ziel.⁷

Inspect.exe und AccEvent, im Windows SDK enthalten, können ebenfalls den UIA-Baum und die Eigenschaften zeigen, sie sind jedoch als Legacy-Werkzeuge eingeordnet, und der Wechsel zu Accessibility Insights wird inzwischen empfohlen.⁷

flowchart TB
    accTitle: Die drei Modi von Accessibility Insights
    accDescr: Accessibility Insights for Windows bietet Live Inspect zum Prüfen von UIA-Eigenschaften, FastPass für eine leichte Prüfung von Problemen mit hoher Wirkung und Troubleshooting zur Hilfe beim Diagnostizieren und Beheben von Problemen, und die Migration von Legacy-Werkzeugen wie Inspect.exe wird empfohlen
    ai["Accessibility Insights"] --> live["Live Inspect"]
    ai --> fast["FastPass"]
    ai --> ts["Troubleshooting"]
    live --> livef["UIA-Eigenschaften prüfen"]
    fast --> fastf["Probleme mit hoher Wirkung erkennen"]
    ts --> tsf["Beim Diagnostizieren und Beheben helfen"]
    legacy["Inspect.exe und andere"] -.->|Migration empfohlen| ai

Abbildung 15: Accessibility Insights hat drei Modi, Prüfen, Erkennen und Diagnostizieren, und ist der empfohlene Ersatz für die Legacy-Werkzeuge.

8.2. Praktische Prüfung mit einem Screenreader

Eine automatische Prüfung zu bestehen und tatsächliche Arbeit abschließen zu können, sind zwei verschiedene Dinge. Werkzeuge können nur Probleme erkennen, die sich mechanisch beurteilen lassen, schließen Sie daher immer ab, indem Sie eine Geschäftsoperation mit einem Screenreader durchgehen.

Starten Sie zuerst Narrator mit Strg+Windows-Taste+Eingabe oder installieren Sie das kostenlose NVDA.¹⁰ Wählen Sie als Nächstes eine repräsentative Aufgabe wie „einen Auftrag eingeben und bestätigen“ und versuchen Sie, sie allein anhand der Ansagen abzuschließen, ohne auf den Bildschirm zu schauen oder mit ausgeschaltetem Display.

Probleme wie eine zusammenhanglose Ansagereihenfolge trotz gesetzter Namen oder Fokus, der aus einem modalen Dialog entweicht, findet man nur durch diese Art praktischer Prüfung.

flowchart TB
    accTitle: Werkzeugprüfung und praktische Prüfung kombinieren
    accDescr: Eine automatische Prüfung wie FastPass kann nur Probleme erkennen, die sich mechanisch beurteilen lassen; für den Rest gehen Sie tatsächliche Geschäftsoperationen mit einem Screenreader durch und finden Probleme der Ansagereihenfolge und des Fokus praktisch
    tool["Automatische Werkzeugprüfung"] --> kikai["Mechanisch beurteilbare Probleme"]
    tool -.-> nokori["Nicht erkennbare Probleme bleiben"]
    nokori --> sr["Praktische Prüfung mit einem Screenreader"]
    sr --> task["Eine Geschäftsoperation durchgehen"]
    task --> mieru["Probleme der Ansagereihenfolge und des Fokus"]

Abbildung 16: Nutzen Sie die automatische Prüfung, um die mechanischen Probleme zu listen, und finden Sie den Rest durch praktische Prüfung mit einem Screenreader.

8.3. Einbau in den Entwicklungsablauf und die Wechselwirkung mit der UI-Testautomatisierung

Damit die Prüfung nicht von einzelnen Personen abhängt, empfehlen wir, die folgende Checkliste in die Prüfpunkte jedes neuen Bildschirms aufzunehmen.

Die UIA-Arbeit auch für automatisierte Tests nutzen

UI-Testautomatisierung mit FlaUI und ähnlichen Werkzeugen sitzt auf derselben UIA, die Screenreader nutzen. Die Name und Muster, die Sie für die Barrierefreiheit einrichten, werden Bausteine für Testcode, und die AutomationId, die Sie für Tests entworfen haben, erleichtert auch das Debuggen in Live Inspect.

Umgekehrt ist eine UI, die nicht im UIA-Baum erscheint, für Tests und Hilfstechnologie gleichermaßen unsichtbar. Barrierefreiheit und Testbarkeit sind zwei Seiten derselben Investition. Zu den Einzelheiten siehe „UI-Automatisierungstests für Windows-Desktop-Apps“.

flowchart TB
    accTitle: Die Wechselwirkung zwischen Barrierefreiheit und UI-Testautomatisierung
    accDescr: Screenreader und UI-Testautomatisierung wie FlaUI sitzen auf derselben UIA, die Name und Muster, die Sie einrichten, lassen sich also von beiden nutzen, und eine UI, die nicht im UIA-Baum erscheint, ist für beide unsichtbar
    uia["UIA-Baum in Ordnung gebracht"] --> sr["Screenreader können ihn lesen"]
    uia --> test["UI-Testautomatisierung kann ihn nutzen"]
    sr -.-> both["Zwei Seiten derselben Investition"]
    test -.-> both
    hidden["UI, die in UIA fehlt"] -.-> invisible["Für beide unsichtbar"]

Abbildung 17: Weil beide auf derselben UIA-Grundlage sitzen, hilft das In-Ordnung-Bringen des UIA-Baums Hilfstechnologie und UI-Testautomatisierung gleichermaßen.

9. Prioritäten setzen — nicht jeden Bildschirm auf einmal korrigieren

Ein Kernsystem mit Hunderten von Bildschirmen auf einmal umzubauen, ist weder von den Kosten noch von der Qualität her realistisch. Wir empfehlen, in den folgenden drei Stufen vorzugehen.

9.1. Mit den Bildschirmen beginnen, auf die dieser Benutzer bei der Arbeit angewiesen ist

Angemessene Vorkehrungen sind ein Prozess, auf die Anfrage der Person individuell zu antworten.² Lassen Sie die Person zuerst ihre tatsächliche Arbeit mit einem Screenreader bedienen und identifizieren Sie gemeinsam, wo sie feststeckt.

In den meisten Fällen engt sich die Menge der im Tagesgeschäft genutzten Bildschirme auf eine Handvoll bis etwa ein Dutzend ein. Die kritischen Probleme darunter, etwa namenlose Schaltflächen oder eine Bestätigen-Schaltfläche, die sich nicht von der Tastatur drücken lässt, lassen sich mit Korrekturen im Maß von Tagen lösen.

9.2. Neue Entwicklung standardmäßig konform machen

Nehmen Sie die Checkliste aus Kapitel 8 in die Definition of Done auf. Die Linie ist, dass neue Bildschirme von Anfang an konform gebaut werden. Anders als Nachrüsten fügt der Einbau zur Entwurfszeit nur geringe Kosten hinzu.

9.3. Über gemeinsame Steuerelemente auf Bildschirme ausbreiten

Implementieren Sie AccessibleName-Standardwerte und AutomationPeers in den hausinternen gemeinsamen Suchdialogen, Rastern, Datumseingaben und so weiter. Korrigieren Sie eine gemeinsame Komponente, und die Korrektur greift auf einmal auf jedem Bildschirm, der sie nutzt. Das ist kosteneffektiver, als einzelne Bildschirme nacheinander zu korrigieren.

flowchart TB
    accTitle: Die drei Stufen der Priorisierung von Korrekturen
    accDescr: Beginnen Sie mit den Bildschirmen, auf die der Benutzer bei der Arbeit angewiesen ist, machen Sie neue Entwicklung mit der Checkliste standardmäßig konform und breiten Sie über die Korrektur gemeinsamer Steuerelemente auf jeden Bildschirm aus
    s1["1. Mit den Bildschirmen beginnen, auf die der Benutzer angewiesen ist"] --> s2["2. Neue Entwicklung standardmäßig konform"] --> s3["3. Über gemeinsame Steuerelemente ausbreiten"]
    s3 -.-> all["Greift auf einmal auf jedem Bildschirm, der sie nutzt"]

Abbildung 18: Statt jeden Bildschirm auf einmal umzubauen, in drei Stufen vorgehen: die genutzten Bildschirme, neue Entwicklung und gemeinsame Komponenten.

9.4. Den Verlauf des Dialogs protokollieren, nicht nur die Korrekturen

Ebenso wichtig wie die technische Arbeit ist das Protokoll des Dialogs. Angemessene Vorkehrungen sind ein Prozess des Sprechens und des Anpassens von Fall zu Fall, nicht des vollständigen Erfüllens jeder Anfrage.

Bei Korrekturen, die eine übermäßige Belastung wären, Alternativen mit der Person zu erwägen und zu vereinbaren, etwa die Aufgabe auf einem anderen Bildschirm auszuführen, einen CSV-Export bereitzustellen oder sie über den Betrieb abzudecken, ist ein legitimes Ergebnis konstruktiven Dialogs.²

Zu protokollieren, was angefragt, was erledigt und was als Alternative angeboten wurde, ist das, was den guten Glauben der Organisation zeigt.

flowchart TB
    accTitle: Der Ablauf von konstruktivem Dialog und Protokoll
    accDescr: Auf eine Anfrage eines Menschen mit Behinderung im konstruktiven Dialog antworten, die machbaren Korrekturen durchführen, bei Korrekturen, die eine übermäßige Belastung wären, eine Alternative mit der Person erwägen und vereinbaren, und protokollieren, was angefragt, was erledigt und was als Alternative angeboten wurde
    req["Anfrage"] --> talk["Konstruktiver Dialog"]
    talk --> q{"Übermäßige Belastung?"}
    q -->|Nein| kaishu["Mit einer Korrektur antworten"]
    q -->|Ja| alt["Eine Alternative erwägen und vereinbaren"]
    kaishu --> rec["Den Verlauf protokollieren"]
    alt --> rec

Abbildung 19: Im konstruktiven Dialog vereinbaren Sie mit der Person eine Korrektur oder eine Alternative und halten fest, wie es gelaufen ist.

10. Zusammenfassung

Rechtlichen Rahmen, Technik und Vorgehen zu trennen, macht den Ausgangspunkt sichtbar.

Rechtlich sind angemessene Vorkehrungen durch Unternehmen seit April 2024 Pflicht, durch Arbeitgeber im Beschäftigungsfeld seit 2016. Eine App im Voraus zu korrigieren, fällt unter die „Gestaltung der Umgebung“ (eine Bemühenspflicht), und je weiter sie fortgeschritten ist, desto leichter fällt die individuelle Antwort. Protokollieren Sie auch den Verlauf des Dialogs.

Technisch prüfen Sie Desktop-Apps um WCAG (JIS X 8341-3:2016) über WCAG2ICT. Die Grundlage ist der UIA-Baum, seine Eigenschaften (Name/ControlType/AutomationId) und die Steuerelementmuster. Die Benennung, die höchste Priorität, erledigen Sie mit AccessibleName und Label plus Tabulatorreihenfolge in WinForms, AutomationProperties.Name/LabeledBy in WPF und einem AutomationPeer für eigene Steuerelemente.

Darüber hinaus räumen Sie Tabulatorreihenfolge, Zugriffstasten und Fokusanzeige so ein, dass jede Funktion allein von der Tastatur erreichbar ist. Für Farbe nutzen Sie ein Kontrastverhältnis von 4,5:1 als Leitlinie, setzen Sie nicht allein auf Farbe und respektieren Sie unter Kontrastthemen die Systemfarben. Diese Verbesserungen heben auch die Produktivität jeder Bedienkraft.

Das Vorgehen läuft in der Reihenfolge Bildschirme, auf die der Benutzer angewiesen ist, standardmäßig konforme neue Entwicklung und Ausbreitung über gemeinsame Steuerelemente. Kombinieren Sie FastPass und Live Inspect in Accessibility Insights mit praktischer Prüfung in Narrator/NVDA und bauen Sie sie als Checkliste für neue Bildschirme in den Entwicklungsablauf ein.

Als ersten Schritt empfehlen wir, einen Ihrer Hauptbildschirme zu wählen, FastPass in Accessibility Insights for Windows auszuführen und dann die Arbeit allein mit der Tabulatortaste durchzugehen. In 30 Minuten sehen Sie überraschend konkret, wo Ihre App gerade steht.

Verwandte Artikel

• UI-Automatisierungstests für Windows-Desktop-Apps — Wie UI Automation funktioniert und wie man mit FlaUI robuste Tests baut
• Windows-App-UX-Design - Prioritäten nach Nutzungsumgebung
• High-DPI-Unterstützung in WinForms — Warum die UI auf 4K-Monitoren verschwimmt oder zerbricht, und wie Sie das praktisch beheben
• High-DPI-Unterstützung in WPF — Warum es trotz „eigentlich DPI-bewusst“ immer noch verschwimmt und durchblutet, und wie Sie es beheben
• Warum KomuraSoft Websites auf dem Designsystem der Digital Agency aufbaut ── Geringe Kosten und hohe Qualität schließen sich nicht aus
• Fallstricke bei japanischen Schriften und Zeichen — Umgang mit JIS2004, IVS und Gaiji in Geschäftsanwendungen

Verwandte Beratungsfelder

KomuraSoft LLC übernimmt Korrekturen der Barrierefreiheit von WinForms/WPF-Geschäftsanwendungen (Screenreader-Unterstützung, Tastaturbedienung, Unterstützung von Kontrastthemen), die Implementierung von AutomationPeer für gemeinsame Steuerelemente sowie die Diagnose des Istzustands und die Priorisierung mit Accessibility Insights. Es ist in Ordnung, bei „wir wollen prüfen, ob ein Beschäftigter unsere App mit einem Screenreader nutzen kann“ zu beginnen.

• Windows-App-Entwicklung
• Technische Beratung und Design-Review
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Ist die Barrierefreiheit einer Geschäftsanwendung gesetzlich vorgeschrieben?

Die Änderung 2021 des Gesetzes zur Beseitigung der Diskriminierung von Menschen mit Behinderungen trat am 1. April 2024 in Kraft, und auch Unternehmen sind nun verpflichtet, Menschen mit Behinderungen angemessene Vorkehrungen bereitzustellen. Angemessene Vorkehrungen bedeuten, eine individuelle Barriere in einem Rahmen zu beseitigen, der keine übermäßige Belastung darstellt, wenn ein Mensch mit Behinderung darum ersucht; eine App im Voraus leichter nutzbar zu machen, ist als Bemühenspflicht namens Gestaltung der Umgebung eingeordnet. Das Beschäftigungsfeld, etwa die Beziehung zwischen Beschäftigten und Unternehmen, fällt nicht unter das Antidiskriminierungsgesetz, sondern unter das Gesetz zur Förderung der Beschäftigung von Menschen mit Behinderungen; dort verpflichtet die Änderung, die im April 2016 in Kraft trat, Arbeitgeber zur Bereitstellung angemessener Vorkehrungen. Mit anderen Worten: Die Lage, dass ein Beschäftigter eine Geschäftsanwendung nicht nutzen kann, liegt schon länger im Bereich der Pflicht. Was und wie weit zu unterstützen ist, hängt vom Einzelfall ab; prüfen Sie daher die Primärquellen des Kabinettsbüros und des Ministeriums für Gesundheit, Arbeit und Soziales und entscheiden Sie im Dialog mit der betroffenen Person.

Wie liest ein Screenreader eine Windows-Desktop-App?

Screenreader wie Narrator und NVDA lesen die UI einer App über eine Barrierefreiheitsgrundlage namens UI Automation (UIA). Die App legt die Elemente auf dem Bildschirm in einer Struktur namens UIA-Baum offen, und jedes Element hat Eigenschaften wie Name (Zweck) und ControlType (Art) sowie Steuerelementmuster wie Invoke (drücken) und Value (Wert). Der Screenreader sagt diese Informationen etwa als „Auftrag bestätigen, Schaltfläche“ an und bedient das Element über die Muster. Standardsteuerelemente von WinForms und WPF bringen diesen Mechanismus mit, die Hauptaufgaben des Entwicklers sind also, Name nicht leer zu lassen, die UI von der Tastatur bedienbar zu machen und die Informationen auf eigenen Steuerelementen zu implementieren.

Womit sollen wir bei einer bestehenden WinForms-App beginnen?

Der kürzeste Weg ist, FastPass in Accessibility Insights for Windows gegen den Zielbildschirm auszuführen und die Steuerelemente mit leerem Name sowie die Probleme der Tabulatorreihenfolge zu listen. Beginnen Sie die Korrekturen damit, AccessibleName auf Nur-Symbol-Schaltflächen zu setzen, ein Label zuzuordnen, indem Sie es in der Tabulatorreihenfolge unmittelbar vor das Eingabefeld legen, und TabIndex so aufzuräumen, dass es der visuellen Reihenfolge entspricht. Starten Sie dann Narrator oder NVDA, gehen Sie eine echte Geschäftsoperation durch, ohne auf den Bildschirm zu schauen, und prüfen Sie, wo Sie feststecken. Es ist nicht nötig, jeden Bildschirm auf einmal zu korrigieren; realistisch ist, mit den Bildschirmen zu beginnen, die jemand tatsächlich nutzt, und neue Bildschirme mit einer Checkliste von vornherein konform zu machen.

Was ist für hohen Kontrast (Kontrastthemen) zu tun?

Die Grundregel ist, Systemfarben zu respektieren statt Farben fest einzucodieren. In WinForms lassen Sie ForeColor/BackColor beim Standard oder nutzen SystemColors, erkennen den Zustand mit SystemInformation.HighContrast und folgen einem Wechsel über das Ereignis UserPreferenceChanged. Auch in WPF und WinUI folgt die UI einem Themenwechsel automatisch, solange sie Ressourcen der Familie SystemColors referenziert. Gleichzeitig hören Sie auf, Informationen allein durch Farbe zu vermitteln, etwa einen Fehler nur in Rot zu zeigen, und ergänzen ein Symbol oder eine Formulierung. Auch unter dem gewöhnlichen Thema macht das WCAG-Kriterium eines Textkontrastverhältnisses von mindestens 4,5:1 als Leitlinie die UI auf einem schlecht beleuchteten Hallenboden und für ältere Benutzer lesbarer.

Hilft die Arbeit an der Barrierefreiheit auch der UI-Testautomatisierung?

Ja. UI-Testautomatisierungswerkzeuge wie FlaUI sitzen auf derselben UI Automation, die Screenreader nutzen. Name, ControlType und Steuerelementmuster, die Sie für die Barrierefreiheit einrichten, lassen sich direkt aus Testcode nutzen, und eine für Tests entworfene AutomationId macht die Elementidentifikation stabil. Umgekehrt ist eine selbstgezeichnete UI, die nicht im UIA-Baum erscheint, für Screenreader und Tests gleichermaßen unsichtbar. Barrierefreiheit und automatisierte Tests sind Investitionen in dieselbe Grundlage; eines einzurichten senkt die Kosten des anderen.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.