Automazione interfaccia utente e Microsoft Active Accessibility

Nota
La presente documentazione è destinata agli sviluppatori di .NET Framework che desiderano utilizzare le classi UI Automation gestite definite nello spazio dei nomi System.Windows.Automation.Per informazioni aggiornate sull'UI Automation, vedere Windows Automation API: Automazione interfaccia utente (la pagina potrebbe essere in inglese).

Microsoft Active Accessibility è la soluzione utilizzata in precedenza per rendere accessibili le applicazioni. Microsoft UI Automation è il nuovo modello di accessibilità per Microsoft Windows, destinato a rispondere ai requisiti di prodotti di Assistive Technology e strumenti di test automatizzati. UI Automation offre numerosi miglioramenti rispetto a Active Accessibility.

In questo argomento vengono descritte le principali funzionalità di UI Automation e vengono illustrate le differenze tra queste funzionalità e quelle di Active Accessibility.

Nel presente argomento sono contenute le seguenti sezioni.

• Linguaggi di programmazione
• Supporto in Windows Presentation Foundation
• Server e client
• Elementi di interfaccia
• Visualizzazioni e spostamento nella struttura ad albero
• Ruoli e tipi di controllo
• Stati e proprietà
• Eventi
• Sicurezza
• Argomenti correlati

Linguaggi di programmazione

Il sistema Active Accessibility è basato su Component Object Model (COM), con il supporto per doppie interfacce, ed è pertanto programmabile in C/C++, Microsoft Visual Basic 6.0 e linguaggi di scripting. Il sistema di UI Automation (inclusa la libreria di provider lato client per i controlli standard) è scritto in codice gestito, quindi le applicazioni client di animazione interfaccia utente vengono programmate più facilmente utilizzando Microsoft Visual C# o Microsoft Visual Basic .NET. I provider di automazione interfaccia utente, che corrispondono a implementazioni di interfaccia, possono essere scritti in codice gestito o in C/C++.

Supporto in Windows Presentation Foundation

Windows Presentation Foundation (WPF) è il nuovo modello per la creazione di interfacce utente. Gli elementi WPF non contengono supporto nativo per Active Accessibility; tuttavia, supportano l'UI Automation, che include il supporto provvisorio per i client Active Accessibility. Solo i client scritti specificamente per UI Automation possono trarre il massimo vantaggio dalle funzionalità di accessibilità di WPF, ad esempio il supporto completo per il testo.

Server e client

In Active Accessibility i server e i client possono comunicare direttamente, soprattutto tramite l'implementazione del server di IAccessible.

In UI Automation tra il server (denominato provider) e il client è disponibile un servizio di base che effettua chiamate alle interfacce implementate dai provider e fornisce servizi aggiuntivi, ad esempio la generazione di identificatori di runtime univoci per gli elementi. Le applicazioni client utilizzano funzioni di libreria per chiamare il servizio di UI Automation.

I provider di automazione interfaccia utente possono fornire informazioni ai client Active Accessibility, mentre i server Active Accessibility possono fornire informazioni alle applicazioni client di automazione interfaccia utente. Tuttavia, poiché Active Accessibility non espone la stessa quantità di informazioni di UI Automation, i due modelli non sono completamente compatibili.

Elementi di interfaccia

Active Accessibility presenta gli elementi dell'UI come interfaccia IAccessible o come identificatore di elemento figlio. È difficile confrontare due puntatori IAccessible per determinare se fanno riferimento allo stesso elemento.

In UI Automation ogni elemento è rappresentato come oggetto AutomationElement. Il confronto viene eseguito utilizzando l'operatore di uguaglianza o il metodo Equals, che confrontano entrambi gli identificatori di runtime univoci degli elementi.

Visualizzazioni e spostamento nella struttura ad albero

Gli elementi dell'user interface (UI) possono essere visualizzati sullo schermo come una struttura ad albero, con il desktop che funge da radice, le finestre delle applicazioni da elementi figlio immediati e gli elementi all'interno delle applicazioni da ulteriori discendenti.

In Active Accessibility molti elementi di automazione irrilevanti per gli utenti finali vengono esposti nella struttura ad albero. Le applicazioni client devono esaminare tutti gli elementi per determinare quali sono significativi.

Le applicazioni client di automazione interfaccia utente vedono l'UI tramite una visualizzazione filtrata, che contiene solo elementi di interesse, ossia quelli che forniscono informazioni all'utente o consentono l'interazione. Sono disponibili visualizzazioni predefinite di soli elementi controllo e di soli elementi contenuto; inoltre, le applicazioni possono definite visualizzazioni personalizzate. Inoltre, UI Automation semplifica l'attività di descrivere l'UI all'utente e l'interazione dell'utente con l'applicazione.

In Active Accessibility lo spostamento tra elementi è spaziale (ad esempio lo spostamento all'elemento che si trova a sinistra dello schermo), logico (ad esempio lo spostamento alla voce di menu successiva o all'elemento successivo nell'ordine di tabulazione in una finestra di dialogo) o gerarchico (ad esempio lo spostamento del primo elemento figlio in un contenitore o dall'elemento figlio all'elemento padre). Lo spostamento gerarchico è complicato dai fatto che gli elementi figlio non sono sempre oggetti che implementano IAccessible.

In UI Automation tutti gli elementi dell'UI sono oggetti AutomationElement che supportano la stessa funzionalità di base. Dal punto di vista del provider, si tratta di oggetti che implementano un'interfaccia ereditata da IRawElementProviderSimple. Lo spostamento è prevalentemente gerarchico: dagli elementi padre agli elementi figlio e da un elemento di pari livello al successivo. Lo spostamento tra elementi di pari livello include un elemento logico, in quanto può seguire l'ordine di tabulazione. È possibile spostarsi da qualsiasi punto iniziale, utilizzando qualsiasi visualizzazione filtrata della struttura ad albero, tramite la classe TreeWalker. È inoltre possibile spostarsi su determinati elementi figlio o discendenti tramite FindFirst e FindAll; ad esempio, è estremamente facile recuperare tutti gli elementi di una finestra di dialogo che supportano un pattern di controllo specificato.

Lo spostamento in UI Automation è più coerente rispetto a Active Accessibility. Alcuni elementi, ad esempio elenchi a discesa e finestre popup, vengono visualizzati due volte nella struttura ad albero di Active Accessibility, quindi lo spostamento da questi elementi può generare risultati imprevisti. È di fatto impossibile implementare correttamente Active Accessibility per un controllo Rebar. UI Automation consente l'assegnazione di nuovi elementi padre e il riposizionamento; pertanto, un elemento può essere posizionato in qualsiasi punto della struttura ad albero nonostante la gerarchia imposta dalla proprietà delle finestre.

Ruoli e tipi di controllo

In Active Accessibility viene utilizzata la proprietà accRole (IAccessible::get_actRole) per recuperare una descrizione del ruolo dell'elemento nell'UI, ad esempio ROLE_SYSTEM_SLIDER o ROLE_SYSTEM_MENUITEM. Il ruolo di un elemento rappresenta l'indicazione principale della relativa funzionalità disponibile. L'interazione con un controllo si ottiene utilizzando metodi fissi, ad esempio IAccessible::accSelect e IAccessible::accDoDefaultAction. L'interazione tra l'applicazione client e l'UI è limitata alle operazioni che è possibile eseguire tramite IAccessible.

Viceversa, in UI Automation il tipo di controllo dell'elemento (descritto dalla proprietà ControlType) è nettamente separato dalla relativa funzionalità prevista. La funzionalità è determinata dai pattern di controllo che sono supportati dal provider tramite la relativa implementazione di interfacce specializzate. I pattern di controllo possono essere combinati per descrivere l'insieme completo di funzionalità supportate da un determinato elemento dell'UI. Alcuni provider devono supportare un determinato pattern di controllo. Ad esempio il provider per una casella di controllo deve supportare il pattern di controllo Toggle. Altri provider devono supportare uno o più insiemi di pattern di controllo. Ad esempio un pulsante deve supportare Toggle o Invoke. Altri provider ancora non supportano affatto i pattern di controllo. Ad esempio un riquadro che non può essere spostato, ridimensionato o ancorato non include alcun pattern di controllo.

UI Automation supporta i controlli personalizzati, che sono identificati dalla proprietà Custom e possono essere descritti dalla proprietà LocalizedControlTypeProperty.

Nella tabella seguente è illustrato il mapping tra i ruoli di Active Accessibility e i tipi di controllo di UI Automation.

Per ulteriori informazioni sui diversi tipi di controllo, vedere Tipi di controllo per l'automazione dell'interfaccia utente.

Stati e proprietà

In Active Accessibility gli elementi supportano un insieme comune di proprietà e alcune proprietà (ad esempio accState) devono descrivere aspetti molto diversi, a seconda del ruolo dell'elemento. I server devono implementare tutti i metodi di IAccessible che restituiscono una proprietà, anche quelli che non sono attinenti all'elemento.

In UI Automation sono definite molte più proprietà, alcune delle quali corrispondono agli stati di Active Accessibility. Alcune sono comuni a tutti gli elementi, mentre altre sono specifiche dei tipi di controllo e dei pattern di controllo. Le proprietà sono differenziate da identificatori univoci e la maggior parte può essere recuperata con un singolo metodo GetCurrentPropertyValue o GetCachedPropertyValue. Molte proprietà sono anche facilmente recuperabili tramite le funzioni di accesso alle proprietà Current e Cached.

Un provider di automazione interfaccia utente non deve implementare proprietà irrilevanti, ma può restituire semplicemente un valore null per tutte le proprietà che non supporta. Inoltre, il servizio di base di UI Automation può ottenere alcune proprietà dal provider di finestre predefinito, che vengono combinate con le proprietà implementate in modo esplicito dal provider.

Oltre a supportare un numero maggiore di proprietà, UI Automation fornisce prestazioni più elevate consentendo il recupero di più proprietà con una singola chiamata tra più processi.

Nella tabella seguente è illustrata la corrispondenza tra le proprietà nei due modelli.

Nella tabella seguente sono illustrate le proprietà di UI Automation che corrispondono alle costanti di stato di Active Accessibility.

I seguenti stati non sono stati implementati dalla maggior parte dei server di controllo di Active Accessibility o non hanno equivalenti in UI Automation.

Per un elenco completo di identificatori di proprietà di UI Automation, vedere Cenni preliminari sulle proprietà di automazione interfaccia utente.

Eventi

Il meccanismo degli eventi di UI Automation, a differenza di quello di Active Accessibility, non si basa sull'indirizzamento di eventi (che è strettamente collegato agli handle di finestra) e non richiede l'impostazione di hook da parte dell'applicazione client. La sottoscrizione di eventi può essere ottimizzata non solo per determinati eventi ma anche per determinate parti della struttura ad albero. I provider possono inoltre ottimizzare la generazione di eventi tenendo traccia degli eventi per i quali esistono elementi in ascolto.

È inoltre più facile per i client recuperare gli elementi che generano eventi, in quanto vengono passati direttamente al callback dell'evento. Le proprietà dell'elemento vengono automaticamente prelette se era attiva una richiesta di cache quando il client ha sottoscritto l'evento.

Nella tabella seguente è illustrata la corrispondenza tra eventi WinEvent di Active Accessibility e eventi di UI Automation.

Sicurezza

Alcuni scenari di personalizzazione di IAccessible richiedono il wrapping di un oggetto IAccessible di base e la chiamata a tale oggetto. Questa operazione ha implicazioni per la sicurezza, in quanto un componente parzialmente attendibile non deve essere un intermediario in un percorso di codice.

Il modello di UI Automation rimuove la necessità che i provider effettuino chiamate ad altro codice di provider. Tutta l'aggregazione necessaria viene completata dal servizio di base di UI Automation.

Vedere anche

Altre risorse

Nozioni fondamentali sull'automazione interfaccia utente