Introduzione all'accessibilità delle app Windows — Prepararsi a UI Automation e agli obblighi di accomodamento ragionevole

«Un assunto a metà carriera con disabilità visiva non riesce a usare l’app core di inserimento ordini con uno screen reader. Usa browser e posta senza problemi, ma solo la lettura della nostra app aziendale non funziona correttamente. Si può fare qualcosa?» — Consulenze di questo tipo dai reparti IT dei clienti sono in aumento.

Uno dei contesti è il quadro giuridico. L’emendamento del 2021 alla legge per l’eliminazione della discriminazione nei confronti delle persone con disabilità è entrato in vigore il 1° aprile 2024, e la «fornitura di accomodamento ragionevole» alle persone con disabilità è diventata un obbligo anche per le imprese.¹ Inoltre, un rapporto dipendente–azienda come quello dell’apertura (il campo dell’occupazione) è il dominio della legge sulla promozione dell’occupazione delle persone con disabilità, che ha obbligato i datori di lavoro a fornire accomodamento ragionevole da aprile 2016.² L’idea che «l’accessibilità è un tema da sito web e non ha niente a che fare con le app Windows interne» non regge più, né in diritto né in pratica.

Dall’altro lato, dal piano di sviluppo, «non sappiamo cosa fare» è un posto onesto in cui stare. L’accessibilità delle app desktop Windows ha meno informazioni del Web, e non c’è una soluzione magica a posteriori. Non c’è bisogno di essere pessimisti, però. Se capite il meccanismo con cui uno screen reader legge un’app (UI Automation) e interiorizzate le basi di nome, tastiera e colore, l’usabilità di un’app aziendale migliora in modo sostanziale. E gran parte di questo è un miglioramento che alza la produttività di ogni utente, con o senza disabilità.

Rivolto agli sviluppatori di app aziendali giapponesi e al personale IT, questo articolo collega in un unico passaggio dal minimo riordino del quadro giuridico e degli standard, attraverso il meccanismo di UI Automation, l’implementazione in WinForms/WPF, l’uso da tastiera, colore e contrasto e gli strumenti di verifica, fino a un modo realistico di fissare le priorità.

flowchart TB
    accTitle: Il flusso di questo articolo
    accDescr: La struttura di questo articolo, che collega in ordine dal riordino del quadro giuridico e degli standard attraverso il meccanismo di UI Automation, l'implementazione in WinForms e WPF, l'uso da tastiera, colore e contrasto, gli strumenti di verifica e come fissare le priorità
    law["Riordino del quadro giuridico e degli standard"] --> uia["Il meccanismo di UI Automation"]
    uia --> impl["Implementazione in WinForms/WPF"]
    impl --> kb["Uso da tastiera"]
    kb --> color["Colore e contrasto"]
    color --> verify["Strumenti di verifica"]
    verify --> prio["Come fissare le priorità"]

Figura 1: Questo articolo collega il quadro giuridico attraverso meccanismo, implementazione, verifica e priorità in un unico flusso.

1. Prima di tutto, la conclusione

• La fornitura di accomodamento ragionevole è un obbligo anche per le imprese dal 1° aprile 2024. Quando una persona con disabilità indica l’intento di far rimuovere una barriera, è richiesta una risposta entro un ambito che non costituisce un onere eccessivo. Il campo dell’occupazione cade sotto la legge sulla promozione dell’occupazione delle persone con disabilità, e quello è un obbligo del datore di lavoro da aprile 2016.¹²
• L’accomodamento ragionevole è un processo di «rispondere a una richiesta individuale attraverso un dialogo costruttivo»; rendere l’app più facile da usare in anticipo è «miglioramento ambientale» (un obbligo di sforzo). Un supporto preventivo perfetto non è l’obbligo; ciò che conta è non rifiutare unilateralmente il dialogo.¹
• I criteri tecnici dell’accessibilità sono concentrati in WCAG (JIS X 8341-3:2016). JIS X 8341-3:2016 è uno standard corrispondente con lo stesso contenuto di WCAG 2.0, e WCAG2ICT del W3C dà indicazioni su come applicarlo al software non Web. Un’app desktop si può ispezionare con lo stesso ragionamento.³⁴
• Uno screen reader legge un’app attraverso UI Automation (UIA). Le proprietà che ogni elemento sull’albero UIA detiene — Name, ControlType e simili — e i pattern di controllo come Invoke, Value e SelectionItem sono il materiale per l’annuncio e l’operazione.⁵
• Un pulsante il cui Name è vuoto viene annunciato solo come «pulsante». La correzione di massima priorità è il naming. WinForms usa AccessibleName e l’associazione di una Label all’ordine di tabulazione; WPF usa AutomationProperties.Name/LabeledBy.⁶⁷
• Poter raggiungere ogni funzione dalla sola tastiera è un criterio di successo WCAG (2.1.1) e, allo stesso tempo, la velocità di input di un operatore esperto. Mettere in piedi ordine di tabulazione, tasti di accesso e indicazione del focus si collega direttamente all’efficienza per ogni utente.⁸
• Prendete come guida un rapporto di contrasto del testo di 4,5:1 o più, e non veicolate informazione solo con il colore. In un tema di contrasto (contrasto elevato), rispettate i colori di sistema piuttosto che colori hard-codificati.⁸⁹
• Combinate la verifica con FastPass in Accessibility Insights for Windows e un controllo pratico con uno screen reader. Poiché poggiano sulla stessa fondazione UIA, questo lavoro si ripaga anche a vicenda con gli asset di test UI automatizzati come FlaUI.¹⁰
• Non dovete sistemare ogni schermata in una volta. L’ordine realistico è (1) dalle schermate che quell’utente usa, (2) il nuovo sviluppo è conforme allo standard, (3) estendete di lato sistemando i controlli condivisi.

In una frase: il supporto all’accessibilità è «esporre il nome e le operazioni corretti sull’albero UIA, e tenere le basi di tastiera e colore».

2. Riordinare il quadro giuridico e gli standard — Cosa è cambiato quando «è diventato un obbligo»

2.1. La legge per l’eliminazione della discriminazione nei confronti delle persone con disabilità — Da aprile 2024, anche le imprese sono obbligate a fornire accomodamento ragionevole

La legge per l’eliminazione della discriminazione nei confronti delle persone con disabilità è una legge che vieta il «trattamento discriminatorio ingiusto» delle persone con disabilità da parte di organi amministrativi e imprese, e richiede la «fornitura di accomodamento ragionevole». Nell’emendamento del 2021 (Reiwa 3), la fornitura di accomodamento ragionevole da parte delle imprese, che era un obbligo di sforzo, è diventata un obbligo, e la legge emendata è entrata in vigore il 1° aprile 2024 (Reiwa 6).¹

Secondo il depliant del Cabinet Office, la fornitura di accomodamento ragionevole è rispondere, entro un ambito che non costituisce un onere eccessivo, quando una persona con disabilità indica l’intento che serve qualche risposta per rimuovere una barriera nella società. E poiché il contenuto differisce per caratteristica della disabilità, scena e situazione, viene enfatizzato un «dialogo costruttivo» in cui la persona con disabilità e l’impresa accumulano dialogo e considerano insieme una risposta. Rifiutare unilateralmente il dialogo costruttivo è dichiarato come potenzialmente costitutivo di una violazione dell’obbligo di fornire accomodamento ragionevole.¹

Qui contano due distinzioni pratiche.

1. «Avere tutto a posto in anticipo» non è ciò che è diventato un obbligo. Le misure di miglioramento preventive rivolte a un numero non specificato di persone con disabilità — il lato soft come rivedere un manuale e la formazione, il lato hard come rendere una struttura senza barriere — si chiamano «miglioramento ambientale», e questo è un obbligo di sforzo.¹ Mettere un’app aziendale in uno stato usabile con uno screen reader in anticipo si può pensare come uno sforzo di miglioramento ambientale. Più il miglioramento ambientale è andato avanti, più è leggero l’onere di fornire accomodamento ragionevole individuale.
2. Il campo dell’occupazione non cade sotto la legge per l’eliminazione della discriminazione nei confronti delle persone con disabilità ma sotto la legge sulla promozione dell’occupazione delle persone con disabilità. Lo stesso depliant afferma anche che occupazione e lavoro seguono le disposizioni della legge sulla promozione dell’occupazione delle persone con disabilità.¹ E sotto quella legge, con l’emendamento in vigore da aprile 2016 (Heisei 28), il divieto di discriminazione per disabilità nell’occupazione e la fornitura di accomodamento ragionevole entro un ambito che non costituisce un onere eccessivo sono obbligati ai datori di lavoro.² La consulenza d’apertura «un dipendente non può usare l’app aziendale» è, di fatto, nel dominio dell’obbligo da ben prima del 2024.

flowchart TB
    accTitle: Il posizionamento di accomodamento ragionevole e miglioramento ambientale
    accDescr: Il rapporto tra un'impresa generale e una persona con disabilità cade sotto la legge antidiscriminazione, e fornire accomodamento ragionevole rispondendo a una richiesta individuale attraverso un dialogo costruttivo è un obbligo da aprile 2024; il campo dell'occupazione è un obbligo del datore di lavoro da aprile 2016 sotto la legge sull'occupazione; rendere l'app più facile da usare in anticipo è miglioramento ambientale, un obbligo di sforzo
    scene{"Quale scena?"}
    scene -->|Impresa + disabilità| kaisho["Legge antidiscriminazione"]
    scene -->|Occupazione / lavoro| koyou["Legge sull'occupazione"]
    kaisho --> moushide["Richiesta via dialogo"]
    moushide --> hairyo["Fornire accomodamento"]
    hairyo -.-> hairyoN["Obbligo dal 2024"]
    koyou --> koyougimu["Fornire accomodamento"]
    koyougimu -.-> koyouN["Obbligo dal 2016"]
    kaisho -.-> kankyo["App più facile in anticipo"]
    kankyo -.-> kankyoN["Miglioramento ambientale"]
    kankyoN -.-> kankyoN2["obbligo di sforzo"]
    kankyo -.-> moushide

Figura 2: La legge competente si spezza per scena; l’accomodamento ragionevole è un obbligo, e le correzioni preventive sono miglioramento ambientale, un obbligo di sforzo.

Come un caso individuale viene trattato in diritto dipende dalla situazione. Questo articolo non entra nell’interpretazione giuridica; procede dal punto di vista di cosa può fare un ingegnere quando viene chiesta una risposta. Per le fonti primarie, fate riferimento ai materiali del Cabinet Office e del Ministero della Salute, del Lavoro e del Welfare.¹²

2.2. JIS X 8341-3 e WCAG — I «criteri Web» si estendono anche al software

Sul lato dei criteri tecnici, sono concentrati in JIS X 8341-3:2016. Questo standard è uno standard corrispondente di ISO/IEC 40500:2012, e il corpo dello standard ha lo stesso contenuto di WCAG 2.0 del W3C.³ Se volete sapere concretamente di cosa consiste il «supporto all’accessibilità», leggere i criteri di successo WCAG (ora estesi in WCAG 2.1/2.2) è il percorso più corto, e ne è pubblicata anche una traduzione giapponese di WAIC.⁸

La domanda «WCAG è un criterio per i contenuti Web?» è legittima, ma il W3C ha organizzato, in una Group Note chiamata WCAG2ICT (Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies), come applicare i criteri di successo WCAG 2.0/2.1/2.2 a documenti e software non Web.⁴ In altre parole, ragionamenti come «alternative testuali», «contrasto», «uso da tastiera» e «il colore non è l’unico mezzo» si possono applicare a un’app desktop Windows nello stesso quadro del Web. I capitoli dal 3 in poi di questo articolo calano quel ragionamento in un’implementazione concreta WinForms/WPF.

flowchart TB
    accTitle: Il rapporto tra JIS X 8341-3 e WCAG
    accDescr: JIS X 8341-3:2016 è uno standard corrispondente con lo stesso contenuto di WCAG 2.0, e WCAG2ICT mostra come applicare i criteri di successo WCAG al software non Web, quindi un'app desktop Windows si può ispezionare nello stesso quadro
    wcag["WCAG 2.0 （W3C）"] ---|Uno standard corrispondente con lo stesso contenuto| jis["JIS X 8341-3:2016"]
    wcag --> ict["WCAG2ICT"]
    ict --> soft["Applicare al software non Web"]
    soft --> app["Un'app desktop Windows"]

Figura 3: JIS X 8341-3:2016 è uno standard corrispondente di WCAG 2.0, e WCAG2ICT estende gli stessi criteri alle app desktop.

3. Come la tecnologia assistiva legge un’app — Il trio di UI Automation

3.1. L’albero UIA, le proprietà e i pattern di controllo

Windows ha incorporata una fondazione di accessibilità chiamata UI Automation (UIA). UIA è un meccanismo che consente alla tecnologia assistiva come uno screen reader di ottenere informazioni sull’UI e di operare l’UI con mezzi diversi dall’input standard, e media tra il lato app (il provider) e il lato tecnologia assistiva (il client).⁵

Il mondo di UIA si può capire come il seguente trio.⁵

Quando uno screen reader mette a fuoco un pulsante, l’annuncio «pulsante Conferma ordine» è, grosso modo, la combinazione di Name + tipo di controllo. Quando l’utente esegue un’operazione «esegui», la tecnologia assistiva preme quel pulsante attraverso il pattern Invoke. In altre parole, se Name e i pattern sono esposti correttamente si può leggere e operare; se non sono esposti, è come se non esistesse anche se è visibile a schermo.

flowchart TB
    accTitle: Il trio di UI Automation
    accDescr: L'app, come provider, espone le proprietà e i pattern di controllo di ogni elemento sull'albero UIA; lo screen reader, come client, annuncia Name e ControlType e opera attraverso pattern come Invoke
    app["App （provider）"] --> tree["Albero UIA"]
    tree --> prop["Proprietà （Name, ControlType e simili）"]
    tree --> pat["Pattern （Invoke, Value e simili）"]
    sr["Screen reader （client）"] -->|Annuncia| prop
    sr -->|Opera| pat

Figura 4: Lo screen reader usa le proprietà e i pattern che l’app ha esposto sull’albero UIA per l’annuncio e l’operazione.

3.2. Uno screen reader è un client UIA

I principali screen reader usati su Windows includono Narrator, incorporato in Windows; NVDA,¹¹ che è libero e open source; e PC-Talker, un prodotto commerciale ampiamente usato in Giappone. Lo stile dell’annuncio differisce tra loro, ma il percorso primario per leggere l’UI di un’app desktop è UIA in ogni caso. Per questo la risposta lato app non è «supporto per un particolare screen reader» ma si concentra su esporre le informazioni corrette a UIA.

flowchart TB
    accTitle: Il percorso comune dei principali screen reader
    accDescr: Se l'app espone le informazioni corrette a UIA, Narrator, NVDA e PC-Talker possono tutti leggere l'UI dallo stesso percorso, quindi la risposta lato app non è rivolta a un particolare screen reader ma si concentra sull'esporre a UIA
    app["App"] -->|Espone informazioni| uia["UI Automation （UIA）"]
    uia --> nar["Narrator"]
    uia --> nvda["NVDA"]
    uia --> pct["PC-Talker"]
    app -.-> goal["La risposta si concentra sull'esporre a UIA"]

Figura 5: I principali screen reader prendono tutti UIA come percorso, quindi la risposta dell’app si concentra sull’esporre a UIA.

3.3. Come viene annunciato un «pulsante il cui Name è vuoto»?

Un esempio concreto. Supponete che una toolbar abbia un pulsante Salva che mostra solo un’icona di floppy disk. Per un utente vedente l’icona convoglia il significato, ma se Name è lasciato vuoto, uno screen reader annuncia questo pulsante solo come «pulsante». Se i vicini «Apri» e «Stampa» sono lo stesso, l’utente sente solo «pulsante, pulsante, pulsante» e non ha modo di sapere quale è quale. Anche la guida alle correzioni di accessibilità di Microsoft elenca un pulsante senza Name, e un’immagine annunciata solo come «Image», come problemi rappresentativi che fermano il lavoro dell’utente.⁷

Per fortuna, sia i controlli standard WinForms sia quelli WPF hanno il supporto UIA fin dall’inizio, e in molti casi Name viene deciso automaticamente dal testo o da un’etichetta. Ciò che si rompe è di solito uno di (1) solo-icona, senza materiale per un nome, (2) nessuna associazione con un’etichetta, o (3) disegno personalizzato che non mette informazioni sull’albero UIA. I due capitoli successivi guardano come sistemarlo per framework.

flowchart TB
    accTitle: Tre modi tipici in cui l'annuncio si rompe
    accDescr: L'annuncio si rompe quando non c'è materiale per un nome perché è solo-icona, quando non c'è associazione con un'etichetta, o quando il disegno personalizzato non mette informazioni sull'albero UIA, e finisce per essere annunciato solo come pulsante
    c1["Solo-icona, nessun materiale"] --> broken["Name diventa vuoto"]
    c2["Nessuna associazione con un'etichetta"] --> broken
    c3["Il disegno personalizzato non emette informazioni"] --> broken
    broken --> result["Annunciato solo come pulsante"]

Figura 6: La rottura dell’annuncio di solito si riduce a uno di tre pattern: materiale insufficiente per un nome, associazione insufficiente, o disegno personalizzato.

4. Implementazione in WinForms — AccessibleName e ordine di tabulazione

4.1. Controlli il cui Text diventa Name automaticamente, e controlli il cui Text non lo diventa

In WinForms, un controllo che mostra testo, come un Button o un CheckBox, usa il valore della proprietà Text come Name UIA. D’altro canto, ComboBox, ListBox, ListView, PictureBox, ProgressBar, TabControl, TextBox, TreeView e simili non fanno di Text il Name. Questi hanno bisogno di un nome per un’altra via.⁶

Il modo più manutenibile è piazzare una Label descrittiva nell’ordine di tabulazione immediatamente precedente del controllo obiettivo. Se impostate il TabIndex del controllo obiettivo perché venga subito dopo il TabIndex della Label, il testo di quella Label viene usato automaticamente come Name UIA. L’etichetta visibile a schermo e l’annuncio coincidono, e non dovete gestire la formulazione due volte.⁶¹²

Se non potete piazzare una Label, impostate AccessibleName in modo esplicito. Potete anche impostare AccessibleDescription se serve una spiegazione supplementare, e AccessibleRole se il ruolo differisce dall’aspetto.¹³

flowchart TB
    accTitle: Come viene deciso il nome di un controllo WinForms
    accDescr: Per Button e simili, Text diventa il Name UIA così com'è; per controlli come TextBox il cui Text non viene riusato, si usa il testo di una Label piazzata nell'ordine di tabulazione immediatamente precedente; se non potete piazzare una Label, impostate AccessibleName in modo esplicito
    ctrl["Controllo"] --> qtext{"Un tipo il cui Text diventa Name?"}
    qtext -->|Sì| usetext["Text diventa Name così com'è"]
    qtext -->|No| qlabel{"Una Label nell'ordine di tabulazione immediatamente precedente?"}
    qlabel -->|Sì| uselabel["Il testo della Label viene usato come Name"]
    qlabel -->|No| explicit["Impostate AccessibleName in modo esplicito"]

Figura 7: Per un Name WinForms, scegliete come deciderlo nell’ordine Text, una Label nell’ordine di tabulazione immediatamente precedente, AccessibleName.

// Un pulsante toolbar solo-icona: dichiarate esplicitamente il nome per l'annuncio
saveToolStripButton.AccessibleName = "Save";

// Un pulsante solo-immagine: nome + una spiegazione supplementare
btnSearchCustomer.AccessibleName = "Search customer";
btnSearchCustomer.AccessibleDescription = "Search the customer master by customer code or name";

// Impostatelo direttamente su un campo di input dove non potete piazzare una Label nell'ordine di tabulazione immediatamente precedente
txtOrderNo.AccessibleName = "Order number";

// Un PictureBox riusato come visualizzazione di un grafico: fate coincidere anche il ruolo con la realtà
pictureBoxChart.AccessibleRole = AccessibleRole.Chart;
pictureBoxChart.AccessibleName = "Monthly order-count chart";

Come avvertenza, se impostate AccessibleName una volta nel riquadro Proprietà di Visual Studio e poi lo cancellate, un’impostazione a stringa vuota può restare nel file designer e interferire con la risoluzione del nome di default. Cancellate la riga corrispondente dal file designer.⁶

flowchart TB
    accTitle: Il problema di un AccessibleName a stringa vuota che resta
    accDescr: Se impostate AccessibleName una volta nel riquadro Proprietà e poi lo cancellate, un'impostazione a stringa vuota resta nel file designer e interferisce con la risoluzione del nome di default, quindi lo sistemate cancellando la riga corrispondente dal file designer
    set["Impostate AccessibleName"] --> erase["Cancellatelo nel riquadro Proprietà"]
    erase --> remain["Resta un'impostazione a stringa vuota"]
    remain --> block["Interferisce con la risoluzione del nome di default"]
    block -.-> fix["Cancellate la riga corrispondente dal file designer"]

Figura 8: Cancellarlo nel riquadro Proprietà lascia comunque una stringa vuota, quindi lo sistemate cancellando la riga corrispondente dal file designer.

4.2. Miglioramenti comuni su una schermata di inserimento ordini

I posti che di fatto sistemiamo spesso nelle app aziendali sono riassunti come checklist.

Ognuno è una correzione di poche righe, ma per un utente di screen reader è il bivio tra «una schermata che non puoi usare» e «una schermata che puoi usare».

5. Implementazione in WPF — AutomationProperties e AutomationPeer

5.1. AutomationProperties.Name / LabeledBy / HelpText

In WPF, un controllo il cui Content è una stringa, come un Button, usa quel contenuto come Name UIA. Un pulsante solo-icona (Image o Path) non ha materiale per un Name, quindi lo dichiarate con AutomationProperties.Name, o se c’è testo di visualizzazione vicino lo associate con AutomationProperties.LabeledBy.⁷

TextBox ha un’avvertenza importante. Il Text di un TextBlock viene riusato come Name, ma il Text di un TextBox è esposto sul lato della proprietà UIA Value e non diventa Name. Per un campo di input, associare il TextBlock dell’etichetta di visualizzazione con LabeledBy è il primo candidato. Annuncio e visualizzazione a schermo coincidono, e evitate anche di gestire la formulazione due volte.¹⁴

<!-- Un campo di input: associate l'etichetta di visualizzazione con LabeledBy -->
<TextBlock x:Name="OrderNoLabel" Text="Order number" />
<TextBox
    AutomationProperties.LabeledBy="{Binding ElementName=OrderNoLabel}"
    AutomationProperties.AutomationId="OrderNoTextBox" />

<!-- Un pulsante solo-icona: dichiarate il nome, e un supplemento se serve -->
<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: Come viene deciso il nome di un controllo WPF
    accDescr: Un controllo il cui Content è una stringa usa quel contenuto come Name; altrimenti associare un'etichetta di visualizzazione vicina con LabeledBy è il primo candidato; se manca anche quella, dichiarate AutomationProperties.Name; il Text di un TextBox è esposto sul lato Value, non come Name
    ctrl["Controllo"] --> qc{"Content è una stringa?"}
    qc -->|Sì| auto["Il contenuto diventa Name"]
    qc -->|No| ql{"Un'etichetta di visualizzazione vicina?"}
    ql -->|Sì| lb["Associate con LabeledBy"]
    ql -->|No| nm["Impostate Name in modo esplicito"]
    tbx["Il Text di un TextBox"] -.-> val["Esposto come Value, non Name"]

Figura 9: Per un Name WPF, decidete nell’ordine stringa Content, LabeledBy, un’impostazione esplicita; il Text di un TextBox non diventa Name.

Informazioni supplementari che non stanno in Name si possono esporre con AutomationProperties.HelpText.⁷ Inoltre, AutomationId è un identificatore usato per l’identificazione degli elementi nei test UI automatizzati, quindi decidere una convenzione di naming in fase di progettazione della schermata si ripaga dopo (trattato in profondità in «Test UI automatizzati per le app desktop Windows»).

5.2. Un controllo personalizzato ha bisogno di un AutomationPeer

Un controllo personalizzato che disegnate voi stessi non può, così com’è, esporre informazioni significative sull’albero UIA. In WPF sovrascrivete OnCreateAutomationPeer su una classe derivata da UIElement e restituite una classe derivata da AutomationPeer per esporre nome, tipo e pattern. Se state ereditando un controllo esistente, ereditare il Peer corrispondente (ButtonBaseAutomationPeer per ButtonBase) vi consente di riprendere il comportamento già implementato.¹⁵

flowchart TB
    accTitle: Come le informazioni vengono esposte via AutomationPeer
    accDescr: Un controllo personalizzato espone nome, tipo e pattern sovrascrivendo OnCreateAutomationPeer e restituendo una classe derivata da AutomationPeer; se state ereditando un controllo esistente, ereditate il Peer corrispondente e riprendete il comportamento già implementato
    custom["Controllo personalizzato"] --> ov["OnCreateAutomationPeer"]
    ov --> peer["Restituite una classe derivata da Peer"]
    peer --> pub["Esponete nome, tipo e pattern"]
    inherit["Ereditate un controllo esistente"] -.-> basepeer["Ereditate il Peer corrispondente"]
    basepeer -.-> reuse["Riprendete il comportamento già implementato"]

Figura 10: Un controllo personalizzato restituisce un Peer da OnCreateAutomationPeer e espone informazioni a UIA.

// Un esempio di un controllo che disegna a mano lo stato di linea come una lampada colorata
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)
    {
        // Sollevate un evento di cambio proprietà UIA nel momento in cui il valore cambia. Senza questo,
        // uno screen reader tiene il vecchio nome e non può accorgersi del cambio di stato
        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; // Equivalente a testo se è una visualizzazione di stato senza operazione

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

Restituire un nome non basta; dirlo con un evento nel momento in cui cambia è anche il lavoro del Peer. La tecnologia assistiva non ha un proprio timing per riafferrare un valore, quindi un’implementazione che non solleva un evento di cambio è in uno stato di «corretto solo quando viene chiesto di nuovo», e un utente di screen reader non viene informato del cambio di stato.

sequenceDiagram
    accTitle: Il flusso di comunicare a uno screen reader un cambio di stato
    accDescr: Nel momento in cui il valore del controllo cambia, l'AutomationPeer solleva un evento di cambio della proprietà Name; la tecnologia assistiva non riafferra da sola, quindi senza l'evento resta sul vecchio nome e non può accorgersi del cambio
    participant c as Controllo
    participant p as AutomationPeer
    participant s as Screen reader
    c->>p: Il valore IsOnline cambia
    p->>s: Sollevate un evento di cambio della proprietà Name
    s->>s: Annunciate il nuovo stato
    Note over s: Senza l'evento resta sul vecchio nome

Figura 11: Un cambio di valore arriva a uno screen reader solo quando l’AutomationPeer lo comunica con un evento di cambio.

Se il controllo personalizzato ha un’operazione (si può premere, se ne può cambiare il valore, si può selezionare), sovrascrivete GetPattern e fornite un’interfaccia di pattern come IInvokeProvider o IRangeValueProvider.¹⁵ Il punto è che se costruite anche il Peer sul lato della libreria di controlli condivisi, ogni schermata che lo usa diventa supportata automaticamente. Quella è la fondazione del «estendere di lato» del capitolo 9.

6. Potete raggiungere ogni funzione dalla sola tastiera?

Il criterio di successo WCAG 2.1.1 (Keyboard) richiede che tutte le funzionalità del contenuto siano operabili attraverso un’interfaccia da tastiera.⁸ Un utente di screen reader in principio non usa il mouse, quindi una funzione che non potete raggiungere dalla tastiera è come una funzione che non esiste. I punti di vista dell’ispezione sono i seguenti.

Anche il walkthrough di accessibilità WinForms elenca, come basi, piazzare un’etichetta nell’ordine di tabulazione immediatamente precedente di un campo di input, e mettere tasti di accesso sui controlli e i menu verso cui l’utente vuole spostarsi.¹²

Ciò che vogliamo enfatizzare è che questo non è «un costo extra per il supporto alla disabilità». In un lavoro di routine come l’inserimento ordini, se potete completare l’input senza togliere le mani dalla posizione di home è ciò che decide il throughput di un operatore così com’è. Un ordine di tabulazione disordinato o un’operazione che richiede il mouse è un difetto che raschia un po’ ogni giorno dalla produttività di ogni utente. Supporto all’accessibilità ed efficienza da tastiera sono solo due nomi per lo stesso lavoro (per le priorità per ambiente di uso, vedete anche «Progettazione UX delle app Windows»).

flowchart TB
    accTitle: Il doppio effetto di mettere in ordine la tastiera
    accDescr: Mettere in piedi ordine di tabulazione, tasti di accesso e indicazione del focus produce due effetti insieme — un utente di tecnologia assistiva può raggiungere una funzione, e la velocità di input di ogni operatore — e una funzione usabile solo con il mouse è come una funzione che non esiste
    seibi["Mettete in ordine la tastiera"] --> a11y["Utenti di tecnologia assistiva"]
    seibi --> speed["La velocità di ogni operatore"]
    mouse["Una funzione solo-mouse"] -.-> none["Come inesistente"]

Figura 12: Mettere in ordine l’uso da tastiera realizza insieme il supporto alla tecnologia assistiva e l’efficienza per ogni utente; una funzione solo-mouse è come se non esistesse.

7. Colore e contrasto — 4,5:1 e «il colore non è l’unico mezzo»

7.1. La guida per il rapporto di contrasto è 4,5:1

Il criterio di successo WCAG 1.4.3 (Contrast (Minimum)) richiede un rapporto di contrasto di almeno 4,5:1 per testo e immagini di testo, e almeno 3:1 per il testo grande.⁸ Un design moderno che piazza testo grigio chiaro su uno sfondo bianco non è raro nel restare sotto questo criterio. Tra gli utenti di un’app aziendale ci sono persone la cui vista e visione dei colori sono cambiate con l’età, e persone che la usano in un ambiente poco illuminato come una fabbrica. Prendete l’abitudine di misurare con un contrast checker in revisione di design.

7.2. Non veicolate informazione solo con il colore

Il criterio di successo 1.4.1 (Use of Color) è che il colore non deve essere l’unico mezzo visivo per veicolare informazione.⁸ Esempi tipici in un’app aziendale sono i seguenti.

• Mostrare una riga di errore solo in testo rosso → fornite anche un’icona di errore e una colonna di messaggio
• Mostrare un campo obbligatorio solo con il colore dell’etichetta → aggiungete un «*» o la formulazione «Obbligatorio»
• Mostrare lo stato solo con il colore della lampada → fatelo colore + forma, o formulazione («In esecuzione», «Fermo»)

Data la diversità della visione dei colori, anche questo non è una «risposta speciale» ma una base della progettazione della visualizzazione.

flowchart TB
    accTitle: Sostituire l'informazione veicolata solo con il colore
    accDescr: Una visualizzazione che mostra un errore solo in testo rosso viene sostituita con un'icona di errore più una colonna di messaggio; una visualizzazione che mostra un campo obbligatorio solo con il colore dell'etichetta viene sostituita con l'aggiunta della formulazione Obbligatorio; una visualizzazione che mostra lo stato solo con il colore della lampada viene sostituita con la combinazione di forma o formulazione
    err["Un errore solo in testo rosso"] --> erra["Fornite anche un'icona e una formulazione"]
    req["Obbligatorio solo con il colore dell'etichetta"] --> reqa["Aggiungete la formulazione Obbligatorio"]
    lamp["Stato solo con il colore della lampada"] --> lampa["Combinate il colore con forma o formulazione"]

Figura 13: Esempi tipici di veicolare solo con il colore vengono sostituiti combinando un’icona, una formulazione e forma o testo.

7.3. Seguire un tema di contrasto (contrasto elevato)

Windows ha temi di contrasto (un tempo contrasto elevato) che passano a uno schema di colori con una forte separazione di primo piano e sfondo; l’utente può selezionare e modificare temi incorporati progettati perché il rapporto di contrasto sia in genere 7:1 o più.⁹ Il principio lato app è semplice: non hard-codificate i colori; rispettate i colori di sistema.

• WinForms: se lasciate ForeColor/BackColor al default, vengono usate le impostazioni di colore dell’utente. Dove avete applicato un colore vostro, giudicate con SystemInformation.HighContrast, passate a uno schema basato su SystemColors, e seguite un cambio di impostazioni con l’evento UserPreferenceChanged.¹²
• WPF/WinUI: se referenziate risorse della classe SystemColors, seguite un cambio di tema. I posti che avete riempito con un brush vostro diventano la causa della rottura.⁹

flowchart TB
    accTitle: Seguire un tema di contrasto
    accDescr: I posti in cui un colore è hard-codificato si rompono su un passaggio a un tema di contrasto, quindi passate a uno schema basato su SystemColors e seguite con un evento di cambio impostazioni; se referenziate i colori di sistema potete seguire automaticamente i colori dell'utente
    theme["Passaggio a un tema di contrasto"] --> qh{"Come è specificato il colore?"}
    qh -->|Hard-codificato| broken["Lo schema di colori si rompe"]
    qh -->|Riferimento al colore di sistema| ok["Segue automaticamente i colori dell'utente"]
    broken -.-> fix["Passate a SystemColors"]
    fix -.-> ev["Seguite con un evento di cambio impostazioni"]

Figura 14: Solo i posti in cui un colore è hard-codificato si rompono sotto un tema di contrasto; un riferimento al colore di sistema segue automaticamente.

Inoltre, un utente ipovedente usa spesso un’elevata magnificazione OS (DPI scaling), quindi il supporto high-DPI è anche parte del supporto all’accessibilità. Un’app il cui layout si rompe al 125%–200% è inutilizzabile a quel punto. Vedete «Supporto high-DPI in WinForms» e «Supporto high-DPI in WPF» per i dettagli.

8. La verifica in pratica — Accessibility Insights e un controllo pratico con screen reader

8.1. Accessibility Insights for Windows

Microsoft fornisce Accessibility Insights for Windows come strumento di verifica dell’accessibilità per le app Windows, con tre usi principali.¹⁰

• Live Inspect: basta passare il mouse su un elemento o metterlo a fuoco da tastiera, e potete confermare le sue proprietà UIA (Name, ControlType, pattern e simili). Il mezzo più corto per vedere «qual è il Name di questo pulsante».
• FastPass: un controllo leggero che rileva problemi di accessibilità ad alto impatto in meno di cinque minuti. I problemi che si possono giudicare meccanicamente, come un Name mancante, si possono inventariare per ogni schermata nuova.
• Troubleshooting: assiste la diagnosi e la correzione di un particolare problema. Da un problema rilevato potete camminare direttamente verso le guide di correzione per framework che cita anche questo articolo.

Inspect.exe e AccEvent, inclusi nel Windows SDK, possono anche confermare l’albero UIA e le proprietà, ma sono posizionati come strumenti legacy, e ora si raccomanda un passaggio a Accessibility Insights.¹⁰

flowchart TB
    accTitle: Tre usi di Accessibility Insights
    accDescr: Accessibility Insights for Windows fornisce la conferma delle proprietà UIA con Live Inspect, un controllo leggero dei problemi ad alto impatto con FastPass, e l'assistenza alla diagnosi e alla correzione di un problema con Troubleshooting; si raccomanda un passaggio da strumenti legacy come Inspect.exe
    ai["Accessibility Insights"] --> live["Live Inspect"]
    ai --> fast["FastPass"]
    ai --> ts["Troubleshooting"]
    live --> livef["Confermate le proprietà UIA"]
    fast --> fastf["Rilevate i problemi ad alto impatto"]
    ts --> tsf["Assistete diagnosi e correzione"]
    legacy["Inspect.exe e simili"] -.->|Si raccomanda un passaggio| ai

Figura 15: Accessibility Insights ha i tre usi di confermare, rilevare e diagnosticare, ed è la destinazione di un passaggio dagli strumenti legacy.

8.2. Un controllo pratico con uno screen reader

Ciò che il controllo automatico di uno strumento può rilevare sono solo i problemi che si possono giudicare meccanicamente. Alla fine, percorrete sempre un’operazione aziendale reale con uno screen reader. Narrator incorporato in Windows si può avviare subito con Ctrl+tasto Windows+Invio, e NVDA si può introdurre gratuitamente.¹¹ Il trucco del controllo è provare, senza guardare lo schermo (o con il display spento), affidandosi solo all’annuncio, se potete completare un compito reale come «inserire un ordine e confermarlo». Problemi come un nome presente ma un ordine di annuncio incoerente, o il focus che esce fuori da una modale, si trovano solo in pratica.

flowchart TB
    accTitle: Combinare la verifica con lo strumento e un controllo pratico
    accDescr: Ciò che un controllo automatico come FastPass può rilevare sono solo i problemi che si possono giudicare meccanicamente; il resto si trova in pratica percorrendo un'operazione aziendale reale con uno screen reader e trovando problemi di ordine di annuncio e di focus
    tool["Il controllo automatico di uno strumento"] --> kikai["Problemi che si possono giudicare meccanicamente"]
    tool -.-> nokori["Restano problemi che non può rilevare"]
    nokori --> sr["Un controllo pratico con uno screen reader"]
    sr --> task["Percorrete un'operazione aziendale"]
    task --> mieru["Problemi di ordine di annuncio e di focus"]

Figura 16: Inventariate i problemi meccanici con un controllo automatico, e trovate il resto con un controllo pratico con uno screen reader.

8.3. Incorporarlo nel flusso di sviluppo, e il reciproco ritorno con i test UI automatizzati

Per evitare che la verifica diventi dipendente dalla persona, raccomandiamo di incorporare la seguente checklist negli elementi di revisione di una schermata nuova.

E un’altra cosa. I test UI automatizzati con FlaUI e simili sono costruiti sulla stessa UIA che usano gli screen reader. Il Name e i pattern che mettete in piedi per l’accessibilità diventano parti del codice di test, e un AutomationId progettato per i test rende più facile il debug in Live Inspect. Viceversa, un’UI che non compare nell’albero UIA è invisibile sia ai test sia alla tecnologia assistiva. Accessibilità e testabilità sono due facce dello stesso investimento («Test UI automatizzati per le app desktop Windows»).

flowchart TB
    accTitle: Il reciproco ritorno di accessibilità e test UI automatizzati
    accDescr: Uno screen reader e i test UI automatizzati come FlaUI sono costruiti sulla stessa UIA, quindi il Name e i pattern che mettete in piedi si possono usare da entrambi, e un'UI che non compare nell'albero UIA è invisibile da entrambi
    uia["Mettere in ordine l'albero UIA"] --> sr["Uno screen reader può leggerlo"]
    uia --> test["Si può usare nei test UI automatizzati"]
    sr -.-> both["Due facce dello stesso investimento"]
    test -.-> both
    hidden["Un'UI che non compare in UIA"] -.-> invisible["Invisibile da entrambi"]

Figura 17: Poiché poggiano sulla stessa fondazione UIA, mettere in ordine l’albero UIA si ripaga sia per la tecnologia assistiva sia per i test UI automatizzati.

9. Come fissare le priorità — Non sistemate ogni schermata in una volta

Sistemare un sistema core di centinaia di schermate tutto in una volta è irrealistico sia in costo sia in qualità. L’approccio che raccomandiamo è i seguenti tre livelli.

1. Sistemate dalle schermate che quell’utente usa nel lavoro. L’accomodamento ragionevole è un processo di rispondere individualmente a una richiesta della persona interessata.¹ Prima fate operare alla persona il lavoro reale con uno screen reader, e identificate insieme dove si blocca. In molti casi le schermate usate nel lavoro quotidiano si restringono a poche o a una dozzina, e i problemi fatali tra loro (un pulsante senza nome, un pulsante di conferma che non si può premere da tastiera) si possono risolvere in una correzione di giorni.
2. Rendete il nuovo sviluppo conforme allo standard. Aggiungete la checklist del capitolo 8 alla Definition of Done, e costruite le schermate nuove supportate fin dall’inizio. A differenza di una correzione a posteriori, l’aumento di costo di incorporarlo in fase di progettazione è lieve.
3. Estendete di lato sistemando i controlli condivisi. Se implementate un AccessibleName di default o un AutomationPeer su parti condivise interne come un dialogo di ricerca, una griglia o un input data, ha effetto in blocco su ogni schermata che le usa. È una mossa di gran lunga più conveniente che toccare le schermate individuali una per una.

flowchart TB
    accTitle: I tre livelli di priorità di correzione
    accDescr: Sistemate dalle schermate che l'utente usa nel lavoro, rendete il nuovo sviluppo conforme allo standard con una checklist, ed estendete a ogni schermata sistemando i controlli condivisi
    s1["1. Sistemate dalle schermate che l'utente usa"] --> s2["2. Il nuovo lavoro è conforme allo standard"] --> s3["3. Estendete di lato con i controlli condivisi"]
    s3 -.-> all["Ha effetto in blocco su ogni schermata che li usa"]

Figura 18: Avanzate non sistemando ogni schermata in una volta ma nei tre livelli di schermate in uso, nuovo lavoro e parti condivise.

E un verbale del dialogo è importante quanto la risposta tecnica. L’accomodamento ragionevole è un processo di «dialogare e aggiustare individualmente», non di soddisfare pienamente ogni richiesta. Considerare un mezzo alternativo con la persona (fare quel lavoro su un’altra schermata, preparare un export CSV, coprirlo in operazioni) e accordarsi, per una correzione il cui onere è troppo pesante, è anche un esito legittimo del dialogo costruttivo.¹ Registrare cosa è stato chiesto, a cosa si è risposto e cosa è stato reso un mezzo alternativo diventa la prova di buona fede dell’organizzazione.

flowchart TB
    accTitle: Il flusso del dialogo costruttivo e di un verbale
    accDescr: Rispondete a una richiesta di una persona con disabilità attraverso un dialogo costruttivo; eseguite una correzione a cui si può rispondere; per una correzione il cui onere è troppo pesante, considerate un mezzo alternativo con la persona e accordatevi; registrate cosa è stato chiesto, a cosa si è risposto e cosa è stato reso un mezzo alternativo
    req["Una richiesta"] --> talk["Dialogo costruttivo"]
    talk --> q{"L'onere è troppo pesante?"}
    q -->|No| kaishu["Rispondete con una correzione"]
    q -->|Sì| alt["Considerate un mezzo alternativo e accordatevi"]
    kaishu --> rec["Registrate la cronologia"]
    alt --> rec

Figura 19: Nel dialogo costruttivo vi accordate con la persona su una correzione o un mezzo alternativo, e lasciate quella cronologia in un verbale.

10. Riepilogo

• Con la legge emendata per l’eliminazione della discriminazione nei confronti delle persone con disabilità in vigore da aprile 2024, la fornitura di accomodamento ragionevole è diventata un obbligo anche per le imprese. Il campo dell’occupazione è un obbligo del datore di lavoro dal 2016 sotto la legge sulla promozione dell’occupazione delle persone con disabilità. Rendere l’app più facile da usare in anticipo è «miglioramento ambientale» (un obbligo di sforzo), e più è andato avanti, più le risposte individuali diventano leggere.
• I criteri tecnici sono concentrati in WCAG (JIS X 8341-3:2016), e lo stesso ragionamento si può applicare a un’app desktop via WCAG2ICT.
• Uno screen reader legge un’app attraverso UI Automation. Il trio di albero UIA, proprietà (Name/ControlType/AutomationId) e pattern di controllo è la fondazione.
• La massima priorità è Name. WinForms usa AccessibleName e l’associazione di una Label all’ordine di tabulazione; WPF usa AutomationProperties.Name/LabeledBy; un controllo personalizzato usa un AutomationPeer.
• Poter raggiungere ogni funzione dalla sola tastiera è un criterio di successo WCAG e, allo stesso tempo, la produttività di ogni operatore. Mettete in ordine ordine di tabulazione, tasti di accesso e indicazione del focus.
• Le tre basi del colore sono un rapporto di contrasto di 4,5:1, il colore non è l’unico mezzo, e rispettare i colori di sistema in un tema di contrasto.
• Combinate la verifica con FastPass+Live Inspect in Accessibility Insights e un controllo pratico con Narrator/NVDA, e incorporatela nel flusso di sviluppo come checklist per una schermata nuova.
• Non sistemate ogni schermata in una volta; avanzate nell’ordine schermate che l’utente usa → supporto standard per il nuovo lavoro → un’estensione di lato dei controlli condivisi. L’accomodamento ragionevole è un processo di dialogo, e un verbale della cronologia protegge l’organizzazione.

Come primo passo raccomandiamo di prendere una delle vostre schermate principali, eseguire FastPass in Accessibility Insights for Windows, e poi percorrere il lavoro con il solo tasto Tab. In trenta minuti, la posizione attuale della vostra app diventa sorprendentemente concreta.

Articoli correlati

• Test UI automatizzati per le app desktop Windows — Come funziona UI Automation e come costruire test robusti con FlaUI
• Progettazione UX delle app Windows - Priorità per ambiente di uso
• Supporto high-DPI in WinForms — Perché l’UI si sfuoca o si rompe sui monitor 4K, e correzioni pratiche
• Supporto high-DPI in WPF — Perché si sfuoca e cola ancora nonostante sia «supposto DPI-aware», e come sistemarlo
• Perché KomuraSoft realizza siti web con il Design System della Digital Agency — costi contenuti e qualità elevata possono convivere
• Insidie di font e caratteri giapponesi — Gestire JIS2004, IVS e gaiji nelle app aziendali

Aree di consulenza correlate

KomuraSoft LLC si occupa di correzioni di accessibilità di app aziendali WinForms/WPF (supporto agli screen reader, mettere in ordine l’uso da tastiera, supporto ai temi di contrasto), dell’implementazione di un AutomationPeer sui controlli condivisi, e di consulenze su una diagnosi dello stato attuale e sul fissare le priorità con Accessibility Insights. Partire dallo stadio di «vogliamo confermare se un dipendente può usare la nostra app con uno screen reader» va bene.

• Sviluppo di app Windows
• Consulenza tecnica e revisione della progettazione
• Contattaci

Riferimenti

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Il supporto all'accessibilità di un'app aziendale è un obbligo di legge?

L'emendamento del 2021 alla legge per l'eliminazione della discriminazione nei confronti delle persone con disabilità è entrato in vigore il 1° aprile 2024, e la fornitura di accomodamento ragionevole alle persone con disabilità è diventata un obbligo anche per le imprese. L'accomodamento ragionevole è una risposta che, quando una persona con disabilità ne fa richiesta, rimuove una barriera individuale entro un ambito che non costituisce un onere eccessivo; rendere l'app più facile da usare in anticipo è posizionato come un obbligo di sforzo chiamato «miglioramento ambientale». L'occupazione, come il rapporto tra un dipendente e l'azienda, non cade sotto quella legge ma sotto la legge sulla promozione dell'occupazione delle persone con disabilità, che ha obbligato i datori di lavoro a fornire accomodamento ragionevole dall'emendamento in vigore da aprile 2016. In altre parole, una situazione «un dipendente non può usare l'app aziendale» è da tempo nel dominio dell'obbligo. Quanto spingersi in un caso concreto dipende dalla situazione individuale, quindi confermate le fonti primarie del Cabinet Office e del Ministero della Salute, del Lavoro e del Welfare e decidete nel dialogo con la persona interessata.

Come fa uno screen reader a leggere un'app desktop Windows?

Screen reader come Narrator e NVDA leggono l'UI di un'app attraverso una fondazione di accessibilità chiamata UI Automation (UIA). Lato app, gli elementi a schermo sono esposti in una struttura chiamata albero UIA; ogni elemento ha proprietà come Name (scopo) e ControlType (tipo), e pattern di controllo come Invoke (premere) e Value (valore). Lo screen reader annuncia queste informazioni come «pulsante Conferma ordine» e opera attraverso i pattern. I controlli standard WinForms e WPF hanno questo meccanismo fin dall'inizio, quindi il lavoro principale dello sviluppatore è non lasciare Name vuoto, rendere l'UI operabile da tastiera e implementare le informazioni sui controlli personalizzati.

Su un'app WinForms esistente, da dove dovremmo partire?

Il percorso più corto è eseguire FastPass in Accessibility Insights for Windows contro la schermata obiettivo e inventariare i controlli con Name vuoto e i problemi di ordine di tabulazione. Le correzioni partono da impostare AccessibleName sui pulsanti solo-icona, associare una Label nell'ordine di tabulazione immediatamente precedente di un campo di input, e riordinare TabIndex perché coincida con l'ordine visivo. Poi avviate Narrator o NVDA e percorrete un'operazione aziendale reale senza guardare lo schermo, e confermate dove vi bloccate. Non dovete sistemare ogni schermata in una volta; partire dalle schermate che qualcuno usa davvero, e rendere le schermate nuove conformi a una checklist, è realistico.

Cosa dovremmo fare per il supporto al contrasto elevato (tema di contrasto)?

La baseline è non hard-codificare i colori e rispettare i colori di sistema. In WinForms, lasciate ForeColor/BackColor al default o usate SystemColors, giudicate lo stato con SystemInformation.HighContrast, e seguite un cambio con l'evento UserPreferenceChanged. Anche in WPF e WinUI, se referenziate risorse della classe SystemColors, seguite automaticamente un cambio di tema. Allo stesso tempo, smettete di veicolare informazione «solo con il colore» — mostrare un errore solo in rosso — e combinatele con un'icona o una formulazione. Anche nel tema ordinario, prendere come guida il criterio WCAG di un rapporto di contrasto del testo di 4,5:1 o più rende l'UI più leggibile per un reparto poco illuminato e per gli utenti più anziani.

Il supporto all'accessibilità aiuta anche i test UI automatizzati?

Sì. Strumenti di test UI automatizzati come FlaUI sono costruiti sulla stessa UI Automation che usano gli screen reader. Name, ControlType e i pattern di controllo che mettete in piedi per l'accessibilità si possono usare così come sono dal codice di test, e un AutomationId progettato per i test stabilizza l'identificazione degli elementi. Viceversa, un'UI disegnata a mano che non compare nell'albero UIA è invisibile sia a uno screen reader sia ai test. Accessibilità e test automatizzati sono un investimento nella stessa fondazione, quindi mettere in piedi l'uno abbassa anche il costo dell'altro.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.