Einführung in die Barrierefreiheit von Windows-Apps — Vorbereitung auf UI Automation und Anforderungen an angemessene Vorkehrungen

„Eine Quereinsteigerin mit Sehbehinderung kann die zentrale Auftragserfassungs-App mit einem Bildschirmleser nicht nutzen. Browser und Mail nutzt sie ohne Probleme, aber nur das Vorlesen unserer Geschäftsanwendung funktioniert nicht richtig. Kann man etwas tun?“ — Beratungen dieser Art aus IT-Abteilungen von Kunden haben zugenommen.

Ein Hintergrund ist der rechtliche Rahmen. Die Änderung 2021 des Gesetzes zur Beseitigung der Diskriminierung von Menschen mit Behinderungen trat am 1. April 2024 in Kraft, und die „Bereitstellung angemessener Vorkehrungen“ für Menschen mit Behinderungen wurde auch für Unternehmen zur Pflicht.¹ Weiterhin ist eine Beschäftigten–Unternehmen-Beziehung wie die der Eröffnung (das Beschäftigungsfeld) das Gebiet des Gesetzes zur Förderung der Beschäftigung von Menschen mit Behinderungen, das Arbeitgeber seit April 2016 zur Bereitstellung angemessener Vorkehrungen verpflichtet.² Die Vorstellung, „Barrierefreiheit sei ein Website-Thema und habe nichts mit internen Windows-Apps zu tun“, hält weder rechtlich noch praktisch.

Andererseits ist „wir wissen nicht, was wir tun sollen“ vom Entwicklungsboden ein ehrlicher Ort. Barrierefreiheit für Windows-Desktop-Apps hat weniger Informationen als das Web, und es gibt keine magische nachträgliche Lösung. Es besteht auch kein Grund zur Pessimismus. Wenn Sie den Mechanismus verstehen, mit dem ein Bildschirmleser eine App liest (UI Automation), und die Grundlagen von Name, Tastatur und Farbe aufnehmen, verbessert sich die Nutzbarkeit einer Geschäftsanwendung wesentlich. Und vieles davon ist eine Verbesserung, die die Produktivität jedes Benutzers hebt, mit oder ohne Behinderung.

An Entwickler japanischer Geschäftsanwendungen und an IT-Personal gerichtet, verbindet dieser Artikel in einem Durchgang von einer minimalen Sortierung des rechtlichen Rahmens und der Normen über den Mechanismus von UI Automation, die Implementierung in WinForms/WPF, Tastaturbedienung, Farbe und Kontrast und Prüfwerkzeuge bis zu einer realistischen Art, Prioritäten zu setzen.

flowchart TB
    accTitle: Der Ablauf dieses Artikels
    accDescr: Die Struktur dieses Artikels, der der Reihe nach von der Sortierung des rechtlichen Rahmens und der Normen über den Mechanismus von UI Automation, die Implementierung in WinForms und WPF, Tastaturbedienung, Farbe und Kontrast, Prüfwerkzeuge und das Setzen von Prioritäten verbindet
    law["Rechtlichen Rahmen und Normen sortieren"] --> uia["Der Mechanismus 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 den rechtlichen Rahmen über Mechanismus, Implementierung, Prüfung und Prioritäten in einem einzigen Fluss.

1. Zuerst das Fazit

• Die Bereitstellung angemessener Vorkehrungen ist seit dem 1. April 2024 auch für Unternehmen Pflicht. Wenn eine Person mit Behinderung die Absicht anzeigt, eine Barriere beseitigen zu lassen, ist eine Antwort in einem Rahmen, der keine übermäßige Belastung ist, erforderlich. Das Beschäftigungsfeld fällt unter das Gesetz zur Förderung der Beschäftigung von Menschen mit Behinderungen, und das ist seit April 2016 eine Arbeitgeberpflicht.¹²
• Angemessene Vorkehrungen sind ein Prozess des „Antwortens auf eine individuelle Anfrage durch konstruktiven Dialog“; die App im Voraus leichter nutzbar zu machen, ist „Umfeldverbesserung“ (eine Bemühungspflicht). Perfekte Vorabunterstützung ist nicht die Pflicht; was zählt, ist, den Dialog nicht einseitig zu verweigern.¹
• Die technischen Kriterien der Barrierefreiheit konzentrieren sich in WCAG (JIS X 8341-3:2016). JIS X 8341-3:2016 ist eine entsprechende Norm mit demselben Inhalt wie WCAG 2.0, und WCAG2ICT des W3C gibt Leitlinien zur Anwendung auf Nicht-Web-Software. Eine Desktop-App kann mit demselben Denken geprüft werden.³⁴
• Ein Bildschirmleser liest eine App über UI Automation (UIA). Die Eigenschaften, die jedes Element auf dem UIA-Baum hält — Name, ControlType und Ähnliches — und die Steuermuster wie Invoke, Value und SelectionItem sind das Material für Ansage und Bedienung.⁵
• Eine Schaltfläche, deren Name leer ist, wird nur als „Schaltfläche“ angesagt. Die Korrektur höchster Priorität ist die Benennung. WinForms nutzt AccessibleName und die Zuordnung eines Labels zur Tabreihenfolge; WPF nutzt AutomationProperties.Name/LabeledBy.⁶⁷
• Jede Funktion allein von der Tastatur erreichen zu können, ist ein WCAG-Erfolgskriterium (2.1.1) und zugleich die Eingabegeschwindigkeit eines geübten Bedieners selbst. Tabreihenfolge, Zugriffstasten und Fokusanzeige einzurichten, verbindet sich direkt mit Effizienz für jeden Benutzer.⁸
• Nehmen Sie ein Textkontrastverhältnis von 4,5:1 oder mehr als Leitlinie und vermitteln Sie Informationen nicht allein durch Farbe. In einem Kontrastthema (hoher Kontrast) respektieren Sie Systemfarben statt fest eingecodierter Farben.⁸⁹
• Kombinieren Sie die Prüfung mit FastPass in Accessibility Insights for Windows und einer praktischen Prüfung mit einem Bildschirmleser. Weil sie auf derselben UIA-Grundlage sitzen, zahlt sich diese Arbeit auch gegenseitig mit UI-Testautomatisierungsvermögen wie FlaUI aus.¹⁰
• Sie müssen nicht jeden Bildschirm auf einmal korrigieren. Die realistische Reihenfolge ist (1) von den Bildschirmen, die dieser Benutzer nutzt, (2) neue Entwicklung ist standardkonform, (3) seitlich ausrollen, indem Sie gemeinsame Steuerelemente korrigieren.

In einem Satz: Barrierefreiheitsunterstützung ist „den richtigen Namen und die richtigen Operationen auf dem UIA-Baum offenzulegen und die Grundlagen von Tastatur und Farbe zu halten“.

2. Den rechtlichen Rahmen und die Normen sortieren — Was „wurde zur Pflicht“ geändert hat

2.1. Das Gesetz zur Beseitigung der Diskriminierung von Menschen mit Behinderungen — Ab April 2024 sind auch Unternehmen verpflichtet, angemessene Vorkehrungen bereitzustellen

Das Gesetz zur Beseitigung der Diskriminierung von Menschen mit Behinderungen ist ein Gesetz, das „ungerechtfertigte diskriminierende Behandlung“ von Menschen mit Behinderungen durch Verwaltungsorgane und Unternehmen verbietet und die „Bereitstellung angemessener Vorkehrungen“ verlangt. In der Änderung 2021 (Reiwa 3) wurde die Bereitstellung angemessener Vorkehrungen durch Unternehmen, die eine Bemühungspflicht gewesen war, zur Pflicht, und das geänderte Gesetz trat am 1. April 2024 (Reiwa 6) in Kraft.¹

Laut dem Faltblatt des Kabinettsbüros ist die Bereitstellung angemessener Vorkehrungen das Antworten, in einem Rahmen, der keine übermäßige Belastung ist, wenn eine Person mit Behinderung die Absicht anzeigt, dass irgendeine Antwort nötig ist, um eine Barriere in der Gesellschaft zu beseitigen. Und weil der Inhalt nach Behinderungscharakteristik, Szene und Lage unterschiedlich ist, wird ein „konstruktiver Dialog“, in dem die Person mit Behinderung und das Unternehmen Dialog stapeln und gemeinsam eine Antwort erwägen, betont. Konstruktiven Dialog einseitig zu verweigern, wird als mögliche Verletzung der Pflicht zur Bereitstellung angemessener Vorkehrungen genannt.¹

Zwei praktische Unterscheidungen zählen hier.

1. „Alles im Voraus in Ordnung zu haben“ ist nicht das, was zur Pflicht wurde. Vorab-Verbesserungsmaßnahmen, die auf eine unbestimmte Zahl von Menschen mit Behinderungen zielen — die weiche Seite wie das Überarbeiten eines Handbuchs und Schulung, die harte Seite wie die barrierefreie Gestaltung einer Einrichtung — heißen „Umfeldverbesserung“, und das ist eine Bemühungspflicht.¹ Eine Geschäftsanwendung im Voraus in einen mit einem Bildschirmleser nutzbaren Zustand zu versetzen, kann als Umfeldverbesserungsbemühung gedacht werden. Je weiter die Umfeldverbesserung gegangen ist, desto leichter wird die Last, individuelle angemessene Vorkehrungen bereitzustellen.
2. Das Beschäftigungsfeld fällt nicht unter das Gesetz zur Beseitigung der Diskriminierung von Menschen mit Behinderungen, sondern unter das Gesetz zur Förderung der Beschäftigung von Menschen mit Behinderungen. Dasselbe Faltblatt stellt auch fest, dass Beschäftigung und Arbeit den Bestimmungen des Gesetzes zur Förderung der Beschäftigung von Menschen mit Behinderungen folgen.¹ Und unter jenem Gesetz sind durch die Änderung, die im April 2016 (Heisei 28) in Kraft trat, das Verbot der Diskriminierung wegen Behinderung in der Beschäftigung und die Bereitstellung angemessener Vorkehrungen in einem Rahmen, der keine übermäßige Belastung ist, den Arbeitgebern auferlegt.² Die Eröffnungsberatung „ein Beschäftigter kann die Geschäftsanwendung nicht nutzen“ liegt tatsächlich schon lange vor 2024 im Bereich der Pflicht.

flowchart TB
    accTitle: Die Positionierung angemessener Vorkehrungen und der Umfeldverbesserung
    accDescr: Die Beziehung zwischen einem allgemeinen Unternehmen und einer Person mit Behinderung fällt unter das Antidiskriminierungsgesetz, und angemessene Vorkehrungen durch Antwort auf eine individuelle Anfrage über konstruktiven Dialog sind seit April 2024 Pflicht; das Beschäftigungsfeld ist seit April 2016 Arbeitgeberpflicht unter dem Beschäftigungsförderungsgesetz; die App im Voraus leichter nutzbar zu machen ist Umfeldverbesserung, eine Bemühungspflicht
    scene{"Welche Szene?"}
    scene -->|Unternehmen + Behinderung| kaisho["Antidiskriminierungsgesetz"]
    scene -->|Beschäftigung / Arbeit| koyou["Beschäftigungsgesetz"]
    kaisho --> moushide["Anfrage über Dialog"]
    moushide --> hairyo["Vorkehrungen bereitstellen"]
    hairyo -.-> hairyoN["Pflicht seit 2024"]
    koyou --> koyougimu["Vorkehrungen bereitstellen"]
    koyougimu -.-> koyouN["Pflicht seit 2016"]
    kaisho -.-> kankyo["App im Voraus leichter"]
    kankyo -.-> kankyoN["Umfeldverbesserung"]
    kankyoN -.-> kankyoN2["Bemühungspflicht"]
    kankyo -.-> moushide

Abbildung 2: Das geltende Gesetz teilt sich nach Szene; angemessene Vorkehrungen sind Pflicht, und Vorabkorrekturen sind Umfeldverbesserung, eine Bemühungspflicht.

Wie ein Einzelfall rechtlich behandelt wird, hängt von der Lage ab. Dieser Artikel tritt nicht in die Rechtsauslegung ein; er geht vom Standpunkt dessen aus, was ein Ingenieur tun kann, wenn eine Antwort angefordert wird. Für 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“ erstrecken sich auch auf Software

Auf der Seite der technischen Kriterien konzentrieren sie sich in JIS X 8341-3:2016. Diese Norm ist eine entsprechende Norm von ISO/IEC 40500:2012, und der Körper der Norm ist derselbe Inhalt wie WCAG 2.0 des W3C.³ Wenn Sie konkret wissen wollen, woraus „Barrierefreiheitsunterstützung“ besteht, ist das Lesen der WCAG-Erfolgskriterien (jetzt in WCAG 2.1/2.2 erweitert) der kürzeste Weg, und eine japanische Übersetzung von WAIC ist ebenfalls veröffentlicht.⁸

Die Frage „ist WCAG ein Kriterium für Webinhalte?“ ist fair, aber das W3C hat in einer Group Note namens WCAG2ICT (Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies) organisiert, wie man WCAG-2.0/2.1/2.2-Erfolgskriterien auf Nicht-Web-Dokumente und Software anwendet.⁴ Mit anderen Worten: Denken wie „Textalternativen“, „Kontrast“, „Tastaturbedienung“ und „Farbe ist nicht das einzige Mittel“ kann auf eine Windows-Desktop-App im selben Rahmen wie das Web angewendet werden. Die Kapitel ab 3 dieses Artikels setzen dieses Denken in konkrete WinForms/WPF-Implementierung um.

flowchart TB
    accTitle: Die Beziehung zwischen JIS X 8341-3 und WCAG
    accDescr: JIS X 8341-3:2016 ist eine entsprechende Norm mit demselben Inhalt wie WCAG 2.0, und WCAG2ICT zeigt, wie man WCAG-Erfolgskriterien auf Nicht-Web-Software anwendet, sodass eine Windows-Desktop-App im selben Rahmen geprüft werden kann
    wcag["WCAG 2.0（W3C）"] ---|Eine entsprechende Norm mit demselben Inhalt| jis["JIS X 8341-3:2016"]
    wcag --> ict["WCAG2ICT"]
    ict --> soft["Auf Nicht-Web-Software anwenden"]
    soft --> app["Eine Windows-Desktop-App"]

Abbildung 3: JIS X 8341-3:2016 ist eine entsprechende Norm von WCAG 2.0, und WCAG2ICT erweitert dieselben Kriterien auf Desktop-Apps.

3. Wie Hilfstechnologie eine App liest — Das UI-Automation-Trio

3.1. Der UIA-Baum, Eigenschaften und Steuermuster

Windows hat eine Barrierefreiheitsgrundlage namens UI Automation (UIA) eingebaut. UIA ist ein Mechanismus, der Hilfstechnologie wie einem Bildschirmleser erlaubt, UI-Informationen zu erhalten und die UI mit anderen Mitteln als Standardeingabe zu bedienen, und vermittelt zwischen der App-Seite (dem Anbieter) und der Hilfstechnologie-Seite (dem Client).⁵

Die Welt von UIA lässt sich als folgendes Trio verstehen.⁵

Wenn ein Bildschirmleser eine Schaltfläche fokussiert, ist die Ansage „Schaltfläche Bestellung bestätigen“ grob die Kombination aus Name + Steuertyp. Wenn der Benutzer eine „Ausführen“-Operation durchführt, drückt Hilfstechnologie diese Schaltfläche über das Invoke-Muster. Mit anderen Worten: Wenn Name und die Muster korrekt offengelegt sind, kann es gelesen und bedient werden; wenn sie nicht offengelegt sind, ist es dasselbe, als existierte es nicht, selbst wenn es auf dem Bildschirm sichtbar ist.

flowchart TB
    accTitle: Das UI-Automation-Trio
    accDescr: Die App legt als Anbieter Eigenschaften und Steuermuster jedes Elements auf dem UIA-Baum offen; der Bildschirmleser kündigt als Client Name und ControlType an und bedient über Muster wie Invoke
    app["App（Anbieter）"] --> tree["UIA-Baum"]
    tree --> prop["Eigenschaften（Name, ControlType und Ähnliches）"]
    tree --> pat["Muster（Invoke, Value und Ähnliches）"]
    sr["Bildschirmleser（Client）"] -->|Kündigt an| prop
    sr -->|Bedient| pat

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

3.2. Ein Bildschirmleser ist ein UIA-Client

Die wichtigsten unter Windows genutzten Bildschirmleser umfassen Narrator, in Windows eingebaut; NVDA,¹¹ das frei und Open Source ist; und PC-Talker, ein in Japan weit verbreitetes kommerzielles Produkt. Der Ansagestil unterscheidet sich unter ihnen, aber der primäre Pfad zum Lesen der UI einer Desktop-App ist in jedem Fall UIA. Deshalb konzentriert sich die Antwort auf der App-Seite nicht auf „Unterstützung für einen bestimmten Bildschirmleser“, sondern auf das Offenlegen der richtigen Informationen an UIA.

flowchart TB
    accTitle: Der gemeinsame Pfad der wichtigsten Bildschirmleser
    accDescr: Wenn die App die richtigen Informationen an UIA offengelegt, können Narrator, NVDA und PC-Talker alle die UI auf demselben Pfad lesen, die Antwort auf der App-Seite zielt also nicht auf einen bestimmten Bildschirmleser, sondern konzentriert sich auf das Offenlegen an UIA
    app["App"] -->|Legt Informationen offen| uia["UI Automation（UIA）"]
    uia --> nar["Narrator"]
    uia --> nvda["NVDA"]
    uia --> pct["PC-Talker"]
    app -.-> goal["Die Antwort konzentriert sich auf das Offenlegen an UIA"]

Abbildung 5: Die wichtigsten Bildschirmleser nehmen alle UIA als Pfad, die Antwort der App konzentriert sich also auf das Offenlegen an UIA.

3.3. Als was wird eine „Schaltfläche, deren Name leer ist“ angesagt?

Ein konkretes Beispiel. Angenommen, eine Symbolleiste hat eine Speichern-Schaltfläche, die nur ein Diskettensymbol anzeigt. Für einen sehenden Benutzer vermittelt das Symbol die Bedeutung, aber wenn Name leer gelassen wird, sagt ein Bildschirmleser diese Schaltfläche nur als „Schaltfläche“ an. Wenn die benachbarten „Öffnen“ und „Drucken“ dasselbe sind, hört der Benutzer nur „Schaltfläche, Schaltfläche, Schaltfläche“ und hat kein Mittel zu wissen, welche welche ist. Microsofts Leitfaden zur Barrierefreiheitskorrektur listet ebenfalls eine Schaltfläche ohne Name und ein nur als „Image“ angesagtes Bild als repräsentative Probleme, die die Arbeit des Benutzers stoppen.⁷

Glücklicherweise haben sowohl WinForms- als auch WPF-Standardsteuerelemente UIA-Unterstützung von Anfang an, und in vielen Fällen wird Name automatisch aus Text oder einem Label entschieden. Was kaputtgeht, ist gewöhnlich eines von (1) nur Symbol, ohne Material für einen Namen, (2) keine Zuordnung zu einem Label oder (3) benutzerdefiniertes Zeichnen, das keine Informationen auf den UIA-Baum legt. Die nächsten zwei Kapitel sehen an, wie man es pro Framework korrigiert.

flowchart TB
    accTitle: Drei typische Wege, auf denen die Ansage kaputtgeht
    accDescr: Die Ansage geht kaputt, wenn es kein Material für einen Namen gibt, weil es nur ein Symbol ist, wenn es keine Zuordnung zu einem Label gibt oder wenn benutzerdefiniertes Zeichnen keine Informationen auf den UIA-Baum legt, und es endet damit, nur als Schaltfläche angesagt zu werden
    c1["Nur Symbol, kein Material"] --> broken["Name wird leer"]
    c2["Keine Zuordnung zu einem Label"] --> broken
    c3["Benutzerdefiniertes Zeichnen gibt nichts aus"] --> broken
    broken --> result["Nur als Schaltfläche angesagt"]

Abbildung 6: Das Kaputtgehen der Ansage kommt gewöhnlich auf eines von drei Mustern zurück: unzureichendes Material für einen Namen, unzureichende Zuordnung oder benutzerdefiniertes Zeichnen.

4. Implementierung in WinForms — AccessibleName und Tabreihenfolge

4.1. Steuerelemente, deren Text automatisch Name wird, und Steuerelemente, deren Text es nicht wird

In WinForms nutzt ein Steuerelement, das Text anzeigt, etwa ein Button oder ein CheckBox, den Wert der Text-Eigenschaft als UIA-Name. Andererseits machen ComboBox, ListBox, ListView, PictureBox, ProgressBar, TabControl, TextBox, TreeView und Ähnliches Text nicht zum Name. Diese brauchen einen Namen auf einem anderen Weg.⁶

Der wartbarste Weg ist, ein beschreibendes Label in der unmittelbar vorhergehenden Tabreihenfolge des Zielsteuerelements zu platzieren. Wenn Sie den TabIndex des Zielsteuerelements so setzen, dass er unmittelbar nach dem TabIndex des Labels kommt, wird der Text dieses Labels automatisch als UIA-Name genutzt. Das auf dem Bildschirm sichtbare Label und die Ansage stimmen überein, und Sie müssen die Formulierung nicht zweimal verwalten.⁶¹²

Wenn Sie kein Label platzieren können, setzen Sie AccessibleName ausdrücklich. Sie können auch AccessibleDescription setzen, wenn eine ergänzende Erklärung nötig ist, und AccessibleRole, wenn die Rolle vom Aussehen abweicht.¹³

flowchart TB
    accTitle: Wie der Name eines WinForms-Steuerelements entschieden wird
    accDescr: Bei Button und Ähnlichem wird Text unverändert zum UIA-Name; bei Steuerelementen wie TextBox, deren Text nicht wiederverwendet wird, wird der Text eines in der unmittelbar vorhergehenden Tabreihenfolge platzierten Labels genutzt; wenn Sie kein Label platzieren können, setzen Sie AccessibleName ausdrücklich
    ctrl["Steuerelement"] --> qtext{"Eine Art, deren Text Name wird?"}
    qtext -->|Ja| usetext["Text wird unverändert Name"]
    qtext -->|Nein| qlabel{"Ein Label in der unmittelbar vorhergehenden Tabreihenfolge?"}
    qlabel -->|Ja| uselabel["Der Text des Labels wird als Name genutzt"]
    qlabel -->|Nein| explicit["AccessibleName ausdrücklich setzen"]

Abbildung 7: Für einen WinForms-Name wählen Sie, wie Sie ihn entscheiden, in der Reihenfolge Text, ein Label in der unmittelbar vorhergehenden Tabreihenfolge, AccessibleName.

// An icon-only toolbar button: state the name for announcement explicitly
saveToolStripButton.AccessibleName = "Save";

// An image-only button: name + a supplementary explanation
btnSearchCustomer.AccessibleName = "Search customer";
btnSearchCustomer.AccessibleDescription = "Search the customer master by customer code or name";

// Set it directly on an input field where you cannot place a Label in the immediately preceding tab order
txtOrderNo.AccessibleName = "Order number";

// A PictureBox reused as a chart display: match the role to the reality as well
pictureBoxChart.AccessibleRole = AccessibleRole.Chart;
pictureBoxChart.AccessibleName = "Monthly order-count chart";

Als Vorsicht: Wenn Sie AccessibleName einmal im Eigenschaftenbereich von Visual Studio setzen und dann löschen, kann eine Leere-Zeichenfolge-Einstellung in der Designerdatei bleiben und die Standardnamensauflösung stören. Löschen Sie die entsprechende Zeile aus der Designerdatei.⁶

flowchart TB
    accTitle: Das Problem einer bleibenden leeren AccessibleName-Zeichenfolge
    accDescr: Wenn Sie AccessibleName einmal im Eigenschaftenbereich setzen und dann löschen, bleibt eine Leere-Zeichenfolge-Einstellung in der Designerdatei und stört die Standardnamensauflösung, Sie korrigieren es also, indem Sie die entsprechende Zeile aus der Designerdatei löschen
    set["AccessibleName setzen"] --> erase["Im Eigenschaftenbereich löschen"]
    erase --> remain["Eine Leere-Zeichenfolge-Einstellung bleibt"]
    remain --> block["Sie stört die Standardnamensauflösung"]
    block -.-> fix["Die entsprechende Zeile aus der Designerdatei löschen"]

Abbildung 8: Das Löschen im Eigenschaftenbereich lässt trotzdem eine leere Zeichenfolge, Sie korrigieren es also, indem Sie die entsprechende Zeile aus der Designerdatei löschen.

4.2. Häufige Verbesserungen auf einem Auftragserfassungsbildschirm

Die Stellen, die wir in Geschäftsanwendungen tatsächlich oft korrigieren, sind als Checkliste zusammengefasst.

Jedes ist eine Korrektur von wenigen Zeilen, aber für einen Bildschirmleser-Benutzer ist es die Gabel zwischen „ein Bildschirm, den Sie nicht nutzen können“ und „ein Bildschirm, den Sie nutzen können“.

5. Implementierung in WPF — AutomationProperties und AutomationPeer

5.1. AutomationProperties.Name / LabeledBy / HelpText

In WPF nutzt ein Steuerelement, dessen Content eine Zeichenfolge ist, etwa ein Button, diesen Inhalt als UIA-Name. Eine Nur-Symbol-Schaltfläche (Image oder Path) hat kein Material für einen Name, Sie geben ihn also mit AutomationProperties.Name an, oder wenn es nahe Anzeigetext gibt, ordnen Sie ihn mit AutomationProperties.LabeledBy zu.⁷

TextBox hat eine wichtige Vorsicht. Der Text eines TextBlock wird als Name wiederverwendet, aber der Text eines TextBox wird auf der UIA-Value-Eigenschaftsseite offengelegt und wird nicht Name. Für ein Eingabefeld ist die Zuordnung des Anzeigelabel-TextBlock mit LabeledBy der erste Kandidat. Ansage und Bildschirmanzeige stimmen überein, und Sie vermeiden auch, die Formulierung zweimal zu verwalten.¹⁴

<!-- An input field: associate the display label with LabeledBy -->
<TextBlock x:Name="OrderNoLabel" Text="Order number" />
<TextBox
    AutomationProperties.LabeledBy="{Binding ElementName=OrderNoLabel}"
    AutomationProperties.AutomationId="OrderNoTextBox" />

<!-- An icon-only button: state the name, and a supplement if needed -->
<Button
    AutomationProperties.Name="Confirm order"
    AutomationProperties.HelpText="Confirm the order being entered and allocate inventory">
    <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 Zuordnung eines nahen Anzeigelabels mit LabeledBy der erste Kandidat; wenn das auch fehlt, geben Sie AutomationProperties.Name an; der Text eines TextBox wird auf der Value-Seite offengelegt, nicht als Name
    ctrl["Steuerelement"] --> qc{"Ist Content eine Zeichenfolge?"}
    qc -->|Ja| auto["Der Inhalt wird Name"]
    qc -->|Nein| ql{"Ein nahes Anzeigelabel?"}
    ql -->|Ja| lb["Mit LabeledBy zuordnen"]
    ql -->|Nein| nm["Name ausdrücklich setzen"]
    tbx["Der Text eines TextBox"] -.-> val["Als Value offengelegt, nicht Name"]

Abbildung 9: Für einen WPF-Name entscheiden Sie in der Reihenfolge Content-Zeichenfolge, LabeledBy, eine ausdrückliche Einstellung; der Text eines TextBox wird nicht Name.

Ergänzende Informationen, die nicht in Name passen, können mit AutomationProperties.HelpText offengelegt werden.⁷ Außerdem ist AutomationId eine Kennung, die zur Elementidentifikation in der UI-Testautomatisierung genutzt wird, eine Namenskonvention zur Bildschirmentwurfszeit zu entscheiden, zahlt sich später aus (ausführlich in „UI-Automatisierungstests für Windows-Desktop-Apps“ behandelt).

5.2. Ein benutzerdefiniertes Steuerelement braucht einen AutomationPeer

Ein benutzerdefiniertes Steuerelement, das Sie selbst zeichnen, kann unverändert keine sinnvollen Informationen auf dem UIA-Baum offenlegen. In WPF überschreiben Sie OnCreateAutomationPeer auf einer von UIElement abgeleiteten Klasse und geben eine von AutomationPeer abgeleitete Klasse zurück, um Name, Art und Muster offenzulegen. Wenn Sie ein bestehendes Steuerelement erben, lässt Sie das Erben des entsprechenden Peers (ButtonBaseAutomationPeer für ButtonBase) bereits implementiertes Verhalten übernehmen.¹⁵

flowchart TB
    accTitle: Wie Informationen über AutomationPeer offengelegt werden
    accDescr: Ein benutzerdefiniertes Steuerelement legt Name, Art und Muster offen, indem es OnCreateAutomationPeer überschreibt und eine von AutomationPeer abgeleitete Klasse zurückgibt; wenn Sie ein bestehendes Steuerelement erben, erben Sie den entsprechenden Peer und übernehmen bereits implementiertes Verhalten
    custom["Benutzerdefiniertes Steuerelement"] --> ov["OnCreateAutomationPeer"]
    ov --> peer["Eine Peer-abgeleitete Klasse zurückgeben"]
    peer --> pub["Name, Art und Muster offenlegen"]
    inherit["Ein bestehendes Steuerelement erben"] -.-> basepeer["Den entsprechenden Peer erben"]
    basepeer -.-> reuse["Bereits implementiertes Verhalten übernehmen"]

Abbildung 10: Ein benutzerdefiniertes Steuerelement gibt einen Peer von OnCreateAutomationPeer zurück und legt Informationen an UIA offen.

// An example of a control that custom-draws line status as a coloured lamp
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 ? "Line status: online" : "Line status: offline";

    private static void OnIsOnlineChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        // Raise a UIA property-changed event the moment the value changes. Without this,
        // a screen reader keeps the old name and cannot notice the change of state
        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-equivalent if it is a status display with no operation

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

Einen Namen zurückzugeben reicht nicht; ihn mit einem Ereignis in dem Moment zu sagen, in dem er sich ändert, ist ebenfalls die Aufgabe des Peers. Hilfstechnologie hat keinen eigenen Zeitpunkt, um einen Wert erneut zu holen, eine Implementierung, die kein Änderungsereignis auslöst, ist also in einem Zustand „nur korrekt, wenn erneut gefragt“, und einem Bildschirmleser-Benutzer wird die Zustandsänderung nicht mitgeteilt.

sequenceDiagram
    accTitle: Der Ablauf, einem Bildschirmleser eine Zustandsänderung zu sagen
    accDescr: In dem Moment, in dem sich der Wert des Steuerelements ändert, löst der AutomationPeer ein Name-Eigenschaftsänderungsereignis aus; Hilfstechnologie holt von selbst nicht erneut, ohne das Ereignis bleibt sie also beim alten Namen und kann die Änderung nicht bemerken
    participant c as Steuerelement
    participant p as AutomationPeer
    participant s as Bildschirmleser
    c->>p: Der IsOnline-Wert ändert sich
    p->>s: Ein Name-Eigenschaftsänderungsereignis auslösen
    s->>s: Den neuen Zustand ansagen
    Note over s: Ohne das Ereignis bleibt sie beim alten Namen

Abbildung 11: Eine Wertänderung erreicht einen Bildschirmleser nur, wenn der AutomationPeer sie mit einem Änderungsereignis sagt.

Wenn das benutzerdefinierte Steuerelement eine Operation hat (es kann gedrückt, sein Wert geändert, es kann ausgewählt werden), überschreiben Sie GetPattern und stellen eine Musterschnittstelle wie IInvokeProvider oder IRangeValueProvider bereit.¹⁵ Der Punkt ist, dass wenn Sie den Peer auch auf der Seite der gemeinsamen Steuerelementbibliothek bauen, jeder Bildschirm, der ihn nutzt, automatisch unterstützt wird. Das ist die Grundlage von Kapitel 9s „seitlich ausrollen“.

6. Können Sie jede Funktion allein von der Tastatur erreichen?

WCAG-Erfolgskriterium 2.1.1 (Keyboard) verlangt, dass die gesamte Funktionalität des Inhalts über eine Tastaturschnittstelle bedienbar ist.⁸ Ein Bildschirmleser-Benutzer nutzt grundsätzlich keine Maus, eine Funktion, die Sie nicht von der Tastatur erreichen können, ist also dasselbe wie eine Funktion, die nicht existiert. Die Prüfstandpunkte sind wie folgt.

Der WinForms-Barrierefreiheits-Walkthrough listet ebenfalls als Grundlagen, ein Label in der unmittelbar vorhergehenden Tabreihenfolge eines Eingabefelds zu platzieren und Zugriffstasten auf die Steuerelemente und Menüs zu setzen, zu denen der Benutzer gehen will.¹²

Was wir betonen wollen, ist, dass das nicht „ein Extraaufwand für Behinderungsunterstützung“ ist. In einer Routinearbeit wie der Auftragserfassung entscheidet, ob Sie die Eingabe beenden können, ohne die Hände von der Grundstellung zu nehmen, den Durchsatz eines Bedieners unverändert. Eine ungeordnete Tabreihenfolge oder eine mauspflichtige Operation ist ein Defekt, der jeden Tag ein wenig von der Produktivität jedes Benutzers abschabt. Barrierefreiheitsunterstützung und Tastatureffizienz sind nur zwei Namen für dieselbe Arbeit (für Prioritäten nach Nutzungsumgebung siehe auch „Windows-App-UX-Design“).

flowchart TB
    accTitle: Die doppelte Wirkung, die Tastatur in Ordnung zu bringen
    accDescr: Tabreihenfolge, Zugriffstasten und Fokusanzeige in Ordnung zu bringen, erzeugt zwei Wirkungen auf einmal — ein Hilfstechnologie-Benutzer kann eine Funktion erreichen, und die Eingabegeschwindigkeit jedes Bedieners — und eine nur mit der Maus nutzbare Funktion ist dasselbe wie eine Funktion, die nicht existiert
    seibi["Tastatur in Ordnung bringen"] --> a11y["Hilfstechnologie-Benutzer"]
    seibi --> speed["Geschwindigkeit jedes Bedieners"]
    mouse["Eine Nur-Maus-Funktion"] -.-> none["Wie nicht existent"]

Abbildung 12: Tastaturbedienung in Ordnung zu bringen, verwirklicht Hilfstechnologieunterstützung und Effizienz für jeden Benutzer zugleich; eine Nur-Maus-Funktion ist wie nicht existent.

7. Farbe und Kontrast — 4,5:1 und „Farbe ist nicht das einzige Mittel“

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

WCAG-Erfolgskriterium 1.4.3 (Contrast (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.⁸ Ein modernes Design, das hellgrauen Text auf weißem Hintergrund platziert, verfehlt dieses Kriterium nicht selten. Benutzer einer Geschäftsanwendung umfassen Menschen, deren Sehen und Farbsehen sich mit dem Alter geändert haben, und Menschen, die sie in einer schlecht beleuchteten Umgebung wie einer Fabrik nutzen. Gewöhnen Sie sich an, bei der Entwurfsprüfung mit einem Kontrastprüfer zu messen.

7.2. Vermitteln Sie Informationen nicht allein durch Farbe

Erfolgskriterium 1.4.1 (Use of Color) ist, dass Farbe nicht das einzige visuelle Mittel zur Vermittlung von Informationen sein darf.⁸ Typische Beispiele in einer Geschäftsanwendung sind wie folgt.

• Eine Fehlerzeile nur in rotem Text zeigen → auch ein Fehlersymbol und eine Nachrichtenspalte bereitstellen
• Ein Pflichtfeld nur durch die Labelfarbe zeigen → ein „*“ oder die Formulierung „Pflicht“ hinzufügen
• Status nur durch die Lampenfarbe zeigen → Farbe + Form oder Formulierung machen („Läuft“, „Gestoppt“)

Angesichts der Vielfalt des Farbsehens ist auch das keine „Sonderantwort“, sondern eine Grundlage der Anzeigegestaltung.

flowchart TB
    accTitle: Informationen ersetzen, die allein durch Farbe vermittelt werden
    accDescr: Eine Anzeige, die einen Fehler nur in rotem Text zeigt, wird durch ein Fehlersymbol plus eine Nachrichtenspalte ersetzt; eine Anzeige, die ein Pflichtfeld nur durch die Labelfarbe zeigt, wird durch das Hinzufügen der Formulierung Pflicht ersetzt; eine Anzeige, die Status nur durch die Lampenfarbe zeigt, wird durch das Kombinieren von Form oder Formulierung ersetzt
    err["Ein Fehler nur in rotem Text"] --> erra["Auch ein Symbol und Formulierung bereitstellen"]
    req["Pflicht nur durch die Labelfarbe"] --> reqa["Die Formulierung Pflicht hinzufügen"]
    lamp["Status nur durch die Lampenfarbe"] --> lampa["Farbe mit Form oder Formulierung kombinieren"]

Abbildung 13: Typische Beispiele der Vermittlung allein durch Farbe werden durch das Kombinieren eines Symbols, einer Formulierung und von Form oder Text ersetzt.

7.3. Einem Kontrastthema (hoher Kontrast) folgen

Windows hat Kontrastthemen (früher hoher Kontrast), die zu einem Farbschema mit starker Trennung von Vorder- und Hintergrund wechseln; der Benutzer kann eingebaute Themen auswählen und bearbeiten, die so entworfen sind, dass das Kontrastverhältnis im Allgemeinen 7:1 oder mehr beträgt.⁹ Das Prinzip auf der App-Seite ist einfach: Farben nicht fest einencodieren; Systemfarben respektieren.

• WinForms: Wenn Sie ForeColor/BackColor beim Standard lassen, werden die Farbeinstellungen des Benutzers genutzt. Wo Sie eine eigene Farbe angewendet haben, beurteilen Sie mit SystemInformation.HighContrast, wechseln Sie zu einem SystemColors-basierten Schema und folgen Sie einer Einstellungssänderung mit dem Ereignis UserPreferenceChanged.¹²
• WPF/WinUI: Wenn Sie Ressourcen der Klasse SystemColors referenzieren, folgen Sie einem Themenwechsel. Stellen, die Sie mit einem eigenen Pinsel gefüllt haben, werden zur Ursache des Bruchs.⁹

flowchart TB
    accTitle: Einem Kontrastthema folgen
    accDescr: Stellen, an denen eine Farbe fest eingecodiert ist, gehen bei einem Wechsel zu einem Kontrastthema kaputt, wechseln Sie also zu einem SystemColors-basierten Schema und folgen Sie mit einem Einstellungssänderungsereignis; wenn Sie Systemfarben referenzieren, können Sie den Farben des Benutzers automatisch folgen
    theme["Zu einem Kontrastthema wechseln"] --> qh{"Wie ist die Farbe angegeben?"}
    qh -->|Fest eingecodiert| broken["Das Farbschema geht kaputt"]
    qh -->|Systemfarbenreferenz| ok["Folgt automatisch den Farben des Benutzers"]
    broken -.-> fix["Zu SystemColors wechseln"]
    fix -.-> ev["Mit einem Einstellungssänderungsereignis folgen"]

Abbildung 14: Nur Stellen, an denen eine Farbe fest eingecodiert ist, gehen unter einem Kontrastthema kaputt; eine Systemfarbenreferenz folgt automatisch.

Außerdem nutzt ein Benutzer mit Sehschwäche oft eine hohe Betriebssystemvergrößerung (DPI-Skalierung), High-DPI-Unterstützung ist also ebenfalls Teil der Barrierefreiheitsunterstützung. Eine App, deren Layout bei 125 %–200 % zerbricht, ist an diesem Punkt unbenutzbar. Siehe „High-DPI-Unterstützung in WinForms“ und „High-DPI-Unterstützung in WPF“ für die Einzelheiten.

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

8.1. Accessibility Insights for Windows

Microsoft stellt Accessibility Insights for Windows als Barrierefreiheitsprüfwerkzeug für Windows-Apps bereit, mit drei Hauptnutzungen.¹⁰

• Live Inspect: Bewegen Sie einfach die Maus über ein Element oder fokussieren Sie es per Tastatur, und Sie können seine UIA-Eigenschaften (Name, ControlType, Muster und Ähnliches) bestätigen. Das kürzeste Mittel zu sehen, „was der Name dieser Schaltfläche ist“.
• FastPass: Eine leichte Prüfung, die hochwirksame Barrierefreiheitsprobleme in unter fünf Minuten erkennt. Probleme, die mechanisch beurteilt werden können, etwa ein fehlender Name, können pro neuem Bildschirm inventarisiert werden.
• Troubleshooting: Unterstützt Diagnose und Korrektur eines bestimmten Problems. Von einem erkannten Problem können Sie direkt zu den korrespondierenden Framework-Korrekturleitfäden gehen, die dieser Artikel ebenfalls zitiert.

Inspect.exe und AccEvent, im Windows SDK enthalten, können ebenfalls den UIA-Baum und Eigenschaften bestätigen, sind aber als Altwerkzeuge positioniert, und ein Wechsel zu Accessibility Insights wird jetzt empfohlen.¹⁰

flowchart TB
    accTitle: Drei Nutzungen von Accessibility Insights
    accDescr: Accessibility Insights for Windows stellt das Bestätigen von UIA-Eigenschaften mit Live Inspect, eine leichte Prüfung hochwirksamer Probleme mit FastPass und Unterstützung bei Diagnose und Korrektur eines Problems mit Troubleshooting bereit; ein Wechsel von Altwerkzeugen wie Inspect.exe wird empfohlen
    ai["Accessibility Insights"] --> live["Live Inspect"]
    ai --> fast["FastPass"]
    ai --> ts["Troubleshooting"]
    live --> livef["UIA-Eigenschaften bestätigen"]
    fast --> fastf["Hochwirksame Probleme erkennen"]
    ts --> tsf["Diagnose und Korrektur unterstützen"]
    legacy["Inspect.exe und Ähnliches"] -.->|Ein Wechsel wird empfohlen| ai

Abbildung 15: Accessibility Insights hat die drei Nutzungen bestätigen, erkennen und diagnostizieren und ist das Ziel eines Wechsels von Altwerkzeugen.

8.2. Eine praktische Prüfung mit einem Bildschirmleser

Was eine automatische Werkzeugprüfung erkennen kann, sind nur Probleme, die mechanisch beurteilt werden können. Am Ende gehen Sie immer eine echte Geschäftsoperation mit einem Bildschirmleser durch. Der in Windows eingebaute Narrator kann sofort mit Strg+Windows-Taste+Eingabe gestartet werden, und NVDA kann kostenlos eingeführt werden.¹¹ Der Trick der Prüfung ist, ohne auf den Bildschirm zu schauen (oder bei ausgeschaltetem Display), nur auf die Ansage gestützt, zu versuchen, ob Sie eine echte Aufgabe wie „eine Bestellung eingeben und bestätigen“ beenden können. Probleme wie ein vorhandener Name, aber eine unzusammenhängende Ansagereihenfolge, oder Fokus, der aus einem Modal entweicht, findet man nur praktisch.

flowchart TB
    accTitle: Werkzeugprüfung und eine praktische Prüfung kombinieren
    accDescr: Was eine automatische Prüfung wie FastPass erkennen kann, sind nur Probleme, die mechanisch beurteilt werden können; den Rest findet man praktisch, indem man eine echte Geschäftsoperation mit einem Bildschirmleser durchgeht und Ansagereihenfolge- und Fokusprobleme findet
    tool["Eine automatische Werkzeugprüfung"] --> kikai["Mechanisch beurteilbare Probleme"]
    tool -.-> nokori["Probleme, die sie nicht erkennt, bleiben"]
    nokori --> sr["Eine praktische Prüfung mit einem Bildschirmleser"]
    sr --> task["Eine Geschäftsoperation durchgehen"]
    task --> mieru["Ansagereihenfolge- und Fokusprobleme"]

Abbildung 16: Inventarisieren Sie mechanische Probleme mit einer automatischen Prüfung und finden Sie den Rest mit einer praktischen Prüfung mit einem Bildschirmleser.

8.3. Es in den Entwicklungsfluss einbauen und der gegenseitige Nutzen mit UI-Testautomatisierung

Damit Prüfung nicht personenabhängig wird, empfehlen wir, die folgende Checkliste in die Review-Punkte für einen neuen Bildschirm einzubauen.

Und noch eines. UI-Testautomatisierung mit FlaUI und Ähnlichem ist auf derselben UIA aufgebaut, die Bildschirmleser nutzen. Der Name und die Muster, die Sie für Barrierefreiheit einrichten, werden Teile von Testcode, und eine für Tests entworfene AutomationId macht das Debuggen in Live Inspect leichter. Umgekehrt ist eine UI, die nicht im UIA-Baum erscheint, sowohl für Tests als auch für Hilfstechnologie unsichtbar. Barrierefreiheit und Testbarkeit sind zwei Seiten derselben Investition („UI-Automatisierungstests für Windows-Desktop-Apps“).

flowchart TB
    accTitle: Der gegenseitige Nutzen von Barrierefreiheit und UI-Testautomatisierung
    accDescr: Ein Bildschirmleser und UI-Testautomatisierung wie FlaUI sind auf derselben UIA aufgebaut, Name und Muster, die Sie einrichten, können also von beiden genutzt werden, und eine UI, die nicht im UIA-Baum erscheint, ist von beiden unsichtbar
    uia["Den UIA-Baum in Ordnung bringen"] --> sr["Ein Bildschirmleser kann ihn lesen"]
    uia --> test["Er kann in der UI-Testautomatisierung genutzt werden"]
    sr -.-> both["Zwei Seiten derselben Investition"]
    test -.-> both
    hidden["Eine UI, die nicht in UIA erscheint"] -.-> invisible["Von beiden unsichtbar"]

Abbildung 17: Weil sie auf derselben UIA-Grundlage sitzen, zahlt sich das In-Ordnung-Bringen des UIA-Baums sowohl für Hilfstechnologie als auch für UI-Testautomatisierung aus.

9. Wie Sie Prioritäten setzen — Korrigieren Sie nicht jeden Bildschirm auf einmal

Ein Kernsystem von Hunderten Bildschirmen auf einmal zu korrigieren, ist in Kosten und Qualität unrealistisch. Der Ansatz, den wir empfehlen, sind die folgenden drei Stufen.

1. Korrigieren Sie von den Bildschirmen, die dieser Benutzer in der Arbeit nutzt. Angemessene Vorkehrungen sind ein Prozess des individuellen Antwortens auf eine Anfrage der betroffenen Person.¹ Lassen Sie zuerst die Person die tatsächliche Arbeit mit einem Bildschirmleser bedienen und identifizieren Sie gemeinsam, wo sie feststeckt. In vielen Fällen verengen sich die im Alltag genutzten Bildschirme auf einige bis ein Dutzend, und die fatalen Probleme darunter (eine Schaltfläche ohne Namen, eine Bestätigen-Schaltfläche, die Sie nicht von der Tastatur drücken können) können in einer Korrektur von Tagen gelöst werden.
2. Machen Sie neue Entwicklung standardkonform. Fügen Sie die Checkliste von Kapitel 8 zur Definition of Done hinzu und bauen Sie neue Bildschirme von Anfang an unterstützt. Anders als eine nachträgliche Korrektur ist der Kostenzuwachs, es zur Entwurfszeit einzubauen, gering.
3. Rollen Sie seitlich aus, indem Sie gemeinsame Steuerelemente korrigieren. Wenn Sie einen Standard-AccessibleName oder einen AutomationPeer auf gemeinsamen internen Teilen wie einem Suchdialog, einem Raster oder einer Datumseingabe implementieren, wirkt das in einem Schwung auf jeden Bildschirm, der sie nutzt. Es ist ein weit kosteneffektiverer Zug, als einzelne Bildschirme nacheinander anzufassen.

flowchart TB
    accTitle: Die drei Stufen der Korrekturpriorität
    accDescr: Korrigieren Sie von den Bildschirmen, die der Benutzer in der Arbeit nutzt, machen Sie neue Entwicklung mit einer Checkliste standardkonform und rollen Sie auf jeden Bildschirm aus, indem Sie gemeinsame Steuerelemente korrigieren
    s1["1. Von den Bildschirmen korrigieren, die der Benutzer nutzt"] --> s2["2. Neue Arbeit ist standardkonform"] --> s3["3. Seitlich mit gemeinsamen Steuerelementen ausrollen"]
    s3 -.-> all["Wirkt in einem Schwung auf jeden Bildschirm, der sie nutzt"]

Abbildung 18: Schreiten Sie nicht voran, indem Sie jeden Bildschirm auf einmal korrigieren, sondern in den drei Stufen genutzte Bildschirme, neue Arbeit und gemeinsame Teile.

Und eine Aufzeichnung des Dialogs ist ebenso wichtig wie die technische Antwort. Angemessene Vorkehrungen sind ein Prozess des „individuellen Dialogs und Anpassens“, nicht des vollständigen Erfüllens jeder Anfrage. Ein alternatives Mittel mit der Person zu erwägen (jene Arbeit auf einem anderen Bildschirm zu tun, einen CSV-Export vorzubereiten, sie im Betrieb abzudecken) und sich für eine Korrektur, deren Last zu schwer ist, zu einigen, ist ebenfalls ein legitimes Ergebnis konstruktiven Dialogs.¹ Aufzuzeichnen, was angefragt, worauf geantwortet und was zu einem alternativen Mittel gemacht wurde, wird zum Nachweis des guten Glaubens der Organisation.

flowchart TB
    accTitle: Der Ablauf konstruktiven Dialogs und einer Aufzeichnung
    accDescr: Antworten Sie auf eine Anfrage einer Person mit Behinderung durch konstruktiven Dialog; führen Sie eine Korrektur aus, auf die geantwortet werden kann; für eine Korrektur, deren Last zu schwer ist, erwägen Sie ein alternatives Mittel mit der Person und einigen Sie sich; zeichnen Sie auf, was angefragt, worauf geantwortet und was zu einem alternativen Mittel gemacht wurde
    req["Eine Anfrage"] --> talk["Konstruktiver Dialog"]
    talk --> q{"Ist die Last zu schwer?"}
    q -->|Nein| kaishu["Mit einer Korrektur antworten"]
    q -->|Ja| alt["Ein alternatives Mittel erwägen und sich einigen"]
    kaishu --> rec["Die Geschichte aufzeichnen"]
    alt --> rec

Abbildung 19: Im konstruktiven Dialog einigen Sie sich mit der Person auf eine Korrektur oder ein alternatives Mittel und hinterlassen diese Geschichte in einer Aufzeichnung.

10. Zusammenfassung

• Mit dem geänderten Gesetz zur Beseitigung der Diskriminierung von Menschen mit Behinderungen, das im April 2024 in Kraft trat, wurde die Bereitstellung angemessener Vorkehrungen auch für Unternehmen zur Pflicht. Das Beschäftigungsfeld ist seit 2016 unter dem Gesetz zur Förderung der Beschäftigung von Menschen mit Behinderungen eine Arbeitgeberpflicht. Die App im Voraus leichter nutzbar zu machen, ist „Umfeldverbesserung“ (eine Bemühungspflicht), und je weiter sie gegangen ist, desto leichter werden individuelle Antworten.
• Die technischen Kriterien konzentrieren sich in WCAG (JIS X 8341-3:2016), und dasselbe Denken kann über WCAG2ICT auf eine Desktop-App angewendet werden.
• Ein Bildschirmleser liest eine App über UI Automation. Das Trio aus UIA-Baum, Eigenschaften (Name/ControlType/AutomationId) und Steuermustern ist die Grundlage.
• Die höchste Priorität ist Name. WinForms nutzt AccessibleName und die Zuordnung eines Labels zur Tabreihenfolge; WPF nutzt AutomationProperties.Name/LabeledBy; ein benutzerdefiniertes Steuerelement nutzt einen AutomationPeer.
• Jede Funktion allein von der Tastatur erreichen zu können, ist ein WCAG-Erfolgskriterium und zugleich die Produktivität jedes Bedieners. Bringen Sie Tabreihenfolge, Zugriffstasten und Fokusanzeige in Ordnung.
• Die drei Grundlagen der Farbe sind ein Kontrastverhältnis von 4,5:1, Farbe ist nicht das einzige Mittel, und das Respektieren von Systemfarben in einem Kontrastthema.
• Kombinieren Sie die Prüfung mit FastPass+Live Inspect in Accessibility Insights und einer praktischen Prüfung mit Narrator/NVDA und bauen Sie sie als Checkliste für einen neuen Bildschirm in den Entwicklungsfluss ein.
• Korrigieren Sie nicht jeden Bildschirm auf einmal; schreiten Sie in der Reihenfolge Bildschirme, die der Benutzer nutzt → Standardunterstützung für neue Arbeit → ein seitliches Ausrollen gemeinsamer Steuerelemente vor. Angemessene Vorkehrungen sind ein Dialogprozess, und eine Aufzeichnung der Geschichte schützt die Organisation.

Als ersten Schritt empfehlen wir, einen Ihrer Hauptbildschirme zu nehmen, FastPass in Accessibility Insights for Windows auszuführen und dann die Arbeit mit der Tab-Taste allein durchzugehen. In dreißig Minuten wird die gegenwärtige Position Ihrer eigenen App überraschend konkret.

Weiterführende 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

Zugehörige Beratungsfelder

KomuraSoft LLC übernimmt Barrierefreiheitskorrekturen von WinForms/WPF-Geschäftsanwendungen (Bildschirmleserunterstützung, Tastaturbedienung in Ordnung bringen, Kontrastthema-Unterstützung), das Implementieren eines AutomationPeer auf gemeinsamen Steuerelementen und Beratungen zu einer Ist-Zustands-Diagnose und Prioritätensetzung mit Accessibility Insights. Vom Stadium „wir wollen bestätigen, ob ein Beschäftigter unsere App mit einem Bildschirmleser nutzen kann“ zu starten, ist in Ordnung.

• Windows-Anwendungsentwicklung
• 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 Barrierefreiheitsunterstützung für eine 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 die Bereitstellung angemessener Vorkehrungen für Menschen mit Behinderungen wurde auch für Unternehmen zur Pflicht. Angemessene Vorkehrungen sind eine Antwort, die, wenn eine Person mit Behinderung eine Anfrage stellt, eine individuelle Barriere in einem Rahmen beseitigt, der keine übermäßige Belastung ist; die App im Voraus leichter nutzbar zu machen, ist als Bemühungspflicht namens „Umfeldverbesserung“ positioniert. Beschäftigung, etwa die Beziehung zwischen einem Beschäftigten und dem Unternehmen, fällt nicht unter jenes Gesetz, sondern unter das Gesetz zur Förderung der Beschäftigung von Menschen mit Behinderungen, das Arbeitgeber seit der Änderung, die im April 2016 in Kraft trat, zur Bereitstellung angemessener Vorkehrungen verpflichtet. Mit anderen Worten: Eine Situation „ein Beschäftigter kann die Geschäftsanwendung nicht nutzen“ liegt schon länger im Bereich der Pflicht. Wie weit man in einem gegebenen Fall geht, hängt von der individuellen Lage ab, Sie bestätigen also Primärquellen des Kabinettsbüros und des Ministeriums für Gesundheit, Arbeit und Soziales und entscheiden im Dialog mit der betroffenen Person.

Wie liest ein Bildschirmleser eine Windows-Desktop-App?

Bildschirmleser wie Narrator und NVDA lesen die UI einer App über eine Barrierefreiheitsgrundlage namens UI Automation (UIA). Die App-Seite legt Elemente auf dem Bildschirm in einer Struktur namens UIA-Baum offen; jedes Element hat Eigenschaften wie Name (Zweck) und ControlType (Art) sowie Steuermuster wie Invoke (drücken) und Value (Wert). Der Bildschirmleser kündigt diese Informationen als „Schaltfläche Bestellung bestätigen“ an und bedient über die Muster. Standard-WinForms- und -WPF-Steuerelemente haben diesen Mechanismus von Anfang an, die Hauptaufgabe des Entwicklers ist also, Name nicht leer zu lassen, die UI von der Tastatur bedienbar zu machen und Informationen auf benutzerdefinierten 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 Steuerelemente mit leerem Name und Tabreihenfolge-Probleme zu inventarisieren. Korrekturen beginnen damit, AccessibleName auf Nur-Symbol-Schaltflächen zu setzen, ein Label in der unmittelbar vorhergehenden Tabreihenfolge eines Eingabefelds zuzuordnen und TabIndex so aufzuräumen, dass es der visuellen Reihenfolge entspricht. Dann starten Sie Narrator oder NVDA und gehen eine echte Geschäftsoperation durch, ohne auf den Bildschirm zu schauen, und bestätigen, wo Sie feststecken. Sie müssen nicht jeden Bildschirm auf einmal korrigieren; von Bildschirmen zu starten, die jemand tatsächlich nutzt, und neue Bildschirme mit einer Checkliste standardkonform zu machen, ist realistisch.

Was sollen wir für die Unterstützung von hohem Kontrast (Kontrastthema) tun?

Die Basis ist, Farben nicht fest einzucodieren und Systemfarben zu respektieren. In WinForms lassen Sie ForeColor/BackColor beim Standard oder nutzen SystemColors, beurteilen den Zustand mit SystemInformation.HighContrast und folgen einem Wechsel mit dem Ereignis UserPreferenceChanged. Auch in WPF und WinUI folgen Sie einem Themenwechsel automatisch, wenn Sie Ressourcen der Klasse SystemColors referenzieren. Gleichzeitig hören Sie auf, Informationen „nur durch Farbe“ zu vermitteln — einen Fehler nur in Rot zu zeigen — und kombinieren sie mit einem Symbol oder einer Formulierung. Auch im gewöhnlichen Thema macht das WCAG-Kriterium eines Textkontrastverhältnisses von 4,5:1 oder mehr als Leitlinie die UI für eine schlecht beleuchtete Werkstatt und für ältere Benutzer lesbarer.

Hilft Barrierefreiheitsunterstützung auch der UI-Testautomatisierung?

Ja. UI-Testautomatisierungswerkzeuge wie FlaUI sind auf derselben UI Automation aufgebaut, die Bildschirmleser nutzen. Name, ControlType und Steuermuster, die Sie für Barrierefreiheit einrichten, können unverändert aus Testcode genutzt werden, und eine für Tests entworfene AutomationId stabilisiert die Elementidentifikation. Umgekehrt ist eine selbstgezeichnete UI, die nicht im UIA-Baum erscheint, sowohl für einen Bildschirmleser als auch für Tests unsichtbar. Barrierefreiheit und automatisierte Tests sind eine Investition in dieselbe Grundlage, eines einzurichten senkt also auch 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.