Accessibilité du clavier

L’accessibilité du clavier doit être traitée comme un modèle d’interaction principal, et non comme un secours secondaire. Une expérience de clavier robuste prend en charge les utilisateurs qui ont divers handicaps et limitations (y compris la vision, l’apprentissage, la déxtériité/mobilité et les handicaps de langage/communication). Il améliore également la productivité des utilisateurs qui préfèrent l’interaction clavier-première pour la vitesse et la précision.

Si l’accès au clavier est incomplet ou incohérent, les utilisateurs peuvent perdre l’accès aux fonctionnalités principales de l’application, même lorsque l’interaction de pointeur apparaît entièrement implémentée.

Navigation au clavier entre les éléments de l’interface utilisateur

Pour interagir avec un contrôle à l’aide du clavier, les contrôles doivent être focusables et accessibles via la traversée du focus. Pour recevoir le focus (sans utiliser de pointeur), le contrôle doit être accessible via la navigation par onglet. Par défaut, l’ordre de tabulation des contrôles est le même que l’ordre dans lequel ils sont ajoutés à un surface de conception, déclaré en XAML ou ajouté par programmation à un conteneur.

Dans de nombreuses interfaces utilisateur, ce comportement par défaut est acceptable et s’aligne sur le flux de lecture. Toutefois, l’ordre visuel et l’ordre du clavier peuvent varier en fonction de la disposition du conteneur et du positionnement enfant. Cette divergence doit être intentionnelle et testée.

Valider explicitement le comportement de l’onglet. La grille, la table et les dispositions similaires sont des sources courantes d’incompatibilité entre l’ordre de lecture perçu et l’ordre de focus. Testez les chemins d’interaction clavier uniquement et tactile pour garantir que la traversée reste efficace et prévisible.

Pour aligner la traversée avec le flux visuel, vous pouvez restructurer XAML ou affecter explicitement TabIndex. L’exemple suivant utilise une grille avec un séquencement de tabulation par colonne d'abord.

<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>

Dans certains scénarios, un élément doit être exclu du parcours par tabulation. L’approche standard consiste à définir IsEnabled sur false, ce qui désactive également l’interaction. Les contrôles désactivés sont automatiquement supprimés de l’ordre de tabulation.

Si un élément reste interactif via d’autres mécanismes, mais qu’il ne doit pas être atteint avec Tab, définissez IsTabStop sur false.

La plupart des contrôles compatibles focus sont inclus dans l’ordre de tabulation par défaut. Une exception courante concerne les contrôles d'affichage de texte tels que RichTextBlock, qui peuvent prendre en charge le focus pour les opérations de sélection de texte et de presse-papiers, mais ne sont généralement pas des points de tabulation, car ils n'acceptent pas l'invocation de commandes. Ces contrôles peuvent toujours être découverts par des technologies d’assistance par le biais d’une sémantique d’automatisation telle que le modèle de contrôle de texte.

Que vous utilisiez la traversée par défaut ou une tabIndex explicite, les règles suivantes s’appliquent :

• Si TabIndex n’est pas défini sur un élément, la valeur par défaut est Int32.MaxValue et l’ordre est basé sur l’ordre de déclaration/insertion.
• Si TabIndex est défini sur un élément :
  • Les éléments avec TabIndex égal à 0 sont ajoutés en fonction de l’ordre de déclaration/insertion.
  • Les éléments avec TabIndex supérieur à 0 sont ajoutés dans l’ordre TabIndex croissant.
  • Les éléments avec TabIndex inférieurs à 0 sont ajoutés avant les éléments avec zéro valeur.

L’extrait de code suivant montre les paramètres TabIndex mixtes (B utilise Int32.MaxValue ou 2 147 483 647).

<StackPanel Background="#333">
  <StackPanel Background="#FF33FF">
    <Button>A</Button>
    <Button TabIndex="2147483647">B</Button>
    <Button>C</Button>
  </StackPanel>
  <StackPanel Background="#33FFFF">
    <Button TabIndex="1">D</Button>
    <Button TabIndex="1">E</Button>
    <Button TabIndex="0">F</Button>
  </StackPanel>
</StackPanel>

Cela produit l’ordre de tabulation suivant :

1. F
2. D
3. E
4. A
5. B
6. C

Navigation au clavier entre les volets d’application avec F6

Un volet d’application est une région de tâches importante à l’intérieur d’une fenêtre. Dans Microsoft Edge, par exemple, les volets incluent la barre d’adresses, la barre de signets, la bande d’onglets et la zone de contenu. F6 est couramment utilisé pour faire passer le focus entre ces panneaux avec des éléments enfants accessibles à l’aide de la navigation au clavier standard.

Bien qu’un modèle de navigation au clavier conforme soit la base de référence, un modèle de navigation au clavier utilisable inclut généralement :

• Écoutez F6 pour passer d’une région d’interface utilisateur à l’autre.
• Fournir des raccourcis clavier pour les commandes fréquentes.
• Fournir des clés d’accès pour les contrôles importants.

Consultez les raccourcis clavier et les touches d’accès pour obtenir des conseils d’implémentation.

Optimiser pour F6

F6 réduit considérablement le coût de navigation en permettant aux utilisateurs de passer entre les régions principales plutôt que de naviguer à travers chaque contrôle enfant.

Par exemple, F6 dans Microsoft Edge alterne entre la barre d’adresses, la barre de signets, la barre d’onglets et le contenu. Étant donné qu’une page peut contenir de nombreux taquets de tabulation, les tâches de navigation courantes deviennent beaucoup plus efficaces.

La séquence F6 peut s’aligner sur des repères ou des en-têtes, mais elle n’a pas besoin de correspondre exactement. Utilisez F6 pour un mouvement de niveau régional étendu et des repères/en-têtes pour la structure sémantique au sein et entre les régions.

Important

Vous devez implémenter explicitement la navigation F6 dans votre application ; elle n’est pas fournie automatiquement.

Dans la mesure du possible, chaque région cible F6 doit avoir un nom accessible clair, à partir de la sémantique de repère ou en définissant AutomationProperties.Name sur la racine de la région.

Maj+F6 doit parcourir le même cycle dans l’ordre inverse.

Navigation au clavier dans un élément d’interface utilisateur

Les contrôles composites doivent fournir une navigation interne prévisible entre les éléments enfants. Un modèle courant consiste à conserver la racine composite dans l'ordre de tabulation et à gérer les descendants actifs en interne, plutôt que d’exposer chaque enfant comme une position de tabulation distincte.

De nombreux contrôles intégrés implémentent déjà ce comportement. Par exemple, la traversée de touches de direction est disponible par défaut pour ListView, GridView, ListBox et FlipView.

Alternatives au clavier aux actions et événements de pointeur pour des éléments de contrôle spécifiques

Toute interface utilisateur pouvant être activée par le pointeur doit également être appelante par clavier. L’activation nécessite que l’élément ait le focus (seules les classes qui dérivent de Control prennent en charge le focus et la navigation par onglet).

Pour les contrôles qui peuvent être appelés, implémentez des gestionnaires d’événements clavier pour la barre d’espace et les touches Entrée. Cela fournit une parité de clavier de base avec des interactions de pointeur.

Si un élément n’est pas compatible avec le focus par défaut, utilisez un type de contrôle focusable ou implémentez un contrôle personnalisé avec un comportement de focus explicite. Dans ce cas, définissez IsTabStop sur true et fournissez un indicateur de focus visible.

Dans de nombreux cas, la composition est plus simple et plus robuste qu'un comportement uniquement basé sur des pointeurs. Par exemple, au lieu de gérer l’entrée de pointeur directement sur une image, placez-la à l’intérieur d’un bouton pour hériter de l’activation du clavier, de la gestion du focus et du comportement d’automatisation.

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

<!--Do this instead.-->
<Button Click="Button_Click"
        AutomationProperties.Name="Open profile photo">
  <Image Source="Assets/profile-photo.png"/>
</Button>

Raccourcis clavier

Outre la navigation et l’activation, implémentez un raccourci (combinaison de touches qui fournit un accès efficace aux fonctionnalités de l’application) pour des commandes importantes ou fréquemment utilisées avec des raccourcis clavier et des touchesd’accès.

Deux types courants de raccourci sont les suivants :

• Accélérateurs : appeler des commandes directement, avec ou sans contrôle visible correspondant.
• Touches d’accès : déplacez le focus vers des contrôles spécifiques dans votre interface utilisateur.

Faites toujours des raccourcis détectables pour les utilisateurs de technologie d’assistance. Communiquez-les via des info-bulles, des métadonnées d’automatisation, des éléments visibles de l'interface utilisateur et une documentation d’aide.

Pour exposer les métadonnées de raccourci aux technologies d’assistance, utilisez AutomationProperties.AccessKey pour les raccourcis mnemoniques et AutomationProperties.AcceleratorKey pour les raccourcis de commande. Étant donné que les lecteurs d’écran peuvent les présenter de manière similaire, documentez les raccourcis dans différents canaux.

L’exemple suivant montre comment documenter les touches de raccourci pour la lecture multimédia, la pause et les boutons d’arrêt.

<Grid>

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

  <MediaPlayerElement x:Name="DemoPlayer"
    Width="500" Height="300" Margin="20"
    HorizontalAlignment="Center"
    AutoPlay="False"
    AreTransportControlsEnabled="True" />

  <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="Ctrl+P"
      AutomationProperties.AccessKey="Alt+P">
      <Button.KeyboardAccelerators>
        <KeyboardAccelerator Modifiers="Control" Key="P"/>
      </Button.KeyboardAccelerators>
      <TextBlock>Play</TextBlock>
    </Button>

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

    <Button x:Name="StopButton" Click="MediaButton_Click"
      ToolTipService.ToolTip="Shortcut key: Ctrl+S"
      AutomationProperties.AcceleratorKey="Ctrl+S"
      AutomationProperties.AccessKey="Alt+S">
      <Button.KeyboardAccelerators>
        <KeyboardAccelerator Modifiers="Control" Key="S"/>
      </Button.KeyboardAccelerators>
      <TextBlock>Stop</TextBlock>
    </Button>
  </StackPanel>
</Grid>

Important

La définition d’AutomationProperties.AcceleratorKey ou AutomationProperties.AccessKey n’implémente pas le comportement du clavier. Ces propriétés exposent les métadonnées à UI Automation afin que les technologies d’assistance puissent annoncer les raccourcis attendus.

Le comportement du clavier doit toujours être implémenté dans le code. Utilisez des définitions KeyboardAccelerator déclaratives lorsque cela est possible et utilisez les gestionnaires KeyDown ou KeyUp où vous avez besoin d’une logique de routage personnalisée. Notez également que la mise en forme de soulignement pour les touches d'accès n’est pas automatique. Si vous souhaitez des soulignements mnémoniques visibles, affichez-les explicitement (par exemple, avec Soulignement).

Pour plus de concision, l’exemple omet des ressources de chaîne telles que « Ctrl+A ». En production, localisez le texte des raccourcis et validez les choix de mnémoniques pour chaque région, car la sélection des touches dépend souvent des étiquettes traduites.

Pour obtenir des conseils supplémentaires, consultez Les touches de raccourci dans les instructions d’interaction de l’expérience utilisateur Windows.

Implémentation d’un gestionnaire d’événements clés

L'entrée clavier utilise des événements routés. Les événements routés peuvent se propager des enfants vers un conteneur parent, permettant au parent de traiter des raccourcis pour plusieurs éléments descendants. Ce modèle d’événement est pratique pour définir des actions de touche de raccourci pour un contrôle qui contient plusieurs éléments enfants, dont aucun ne peut avoir le focus ou faire partie de l’ordre de tabulation.

Pour obtenir des exemples de code qui incluent des vérifications de touche de modification (par exemple, Ctrl), consultez interactions clavier.

Navigation au clavier pour les contrôles personnalisés

Pour les contrôles personnalisés, utilisez les touches fléchées lorsque les éléments enfants sont liés spatialement. Dans les scénarios d’arborescence où développer/réduire et activer sont des interactions distinctes, mapper les flèches gauche et droite pour développer/réduire le comportement. Pour les contrôles orientés, associez les touches directionnelles à l'orientation visuelle du contrôle.

Le comportement de clé personnalisée est généralement implémenté en remplaçant OnKeyDown et OnKeyUp.

Exemple d’état visuel pour un indicateur de focus

Tout contrôle personnalisé pouvant être mis au point doit exposer un indicateur clair de focus visuel. Un modèle courant utilise une superposition Rectangle qui démarre masquée via visibilité et s’affiche lorsque le focus entre.

Les contrôles XAML intégrés fournissent déjà des indicateurs de focus. L’apparence exacte peut varier avec les paramètres de thème, y compris le mode contraste élevé. Si vous modifiez le modèle des contrôles, conservez le même comportement de visibilité du focus.

L’exemple suivant est adapté à partir du modèle Button par défaut.

<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>

Pour activer la visibilité de l’indicateur de focus, utilisez VisualStateManager et VisualStateManager.VisualStateGroups sur la racine du modèle.

<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"/>
          </Storyboard>
        </VisualState>
        <VisualState x:Name="Unfocused" />
        <VisualState x:Name="PointerFocused" />
      </VisualStateGroup>
    </VisualStateManager.VisualStateGroups>

    <!--composition is here-->
  </Grid>
</ControlTemplate>

Un seul état dans ce groupe modifie explicitement le visuel de mise au point. Les autres états peuvent rester vides, car les transitions à l’intérieur du même VisualStateGroup annulent les animations d’état antérieures. Les événements de mise au point tels que GotFocus, combinés à GoToState, pilotent généralement ces transitions.

Accessibilité du clavier et appareils sans clavier matériel

Certains appareils s’appuient sur un panneau d’entrée réversible (SIP) au lieu d’un clavier matériel. Les lecteurs d'écran peuvent détecter que l'utilisateur scanne les touches et annoncent l'exploration des touches SIP de l'utilisateur, et de nombreux concepts d'accessibilité clavier s'appliquent toujours grâce à des gestes équivalents.

Par exemple, même sans touche Tab physique, Narrator prend en charge des gestes qui imitent l'effet de tabulation. Cela signifie que l’ordre de tabulation cohérent est toujours critique. Le Narrateur fournit également des équivalents de mouvement pour la navigation directionnelle dans les contrôles complexes (voir commandes clavier du Narrateur et mouvements tactiles).

Exemples

Ouvrez l’application galerie WinUI 3 et consultez la prise en charge de l’accessibilité du clavier en action

L’application Galerie WinUI 3 inclut des exemples interactifs de contrôles et de fonctionnalités WinUI. Obtenez l’application à partir du Microsoft Store ou parcourez le code source sur GitHub.

Rubriques connexes

• Présentation de l’accessibilité
• Interactions avec le clavier
• Exemple de clavier tactile (exemple hérité)
• Exemple d’accessibilité XAML (exemple hérité archivé)