Accessibilité des applications Windows — UI Automation et l'obligation d'aménagement raisonnable

« Un salarié malvoyant ne peut pas utiliser notre application cœur de saisie de commandes avec un lecteur d’écran. Il se sert sans peine d’un navigateur web et du courrier, mais dans notre application métier seule, les annonces ne fonctionnent pas. » Nous entendons ce type de question de plus en plus souvent de la part des services informatiques des clients.

Le point de départ pour résoudre ce problème est de regarder ce que vous dites à la technologie d’assistance, et non l’apparence de l’écran. Windows dispose de UI Automation (UIA), le mécanisme par lequel les lecteurs d’écran lisent les informations d’une application. Une fois le fonctionnement compris et les bases du nom, du clavier et de la couleur couvertes, l’utilisabilité d’une application métier s’améliore substantiellement.¹

Sur le plan juridique aussi, les applications Windows internes ne sont pas exemptées. L’amendement de 2021 à la loi sur l’élimination des discriminations à l’égard des personnes handicapées est entré en vigueur le 1er avril 2024, et les entreprises aussi sont désormais tenues de fournir des aménagements raisonnables. Le champ de l’emploi, comme dans l’exemple d’ouverture, relève plutôt de la loi sur la promotion de l’emploi des personnes handicapées et est une obligation d’employeur depuis avril 2016. Le chapitre 2 démêle cette différence.²³

L’accessibilité des applications de bureau Windows dispose de moins d’informations que le Web, et il n’existe pas de moyen de tout résoudre d’un coup après coup. Une grande part des améliorations nécessaires relève toutefois aussi la productivité de chaque utilisateur, avec ou sans handicap.

Cet article s’adresse aux développeurs d’applications métier japonaises et aux responsables informatiques. Il traite le cadre juridique et les normes ainsi que le fonctionnement de UIA, puis passe à l’implémentation dans WinForms/WPF, au fonctionnement au clavier, à la couleur et au contraste, à la vérification et à la façon de prioriser les corrections.

flowchart TB
    accTitle: Le flux de cet article
    accDescr: La structure de cet article, qui relie dans l'ordre le cadre juridique et les normes, le fonctionnement de UI Automation, l'implémentation dans WinForms et WPF, le fonctionnement au clavier, la couleur et le contraste, les outils de vérification, et la façon de fixer les priorités
    law["Cadre juridique et normes"] --> uia["Fonctionnement de UI Automation"]
    uia --> impl["Implémentation dans WinForms/WPF"]
    impl --> kb["Fonctionnement au clavier"]
    kb --> color["Couleur et contraste"]
    color --> verify["Outils de vérification"]
    verify --> prio["Façon de fixer les priorités"]

Figure 1 : Cet article relie le cadre juridique, le mécanisme, l’implémentation, la vérification et les priorités en un seul flux.

1. D’abord la conclusion

Trois points à retenir d’abord.

1. Séparez l’aménagement raisonnable individuel de l’aménagement préalable de l’environnement. L’aménagement raisonnable est un processus de réponse à une demande par le dialogue constructif, dans une mesure qui n’est pas une charge excessive. Les entreprises y sont tenues depuis avril 2024, et les employeurs dans le champ de l’emploi depuis avril 2016. Corriger une application à l’avance relève de l’« aménagement de l’environnement » (une obligation de moyens), ce qui est autre chose que de rendre chaque écran parfait dès le départ.²³
2. La fondation technique est d’exposer des informations à UIA, plus les bases du nom, du clavier et de la couleur. Le Name et le ControlType de l’arbre UIA, et des modèles tels que Invoke, Value et SelectionItem, sont le matériau de l’annonce et de l’opération. Le nommage vient en premier. WinForms le traite avec AccessibleName et l’association entre un Label et l’ordre de tabulation, WPF avec AutomationProperties.Name/LabeledBy ; vous mettez aussi en ordre le fonctionnement au clavier, un schéma de couleurs guidé par un rapport de contraste de 4,5:1, et des affichages qui ne s’appuient pas sur la couleur seule.¹⁴⁵⁶
3. Vérifiez et corrigez en partant du travail réel. Combinez FastPass dans Accessibility Insights avec des contrôles pratiques au lecteur d’écran, et parcourez dans cet ordre les écrans sur lesquels l’utilisateur s’appuie, puis les nouveaux écrans, puis les contrôles partagés. Les mêmes améliorations aident aussi les tests UI automatisés tels que FlaUI, qui reposent sur la même fondation UIA.⁷

Les critères techniques s’organisent autour de WCAG. JIS X 8341-3:2016 est une norme identique au même contenu que WCAG 2.0, et WCAG2ICT donne des orientations pour l’appliquer aux logiciels non Web. La section 2.2 entre dans le détail.⁸⁹

Si vous voulez lire selon votre objectif, partez du chapitre ci-dessous.

En une phrase, le support d’accessibilité consiste à « exposer les noms et les opérations corrects sur l’arbre UIA, et à tenir les bases du clavier et de la couleur ».

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (16 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. Le cadre juridique et les normes — ce que l’« obligation » a changé

2.1. La loi sur l’élimination des discriminations à l’égard des personnes handicapées — depuis avril 2024, les entreprises aussi doivent fournir des aménagements raisonnables

Cette section sépare trois questions : ce qui est devenu une obligation, où s’insèrent les corrections préalables, et quelle loi s’applique dans le champ de l’emploi.

L’aménagement raisonnable par les entreprises est passé d’une obligation de moyens à une obligation

La loi sur l’élimination des discriminations à l’égard des personnes handicapées interdit aux organes administratifs et aux entreprises le « traitement discriminatoire injuste » des personnes handicapées et leur demande de « fournir des aménagements raisonnables ». Avec l’amendement de 2021 (Reiwa 3), la fourniture d’aménagements raisonnables par les entreprises, jusqu’alors une obligation de moyens, est devenue une obligation, et l’amendement est entré en vigueur le 1er avril 2024 (Reiwa 6).²

Le prospectus du Cabinet Office l’explique comme une réponse, dans une mesure qui n’est pas une charge excessive, lorsqu’une personne handicapée exprime le souhait de faire lever une barrière. Parce que le détail diffère selon le type de handicap, la scène et la situation, le « dialogue constructif », dans lequel la personne et l’entreprise examinent ensemble les options, est important. Le prospectus indique explicitement que refuser unilatéralement le dialogue peut constituer une violation de l’obligation de fournir l’aménagement.²

Traitez les corrections préalables de l’application comme un « aménagement de l’environnement »

Ce n’est pas d’avoir tout en place à l’avance qui est devenu une obligation. Les mesures prises à l’avance pour un nombre indéterminé de personnes handicapées, telles que la révision des manuels, la formation et la mise en accessibilité des locaux, s’appellent « aménagement de l’environnement » et sont positionnées comme une obligation de moyens.²

Mettre une application métier dans un état utilisable par un lecteur d’écran à l’avance peut se regarder comme un effort de ce côté de l’aménagement de l’environnement. Plus cet aménagement a avancé, plus la charge de fournir un aménagement raisonnable individuel est légère.

Là où des salariés sont concernés, voyez la loi sur la promotion de l’emploi des personnes handicapées

L’emploi et le travail relèvent de la loi sur la promotion de l’emploi des personnes handicapées, non de la loi sur l’élimination des discriminations à l’égard des personnes handicapées. Le prospectus du Cabinet Office note aussi cette distinction.²

Sous la loi sur la promotion de l’emploi des personnes handicapées, l’amendement entré en vigueur en avril 2016 (Heisei 28) oblige les employeurs à s’abstenir de discrimination fondée sur le handicap dans l’emploi et à fournir des aménagements raisonnables dans une mesure qui n’est pas une charge excessive. La question d’ouverture, « un salarié ne peut pas utiliser l’application métier », est donc dans le domaine de l’obligation bien avant 2024.³

flowchart TB
    accTitle: Où s'insèrent l'aménagement raisonnable et l'aménagement de l'environnement
    accDescr: La relation entre une entreprise générale et une personne handicapée relève de la loi sur l'élimination des discriminations à l'égard des personnes handicapées, et fournir des aménagements raisonnables en répondant à une demande individuelle par le dialogue constructif est une obligation depuis avril 2024 ; le champ de l'emploi est une obligation d'employeur depuis avril 2016 sous la loi sur la promotion de l'emploi des personnes handicapées ; corriger une application à l'avance relève de l'aménagement de l'environnement, une obligation de moyens
    scene{"Quelle scène ?"} -->|Entreprise et une personne handicapée| kaisho["Loi sur l'élimination des discriminations à l'égard des personnes handicapées"]
    scene -->|Emploi et travail| koyou["Loi sur la promotion de l'emploi des personnes handicapées"]
    kaisho --> moushide["Répondre aux demandes individuelles par le dialogue constructif"]
    moushide --> hairyo["Fourniture d'aménagements raisonnables (obligation depuis avril 2024)"]
    koyou --> koyougimu["Fourniture d'aménagements raisonnables (obligation depuis avril 2016)"]
    kaisho -.-> kankyo["Corrections préalables de l'application = aménagement de l'environnement (obligation de moyens)"]
    kankyo -.-> moushide

Figure 2 : La loi applicable dépend de la scène ; l’aménagement raisonnable est une obligation, et les corrections préalables relèvent de l’aménagement de l’environnement, une obligation de moyens.

Le traitement juridique d’un cas individuel dépend de la situation. Cet article n’entre pas dans l’interprétation juridique ; il part du point de vue de ce qu’un ingénieur peut faire lorsqu’on lui demande de répondre. Pour les sources primaires, voir les documents du Cabinet Office et du ministère de la Santé, du Travail et des Affaires sociales.²³

2.2. JIS X 8341-3 et WCAG — les « critères du Web » s’étendent aussi aux logiciels

Lorsque vous lisez les critères techniques en détail, les organiser autour de WCAG donne la vue la plus claire. JIS X 8341-3:2016, WCAG et WCAG2ICT se relient comme suit.⁸⁶⁹

À la question « WCAG n’est-elle pas une norme pour le contenu Web ? », WCAG2ICT est le pont. Son nom complet est Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies.⁹

Des idées telles que les alternatives textuelles, le contraste, le fonctionnement au clavier et le fait de ne pas transmettre l’information par la couleur seule s’appliquent à une application de bureau Windows dans le même cadre. À partir du chapitre 3, cet article les traduit en implémentation WinForms/WPF.

flowchart TB
    accTitle: La relation entre JIS X 8341-3 et WCAG
    accDescr: JIS X 8341-3:2016 est une norme identique au même contenu que WCAG 2.0, et WCAG2ICT montre comment appliquer les critères de succès WCAG aux logiciels non Web, de sorte qu'une application de bureau Windows peut être inspectée dans le même cadre
    wcag["WCAG 2.0 (W3C)"] ---|Norme identique au même contenu| jis["JIS X 8341-3:2016"]
    wcag --> ict["WCAG2ICT"]
    ict --> soft["Appliqué aux logiciels non Web"]
    soft --> app["Applications de bureau Windows"]

Figure 3 : JIS X 8341-3:2016 est une norme identique de WCAG 2.0, et WCAG2ICT étend les mêmes critères aux applications de bureau.

3. Comment la technologie d’assistance lit une application — le trio de UI Automation

3.1. L’arbre UIA, les propriétés et les modèles de contrôle

UI Automation (UIA), intégrée à Windows, est la fondation d’accessibilité qui médie entre l’application et la technologie d’assistance. L’application expose les informations d’interface en tant que « fournisseur », et la technologie d’assistance telle qu’un lecteur d’écran les obtient en tant que « client ». L’opération de l’interface par des moyens autres que la saisie standard est aussi rendue possible par ce mécanisme.¹

Commencez par le comprendre comme un trio : la structure de l’écran, la nature de chaque élément, et les opérations disponibles.¹

Par exemple, l’annonce « Confirmer la commande, bouton » lorsqu’un bouton reçoit le focus est grosso modo la combinaison de Name et du type de contrôle. Lorsque l’utilisateur donne une commande d’exécution, la technologie d’assistance appuie sur le bouton à travers le modèle Invoke.

Autrement dit, qu’un bouton soit dessiné à l’écran et qu’un bouton soit lisible et opérable par la technologie d’assistance sont deux choses distinctes. Si Name et les modèles ne sont pas exposés correctement, le bouton pourrait aussi bien ne pas exister, même s’il est visible à l’écran.

flowchart TB
    accTitle: Le trio de UI Automation
    accDescr: L'application, en tant que fournisseur, expose les propriétés et les modèles de contrôle de chaque élément sur l'arbre UIA ; le lecteur d'écran, en tant que client, annonce Name et ControlType et opère à travers des modèles tels que Invoke
    app["Application (fournisseur)"] --> tree["Arbre UIA"]
    tree --> prop["Propriétés (Name, ControlType, etc.)"]
    tree --> pat["Modèles (Invoke, Value, etc.)"]
    sr["Lecteur d'écran (client)"] -->|Annonce| prop
    sr -->|Opère| pat

Figure 4 : Le lecteur d’écran utilise les propriétés et les modèles que l’application a exposés sur l’arbre UIA pour l’annonce et l’opération.

3.2. Un lecteur d’écran est un client UIA

Les principaux lecteurs d’écran sous Windows sont Narrator intégré, NVDA libre et open source,¹⁰ et PC-Talker, un produit commercial largement utilisé au Japon.

Chacun a son propre style d’annonce, mais le chemin principal pour lire l’interface d’une application de bureau est UIA dans tous les cas. Le travail côté application se ramène donc à exposer des informations correctes à UIA, plutôt qu’à viser un lecteur d’écran particulier.

flowchart TB
    accTitle: Le chemin commun des principaux lecteurs d'écran
    accDescr: Si l'application expose des informations correctes à UIA, Narrator, NVDA et PC-Talker peuvent tous lire l'interface par le même chemin, le travail côté application ne vise donc pas un lecteur d'écran particulier mais se ramène à exposer à UIA
    app["Application"] -->|Expose des informations| uia["UI Automation (UIA)"]
    uia --> nar["Narrator"]
    uia --> nvda["NVDA"]
    uia --> pct["PC-Talker"]
    app -.-> goal["Le travail se ramène à exposer à UIA"]

Figure 5 : Les principaux lecteurs d’écran passent tous par UIA, le travail de l’application se ramène donc à exposer à UIA.

3.3. Comment un « bouton dont Name est vide » est-il annoncé ?

Supposez qu’une barre d’outils a un bouton Enregistrer qui n’affiche qu’une icône de disquette. Même si l’objet est clair visuellement, si Name reste vide le lecteur d’écran n’annonce rien de plus que « bouton ». Si les « Ouvrir » et « Imprimer » voisins sont dans le même état, l’utilisateur n’entend que « bouton, bouton, bouton » et ne peut pas les distinguer.

Les boutons sans Name et les images annoncées seulement comme « Image » figurent dans les guides de correction de Microsoft comme des problèmes typiques qui arrêtent le travail de l’utilisateur.⁵

Les contrôles WinForms/WPF standard prennent en charge UIA dès le départ, et pour la plupart Name est dérivé automatiquement du texte ou d’une étiquette. Les trois façons typiques dont cela casse sont les suivantes.

Les deux chapitres suivants relient ce triage aux corrections pour WinForms et WPF respectivement.

flowchart TB
    accTitle: Trois façons typiques dont l'annonce casse
    accDescr: L'annonce casse lorsqu'il n'y a pas de matériau pour un nom parce que le contrôle n'est qu'une icône, lorsqu'il n'y a pas d'association avec une étiquette, ou lorsqu'un dessin personnalisé ne met aucune information sur l'arbre UIA, et le contrôle finit annoncé seulement comme bouton
    c1["Icône seulement, pas de matériau"] --> broken["Name finit vide"]
    c2["Pas d'association d'étiquette"] --> broken
    c3["Le dessin personnalisé n'expose rien"] --> broken
    broken --> result["Annoncé seulement comme bouton"]

Figure 6 : Les annonces cassées se ramènent en général à trois schémas : matériau manquant pour un nom, association manquante, ou dessin personnalisé.

4. Implémentation dans WinForms — AccessibleName et ordre de tabulation

4.1. Les contrôles dont Text devient Name automatiquement, et ceux dont Text ne le devient pas

D’abord, vérifier si le contrôle est d’une sorte dont Text est utilisé comme nom

Dans WinForms, même parmi les contrôles qui affichent du texte, certains utilisent Text comme Name UIA et d’autres non.⁴

Utiliser une étiquette d’affichage, et définir AccessibleName là où vous ne pouvez pas en placer une

L’approche la plus facile à maintenir est de placer un Label descriptif immédiatement avant le contrôle cible dans l’ordre de tabulation. Si le TabIndex du contrôle cible vient directement après le TabIndex du Label, le texte du Label est utilisé comme Name UIA. L’affichage et l’annonce concordent, et vous évitez de maintenir la formulation deux fois.⁴¹¹

Là où vous ne pouvez pas placer un Label, définissez AccessibleName explicitement. Vous pouvez aussi définir AccessibleDescription pour des informations complémentaires, et AccessibleRole lorsque le rôle doit correspondre à ce que le contrôle fait réellement.¹²

flowchart TB
    accTitle: Comment le nom d'un contrôle WinForms est décidé
    accDescr: Pour Button et les contrôles similaires, Text devient le Name UIA tel quel ; pour les contrôles tels que TextBox dont Text n'est pas réutilisé, le texte d'un Label placé immédiatement avant dans l'ordre de tabulation est utilisé ; là où un Label ne peut pas être placé, AccessibleName est défini explicitement
    ctrl["Contrôle"] --> qtext{"Text devient Name ?"}
    qtext -->|Oui| usetext["Text est utilisé comme Name tel quel"]
    qtext -->|Non| qlabel{"Label immédiatement avant dans l'ordre de tabulation ?"}
    qlabel -->|Oui| uselabel["Le texte du Label est utilisé comme Name"]
    qlabel -->|Non| explicit["Définir AccessibleName explicitement"]

Figure 7 : Un Name WinForms se décide dans l’ordre Text, le Label immédiatement avant dans l’ordre de tabulation, puis AccessibleName.

// Bouton de barre d'outils icône seulement : définir le nom pour l'annonce explicitement
saveToolStripButton.AccessibleName = "Enregistrer";

// Bouton image seulement : nom plus description complémentaire
btnSearchCustomer.AccessibleName = "Rechercher des clients";
btnSearchCustomer.AccessibleDescription = "Recherche dans le fichier clients par code client ou nom";

// Champ de saisie où un Label ne peut pas être placé immédiatement avant dans l'ordre de tabulation : le définir directement
txtOrderNo.AccessibleName = "Numéro de commande";

// PictureBox réutilisé comme graphique : faire correspondre le rôle à ce qu'il est réellement
pictureBoxChart.AccessibleRole = AccessibleRole.Chart;
pictureBoxChart.AccessibleName = "Graphique du nombre de commandes par mois";

Lorsque vous avez effacé le nom mais que l’annonce par défaut ne revient pas

Si vous définissez AccessibleName une fois dans le volet Propriétés de Visual Studio puis l’effacez, un paramètre avec une chaîne vide peut rester dans le fichier designer. Si ce paramètre bloque la résolution de nom par défaut, supprimez la ligne du fichier designer.⁴

flowchart TB
    accTitle: Le problème d'un AccessibleName chaîne vide qui reste
    accDescr: Si vous définissez AccessibleName une fois dans le volet Propriétés puis l'effacez, un paramètre chaîne vide reste dans le fichier designer et bloque la résolution de nom par défaut, vous le corrigez en supprimant la ligne du fichier designer
    set["Définir AccessibleName"] --> erase["L'effacer dans le volet Propriétés"]
    erase --> remain["Un paramètre chaîne vide reste"]
    remain --> block["Bloque la résolution de nom par défaut"]
    block -.-> fix["Supprimer la ligne du fichier designer"]

Figure 8 : Effacer la valeur dans le volet Propriétés laisse une chaîne vide, corrigez-le en supprimant la ligne du fichier designer.

4.2. Améliorations fréquentes sur un écran de saisie de commandes

Voici une liste de contrôle des endroits que nous corrigeons le plus souvent dans les applications métier.

Chacune est une correction de quelques lignes, mais pour un utilisateur de lecteur d’écran c’est la différence entre un écran qu’il ne peut pas utiliser et un qu’il peut.

5. Implémentation dans WPF — AutomationProperties et AutomationPeer

5.1. AutomationProperties.Name / LabeledBy / HelpText

Donner à un bouton son nom par un Content chaîne ou un paramètre explicite

Dans un contrôle dont le Content est une chaîne, tel qu’un Button WPF, ce contenu est utilisé comme Name UIA. Un bouton qui ne contient qu’un Image ou un Path, en revanche, n’a pas de matériau pour un nom. Soit vous le définissez explicitement avec AutomationProperties.Name, soit, s’il y a du texte d’affichage à proximité, vous l’associez avec AutomationProperties.LabeledBy.⁵

Dans une TextBox, séparer le « nom » de la « valeur saisie »

Le Text d’un TextBlock est réutilisé comme Name, mais le Text d’une TextBox est exposé sur la propriété Value de UIA et ne devient pas Name. Même lorsque le champ contient une valeur, cela ne dit pas à lui seul à l’utilisateur à quoi sert le champ.¹³

Pour un champ de saisie, le premier choix est d’associer le TextBlock d’étiquette d’affichage via LabeledBy. L’affichage et l’annonce concordent, et vous évitez de maintenir la formulation deux fois.¹³

<!-- Champ de saisie : associer l'étiquette d'affichage via LabeledBy -->
<TextBlock x:Name="OrderNoLabel" Text="Numéro de commande" />
<TextBox
    AutomationProperties.LabeledBy="{Binding ElementName=OrderNoLabel}"
    AutomationProperties.AutomationId="OrderNoTextBox" />

<!-- Bouton icône seulement : définir le nom explicitement et ajouter un complément si besoin -->
<Button
    AutomationProperties.Name="Confirmer la commande"
    AutomationProperties.HelpText="Confirme la commande en cours de saisie et alloue le stock">
    <Path Data="{StaticResource CheckIconGeometry}" Width="16" Height="16" />
</Button>

flowchart TB
    accTitle: Comment le nom d'un contrôle WPF est décidé
    accDescr: Un contrôle dont le Content est une chaîne utilise ce contenu comme Name ; sinon le premier choix est d'associer une étiquette d'affichage proche via LabeledBy, et s'il n'y en a pas, AutomationProperties.Name est défini explicitement ; le Text d'une TextBox est exposé comme Value, non comme Name
    ctrl["Contrôle"] --> qc{"Le Content est une chaîne ?"}
    qc -->|Oui| auto["Le contenu devient Name"]
    qc -->|Non| ql{"Étiquette d'affichage à proximité ?"}
    ql -->|Oui| lb["Associer via LabeledBy"]
    ql -->|Non| nm["Définir Name explicitement"]
    tbx["Text de TextBox"] -.-> val["Exposé comme Value, non comme Name"]

Figure 9 : Un Name WPF se décide dans l’ordre Content chaîne, LabeledBy, puis un paramètre explicite ; le Text d’une TextBox ne devient pas Name.

HelpText et AutomationId jouent des rôles différents du nom

Les informations complémentaires qui ne tiennent pas dans Name sont exposées via AutomationProperties.HelpText.⁵ AutomationId est un identifiant aussi utilisé pour localiser des éléments dans les tests UI automatisés. Décider d’une convention de nommage au stade de la conception d’écran paie dans les tests ultérieurs.

En bref, Name est l’objet, HelpText le complément, et AutomationId l’identifiant. Leur usage dans les tests automatisés est détaillé dans « Tests UI automatisés pour applications de bureau Windows ».

5.2. Les contrôles personnalisés ont besoin d’un AutomationPeer

Un contrôle dessiné sur mesure ne peut pas, à lui seul, exposer des informations significatives sur l’arbre UIA. Dans WPF, vous exposez le nom, la sorte et les modèles en surchargeant OnCreateAutomationPeer sur une classe dérivée de UIElement et en renvoyant une classe dérivée de AutomationPeer.¹⁴

Si vous héritez d’un contrôle existant, héritez aussi du Peer correspondant. Pour ButtonBase, par exemple, utiliser ButtonBaseAutomationPeer permet de reprendre le comportement déjà implémenté.¹⁴

flowchart TB
    accTitle: Comment AutomationPeer expose les informations
    accDescr: Un contrôle personnalisé expose le nom, la sorte et les modèles en surchargeant OnCreateAutomationPeer et en renvoyant une classe dérivée de AutomationPeer ; s'il hérite d'un contrôle existant, il hérite du Peer correspondant et reprend le comportement déjà implémenté
    custom["Contrôle personnalisé"] --> ov["OnCreateAutomationPeer"]
    ov --> peer["Renvoyer une classe dérivée de Peer"]
    peer --> pub["Exposer le nom, la sorte et les modèles"]
    inherit["Hérite d'un contrôle existant"] -.-> basepeer["Hériter du Peer correspondant"]
    basepeer -.-> reuse["Reprendre le comportement implémenté"]

Figure 10 : Un contrôle personnalisé renvoie un Peer depuis OnCreateAutomationPeer pour exposer des informations à UIA.

// Exemple d'un contrôle qui dessine sur mesure l'état de la ligne comme une lampe colorée
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 ? "État de la ligne : en ligne" : "État de la ligne : hors ligne";

    private static void OnIsOnlineChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        // Déclencher l'événement de changement de propriété UIA au moment où la valeur change. Sans lui,
        // le lecteur d'écran conserve l'ancien nom et ne remarque jamais le changement d'état
        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 convient à un affichage d'état sans opérations

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

Signaler les changements d’état, pas seulement le nom actuel

L’exemple ci-dessus combine deux choses : renvoyer un nom qui reflète l’état actuel, et déclencher un événement de changement de propriété Name lorsque IsOnline change.

Le travail du Peer n’est pas seulement de renvoyer le nom, mais aussi de signaler le changement par un événement au moment où il se produit. La technologie d’assistance n’a pas de moment propre pour redemander une valeur ; sans l’événement, l’implémentation n’est « correcte que lorsqu’on redemande », et les utilisateurs de lecteur d’écran n’apprennent jamais que l’état a changé.

sequenceDiagram
    accTitle: Comment un changement d'état atteint le lecteur d'écran
    accDescr: Au moment où la valeur du contrôle change, l'AutomationPeer déclenche un événement de changement de propriété Name ; la technologie d'assistance ne redemande pas d'elle-même, sans l'événement elle conserve l'ancien nom et ne remarque jamais le changement
    participant c as Contrôle
    participant p as AutomationPeer
    participant s as Lecteur d'écran
    c->>p: La valeur IsOnline change
    p->>s: Déclenche un événement de changement de propriété Name
    s->>s: Annonce le nouvel état
    Note over s: Sans l'événement, l'ancien nom reste

Figure 11 : Un changement de valeur n’atteint le lecteur d’écran que lorsque l’AutomationPeer le signale par un événement de changement.

Si le contrôle a des opérations, implémenter les modèles et les placer dans des composants partagés

Pour les contrôles personnalisés que l’on peut enfoncer, qui ont une valeur modifiable, ou que l’on peut sélectionner, surchargez GetPattern et fournissez des interfaces de modèle telles que IInvokeProvider et IRangeValueProvider.¹⁴

Si vous construisez le Peer dans la bibliothèque de contrôles partagés, chaque écran qui l’utilise devient conforme automatiquement. C’est la fondation du déploiement décrit au chapitre 9.

6. Chaque fonction est-elle atteignable depuis le clavier seul ?

Le critère de succès WCAG 2.1.1 (Clavier) exige que toute la fonctionnalité soit opérable à travers une interface clavier.⁶ Les utilisateurs de lecteur d’écran n’utilisent en général pas de souris, une fonction qui ne peut pas être atteinte depuis le clavier est donc la même qu’une fonction qui n’existe pas.

6.1. Vérifier le déplacement, l’exécution et la position actuelle

Vérifiez non seulement l’ordre de tabulation, mais aussi que les opérations principales peuvent être exécutées et que le focus actuel est visible.

Le guide d’accessibilité WinForms cite aussi, comme bases, le placement d’une étiquette immédiatement avant un champ de saisie dans l’ordre de tabulation et l’attribution de touches d’accès aux contrôles et menus vers lesquels l’utilisateur veut se déplacer.¹¹

6.2. Le travail clavier améliore aussi l’efficacité de saisie de chaque utilisateur

Ce n’est pas seulement « un coût supplémentaire pour soutenir les personnes handicapées ». Dans un travail de routine tel que la saisie de commandes, le fait que l’opérateur puisse achever la saisie sans quitter la position de repos décide du nombre d’opérations qu’il mène à bien.

Un ordre de tabulation brouillé ou une opération qui exige la souris est un défaut qui entame un peu chaque jour la productivité de chaque utilisateur. Le travail d’accessibilité et l’efficacité clavier sont deux noms pour le même travail. Pour les priorités selon l’environnement d’utilisation, voir aussi « Conception UX des applications Windows ».

flowchart TB
    accTitle: Le double effet du travail clavier
    accDescr: Mettre en ordre l'ordre de tabulation, les touches d'accès et l'indication de focus produit deux effets à la fois, que les utilisateurs de technologie d'assistance puissent atteindre les fonctions et la vitesse de saisie de chaque opérateur, tandis qu'une fonction utilisable seulement à la souris est la même qu'une fonction qui n'existe pas
    seibi["Fonctionnement au clavier mis en ordre"] --> a11y["Les utilisateurs de technologie d'assistance peuvent travailler"]
    seibi --> speed["Vitesse de saisie de chaque opérateur"]
    mouse["Fonctions souris seulement"] -.-> none["Équivalent à des fonctions inexistantes"]

Figure 12 : Le travail clavier apporte à la fois le support de la technologie d’assistance et l’efficacité pour chaque utilisateur ; une fonction souris seulement équivaut à une fonction inexistante.

7. Couleur et contraste — 4,5:1 et « pas par la couleur seule »

7.1. Le guide du rapport de contraste est 4,5:1

Le critère de succès WCAG 1.4.3 (Contraste (minimum)) exige un rapport de contraste d’au moins 4,5:1 pour le texte et les images de texte, et d’au moins 3:1 pour le grand texte.⁶

Les conceptions qui placent du texte gris clair sur un fond blanc manquent ce critère plus souvent qu’on ne le croit. Gardez à l’esprit les personnes dont la vision et la perception des couleurs ont changé avec l’âge et les personnes qui travaillent dans des lieux mal éclairés tels que des usines, et prenez l’habitude de mesurer avec un vérificateur de contraste lors de la revue de conception.

7.2. Ne transmettez pas l’information par la couleur seule

Le critère de succès 1.4.1 (Utilisation de la couleur) dit que la couleur ne doit pas être le seul moyen visuel de transmettre une information.⁶ Les cas typiques dans les applications métier sont les suivants.

Compte tenu de la diversité de la vision des couleurs, cela aussi est une base de la conception d’affichage plutôt qu’une « mesure spéciale ».

flowchart TB
    accTitle: Remplacer l'information transmise par la couleur seule
    accDescr: Un affichage qui montre les erreurs seulement en texte rouge est remplacé par une icône d'erreur et une colonne de message à côté, un affichage qui montre les champs obligatoires seulement par la couleur de l'étiquette reçoit un marqueur Obligatoire, et un affichage qui montre l'état seulement par la couleur de lampe est remplacé par une forme ou un texte à côté de la couleur
    err["Erreurs en texte rouge seulement"] --> erra["Ajouter une icône et une formulation"]
    req["Obligatoire par la couleur d'étiquette seulement"] --> reqa["Ajouter un marqueur Obligatoire"]
    lamp["État par la couleur de lampe seulement"] --> lampa["Combiner la couleur avec une forme ou un texte"]

Figure 13 : Remplacez les indices typiques par la couleur seule par une icône, un marqueur, ou une forme et un texte à côté de la couleur.

7.3. Suivre les thèmes de contraste (contraste élevé)

Les thèmes de contraste Windows (anciennement contraste élevé) sont des schémas de couleurs qui séparent fortement premier plan et arrière-plan. Les thèmes intégrés sont conçus pour un rapport de contraste d’environ 7:1 ou plus, et les utilisateurs peuvent les sélectionner et les modifier.¹⁵

Côté application, ne codez pas les couleurs en dur ; respectez les couleurs système. Ce qu’il faut faire dans chaque infrastructure suit.

Pour les paramètres WinForms concrets, voir le guide de Microsoft, et pour les couleurs de thème, la documentation des thèmes de contraste.¹¹¹⁵

flowchart TB
    accTitle: Suivre les thèmes de contraste
    accDescr: Les endroits où les couleurs sont codées en dur cassent lors d'un basculement vers un thème de contraste, basculez donc vers un schéma fondé sur SystemColors et suivez via l'événement de changement de paramètres ; si vous référencez les couleurs système, l'interface suit les couleurs de l'utilisateur automatiquement
    theme["Basculer vers un thème de contraste"] --> qh{"Comment les couleurs sont-elles spécifiées ?"}
    qh -->|Codées en dur| broken["Le schéma de couleurs casse"]
    qh -->|Références aux couleurs système| ok["Suit les couleurs de l'utilisateur automatiquement"]
    broken -.-> fix["Basculer vers SystemColors"]
    fix -.-> ev["Suivre via l'événement de changement de paramètres"]

Figure 14 : Seules les couleurs codées en dur cassent sous un thème de contraste ; les références aux couleurs système suivent automatiquement.

Inclure la survie au haut DPI dans le même contrôle

Les utilisateurs malvoyants travaillent souvent avec un facteur d’échelle OS élevé (mise à l’échelle DPI), le support du haut DPI fait donc aussi partie de l’accessibilité. Une application dont la disposition casse de 125 % à 200 % est inutilisable dans cet environnement.

Pour le détail, voir « La prise en charge du haut DPI dans WinForms » et « Le support du haut DPI dans WPF ».

8. La vérification en pratique — Accessibility Insights et contrôles pratiques au lecteur d’écran

8.1. Accessibility Insights for Windows

Accessibility Insights for Windows de Microsoft offre trois façons de travailler, selon l’objectif.⁷

Inspect.exe et AccEvent, inclus dans le Windows SDK, peuvent aussi montrer l’arbre UIA et les propriétés, mais ils sont positionnés comme des outils hérités, et le passage à Accessibility Insights est désormais recommandé.⁷

flowchart TB
    accTitle: Les trois modes d'Accessibility Insights
    accDescr: Accessibility Insights for Windows fournit Live Inspect pour vérifier les propriétés UIA, FastPass pour un contrôle léger des problèmes à fort impact, et Troubleshooting pour aider à diagnostiquer et corriger les problèmes, et la migration depuis des outils hérités tels que Inspect.exe est recommandée
    ai["Accessibility Insights"] --> live["Live Inspect"]
    ai --> fast["FastPass"]
    ai --> ts["Troubleshooting"]
    live --> livef["Vérifier les propriétés UIA"]
    fast --> fastf["Détecter les problèmes à fort impact"]
    ts --> tsf["Aider à diagnostiquer et corriger"]
    legacy["Inspect.exe et autres"] -.->|Migration recommandée| ai

Figure 15 : Accessibility Insights a trois modes, vérifier, détecter et diagnostiquer, et est le remplacement recommandé des outils hérités.

8.2. Contrôles pratiques avec un lecteur d’écran

Passer un contrôle automatique et pouvoir achever un travail réel sont deux choses distinctes. Les outils ne peuvent détecter que les problèmes que l’on peut juger mécaniquement, terminez donc toujours en parcourant une opération métier avec un lecteur d’écran.

D’abord, démarrez Narrator avec Ctrl+touche Windows+Entrée, ou installez le NVDA gratuit.¹⁰ Ensuite, choisissez une tâche représentative telle que « saisir une commande et la confirmer », et essayez de l’achever par les annonces seules, sans regarder l’écran ou avec l’affichage éteint.

Des problèmes tels qu’un ordre d’annonce incohérent malgré des noms définis, ou un focus qui s’échappe hors d’une boîte de dialogue modale, ne se trouvent que par ce type de contrôle pratique.

flowchart TB
    accTitle: Combiner la vérification par outil et les contrôles pratiques
    accDescr: Un contrôle automatique tel que FastPass ne peut détecter que les problèmes que l'on peut juger mécaniquement ; pour le reste, parcourez des opérations métier réelles avec un lecteur d'écran et trouvez les problèmes d'ordre d'annonce et de focus sur le terrain
    tool["Contrôle automatique par outil"] --> kikai["Problèmes que l'on peut juger mécaniquement"]
    tool -.-> nokori["Des problèmes indétectables restent"]
    nokori --> sr["Contrôle pratique avec un lecteur d'écran"]
    sr --> task["Parcourir une opération métier"]
    task --> mieru["Problèmes d'ordre d'annonce et de focus"]

Figure 16 : Utilisez le contrôle automatique pour lister les problèmes mécaniques, et trouvez le reste par des contrôles pratiques au lecteur d’écran.

8.3. L’intégrer au flux de développement, et la synergie avec les tests UI automatisés

Pour que la vérification ne dépende pas de personnes particulières, nous recommandons d’ajouter la liste de contrôle suivante aux points de revue de chaque nouvel écran.

Réutiliser le travail UIA pour les tests automatisés

Les tests UI automatisés avec FlaUI et des outils similaires reposent sur la même UIA que les lecteurs d’écran. Le Name et les modèles que vous mettez en place pour l’accessibilité deviennent des briques pour le code de test, et l’AutomationId que vous avez conçu pour les tests facilite aussi le débogage dans Live Inspect.

Inversement, une interface qui n’apparaît pas dans l’arbre UIA est invisible aussi bien pour les tests que pour la technologie d’assistance. L’accessibilité et la testabilité sont les deux faces du même investissement. Pour le détail, voir « Tests UI automatisés pour applications de bureau Windows ».

flowchart TB
    accTitle: La synergie entre accessibilité et tests UI automatisés
    accDescr: Les lecteurs d'écran et les tests UI automatisés tels que FlaUI reposent sur la même UIA, le Name et les modèles que vous mettez en place peuvent donc être utilisés des deux côtés, et une interface qui n'apparaît pas dans l'arbre UIA est invisible pour les deux
    uia["Arbre UIA mis en ordre"] --> sr["Les lecteurs d'écran peuvent le lire"]
    uia --> test["Les tests UI automatisés peuvent l'utiliser"]
    sr -.-> both["Deux faces du même investissement"]
    test -.-> both
    hidden["Interface absente de UIA"] -.-> invisible["Invisible pour les deux"]

Figure 17 : Parce que les deux reposent sur la même fondation UIA, mettre l’arbre UIA en ordre aide à la fois la technologie d’assistance et les tests UI automatisés.

9. Comment prioriser — ne corrigez pas tous les écrans d’un coup

Refondre d’un coup un système cœur de plusieurs centaines d’écrans n’est réaliste ni en coût ni en qualité. Nous recommandons de procéder en trois étapes.

9.1. Commencer par les écrans sur lesquels cet utilisateur s’appuie au travail

L’aménagement raisonnable est un processus de réponse individuelle à la demande de la personne.² Faites d’abord opérer à la personne son travail réel avec un lecteur d’écran, et identifiez ensemble où elle bloque.

Dans la plupart des cas, les écrans utilisés au quotidien se réduisent à une poignée jusqu’à une dizaine. Les problèmes critiques parmi eux, tels que des boutons sans nom ou un bouton de confirmation que l’on ne peut pas enfoncer au clavier, se résolvent par des corrections mesurées en jours.

9.2. Rendre le nouveau développement conforme par défaut

Ajoutez la liste de contrôle du chapitre 8 à la Definition of Done. La ligne est que les nouveaux écrans sont construits conformes dès le départ. Contrairement au rattrapage, l’intégrer à la conception n’ajoute qu’un petit coût.

9.3. Déployer sur les écrans en corrigeant les contrôles partagés

Implémentez des valeurs par défaut AccessibleName et des AutomationPeer dans les boîtes de dialogue de recherche, grilles, saisies de date et analogues partagées en interne. Corrigez un composant partagé, et la correction prend effet d’un coup sur chaque écran qui l’utilise. C’est un geste plus rentable que de corriger les écrans un par un.

flowchart TB
    accTitle: Les trois étapes de priorisation des corrections
    accDescr: Commencez par les écrans sur lesquels l'utilisateur s'appuie au travail, rendez le nouveau développement conforme par défaut avec la liste de contrôle, et déployez sur chaque écran en corrigeant les contrôles partagés
    s1["1. Commencer par les écrans sur lesquels l'utilisateur s'appuie"] --> s2["2. Nouveau développement conforme par défaut"] --> s3["3. Déployer via les contrôles partagés"]
    s3 -.-> all["Prend effet d'un coup sur chaque écran qui les utilise"]

Figure 18 : Plutôt que de tout refondre d’un coup, procédez en trois étapes : les écrans utilisés, le nouveau développement, et les composants partagés.

9.4. Consigner le cours du dialogue, pas seulement les corrections

Aussi important que le travail technique est la trace du dialogue. L’aménagement raisonnable est un processus de discussion et d’ajustement au cas par cas, non d’exaucer pleinement chaque demande.

Pour les corrections qui seraient une charge excessive, envisager et convenir d’alternatives avec la personne, telles qu’effectuer la tâche sur un autre écran, fournir un export CSV, ou la couvrir par l’exploitation, est un aboutissement légitime du dialogue constructif.²

Consigner ce qui a été demandé, ce qui a été fait, et ce qui a été proposé comme alternative est ce qui démontre la bonne foi de l’organisation.

flowchart TB
    accTitle: Le flux du dialogue constructif et des traces
    accDescr: Répondre à une demande d'une personne handicapée par le dialogue constructif, réaliser les corrections possibles, pour les corrections qui seraient une charge excessive envisager et convenir d'une alternative avec la personne, et consigner ce qui a été demandé, ce qui a été fait, et ce qui a été proposé comme alternative
    req["Demande"] --> talk["Dialogue constructif"]
    talk --> q{"Charge excessive ?"}
    q -->|Non| kaishu["Répondre par une correction"]
    q -->|Oui| alt["Envisager et convenir d'une alternative"]
    kaishu --> rec["Consigner le cours des événements"]
    alt --> rec

Figure 19 : Dans le dialogue constructif, convenez avec la personne d’une correction ou d’une alternative, et gardez une trace de la façon dont cela s’est passé.

10. Synthèse

Séparer le cadre juridique, la technique et la démarche rend le point de départ visible.

Sur le plan juridique, l’aménagement raisonnable par les entreprises est une obligation depuis avril 2024, et par les employeurs dans le champ de l’emploi depuis 2016. Corriger une application à l’avance relève de l’« aménagement de l’environnement » (une obligation de moyens), et plus il a avancé, plus la réponse individuelle est légère. Consigner aussi le cours du dialogue.

Sur le plan technique, inspectez les applications de bureau autour de WCAG (JIS X 8341-3:2016) à travers WCAG2ICT. La fondation est l’arbre UIA, ses propriétés (Name/ControlType/AutomationId) et les modèles de contrôle. Le nommage, priorité la plus haute, se traite avec AccessibleName et Label plus ordre de tabulation dans WinForms, AutomationProperties.Name/LabeledBy dans WPF, et un AutomationPeer pour les contrôles personnalisés.

Par-dessus, mettez en ordre l’ordre de tabulation, les touches d’accès et l’indication de focus pour que chaque fonction soit atteignable depuis le clavier seul. Pour la couleur, prenez un rapport de contraste de 4,5:1 comme guide, ne vous appuyez pas sur la couleur seule, et respectez les couleurs système sous les thèmes de contraste. Ces améliorations relèvent aussi la productivité de chaque opérateur.

La démarche suit l’ordre écrans sur lesquels l’utilisateur s’appuie, nouveau développement conforme par défaut, et déploiement via les contrôles partagés. Combinez FastPass et Live Inspect dans Accessibility Insights avec des contrôles pratiques dans Narrator/NVDA, et intégrez-les au flux de développement comme liste de contrôle des nouveaux écrans.

Comme premier pas, nous recommandons de choisir un de vos écrans principaux, d’exécuter FastPass dans Accessibility Insights for Windows, puis de parcourir le travail avec la touche Tab seule. En 30 minutes, vous verrez, de façon étonnamment concrète, où en est votre application.

Articles connexes

• Tests UI automatisés pour applications de bureau Windows — le fonctionnement de UI Automation et la construction de tests robustes avec FlaUI
• Conception UX des applications Windows - Priorités selon l’environnement d’utilisation
• La prise en charge du haut DPI dans WinForms — pourquoi l’interface devient floue ou se casse sur les moniteurs 4K, et solutions concrètes
• Le support du haut DPI dans WPF — pourquoi l’affichage reste flou et baveux malgré une application « censée résister au DPI », et comment y remédier
• Pourquoi KomuraSoft crée des sites web avec le Design System de l’Agence numérique — coût réduit et haute qualité peuvent coexister
• Pièges des polices et des caractères japonais — Traiter JIS2004, IVS et les gaiji (caractères personnalisés EUDC) dans les applications métier

Domaines de conseil associés

KomuraSoft LLC prend en charge les corrections d’accessibilité des applications métier WinForms/WPF (support des lecteurs d’écran, fonctionnement au clavier, support des thèmes de contraste), l’implémentation d’AutomationPeer pour les contrôles partagés, et le diagnostic de l’état actuel et la priorisation avec Accessibility Insights. Commencer au stade « nous voulons vérifier si un salarié peut utiliser notre application avec un lecteur d’écran » convient parfaitement.

• Développement d’applications Windows
• Conseil technique et revue de conception
• Nous contacter

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Le support d'accessibilité d'une application métier est-il exigé par la loi ?

L'amendement de 2021 à la loi sur l'élimination des discriminations à l'égard des personnes handicapées est entré en vigueur le 1er avril 2024, et les entreprises aussi sont désormais tenues de fournir des aménagements raisonnables aux personnes handicapées. L'aménagement raisonnable consiste à lever une barrière individuelle, dans une mesure qui n'est pas une charge excessive, lorsqu'une personne handicapée en fait la demande ; rendre une application plus facile à utiliser à l'avance est positionné comme une obligation de moyens appelée aménagement de l'environnement. Le champ de l'emploi, telle la relation entre un salarié et l'entreprise, relève de la loi sur la promotion de l'emploi des personnes handicapées plutôt que de la loi antidiscrimination, et l'amendement entré en vigueur en avril 2016 y oblige les employeurs à fournir des aménagements raisonnables. Autrement dit, la situation où un salarié ne peut pas utiliser une application métier est dans le domaine de l'obligation depuis un certain temps. Ce qu'il faut prendre en charge et jusqu'où dépend de la situation individuelle : consultez les sources primaires du Cabinet Office et du ministère de la Santé, du Travail et des Affaires sociales, et décidez par le dialogue avec la personne concernée.

Comment un lecteur d'écran lit-il une application de bureau Windows ?

Les lecteurs d'écran tels que Narrator et NVDA lisent l'interface d'une application à travers une fondation d'accessibilité appelée UI Automation (UIA). L'application expose les éléments à l'écran dans une structure appelée arbre UIA, et chaque élément a des propriétés telles que Name (objet) et ControlType (sorte) ainsi que des modèles de contrôle tels que Invoke (appuyer) et Value (valeur). Le lecteur d'écran annonce ces informations comme « Confirmer la commande, bouton » et opère l'élément à travers les modèles. Les contrôles WinForms et WPF standard embarquent ce mécanisme, le travail principal du développeur est donc de ne pas laisser Name vide, de rendre l'interface opérable au clavier, et d'implémenter les informations sur les contrôles personnalisés.

Par où commencer sur une application WinForms existante ?

Le chemin le plus court est d'exécuter FastPass dans Accessibility Insights for Windows contre l'écran cible et de lister les contrôles dont Name est vide ainsi que les problèmes d'ordre de tabulation. Commencez les corrections par définir AccessibleName sur les boutons icône seulement, associer un Label en le plaçant immédiatement avant le champ de saisie dans l'ordre de tabulation, et ranger TabIndex pour qu'il corresponde à l'ordre visuel. Démarrez ensuite Narrator ou NVDA, parcourez une opération métier réelle sans regarder l'écran, et vérifiez où vous bloquez. Il n'est pas nécessaire de corriger tous les écrans d'un coup ; il est réaliste de partir des écrans que quelqu'un utilise réellement et de rendre les nouveaux écrans conformes dès le départ avec une liste de contrôle.

Que faut-il faire pour le contraste élevé (thèmes de contraste) ?

La règle de base est de respecter les couleurs système plutôt que de coder les couleurs en dur. Dans WinForms, laissez ForeColor/BackColor à leurs valeurs par défaut ou utilisez SystemColors, détectez l'état avec SystemInformation.HighContrast, et suivez un basculement par l'événement UserPreferenceChanged. Dans WPF et WinUI aussi, l'interface suit un basculement de thème automatiquement tant qu'elle référence les ressources de la famille SystemColors. En même temps, cessez de transmettre l'information par la couleur seule, par exemple montrer une erreur uniquement en rouge, et ajoutez une icône ou une formulation. Même sous le thème ordinaire, prendre le critère WCAG d'un rapport de contraste de texte d'au moins 4,5:1 comme guide rend l'interface plus lisible dans un atelier mal éclairé et pour les utilisateurs plus âgés.

Le travail d'accessibilité aide-t-il aussi les tests UI automatisés ?

Oui. Les outils de tests UI automatisés tels que FlaUI reposent sur la même UI Automation que les lecteurs d'écran. Le Name, le ControlType et les modèles de contrôle que vous mettez en place pour l'accessibilité peuvent être utilisés directement depuis le code de test, et un AutomationId conçu pour les tests stabilise l'identification des éléments. Inversement, une interface dessinée sur mesure qui n'apparaît pas dans l'arbre UIA est invisible aussi bien pour les lecteurs d'écran que pour les tests. L'accessibilité et les tests automatisés sont des investissements dans la même fondation, mettre l'un en place abaisse le coût de l'autre.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.