Implementieren von Barrierefreiheit für den Tastaturzugriff (XAML)

Applies to Windows and Windows Phone

Sie suchen die HTML/JavaScript-Version dieses Themas? Informationen finden Sie unter Implementieren von Barrierefreiheit für den Tastaturzugriff (HTML).

Viele Benutzer, die blind oder in ihrer Beweglichkeit eingeschränkt sind, sind auf die Tastatur als einziges Mittel zur Navigation in der Benutzeroberfläche Ihrer App sowie zum Zugriff auf die Funktionen der App angewiesen. Wenn Ihre App keinen guten Zugriff über die Tastatur ermöglicht, können diese Benutzer Schwierigkeiten bei der Verwendung Ihrer App haben oder Ihre App möglicherweise überhaupt nicht nutzen.

Sehen Sie dieses Feature in unserer Reihe App-Features von A bis Z in Aktion.:  Benutzerinteraktion: Toucheingabe... und vieles mehr

Navigation zwischen Benutzeroberflächenelementen mithilfe der Tastatur

Um die Tastatur für ein Steuerelement verwenden zu können, muss das Steuerelement den Fokus haben, und damit es den Fokus (ohne Verwendung eines Zeigers) erhalten kann, muss es in einem Benutzeroberflächenentwurf über die TAB-Navigation erreichbar sein. Standardmäßig entspricht die Aktivierreihenfolge von Steuerelementen der Reihenfolge, in der die Steuerelemente der Entwurfsoberfläche hinzugefügt, in XAML aufgelistet oder programmgesteuert einem Container hinzugefügt werden.

In den meisten Fällen ist die auf Ihrer Definition der Steuerelemente in XAML basierende Standardreihenfolge die beste Reihenfolge, insbesondere, weil die Steuerelemente in dieser Reihenfolge auch von Bildschirmleseprogrammen gelesen werden. Die Standardreihenfolge ist jedoch nicht notwendigerweise mit der visuellen Reihenfolge identisch. Die tatsächliche Anzeigeposition kann vom übergeordneten Layoutcontainer und bestimmten Eigenschaften abhängen, die Sie für die untergeordneten Elemente festlegen können, um das Layout zu beeinflussen. Testen Sie dieses Verhalten selbst, um sicherzustellen dass die Aktivierreihenfolge Ihrer App gut ist. Insbesondere bei einer Raster- oder Tabellenmetapher für Ihr Layout lesen die Benutzer am Ende möglicherweise in einer anderen Reihenfolge als der Aktivierreihenfolge. Das ist an sich nicht unbedingt ein Problem. Achten Sie aber darauf, die Funktionen der App sowohl als UI für die Toucheingabe als auch als UI für die Verwendung mit der Tastatur zu testen. Vergewissern Sie sich, dass die UI bei beiden Methoden sinnvoll ist.

Sie können eine der visuellen Reihenfolge entsprechende Aktivierreihenfolge verwenden oder das XAML anpassen. Sie können auch die standardmäßige Aktivierreihenfolge überschreiben, indem Sie die TabIndex-Eigenschaft festlegen. Das folgende Beispiel zeigt dies für ein Grid-Layout mit Tab-Navigation, bei dem zuerst Spalten aktiviert werden.


<!--Custom tab order.--> 
<Grid>
  <Grid.RowDefinitions>...</Grid.RowDefinitions>
  <Grid.ColumnDefinitions>...</Grid.ColumnDefinitions>

  <TextBlock Grid.Column="1" HorizontalAlignment="Center">Groom</TextBlock>
  <TextBlock Grid.Column="2" HorizontalAlignment="Center">Bride</TextBlock>

  <TextBlock Grid.Row="1">First name</TextBlock>
  <TextBox x:Name="GroomFirstName" Grid.Row="1" Grid.Column="1" TabIndex="1"/>
  <TextBox x:Name="BrideFirstName" Grid.Row="1" Grid.Column="2" TabIndex="3"/>

  <TextBlock Grid.Row="2">Last name</TextBlock>
  <TextBox x:Name="GroomLastName" Grid.Row="2" Grid.Column="1" TabIndex="2"/>
  <TextBox x:Name="BrideLastName" Grid.Row="2" Grid.Column="2" TabIndex="4"/>
</Grid>

Möglicherweise möchten Sie ein Steuerelement von der Aktivierreihenfolge ausschließen. In der Regel legen Sie das Steuerelement dazu nur als nicht interaktiv fest, indem Sie z. B. seine IsEnabled-Eigenschaft auf false setzen. Ein deaktiviertes Steuerelement wird automatisch von der Aktivierreihenfolge ausgeschlossen. Mitunter ist es aber erforderlich, ein nicht deaktiviertes Steuerelement von der Aktivierreihenfolge auszuschließen. In diesem Fall können Sie die IsTabStop-Eigenschaft auf false festlegen.

Alle Elemente, die den Fokus haben können, sind normalerweise standardmäßig in der Aktivierreihenfolge enthalten. Eine Ausnahme sind bestimmte Textanzeigetypen wie RichTextBlock, die den Fokus haben können, damit die Zwischenablage zur Textauswahl auf sie zugreifen kann. Diese Elemente sind aber nicht in der Aktivierreihenfolge enthalten, weil dies bei statischen Textelementen nicht zu erwarten ist. Sie sind nicht im herkömmlichen Sinn interaktiv (sie können nicht aufgerufen werden und erfordern keine Texteingabe, unterstützen aber das Steuerelementmuster für Text, das das Suchen und Anpassen von Auswahlpunkten in Text unterstützt). Text sollte nicht die Konnotation aufweisen, dass ein Festlegen des Fokus darauf eine mögliche Aktion auslöst. Textelemente werden von Hilfstechnologien weiterhin erkannt und von Sprachausgaben laut vorgelesen, dies basiert jedoch auf anderen Techniken als dem Finden dieser Elemente in der praktischen Aktivierreihenfolge.

Unabhängig davon, ob Sie TabIndex-Werte anpassen oder die Standardreihenfolge verwenden, gelten folgende Regeln:

  • Benutzeroberflächenelemente, bei denen TabIndex gleich 0 ist, werden der Aktivierreihenfolge basierend auf der Deklarierungsreihenfolge in XAML- oder untergeordneten Sammlungen hinzugefügt.
  • Benutzeroberflächenelemente, bei denen TabIndex größer als 0 ist, werden der Aktivierreihenfolge basierend auf dem TabIndex-Wert hinzugefügt.
  • Benutzeroberflächenelemente, bei denen TabIndex kleiner als 0 ist, werden der Aktivierreihenfolge hinzugefügt und erscheinen vor allen Elementen mit NULL-Werten. Dies ist möglicherweise anders als in der Behandlung des tabindex-Attributs in HTML (und ein negativer tabindex wurde in älteren HTML-Spezifikationen nicht unterstützt).

Navigation innerhalb eines Benutzeroberflächenelements mithilfe der Tastatur

Bei zusammengesetzten Elementen ist es wichtig, eine ordnungsgemäße interne Navigation zwischen den enthaltenen Elementen sicherzustellen. Ein zusammengesetztes Element kann seine derzeit aktiven untergeordneten Elemente verwalten, wodurch der Mehraufwand reduziert wird, der entsteht, wenn alle untergeordneten Elemente fokussierbar sein müssen. Ein solches zusammengesetztes Element ist in der Aktivierreihenfolge enthalten und behandelt Tastaturnavigationsereignisse selbst. Viele der zusammengesetzten Steuerelemente, die Sie für eine Windows-Runtime-App mit C++, C# oder Visual Basic verwenden, verfügen bereits über eine in ihre Ereignisbehandlung integrierte Navigationslogik. Das Durchlaufen von Elementen mit den Pfeiltasten ist z. B. standardmäßig für die Elemente eines ItemsControl-Steuerelements aktiviert.

Tastaturalternativen für Zeigeraktionen und Ereignisse für bestimmte Steuerelemente

Stellen Sie sicher, dass Benutzeroberflächenelemente, auf die geklickt werden kann, auch über die Tastatur aufgerufen werden können. Um die Tastatur für ein Benutzeroberflächenelement verwenden zu können, muss das Element den Fokus haben. Nur von Control abgeleitete Klassen unterstützen den Fokus und die TAB-Navigation.

Implementieren Sie für Benutzeroberflächenelemente, die aufgerufen werden können, Tastaturereignishandler für die Leertaste und die EINGABETASTE. So machen Sie die Unterstützung für die Barrierefreiheit des Tastaturzugriffs komplett und ermöglichen es Benutzern, einfache App-Szenarien nur über die Tastatur auszuführen – d. h. Benutzer können über die Tastatur alle interaktiven Benutzeroberflächenelemente erreichen und die Standardfunktionen aktivieren.

Wenn ein Element, das Sie in der Benutzeroberfläche verwenden möchten, nicht den Fokus haben kann, können Sie ein eigenes benutzerdefiniertes Steuerelement erstellen. Sie müssen die IsTabStop-Eigenschaft auf true festlegen, damit das Element den Fokus erhalten kann, und Sie müssen eine visuelle Anzeige des fokussierten Zustands bereitstellen, indem Sie einen visuellen Zustand erstellen, der für eine Fokusanzeige auf der UI sorgt. Oft ist es allerdings einfacher, die Steuerelementkomposition zu verwenden, damit die Unterstützung für TAB-Navigation, Fokus und Microsoft-Benutzeroberflächenautomatisierungs-Peers und -Muster von dem Steuerelement behandelt werden kann, in dem Sie den Inhalt zusammensetzen.

Anstatt z. B. das PointerPressed-Ereignis für ein Image zu behandeln, können Sie das Element in einem Button-Objekt umschließen, um die Zeiger-, Tastatur- und Fokusunterstützung bereitzustellen.


<!--Don't do this.-->
<Image Source="sample.jpg" PointerPressed="Image_PointerPressed"/>

<!--Do this instead.-->
<Button Click="Button_Click"><Image Source="sample.jpg"/></Button>

Tastenkombinationen

Zusätzlich zur Navigation und Aktivierung über die Tastatur empfiehlt es sich, Tastenkombinationen für die Funktionen Ihrer App zu implementieren. Die TAB-Navigation ist eine gute, einfache Form der Tastaturunterstützung. Bei komplexeren Formularen kann es aber sinnvoll sein, auch Unterstützung für Tastenkombinationen hinzuzufügen. Hierdurch kann Ihre App effizienter genutzt werden – auch von Menschen, die sowohl Tastatur als auch Zeigegeräte nutzen.

Tastenkombinationen sind eine effiziente Methode für den Zugriff auf App-Funktionen und verbessern daher die Produktivität der Benutzer. Es gibt zwei Arten von Tastenkombinationen:

  • Tastenkombinationen mit der ALT-TASTE ermöglichen den schnellen Zugriff auf Benutzeroberflächenelemente Ihrer App. Hierbei handelt es sich um eine Kombination aus der ALT-TASTE und einer Buchstabentaste.
  • Tastenkombinationen mit der STRG-Taste ermöglichen den schnellen Zugriff auf App-Befehle. Ihr App kann Benutzeroberflächenelemente aufweisen, die exakt dem Befehl entsprechen. Hierbei handelt es sich um eine Kombination aus der STRG-TASTE und einer Buchstabentaste.

Es ist unbedingt notwendig, dass Benutzer, die auf Bildschirmleseprogramme und andere Hilfstechnologien angewiesen sind, die Tastenkombinationen der App einfach erkennen können. Weisen Sie mithilfe von QuickInfos, Namen und Beschreibungen zur Verwendung durch Bildschirmleseprogramme oder anderen Hinweisen auf dem Bildschirm auf Tastenkombinationen hin. Zumindest sollten die Tastenkombinationen im Hilfeinhalt Ihrer App gut dokumentiert sein.

Sie können Zugriffstasten über Bildschirmleseprogramme dokumentieren, indem Sie die angefügte Eigenschaft AutomationProperties.AccessKey auf eine Zeichenfolge festlegen, die die Tastenkombination beschreibt. Darüber hinaus gibt es die angefügte Eigenschaft AutomationProperties.AcceleratorKey, um nicht-mmemonische Tastenkombinationen zu dokumentieren. Beide Eigenschaften werden von Bildschirmleseprogrammen jedoch normalerweise gleich behandelt. Sie sollten versuchen, Tastenkombinationen auf mehrere Arten zu dokumentieren – mithilfe von QuickInfos, Automatisierungseigenschaften und schriftlicher Hilfedokumentation.

Das folgende Beispiel zeigt das Dokumentieren von Tastenkombinationen für Medienwiedergabe-, Pause- und Stopp-Schaltflächen.


<Grid KeyDown="Grid_KeyDown">

  <Grid.RowDefinitions>
    <RowDefinition Height="Auto" />
    <RowDefinition Height="Auto" />
  </Grid.RowDefinitions>

  <MediaElement x:Name="DemoMovie" Source="xbox.wmv" 
    Width="500" Height="500" Margin="20" HorizontalAlignment="Center" />

  <StackPanel Grid.Row="1" Margin="10"
    Orientation="Horizontal" HorizontalAlignment="Center">

    <Button x:Name="PlayButton" Click="MediaButton_Click"
      ToolTipService.ToolTip="Shortcut key: Ctrl+P"
      AutomationProperties.AcceleratorKey="Control P">
      <TextBlock>Play</TextBlock>
    </Button>

    <Button x:Name="PauseButton" Click="MediaButton_Click"
      ToolTipService.ToolTip="Shortcut key: Ctrl+A" 
      AutomationProperties.AcceleratorKey="Control A">
      <TextBlock>Pause</TextBlock>
    </Button>

    <Button x:Name="StopButton" Click="MediaButton_Click"
      ToolTipService.ToolTip="Shortcut key: Ctrl+S" 
      AutomationProperties.AcceleratorKey="Control S">
      <TextBlock>Stop</TextBlock>
    </Button>

  </StackPanel>

</Grid>


Wichtig  Durch die Einstellung AutomationProperties.AcceleratorKey oder AutomationProperties.AccessKey werden keine Tastaturfunktionen aktiviert. Es wird lediglich an das Benutzeroberflächenautomatisierungs-Framework weitergegeben, welche Tasten verwendet werden sollen, damit diese Informationen über Hilfstechnologien an Benutzer weitergeleitet werden können. Die Implementierung für die Tastenbehandlung muss dennoch im Code erfolgen, nicht in XAML. Sie müssen weiterhin Handler für KeyDown- oder KeyUp-Ereignisse im entsprechenden Steuerelement anhängen, um das Verhalten der Tastenkombination tatsächlich in die App zu implementieren. Außerdem wird der Unterstrichzusatz für eine Zugriffstaste nicht automatisch bereitgestellt. Sie müssen den Text für die jeweilige Taste in Ihrem mnemonischen Zeichen explizit als Underline-Inlineformatierung unterstreichen, wenn auf der Benutzeroberfläche unterstrichener Text angezeigt werden soll.

Aus Gründen der Einfachheit werden im obigen Beispiel Ressourcen für Zeichenfolgen wie "STRG+A" weggelassen. Sie müssen die Tastenkombinationen aber auch während der Lokalisierung berücksichtigen. Die Lokalisierung von Tastenkombinationen ist wichtig, da die Auswahl einer Taste als Tastenkombination in der Regel von der sichtbaren Textbezeichnung des Elements abhängt. Weitere Informationen finden Sie unter Globalisieren Ihrer App.

Weitere Unterstützung bei der Implementierung von Tastenkombinationen erhalten Sie unter Tastenkombinationen in den Richtlinien zur benutzerfreundlichen Interaktion bei Windows.

Implementieren eines Tastenereignishandlers

Für Eingabeereignisse wie Tastenereignisse wird ein als Routingereignisse bezeichnetes Ereigniskonzept verwendet. Ein Routingereignis kann durch die untergeordneten Elemente eines zusammengesetzten Steuerelements per Bubbling weitergeleitet werden, sodass ein gemeinsames übergeordnetes Steuerelement Ereignisse für mehrere untergeordnete Elemente behandeln kann. Dieses Ereignismodell eignet sich zum Definieren von Tastenkombinationsaktionen für ein Steuerelement mit mehreren zusammengesetzten Teilen, die entwurfsbedingt nicht den Fokus haben oder Teil der Aktivierreihenfolge sein können.

Beispielcode für das Erstellen eines Tastenereignishandlers, der eine Überprüfung auf Zusatztasten wie die STRG-TASTE beinhaltet, finden Sie unter Reaktion auf Tastatureingaben.

Weitere allgemeine Informationen zum Routingereigniskonzept finden Sie unter Übersicht über Ereignisse und Routingereignisse.

Tastaturnavigation für benutzerdefinierte Steuerelemente

Wenn zwischen untergeordneten Elementen eine räumliche Beziehung besteht, empfehlen wir, die Pfeiltasten als Tastenkombinationen für die Navigation zwischen den Elementen zu verwenden. Falls für die Knoten einer Strukturansicht separate Unterelemente für das Erweitern/Reduzieren und die Knotenaktivierung vorhanden sind, verwenden Sie die Nach-links- und Nach-rechts-Tasten, um die Funktion zum Erweitern/Reduzieren über die Tastatur bereitzustellen. Für ein ausgerichtetes Steuerelement, dessen Inhalt in einer bestimmten Richtung durchlaufen werden kann, verwenden Sie die entsprechenden Pfeiltasten.

Im Allgemeinen implementieren Sie die benutzerdefinierte Tastenbehandlung für benutzerdefinierte Steuerelemente, indem Sie in der Klassenlogik eine Überschreibung der OnKeyDown- und OnKeyUp-Methoden hinzufügen.

Beispiel für einen Ansichtszustand für eine Fokusanzeige

Wie bereits erwählt sollte jedes benutzerdefinierte Steuerelement, mit dem Benutzer fokussieren können, über eine visuelle Fokusanzeige verfügen. In der Regel kann diese Fokusanzeige einfach durch Zeichnen eines Rechtecks direkt um das normale umgebende Rechteck des Steuerelement erzeugt werden. Die Rectangle für visuellen Fokus ist ein Peerelement der übrigen Zusammenstellung des Steuerelements in einer Steuerelementvorlage, wird jedoch anfänglich dem Visibility-Wert Collapsed festgelegt, da das Steuerelement noch nicht fokussiert ist. Wenn das Steuerelement Fokus erhält, wird ein visueller Zustand aufgerufen, der die Visibility des visuellen Fokus speziell auf Visible festlegt. Sobald der Fokus verschoben wird, wird ein anderer visueller Zustand auf gerufen, und die Visibility wird zu Collapsed.

Alle standardmäßigen XAML-Steuerelemente für Windows-Runtime weisen eine entsprechende visuelle Fokusanzeige auf, wenn sie den Fokus erhalten (sofern sie den Fokus erhalten können). Abhängig vom ausgewählten Design des Benutzers ergibt sich außerdem möglicherweise eine andere Optik (insbesondere, wenn der Benutzer einen Modus mit hohem Kontrast verwendet). Wenn Sie in Ihrer UI die XAML-Steuerelemente verwenden und die Steuerelementvorlagen nicht ersetzen, müssen Sie sonst nichts unternehmen, um visuelle Fokusanzeigen für Steuerelemente zu erhalten, die sich ordnungsgemäß verhalten und richtig angezeigt werden. Wenn Sie aber eine neue Vorlage für ein Steuerelement verwenden möchten oder sich fragen, wie XAML-Steuerelemente ihre Fokusanzeigen bereitstellen, wird im restlichen Teil dieses Abschnitts erläutert, wie Sie dies in XAML und in der Steuerelementlogik erreichen.

Im Folgenden finden Sie eine Beispiel-XAML, die aus der standardmäßigen XAML-Vorlage der Windows-Runtime für eine Button stammt.


<ControlTemplate TargetType="Button">
... 
    <Rectangle 
      x:Name="FocusVisualWhite" 
      IsHitTestVisible="False" 
      Stroke="{ThemeResource FocusVisualWhiteStrokeThemeBrush}" 
      StrokeEndLineCap="Square" 
      StrokeDashArray="1,1" 
      Opacity="0" 
      StrokeDashOffset="1.5"/>
    <Rectangle 
      x:Name="FocusVisualBlack" 
      IsHitTestVisible="False" 
      Stroke="{ThemeResource FocusVisualBlackStrokeThemeBrush}" 
      StrokeEndLineCap="Square" 
      StrokeDashArray="1,1" 
      Opacity="0" 
      StrokeDashOffset="0.5"/>
...
</ControlTemplate>


Bislang ist nur die Zusammensetzung vorhanden. Zum Steuern der Sichtbarkeit der Fokusanzeige definieren Sie visuelle Zustände zum Umschalten der Visibility-Eigenschaft. Dazu verwenden Sie die angefügte Eigenschaft VisualStateManager.VisualStateGroups wie bei der Anwendung auf das Stammelement, das die Zusammensetzung definiert.


<ControlTemplate TargetType="Button">
  <Grid>
    <VisualStateManager.VisualStateGroups> 
       <!--other visual state groups here-->
       <VisualStateGroup x:Name="FocusStates"> 
         <VisualState x:Name="Focused"> 
           <Storyboard> 
             <DoubleAnimation 
               Storyboard.TargetName="FocusVisualWhite" 
               Storyboard.TargetProperty="Opacity" 
               To="1" Duration="0"/>
             <DoubleAnimation 
               Storyboard.TargetName="FocusVisualBlack" 
               Storyboard.TargetProperty="Opacity" 
               To="1" Duration="0"/>
         </VisualState> 
         <VisualState x:Name="Unfocused" /> 
         <VisualState x:Name="PointerFocused" /> 
       </VisualStateGroup>
     <VisualStateManager.VisualStateGroups>
<!--composition is here-->
   </Grid>
</ControlTemplate>

Nur einer der benannten Zustände passt Visibility direkt an, während die anderen scheinbar leer sind. Die Funktionsweise visueller Zustände besteht darin, dass bei Verwendung eines anderen Zustands aus derselben VisualStateGroup durch das Steuerelement alle im vorhergehenden Zustand angewendeten Animationen sofort abgebrochen werden. Dies bedeutet, dass das Rechteck nicht angezeigt wird, da die Standard-Visibility aus der Zusammensetzung Collapsed ist. Die Logik des Steuerelements steuert dies durch Überwachen von Fokusereignissen wie z. B. GotFocus und Ändern der Status mit der GoToState. Bei Verwendung eines Standardsteuerelements oder bei einer Anpassung, die auf einem Steuerelement mit diesem Verhalten basiert, wird dieser Schritt oftmals automatisch für Sie erledigt. Weitere Informationen zur Verwendung von visuellen Zuständen finden Sie unter Storyboardanimationen für visuelle Zustände.

Barrierefreiheit der Tastaturnavigation und Windows Phone

Ein Windows Phone-Gerät verfügt in der Regel nicht über eine dedizierte Hardwaretastatur. Ein Soft Input Panel (SIP) kann jedoch mehrere Szenarien der Barrierefreiheit der Tastaturnavigation unterstützen. Sprachausgaben können Texteingaben vom Text-SIP lesen, darunter Löschankündigungen. Benutzer wissen, wo sich ihre Finger befinden, da das Bildschirmleseprogramm erkennt, dass der Benutzer Tasten auswählt und den Namen der ausgewählten Taste laut vorliest. Einige der tastaturbezogenen Konzepte für die Barrierefreiheit können auch zugehörigen Hilfstechnologieverhalten zugeordnet werden, die überhaupt keine Tastatur verwenden. Das SIP verfügt zwar nicht über eine Tabulatortaste, die Sprachausgabe unterstützt jedoch eine Touchbewegung, die dem Drücken der Tabulatortaste entspricht. Daher ist eine geeignete Aktivierreihenfolge über die Steuerelemente auf einer UI weiterhin ein wichtiges Barrierefreiheitsprinzip. Pfeiltasten, wie sie für die Navigation innerhalb von komplexen Steuerelementen verwendet werden, werden auch über die Toucheingabe der Sprachausgabe unterstützt. Sobald der Fokus auf einem Steuerelement liegt, das nicht zur Texteingabe dient, unterstützt die Sprachausgabe eine Geste zum Aufrufen der Aktion dieses Steuerelements.

Tastenkombinationen sind für Windows Phone-Apps in der Regel nicht relevant, da ein SIP nicht über STRG- und ALT-TASTEN verfügt.

Verwandte Themen

Reaktion auf Tastatureingaben
Eingabe: Beispiel für die Bildschirmtastatur
Beispiel für die Reaktion auf die Anzeige der Bildschirmtastatur
XAML-Beispiel für Barrierefreiheit
Storyboardanimationen für visuelle Zustände

 

 

Anzeigen:
© 2014 Microsoft