Introduction à l'accessibilité des applications Windows — se préparer à UI Automation et aux exigences d'aménagement raisonnable

« Un embauché en milieu de carrière qui est malvoyant ne peut pas utiliser l’application cœur de saisie de commandes avec un lecteur d’écran. Il utilise un navigateur web et le courrier sans problème, mais seule la lecture de notre application métier ne fonctionne pas correctement. Peut-on faire quelque chose ? » — Les consultations de ce type venant des services informatiques des clients ont augmenté.

Un arrière-plan est le cadre juridique. 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 la « fourniture d’aménagements raisonnables » aux personnes handicapées est devenue une obligation aussi pour les entreprises.¹ De plus, une relation salarié–entreprise telle que celle de l’ouverture (le champ de l’emploi) est le domaine de la loi sur la promotion de l’emploi des personnes handicapées, qui a obligé les employeurs à fournir des aménagements raisonnables depuis avril 2016.² L’idée que « l’accessibilité est un sujet de site web et n’a rien à voir avec les applications Windows internes » ne tient plus, ni juridiquement ni en pratique.

D’un autre côté, depuis le terrain de développement, « nous ne savons pas quoi faire » est un endroit honnête. L’accessibilité des applications de bureau Windows a moins d’informations que le Web, et il n’y a pas de solution magique après coup. Il n’y a pas non plus besoin d’être pessimiste. Si vous comprenez le mécanisme par lequel un lecteur d’écran lit une application (UI Automation) et intégrez les bases du nom, du clavier et de la couleur, l’utilisabilité d’une application métier s’améliore substantiellement. Et une grande part de cela est une amélioration qui relève la productivité de chaque utilisateur, avec ou sans handicap.

Destiné aux développeurs d’applications métier japonaises et au personnel informatique, cet article relie en une passe du tri minimum du cadre juridique et des normes, à travers le mécanisme de UI Automation, l’implémentation dans WinForms/WPF, le fonctionnement au clavier, la couleur et le contraste, et les outils de vérification, jusqu’à une façon réaliste de fixer les priorités.

flowchart TB
    accTitle: Le flux de cet article
    accDescr: La structure de cet article, reliant dans l'ordre du tri du cadre juridique et des normes à travers le mécanisme 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 comment fixer les priorités
    law["Trier le cadre juridique et les normes"] --> uia["Le mécanisme 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["Comment fixer les priorités"]

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

1. La conclusion, d’abord

• La fourniture d’aménagements raisonnables est une obligation aussi pour les entreprises depuis le 1er avril 2024. Lorsqu’une personne handicapée indique l’intention de faire lever une barrière, une réponse dans une mesure qui n’est pas une charge excessive est exigée. Le champ de l’emploi est sous la loi sur la promotion de l’emploi des personnes handicapées, et cela est une obligation d’employeur depuis avril 2016.¹²
• L’aménagement raisonnable est un processus de « répondre à une demande individuelle par un dialogue constructif » ; rendre l’application plus facile à utiliser à l’avance est l’« amélioration de l’environnement » (une obligation d’effort). Un support préalable parfait n’est pas l’obligation ; ce qui compte est de ne pas refuser unilatéralement le dialogue.¹
• Les critères techniques de l’accessibilité sont concentrés dans WCAG (JIS X 8341-3:2016). JIS X 8341-3:2016 est une norme correspondante au même contenu que WCAG 2.0, et WCAG2ICT du W3C donne des orientations pour l’appliquer aux logiciels non Web. Une application de bureau peut être inspectée avec la même pensée.³⁴
• Un lecteur d’écran lit une application à travers UI Automation (UIA). Les propriétés que chaque élément de l’arbre UIA détient — Name, ControlType et analogues — et les motifs de contrôle tels que Invoke, Value et SelectionItem sont le matériau de l’annonce et de l’opération.⁵
• Un bouton dont Name est vide n’est annoncé que comme « bouton ». La correction de plus haute priorité est le nommage. WinForms utilise AccessibleName et l’association d’un Label à l’ordre de tabulation ; WPF utilise AutomationProperties.Name/LabeledBy.⁶⁷
• Pouvoir atteindre chaque fonction depuis le clavier seul est un critère de succès WCAG (2.1.1) et, en même temps, la vitesse de saisie d’un opérateur expérimenté elle-même. Mettre en place l’ordre de tabulation, les touches d’accès et l’indication de focus se connecte directement à l’efficacité pour chaque utilisateur.⁸
• Prenez un ratio de contraste de texte de 4,5:1 ou plus comme guide, et ne transmettez pas l’information par la couleur seule. Dans un thème de contraste (contraste élevé), respectez les couleurs système plutôt que des couleurs codées en dur.⁸⁹
• Combinez la vérification avec FastPass dans Accessibility Insights for Windows et un contrôle pratique avec un lecteur d’écran. Parce qu’ils reposent sur la même fondation UIA, ce travail paie aussi mutuellement avec les actifs de tests UI automatisés tels que FlaUI.¹⁰
• Vous n’avez pas besoin de corriger tous les écrans d’un coup. L’ordre réaliste est (1) depuis les écrans que cet utilisateur utilise, (2) le nouveau développement est conforme, (3) déployer latéralement en corrigeant les contrôles partagés.

En une phrase : le support d’accessibilité est « exposer le nom et les opérations corrects sur l’arbre UIA, et garder les bases du clavier et de la couleur ».

2. Trier le cadre juridique et les normes — Ce que « est devenu une obligation » a changé

2.1. La loi sur l’élimination des discriminations à l’égard des personnes handicapées — À partir d’avril 2024, les entreprises aussi sont obligées de fournir des aménagements raisonnables

La loi sur l’élimination des discriminations à l’égard des personnes handicapées est une loi qui interdit le « traitement discriminatoire injuste » des personnes handicapées par les organes administratifs et les entreprises, et exige la « fourniture d’aménagements raisonnables ». Dans l’amendement de 2021 (Reiwa 3), la fourniture d’aménagements raisonnables par les entreprises, qui était une obligation d’effort, est devenue une obligation, et la loi amendée est entrée en vigueur le 1er avril 2024 (Reiwa 6).¹

Selon le dépliant du Cabinet Office, la fourniture d’aménagements raisonnables est répondre, dans une mesure qui n’est pas une charge excessive, lorsqu’une personne handicapée indique l’intention qu’une certaine réponse est nécessaire pour lever une barrière dans la société. Et parce que le contenu diffère selon la caractéristique du handicap, la scène et la situation, un « dialogue constructif » dans lequel la personne handicapée et l’entreprise empilent le dialogue et considèrent une réponse ensemble est souligné. Refuser unilatéralement le dialogue constructif est énoncé comme pouvant constituer une violation de l’obligation de fournir des aménagements raisonnables.¹

Deux distinctions pratiques comptent ici.

1. « Avoir tout en place à l’avance » n’est pas ce qui est devenu une obligation. Les mesures d’amélioration préalable visant un nombre non spécifié de personnes handicapées — le côté souple tel que revoir un manuel et former, le côté dur tel que rendre un établissement sans barrières — sont appelées « amélioration de l’environnement », et c’est une obligation d’effort.¹ Mettre une application métier dans un état utilisable avec un lecteur d’écran à l’avance peut être pensé comme un effort d’amélioration de l’environnement. Plus l’amélioration de l’environnement est allée loin, plus la charge de fournir des aménagements raisonnables individuels est légère.
2. Le champ de l’emploi n’est pas sous la loi sur l’élimination des discriminations à l’égard des personnes handicapées mais sous la loi sur la promotion de l’emploi des personnes handicapées. Le même dépliant énonce aussi que l’emploi et le travail suivent les dispositions de la loi sur la promotion de l’emploi des personnes handicapées.¹ Et sous cette loi, par l’amendement entré en vigueur en avril 2016 (Heisei 28), l’interdiction de la discrimination fondée sur le handicap dans l’emploi et la fourniture d’aménagements raisonnables dans une mesure qui n’est pas une charge excessive ont été obligées des employeurs.² La consultation d’ouverture de « un salarié ne peut pas utiliser l’application métier » est, en fait, dans le domaine de l’obligation bien avant 2024.

flowchart TB
    accTitle: Le positionnement de l'aménagement raisonnable et de l'amélioration de l'environnement
    accDescr: La relation entre une entreprise générale et une personne handicapée est sous la loi sur l'élimination des discriminations, et fournir des aménagements raisonnables en répondant à une demande individuelle par un 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 ; rendre l'application plus facile à utiliser à l'avance est l'amélioration de l'environnement, une obligation d'effort
    scene{"Quelle scène ?"}
    scene -->|Entreprise + handicap| kaisho["Loi anti-discrimination"]
    scene -->|Emploi / travail| koyou["Loi sur l'emploi"]
    kaisho --> moushide["Demande via le dialogue"]
    moushide --> hairyo["Fournir l'aménagement"]
    hairyo -.-> hairyoN["Obligation depuis 2024"]
    koyou --> koyougimu["Fournir l'aménagement"]
    koyougimu -.-> koyouN["Obligation depuis 2016"]
    kaisho -.-> kankyo["Application plus facile à l'avance"]
    kankyo -.-> kankyoN["Amél. de l'environnement"]
    kankyoN -.-> kankyoN2["obligation d'effort"]
    kankyo -.-> moushide

Figure 2 : la loi applicable se scinde par scène ; l’aménagement raisonnable est une obligation, et les corrections préalables sont l’amélioration de l’environnement, une obligation d’effort.

Comment un cas individuel est traité en droit dépend de la situation. Cet article n’entre pas dans l’interprétation juridique ; il procède du point de vue de ce qu’un ingénieur peut faire lorsqu’une réponse est demandée. Pour les sources primaires, se référer aux 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 Web » s’étendent aussi aux logiciels

Du côté des critères techniques, ils sont concentrés dans JIS X 8341-3:2016. Cette norme est une norme correspondante d’ISO/IEC 40500:2012, et le corps de la norme est le même contenu que WCAG 2.0 du W3C.³ Si vous voulez savoir concrètement de quoi consiste le « support d’accessibilité », lire les critères de succès WCAG (maintenant étendus dans WCAG 2.1/2.2) est le chemin le plus court, et une traduction japonaise par WAIC est aussi publiée.⁸

La question « WCAG est-il un critère pour le contenu Web ? » est juste, mais le W3C a organisé, dans une Group Note appelée WCAG2ICT (Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies), comment appliquer les critères de succès WCAG 2.0/2.1/2.2 aux documents et logiciels non Web.⁴ Autrement dit, une pensée telle que « alternatives textuelles », « contraste », « fonctionnement au clavier » et « la couleur n’est pas le seul moyen » peut s’appliquer à une application de bureau Windows dans le même cadre que le Web. Les chapitres 3 et suivants de cet article descendent cette pensée dans une implémentation WinForms/WPF concrète.

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

Figure 3 : JIS X 8341-3:2016 est une norme correspondante 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 UI Automation

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

Windows a une fondation d’accessibilité appelée UI Automation (UIA) intégrée. UIA est un mécanisme qui laisse la technologie d’assistance telle qu’un lecteur d’écran obtenir des informations d’interface et opérer l’interface par des moyens autres que la saisie standard, et elle médie entre le côté application (le fournisseur) et le côté technologie d’assistance (le client).⁵

Le monde d’UIA peut se comprendre comme le trio suivant.⁵

Lorsqu’un lecteur d’écran met le focus sur un bouton, l’annonce « bouton Confirmer la commande » est, grosso modo, la combinaison de Name + type de contrôle. Lorsque l’utilisateur effectue une opération « exécuter », la technologie d’assistance appuie sur ce bouton à travers le motif Invoke. Autrement dit, si Name et les motifs sont exposés correctement, cela peut être lu et opéré ; s’ils ne sont pas exposés, c’est comme si cela n’existait pas même si c’est visible à l’écran.

flowchart TB
    accTitle: Le trio UI Automation
    accDescr: L'application, en tant que fournisseur, expose les propriétés et les motifs 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 motifs tels que Invoke
    app["Application（fournisseur）"] --> tree["Arbre UIA"]
    tree --> prop["Propriétés（Name, ControlType et analogues）"]
    tree --> pat["Motifs（Invoke, Value et analogues）"]
    sr["Lecteur d'écran（client）"] -->|Annonce| prop
    sr -->|Opère| pat

Figure 4 : le lecteur d’écran utilise les propriétés et les motifs 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 utilisés sous Windows incluent Narrateur, intégré à Windows ; NVDA,¹¹ qui est libre et open source ; et PC-Talker, un produit commercial largement utilisé au Japon. Le style d’annonce diffère parmi eux, mais le chemin primaire pour lire l’interface d’une application de bureau est UIA dans tous les cas. C’est pourquoi la réponse côté application n’est pas « le support d’un lecteur d’écran particulier » mais se concentre sur exposer les informations correctes à UIA.

flowchart TB
    accTitle: Le chemin commun des principaux lecteurs d'écran
    accDescr: Si l'application expose les informations correctes à UIA, Narrateur, NVDA et PC-Talker peuvent tous lire l'interface par le même chemin, donc la réponse côté application ne vise pas un lecteur d'écran particulier mais se concentre sur l'exposition à UIA
    app["Application"] -->|Expose les informations| uia["UI Automation（UIA）"]
    uia --> nar["Narrateur"]
    uia --> nvda["NVDA"]
    uia --> pct["PC-Talker"]
    app -.-> goal["La réponse se concentre sur l'exposition à UIA"]

Figure 5 : les principaux lecteurs d’écran prennent tous UIA comme chemin, donc la réponse de l’application se concentre sur l’exposition à UIA.

3.3. Qu’est-ce qu’un « bouton dont Name est vide » est annoncé comme ?

Un exemple concret. Supposez qu’une barre d’outils a un bouton Enregistrer qui n’affiche qu’une icône de disquette. Pour un utilisateur voyant l’icône transmet le sens, mais si Name est laissé vide, un lecteur d’écran annonce ce bouton seulement comme « bouton ». Si les « Ouvrir » et « Imprimer » voisins sont les mêmes, l’utilisateur n’entend que « bouton, bouton, bouton » et n’a aucun moyen de savoir lequel est lequel. Le guide de correction d’accessibilité de Microsoft liste aussi un bouton sans Name, et une image annoncée seulement comme « Image », comme des problèmes représentatifs qui arrêtent le travail de l’utilisateur.⁷

Heureusement, les contrôles standard WinForms et WPF ont le support UIA dès le départ, et dans de nombreux cas Name est décidé automatiquement à partir du texte ou d’un libellé. Ce qui casse est habituellement l’un de (1) icône seulement, sans matériau pour un nom, (2) pas d’association avec un libellé, ou (3) dessin personnalisé qui ne met pas d’informations sur l’arbre UIA. Les deux chapitres suivants regardent comment le corriger par framework.

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 c'est icône seulement, lorsqu'il n'y a pas d'association avec un libellé, ou lorsque le dessin personnalisé ne met pas d'informations sur l'arbre UIA, et cela finit par n'être annoncé que comme bouton
    c1["Icône seulement, pas de matériau"] --> broken["Name devient vide"]
    c2["Pas d'association avec un libellé"] --> broken
    c3["Le dessin personnalisé n'émet rien"] --> broken
    broken --> result["Annoncé seulement comme bouton"]

Figure 6 : l’annonce qui casse se ramène habituellement à l’un de trois motifs : matériau insuffisant pour un nom, association insuffisante, ou dessin personnalisé.

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

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

Dans WinForms, un contrôle qui affiche du texte, tel qu’un Button ou un CheckBox, utilise la valeur de la propriété Text comme Name UIA. En revanche, ComboBox, ListBox, ListView, PictureBox, ProgressBar, TabControl, TextBox, TreeView et analogues ne font pas de Text le Name. Ceux-ci ont besoin d’un nom par un autre moyen.⁶

La façon la plus maintenable est de placer un Label descriptif dans l’ordre de tabulation immédiatement précédent du contrôle cible. Si vous définissez le TabIndex du contrôle cible pour qu’il vienne immédiatement après le TabIndex du Label, le texte de ce Label est utilisé automatiquement comme Name UIA. Le libellé visible à l’écran et l’annonce correspondent, et vous n’avez pas à gérer la formulation deux fois.⁶¹²

Si vous ne pouvez pas placer un Label, définissez AccessibleName explicitement. Vous pouvez aussi définir AccessibleDescription si une explication complémentaire est nécessaire, et AccessibleRole si le rôle diffère de l’apparence.¹³

flowchart TB
    accTitle: Comment le nom d'un contrôle WinForms est décidé
    accDescr: Pour Button et analogues, Text devient le Name UIA tel quel ; pour des contrôles tels que TextBox dont le Text n'est pas réutilisé, le texte d'un Label placé dans l'ordre de tabulation immédiatement précédent est utilisé ; si vous ne pouvez pas placer un Label, définissez AccessibleName explicitement
    ctrl["Contrôle"] --> qtext{"Une sorte dont Text devient Name ?"}
    qtext -->|Oui| usetext["Text devient Name tel quel"]
    qtext -->|Non| qlabel{"Un Label dans l'ordre de tabulation précédent ?"}
    qlabel -->|Oui| uselabel["Le texte du Label est utilisé comme Name"]
    qlabel -->|Non| explicit["Définir AccessibleName explicitement"]

Figure 7 : pour un Name WinForms, choisissez comment le décider dans l’ordre Text, un Label dans l’ordre de tabulation immédiatement précédent, AccessibleName.

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

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

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

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

Comme mise en garde, si vous définissez AccessibleName une fois dans le volet Propriétés de Visual Studio puis l’effacez, un paramètre de chaîne vide peut rester dans le fichier designer et interférer avec la résolution de nom par défaut. Supprimez la ligne correspondante 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 de chaîne vide reste dans le fichier designer et interfère avec la résolution de nom par défaut, donc vous le corrigez en supprimant la ligne correspondante du fichier designer
    set["Définir AccessibleName"] --> erase["L'effacer dans le volet Propriétés"]
    erase --> remain["Un paramètre de chaîne vide reste"]
    remain --> block["Il interfère avec la résolution de nom par défaut"]
    block -.-> fix["Supprimer la ligne correspondante du fichier designer"]

Figure 8 : l’effacer dans le volet Propriétés laisse encore une chaîne vide, donc vous le corrigez en supprimant la ligne correspondante du fichier designer.

4.2. Améliorations courantes sur un écran de saisie de commandes

Les endroits que nous corrigeons réellement souvent dans les applications métier sont résumés comme une liste de contrôle.

Chacun est une correction de quelques lignes, mais pour un utilisateur de lecteur d’écran c’est la fourche entre « un écran que vous ne pouvez pas utiliser » et « un écran que vous pouvez utiliser ».

5. Implémentation dans WPF — AutomationProperties et AutomationPeer

5.1. AutomationProperties.Name / LabeledBy / HelpText

Dans WPF, un contrôle dont le Content est une chaîne, tel qu’un Button, utilise ce contenu comme Name UIA. Un bouton icône seulement (Image ou Path) n’a pas de matériau pour un Name, donc vous l’énoncez avec AutomationProperties.Name, ou s’il y a du texte d’affichage à proximité vous l’associez avec AutomationProperties.LabeledBy.⁷

TextBox a une mise en garde importante. Le Text d’un TextBlock est réutilisé comme Name, mais le Text d’un TextBox est exposé du côté de la propriété UIA Value et ne devient pas Name. Pour un champ de saisie, associer le TextBlock de libellé d’affichage avec LabeledBy est le premier candidat. L’annonce et l’affichage à l’écran correspondent, et vous évitez aussi de gérer la formulation deux fois.¹⁴

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

<!-- An icon-only button: state the name, and a supplement if needed -->
<Button
    AutomationProperties.Name="Confirm order"
    AutomationProperties.HelpText="Confirm the order being entered and allocate inventory">
    <Path Data="{StaticResource CheckIconGeometry}" Width="16" Height="16" />
</Button>

flowchart TB
    accTitle: 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 associer un libellé d'affichage voisin avec LabeledBy est le premier candidat ; si cela aussi est absent, énoncer AutomationProperties.Name ; le Text d'un TextBox est exposé du côté Value, pas comme Name
    ctrl["Contrôle"] --> qc{"Le Content est-il une chaîne ?"}
    qc -->|Oui| auto["Le contenu devient Name"]
    qc -->|Non| ql{"Un libellé d'affichage voisin ?"}
    ql -->|Oui| lb["Associer avec LabeledBy"]
    ql -->|Non| nm["Définir Name explicitement"]
    tbx["Le Text d'un TextBox"] -.-> val["Exposé comme Value, pas Name"]

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

Les informations complémentaires qui ne tiennent pas dans Name peuvent s’exposer avec AutomationProperties.HelpText.⁷ Aussi, AutomationId est un identifiant utilisé pour l’identification d’éléments dans les tests UI automatisés, donc décider une convention de nommage au moment de la conception d’écran paie plus tard (couvert en profondeur dans « Tests UI automatisés pour applications de bureau Windows »).

5.2. Un contrôle personnalisé a besoin d’un AutomationPeer

Un contrôle personnalisé que vous dessinez vous-même ne peut pas, tel quel, exposer des informations significatives sur l’arbre UIA. Dans WPF vous surchargez OnCreateAutomationPeer sur une classe dérivée de UIElement et renvoyez une classe dérivée d’AutomationPeer pour exposer le nom, la sorte et les motifs. Si vous héritez d’un contrôle existant, hériter du Peer correspondant (ButtonBaseAutomationPeer pour ButtonBase) vous laisse reprendre le comportement déjà implémenté.¹⁵

flowchart TB
    accTitle: Comment les informations sont exposées via AutomationPeer
    accDescr: Un contrôle personnalisé expose le nom, la sorte et les motifs en surchargeant OnCreateAutomationPeer et en renvoyant une classe dérivée d'AutomationPeer ; si vous héritez d'un contrôle existant, héritez du Peer correspondant et reprenez 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 nom, sorte et motifs"]
    inherit["Hériter d'un contrôle existant"] -.-> basepeer["Hériter du Peer correspondant"]
    basepeer -.-> reuse["Reprendre le comportement déjà implémenté"]

Figure 10 : un contrôle personnalisé renvoie un Peer depuis OnCreateAutomationPeer et expose les informations à UIA.

// An example of a control that custom-draws line status as a coloured lamp
public class StatusLamp : Control
{
    public static readonly DependencyProperty IsOnlineProperty =
        DependencyProperty.Register(nameof(IsOnline), typeof(bool), typeof(StatusLamp),
            new FrameworkPropertyMetadata(false,
                FrameworkPropertyMetadataOptions.AffectsRender, OnIsOnlineChanged));

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

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

    private static void OnIsOnlineChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        // Raise a UIA property-changed event the moment the value changes. Without this,
        // a screen reader keeps the old name and cannot notice the change of state
        if (UIElementAutomationPeer.FromElement((UIElement)d) is AutomationPeer peer)
        {
            peer.RaisePropertyChangedEvent(
                AutomationElementIdentifiers.NameProperty,
                NameFor((bool)e.OldValue), NameFor((bool)e.NewValue));
        }
    }

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

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

    protected override AutomationControlType GetAutomationControlTypeCore()
        => AutomationControlType.Text; // Text-equivalent if it is a status display with no operation

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

Renvoyer un nom ne suffit pas ; le dire avec un événement au moment où il change est aussi le travail du Peer. La technologie d’assistance n’a pas son propre moment pour récupérer à nouveau une valeur, donc une implémentation qui ne lève pas d’événement de changement est dans un état de « correct seulement lorsqu’on redemande », et un utilisateur de lecteur d’écran n’est pas informé du changement d’état.

sequenceDiagram
    accTitle: Le flux de dire à un lecteur d'écran un changement d'état
    accDescr: Au moment où la valeur du contrôle change, l'AutomationPeer lève un événement de changement de propriété Name ; la technologie d'assistance ne récupère pas d'elle-même, donc sans l'événement elle reste sur l'ancien nom et ne peut pas remarquer 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: Lever un événement de changement de propriété Name
    s->>s: Annoncer le nouvel état
    Note over s: Sans l'événement elle reste sur l'ancien nom

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

Si le contrôle personnalisé a une opération (on peut l’appuyer, on peut changer sa valeur, on peut le sélectionner), vous surchargez GetPattern et fournissez une interface de motif telle que IInvokeProvider ou IRangeValueProvider.¹⁵ Le point est que si vous construisez le Peer aussi du côté de la bibliothèque de contrôles partagés, chaque écran qui l’utilise devient supporté automatiquement. C’est la fondation du « déployer latéralement » du chapitre 9.

6. Pouvez-vous atteindre chaque fonction depuis le clavier seul ?

Le critère de succès WCAG 2.1.1 (Keyboard) exige que toute fonctionnalité du contenu soit opérable à travers une interface clavier.⁸ Un utilisateur de lecteur d’écran n’utilise en principe pas de souris, donc une fonction que vous ne pouvez pas atteindre depuis le clavier est la même chose qu’une fonction qui n’existe pas. Les points de vue d’inspection sont les suivants.

Le walkthrough d’accessibilité WinForms liste aussi, comme bases, placer un libellé dans l’ordre de tabulation immédiatement précédent d’un champ de saisie, et mettre des touches d’accès sur les contrôles et menus vers lesquels l’utilisateur veut se déplacer.¹²

Ce que nous voulons souligner, c’est que ce n’est pas « un coût extra pour le support du handicap ». Dans un travail de routine tel que la saisie de commandes, pouvoir terminer la saisie sans quitter la position de repos est ce qui décide le débit d’un opérateur tel quel. Un ordre de tabulation désordonné ou une opération qui exige la souris est un défaut qui rogne un peu la productivité de chaque utilisateur chaque jour. Le support d’accessibilité et l’efficacité clavier ne sont que deux noms pour le même travail (pour les priorités par environnement d’utilisation, voir aussi « Conception UX des applications Windows »).

flowchart TB
    accTitle: Le double effet de ranger le clavier
    accDescr: Ranger l'ordre de tabulation, les touches d'accès et l'indication de focus produit deux effets à la fois — un utilisateur de technologie d'assistance peut atteindre une fonction, et la vitesse de saisie de chaque opérateur — et une fonction utilisable seulement à la souris est la même chose qu'une fonction qui n'existe pas
    seibi["Ranger le clavier"] --> a11y["Utilisateurs de tech. d'assistance"]
    seibi --> speed["Vitesse de chaque opérateur"]
    mouse["Une fonction souris seulement"] -.-> none["Comme inexistante"]

Figure 12 : ranger le fonctionnement au clavier réalise le support de la technologie d’assistance et l’efficacité pour chaque utilisateur en même temps ; une fonction souris seulement est comme si elle n’existait pas.

7. Couleur et contraste — 4,5:1 et « la couleur n’est pas le seul moyen »

7.1. Le guide pour le ratio de contraste est 4,5:1

Le critère de succès WCAG 1.4.3 (Contrast (Minimum)) exige un ratio 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.⁸ Un design moderne qui place du texte gris clair sur un fond blanc n’est pas rare à manquer ce critère. Les utilisateurs d’une application métier incluent des personnes dont la vision et la vision des couleurs ont changé avec l’âge, et des personnes qui l’utilisent dans un environnement mal éclairé tel qu’une usine. Prenez l’habitude de mesurer avec un vérificateur de contraste à la revue de conception.

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

Le critère de succès 1.4.1 (Use of Color) est que la couleur ne doit pas être le seul moyen visuel de transmettre l’information.⁸ Les exemples typiques dans une application métier sont les suivants.

• Montrer une ligne d’erreur en texte rouge seulement → fournir aussi une icône d’erreur et une colonne de message
• Montrer un champ obligatoire par la couleur du libellé seulement → ajouter un « * » ou la formulation « Obligatoire »
• Montrer l’état par la couleur de la lampe seulement → le faire couleur + forme, ou formulation (« En cours », « Arrêté »)

Étant donné la diversité de la vision des couleurs, ceci aussi n’est pas une « réponse spéciale » mais une base de conception d’affichage.

flowchart TB
    accTitle: Remplacer l'information transmise par la couleur seule
    accDescr: Un affichage qui montre une erreur en texte rouge seulement est remplacé par une icône d'erreur plus une colonne de message ; un affichage qui montre un champ obligatoire par la couleur du libellé seulement est remplacé par l'ajout de la formulation Obligatoire ; un affichage qui montre l'état par la couleur de la lampe seulement est remplacé par combiner la forme ou la formulation
    err["Une erreur en texte rouge seulement"] --> erra["Fournir aussi une icône et une formulation"]
    req["Obligatoire par la couleur du libellé seulement"] --> reqa["Ajouter la formulation Obligatoire"]
    lamp["État par la couleur de la lampe seulement"] --> lampa["Combiner couleur avec forme ou formulation"]

Figure 13 : les exemples typiques de transmission par la couleur seule sont remplacés par combiner une icône, une formulation, et une forme ou du texte.

7.3. Suivre un thème de contraste (contraste élevé)

Windows a des thèmes de contraste (anciennement contraste élevé) qui basculent vers un schéma de couleurs avec une forte séparation de premier plan et d’arrière-plan ; l’utilisateur peut sélectionner et éditer des thèmes intégrés conçus pour que le ratio de contraste soit généralement de 7:1 ou plus.⁹ Le principe côté application est simple : ne codez pas les couleurs en dur ; respectez les couleurs système.

• WinForms : si vous laissez ForeColor/BackColor au défaut, les paramètres de couleur de l’utilisateur sont utilisés. Là où vous avez appliqué une couleur à vous, jugez avec SystemInformation.HighContrast, basculez vers un schéma basé sur SystemColors, et suivez un changement de paramètres avec l’événement UserPreferenceChanged.¹²
• WPF/WinUI : si vous référencez des ressources de la classe SystemColors, vous suivez un basculement de thème. Les endroits que vous avez remplis avec un pinceau à vous deviennent la cause de la casse.⁹

flowchart TB
    accTitle: Suivre un thème de contraste
    accDescr: Les endroits où une couleur est codée en dur cassent lors d'un basculement vers un thème de contraste, donc basculez vers un schéma basé sur SystemColors et suivez avec un événement de changement de paramètres ; si vous référencez les couleurs système vous pouvez suivre les couleurs de l'utilisateur automatiquement
    theme["Basculer vers un thème de contraste"] --> qh{"Comment la couleur est-elle spécifiée ?"}
    qh -->|Codée en dur| broken["Le schéma de couleurs casse"]
    qh -->|Référence de couleur système| ok["Suit automatiquement les couleurs de l'utilisateur"]
    broken -.-> fix["Basculer vers SystemColors"]
    fix -.-> ev["Suivre avec un événement de changement de paramètres"]

Figure 14 : seuls les endroits où une couleur est codée en dur cassent sous un thème de contraste ; une référence de couleur système suit automatiquement.

Aussi, un utilisateur malvoyant utilise souvent un fort agrandissement de l’OS (mise à l’échelle DPI), donc le support haut DPI fait aussi partie du support d’accessibilité. Une application dont la mise en page casse à 125 %–200 % est inutilisable à ce point. Voir « La prise en charge du haut DPI dans WinForms » et « Le support du haut DPI dans WPF » pour les détails.

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

8.1. Accessibility Insights for Windows

Microsoft fournit Accessibility Insights for Windows comme outil de vérification d’accessibilité pour les applications Windows, avec trois usages principaux.¹⁰

• Live Inspect : survolez simplement la souris sur un élément ou mettez-le au focus clavier, et vous pouvez confirmer ses propriétés UIA (Name, ControlType, motifs et analogues). Le moyen le plus court de voir « quel est le Name de ce bouton ».
• FastPass : un contrôle léger qui détecte les problèmes d’accessibilité à fort impact en moins de cinq minutes. Les problèmes qui peuvent être jugés mécaniquement, tels qu’un Name manquant, peuvent être inventoriés par nouvel écran.
• Troubleshooting : aide le diagnostic et la correction d’un problème particulier. Depuis un problème détecté vous pouvez aller directement aux guides de correction par framework que cet article cite aussi.

Inspect.exe et AccEvent, inclus dans le Windows SDK, peuvent aussi confirmer l’arbre UIA et les propriétés, mais ils sont positionnés comme outils hérités, et un passage à Accessibility Insights est maintenant recommandé.¹⁰

flowchart TB
    accTitle: Trois usages d'Accessibility Insights
    accDescr: Accessibility Insights for Windows fournit la confirmation des propriétés UIA avec Live Inspect, un contrôle léger des problèmes à fort impact avec FastPass, et l'aide au diagnostic et à la correction d'un problème avec Troubleshooting ; un passage depuis les outils hérités tels qu'Inspect.exe est recommandé
    ai["Accessibility Insights"] --> live["Live Inspect"]
    ai --> fast["FastPass"]
    ai --> ts["Troubleshooting"]
    live --> livef["Confirmer les propriétés UIA"]
    fast --> fastf["Détecter les problèmes à fort impact"]
    ts --> tsf["Aider le diagnostic et la correction"]
    legacy["Inspect.exe et analogues"] -.->|Un passage est recommandé| ai

Figure 15 : Accessibility Insights a les trois usages confirmer, détecter et diagnostiquer, et est la destination d’un passage depuis les outils hérités.

8.2. Un contrôle pratique avec un lecteur d’écran

Ce qu’un contrôle automatique d’outil peut détecter n’est que les problèmes qui peuvent être jugés mécaniquement. À la fin, parcourez toujours une opération métier réelle avec un lecteur d’écran. Le Narrateur intégré à Windows peut se démarrer immédiatement avec Ctrl+touche Windows+Entrée, et NVDA peut s’introduire gratuitement.¹¹ L’astuce du contrôle est d’essayer, sans regarder l’écran (ou avec l’affichage éteint), en ne s’appuyant que sur l’annonce, si vous pouvez terminer une tâche réelle telle que « saisir une commande et la confirmer ». Les problèmes tels qu’un nom présent mais l’ordre d’annonce incohérent, ou le focus qui s’échappe hors d’une fenêtre modale, ne se trouvent que de façon pratique.

flowchart TB
    accTitle: Combiner la vérification d'outil et un contrôle pratique
    accDescr: Ce qu'un contrôle automatique tel que FastPass peut détecter n'est que les problèmes qui peuvent être jugés mécaniquement ; le reste se trouve de façon pratique en parcourant une opération métier réelle avec un lecteur d'écran et en trouvant les problèmes d'ordre d'annonce et de focus
    tool["Un contrôle automatique d'outil"] --> kikai["Problèmes jugés mécaniquement"]
    tool -.-> nokori["Des problèmes qu'il ne détecte pas restent"]
    nokori --> sr["Un 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 : inventoriez les problèmes mécaniques avec un contrôle automatique, et trouvez le reste avec un contrôle pratique avec un lecteur d’écran.

8.3. L’intégrer dans le flux de développement, et le paiement mutuel avec les tests UI automatisés

Pour que la vérification ne devienne pas dépendante de la personne, nous recommandons d’intégrer la liste de contrôle suivante dans les éléments de revue d’un nouvel écran.

Et un de plus. Les tests UI automatisés avec FlaUI et analogues sont construits sur la même UIA que les lecteurs d’écran utilisent. Le Name et les motifs que vous mettez en place pour l’accessibilité deviennent des pièces du code de test, et un AutomationId conçu pour les tests rend le débogage dans Live Inspect plus facile. Inversement, une interface qui n’apparaît pas dans l’arbre UIA est invisible à la fois pour les tests et pour la technologie d’assistance. L’accessibilité et la testabilité sont deux faces du même investissement (« Tests UI automatisés pour applications de bureau Windows »).

flowchart TB
    accTitle: Le paiement mutuel de l'accessibilité et des tests UI automatisés
    accDescr: Un lecteur d'écran et les tests UI automatisés tels que FlaUI sont construits sur la même UIA, donc le Name et les motifs que vous mettez en place peuvent être utilisés des deux côtés, et une interface qui n'apparaît pas dans l'arbre UIA est invisible de l'un comme de l'autre
    uia["Ranger l'arbre UIA"] --> sr["Un lecteur d'écran peut le lire"]
    uia --> test["Cela peut être utilisé dans les tests UI automatisés"]
    sr -.-> both["Deux faces du même investissement"]
    test -.-> both
    hidden["Une interface qui n'apparaît pas dans UIA"] -.-> invisible["Invisible de l'un comme de l'autre"]

Figure 17 : parce qu’ils reposent sur la même fondation UIA, ranger l’arbre UIA paie à la fois pour la technologie d’assistance et pour les tests UI automatisés.

9. Comment fixer les priorités — Ne corrigez pas tous les écrans d’un coup

Corriger un système cœur de centaines d’écrans d’un coup est irréaliste en coût comme en qualité. L’approche que nous recommandons est les trois niveaux suivants.

1. Corrigez depuis les écrans que cet utilisateur utilise dans le travail. L’aménagement raisonnable est un processus de répondre individuellement à une demande de la personne concernée.¹ Faites d’abord opérer la personne le travail réel avec un lecteur d’écran, et identifiez ensemble où elle bloque. Dans de nombreux cas les écrans utilisés au quotidien se réduisent à quelques-uns jusqu’à une douzaine, et les problèmes fatals parmi eux (un bouton sans nom, un bouton de confirmation que vous ne pouvez pas appuyer depuis le clavier) peuvent se résoudre en une correction de quelques jours.
2. Rendez le nouveau développement conforme. Ajoutez la liste de contrôle du chapitre 8 à la Definition of Done, et construisez les nouveaux écrans supportés dès le départ. Contrairement à une correction après coup, l’augmentation de coût de l’intégrer à la conception est légère.
3. Déployez latéralement en corrigeant les contrôles partagés. Si vous implémentez un AccessibleName par défaut ou un AutomationPeer sur des pièces internes partagées telles qu’une boîte de dialogue de recherche, une grille ou une saisie de date, cela prend effet en lot sur chaque écran qui les utilise. C’est un geste bien plus rentable que de toucher les écrans individuels un par un.

flowchart TB
    accTitle: Les trois niveaux de priorité de correction
    accDescr: Corrigez depuis les écrans que l'utilisateur utilise dans le travail, rendez le nouveau développement conforme avec une liste de contrôle, et déployez sur chaque écran en corrigeant les contrôles partagés
    s1["1. Corriger depuis les écrans que l'utilisateur utilise"] --> s2["2. Le nouveau travail est conforme"] --> s3["3. Déployer latéralement avec les contrôles partagés"]
    s3 -.-> all["Prend effet en lot sur chaque écran qui les utilise"]

Figure 18 : avancez non pas en corrigeant tous les écrans d’un coup mais aux trois niveaux des écrans en usage, du nouveau travail et des pièces partagées.

Et un enregistrement du dialogue est aussi important que la réponse technique. L’aménagement raisonnable est un processus de « dialoguer et ajuster individuellement », non de satisfaire pleinement chaque demande. Considérer un moyen alternatif avec la personne (faire ce travail sur un autre écran, préparer un export CSV, le couvrir en exploitation) et convenir, pour une correction dont la charge est trop lourde, est aussi un résultat légitime du dialogue constructif.¹ Enregistrer ce qui a été demandé, ce à quoi on a répondu, et ce qui a été fait moyen alternatif devient la preuve de bonne foi de l’organisation.

flowchart TB
    accTitle: Le flux du dialogue constructif et d'un enregistrement
    accDescr: Répondez à une demande d'une personne handicapée par un dialogue constructif ; réalisez une correction à laquelle on peut répondre ; pour une correction dont la charge est trop lourde, considérez un moyen alternatif avec la personne et convenez ; enregistrez ce qui a été demandé, ce à quoi on a répondu, et ce qui a été fait moyen alternatif
    req["Une demande"] --> talk["Dialogue constructif"]
    talk --> q{"La charge est-elle trop lourde ?"}
    q -->|Non| kaishu["Répondre par une correction"]
    q -->|Oui| alt["Considérer un moyen alternatif et convenir"]
    kaishu --> rec["Enregistrer l'historique"]
    alt --> rec

Figure 19 : dans le dialogue constructif vous convenez avec la personne d’une correction ou d’un moyen alternatif, et laissez cet historique dans un enregistrement.

10. Résumé

• Avec la loi amendée sur l’élimination des discriminations à l’égard des personnes handicapées entrée en vigueur en avril 2024, la fourniture d’aménagements raisonnables est devenue une obligation aussi pour les entreprises. Le champ de l’emploi est une obligation d’employeur depuis 2016 sous la loi sur la promotion de l’emploi des personnes handicapées. Rendre l’application plus facile à utiliser à l’avance est l’« amélioration de l’environnement » (une obligation d’effort), et plus elle est allée loin, plus les réponses individuelles deviennent légères.
• Les critères techniques sont concentrés dans WCAG (JIS X 8341-3:2016), et la même pensée peut s’appliquer à une application de bureau via WCAG2ICT.
• Un lecteur d’écran lit une application à travers UI Automation. Le trio de l’arbre UIA, des propriétés (Name/ControlType/AutomationId) et des motifs de contrôle est la fondation.
• La plus haute priorité est Name. WinForms utilise AccessibleName et l’association d’un Label à l’ordre de tabulation ; WPF utilise AutomationProperties.Name/LabeledBy ; un contrôle personnalisé utilise un AutomationPeer.
• Pouvoir atteindre chaque fonction depuis le clavier seul est un critère de succès WCAG et, en même temps, la productivité de chaque opérateur. Rangez l’ordre de tabulation, les touches d’accès et l’indication de focus.
• Les trois bases de la couleur sont un ratio de contraste de 4,5:1, la couleur n’est pas le seul moyen, et respecter les couleurs système dans un thème de contraste.
• Combinez la vérification avec FastPass+Live Inspect dans Accessibility Insights et un contrôle pratique avec Narrateur/NVDA, et intégrez-la dans le flux de développement comme liste de contrôle pour un nouvel écran.
• Ne corrigez pas tous les écrans d’un coup ; avancez dans l’ordre écrans que l’utilisateur utilise → support standard pour le nouveau travail → un déploiement latéral des contrôles partagés. L’aménagement raisonnable est un processus de dialogue, et un enregistrement de l’historique protège l’organisation.

Comme premier pas nous recommandons de prendre l’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 trente minutes, la position actuelle de votre propre application devient étonnamment concrète.

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 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, ranger le fonctionnement au clavier, support des thèmes de contraste), l’implémentation d’un AutomationPeer sur les contrôles partagés, et les consultations sur un diagnostic de l’état présent et la fixation des priorités avec Accessibility Insights. Commencer dès le stade de « nous voulons confirmer si un salarié peut utiliser notre application avec un lecteur d’écran » convient.

• 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 la fourniture d'aménagements raisonnables aux personnes handicapées est devenue une obligation aussi pour les entreprises. L'aménagement raisonnable est une réponse qui, lorsqu'une personne handicapée en fait la demande, lève une barrière individuelle dans une mesure qui n'est pas une charge excessive ; rendre l'application plus facile à utiliser à l'avance est positionné comme une obligation d'effort appelée « amélioration de l'environnement ». L'emploi, tel que la relation entre un salarié et l'entreprise, n'est pas sous cette loi mais sous la loi sur la promotion de l'emploi des personnes handicapées, qui a obligé les employeurs à fournir des aménagements raisonnables depuis l'amendement entré en vigueur en avril 2016. Autrement dit, une situation de « un salarié ne peut pas utiliser l'application métier » est dans le domaine de l'obligation depuis un certain temps. Jusqu'où aller dans un cas donné dépend de la situation individuelle, donc vous confirmez les sources primaires du Cabinet Office et du ministère de la Santé, du Travail et des Affaires sociales et vous 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 Narrateur et NVDA lisent l'interface d'une application à travers une fondation d'accessibilité appelée UI Automation (UIA). Le côté application expose les éléments à l'écran dans une structure appelée l'arbre UIA ; chaque élément a des propriétés telles que Name (objet) et ControlType (sorte), et des motifs de contrôle tels que Invoke (appuyer) et Value (valeur). Le lecteur d'écran annonce ces informations comme « bouton Confirmer la commande » et opère à travers les motifs. Les contrôles WinForms et WPF standard ont ce mécanisme dès le départ, donc le travail principal du développeur est de ne pas laisser Name vide, de rendre l'interface opérable depuis le clavier, et d'implémenter les informations sur les contrôles personnalisés.

Sur une application WinForms existante, par quoi commencer ?

Le chemin le plus court est d'exécuter FastPass dans Accessibility Insights for Windows contre l'écran cible et d'inventorier les contrôles dont Name est vide et les problèmes d'ordre de tabulation. Les corrections commencent par définir AccessibleName sur les boutons icône seulement, associer un Label dans l'ordre de tabulation immédiatement précédent d'un champ de saisie, et ranger TabIndex pour qu'il corresponde à l'ordre visuel. Puis démarrez Narrateur ou NVDA et parcourez une opération métier réelle sans regarder l'écran, et confirmez où vous bloquez. Vous n'avez pas besoin de corriger tous les écrans d'un coup ; partir des écrans que quelqu'un utilise réellement, et rendre les nouveaux écrans conformes à une liste de contrôle, est réaliste.

Que faire pour le support du contraste élevé (thème de contraste) ?

La base est de ne pas coder les couleurs en dur et de respecter les couleurs système. Dans WinForms, laissez ForeColor/BackColor au défaut ou utilisez SystemColors, jugez l'état avec SystemInformation.HighContrast, et suivez un basculement avec l'événement UserPreferenceChanged. Dans WPF et WinUI aussi, si vous référencez des ressources de la classe SystemColors, vous suivez un basculement de thème automatiquement. En même temps, cessez de transmettre l'information « par la couleur seule » — montrer une erreur seulement en rouge — et combinez-la avec une icône ou une formulation. Même dans le thème ordinaire, prendre le critère WCAG d'un ratio de contraste de texte de 4,5:1 ou plus comme guide rend aussi l'interface plus lisible pour un atelier mal éclairé et pour les utilisateurs plus âgés.

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

Oui. Les outils de tests UI automatisés tels que FlaUI sont construits sur la même UI Automation que les lecteurs d'écran utilisent. Le Name, le ControlType et les motifs de contrôle que vous mettez en place pour l'accessibilité peuvent être utilisés tels quels 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 à la fois pour un lecteur d'écran et pour les tests. L'accessibilité et les tests automatisés sont un investissement dans la même fondation, donc mettre l'un en place abaisse aussi 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.