UI Automation y Microsoft Active Accessibility

Nota
Esta documentación está dirigida a desarrolladores de .NET Framework que desean usar las clases administradas de UI Automation definidas en el espacio de nombres System.Windows.Automation.Para obtener información actualizada sobre UI Automation, vea Windows Automation API: UI Automation.

Microsoft Active Accessibility fue la solución anterior para hacer las aplicaciones accesibles. Microsoft UI Automation es el nuevo modelo de accesibilidad para Microsoft Windows y está diseñado para abordar las necesidades de los productos de tecnología de ayuda y las herramientas de prueba automatizadas. UI Automation proporciona numerosas mejoras con respecto a Active Accessibility.

En este tema se incluyen las características principales de UI Automation y se explica en qué se diferencian de Active Accessibility.

Este tema contiene las secciones siguientes.

• Lenguajes de programación
• Compatibilidad en Windows Presentation Foundation
• Servidores y clientes
• Elementos de interfaz de usuario
• Vistas de árbol y navegación
• Funciones y tipos de control
• Estados y propiedades
• Eventos
• Seguridad
• Temas relacionados

Lenguajes de programación

Active Accessibility está basado en el Component Object Model (COM), con compatibilidad con interfaces duales; por lo tanto, se puede programar en C/C++, Microsoft Visual Basic 6.0 y lenguajes de scripting. La UI Automation (incluida la biblioteca de controles estándar del proveedor de cliente) se escribe en código administrado y las aplicaciones cliente de Automatización de la interfaz de usuario se programan más fácilmente en Microsoft Visual C# o Microsoft Visual Basic .NET. Los proveedores de Automatización de la interfaz de usuario, que son implementaciones de interfaz, se pueden escribir en código administrado o en C/C++.

Compatibilidad en Windows Presentation Foundation

Windows Presentation Foundation (WPF) es el nuevo modelo para crear interfaces de usuario. Los elementos de WPF no contienen compatibilidad nativa con Active Accessibility; no obstante, sí admiten UI Automation, que incluye compatibilidad puente con clientes Active Accessibility. Sólo los clientes escritos específicamente para UI Automation pueden aprovechar totalmente las características de accesibilidad de WPF, como las eficaces funciones para texto.

Servidores y clientes

En Active Accessibility, los servidores y clientes se comunican directamente, sobre todo a través de la implementación de IAccessible en el servidor.

En UI Automation, entre el servidor (proveedor) y el cliente se encuentra un servicio principal. El servicio principal realiza llamadas a las interfaces implementadas por los proveedores y proporciona servicios adicionales, como la generación de identificadores únicos para los elementos en tiempo de ejecución. Las aplicaciones cliente usan funciones de biblioteca para llamar al servicio de UI Automation.

Los proveedores de Automatización de la interfaz de usuario pueden proporcionar información a los clientes de Active Accessibility y los servidores de Active Accessibility pueden proporcionar información a las aplicaciones cliente de Automatización de la interfaz de usuario. Sin embargo, debido a que Active Accessibility no expone tanta información como UI Automation, los dos modelos no son totalmente compatibles.

Elementos de interfaz de usuario

Active Accessibility presenta los elementos de la UI como una interfaz IAccessible o como un identificador secundario. Es difícil comparar dos punteros IAccessible para determinar si hacen referencia al mismo elemento.

En UI Automation, cada elemento se representa como un objeto AutomationElement. La comparación se realiza mediante el uso del operador de igualdad o el método Equals; ambos comparan los identificadores únicos de los elementos en tiempo de ejecución.

Vistas de árbol y navegación

Los elementos de la user interface (UI) en la pantalla se pueden ver como una estructura en árbol con el escritorio como raíz, las ventanas de la aplicación como elementos secundarios inmediatos y los elementos dentro de las aplicaciones como descendientes más lejanos.

En Active Accessibility, se exponen en el árbol muchos elementos de automatización que son irrelevantes para el usuario final. Las aplicaciones cliente tienen que revisar todos los elementos para determinar cuáles son significativos.

Las aplicaciones cliente de Automatización de la interfaz de usuario ven la UI a través de una vista filtrada. La vista sólo contiene elementos de interés, los que proporcionan información al usuario o permiten su interacción. Existen vistas predefinidas que únicamente contienen elementos de control o de contenido; además, las aplicaciones pueden definir vistas personalizadas. UI Automation simplifica la tarea de describir UI al usuario y ayudarle a interactuar con la aplicación.

La navegación entre los elementos en Active Accessibility es espacial (por ejemplo, desplazamiento hasta el elemento que se encuentra a la izquierda en la pantalla), lógica (por ejemplo, desplazamiento hasta el siguiente elemento de menú o hasta el siguiente elemento por orden de tabulación en un cuadro de diálogo) o jerárquica (por ejemplo, desplazamiento del primer elemento secundario en un contenedor o desplazamiento desde el elemento secundario hasta su elemento primario). La navegación jerárquica se complica por el hecho de que los elementos secundarios no siempre son objetos que implementan IAccessible.

En la UI Automation, todos los elementos de la UI son objetos AutomationElement que admiten la misma funcionalidad básica. (Desde el punto de vista del proveedor, son objetos que implementan una interfaz heredada de IRawElementProviderSimple.) La navegación es principalmente jerárquica: de los elementos primarios a los elementos secundarios y de un elemento del mismo nivel al siguiente. (La navegación entre elementos del mismo nivel tiene un componente lógico, ya que puede seguir el orden de tabulación.) La navegación es posible desde cualquier punto inicial, usando cualquier vista filtrada del árbol, mediante la clase TreeWalker. La navegación a elementos secundarios o descendientes determinados también es posible mediante FindFirst y FindAll; por ejemplo, es muy fácil de recuperar todos los elementos de un cuadro de diálogo que admiten un patrón de control especificado.

La navegación en UI Automation es más coherente que en Active Accessibility. Algunos elementos, como las listas desplegables y las ventanas emergentes, aparecen dos veces en el árbol de Active Accessibility y la navegación desde ellos puede generar resultados imprevistos. Es realmente imposible implementar Active Accessibility correctamente para un control rebar. UI Automation permite cambiar los elementos primarios y de posición para que un elemento se pueda colocar en cualquier parte del árbol a pesar de la jerarquía impuesta por la propiedad de las ventanas.

Funciones y tipos de control

Active Accessibility usa la propiedad accRole (IAccessible::get_actRole) para recuperar una descripción de la función del elemento en la UI, como ROLE_SYSTEM_SLIDER o ROLE_SYSTEM_MENUITEM. La función de un elemento es la principal indicación de la funcionalidad de que dispone. La interacción con un control se logra mediante el uso de métodos fijos como IAccessible::accSelect e IAccessible::accDoDefaultAction. La interacción entre la aplicación cliente y la UI se limita a lo que se puede hacer a través de IAccessible.

Por el contrario, la UI Automation prácticamente rompe el vínculo entre el tipo de control del elemento (descrito en la propiedad ControlType) y su funcionalidad prevista. La funcionalidad viene determinada por los patrones de control que el proveedor admite a través de su implementación de interfaces especializadas. Los patrones de control se pueden combinar para describir el conjunto completo de funcionalidad que admite un elemento concreto de la UI. Algunos proveedores deben admitir un patrón de control determinado; por ejemplo, el proveedor de una casilla debe admitir el patrón de control Toggle. Otros proveedores deben admitir uno o varios patrones de control de un conjunto; por ejemplo, un botón debe admitir Toggle o Invoke. Quedan otros que no admiten ningún patrón de control en absoluto; por ejemplo, un panel que no se puede mover, cambiar de tamaño o acoplar no tiene ningún patrón de control.

La UI Automation admite controles personalizados, que se identifican mediante la propiedad Custom y pueden describirse mediante la propiedad LocalizedControlTypeProperty.

En la tabla siguiente se muestra la asignación de funciones de Active Accessibility a tipos de control de UI Automation.

Para obtener información acerca de los distintos tipos de control, consulte Tipos de control de UI Automation.

Estados y propiedades

En Active Accessibility, los elementos admiten un conjunto común de propiedades y algunas propiedades (como accState) deben describir cosas muy diferentes, dependiendo de la función del elemento. Los servidores deben implementar todos los métodos de IAccessible que devuelven una propiedad, incluso aquéllos que no son pertinentes al elemento.

La UI Automation define muchas más propiedades, algunas de las cuales se corresponden con los estados de Active Accessibility. Algunas son comunes a todos los elementos, mientras que otras son específicas de los tipos de control y patrones de control. Las propiedades se distinguen por sus identificadores únicos y la mayoría se puede recuperar mediante un solo método, GetCurrentPropertyValue o GetCachedPropertyValue. Muchas propiedades también se pueden recuperar de los descriptores de acceso de propiedad Current y Cached.

Un proveedor de Automatización de la interfaz de usuario no tiene que implementar propiedades irrelevantes, sino simplemente devolver un valor null para todas las propiedades que no admite. Asimismo, el servicio principal de UI Automation puede obtener algunas propiedades del proveedor predeterminado de la ventana, y éstas se combinan con las propiedades implementadas explícitamente por el proveedor.

Además de admitir muchas más propiedades, la UI Automation mejora el rendimiento, ya que permite recuperar varias propiedades con una sola llamada entre procesos.

En la tabla siguiente se muestra la correspondencia entre las propiedades de ambos modelos.

En la tabla siguiente se muestra qué propiedades de UI Automation se corresponden con las constantes de estado de Active Accessibility.

Los estados siguientes o bien no fueron implementados por la mayoría de los servidores de control de Active Accessibility o no tenían equivalentes en UI Automation.

Para obtener una lista completa de los identificadores de propiedad de UI Automation, consulte Información general acerca de las propiedades de UI Automation.

Eventos

El mecanismo de eventos de UI Automation, a diferencia del que está presente en Active Accessibility, no se basa en el enrutamiento de eventos de Windows (que está estrechamente relacionado con los identificadores de ventana) y no requiere que la aplicación cliente configure enlaces. Las suscripciones a eventos se pueden ajustar no sólo a eventos determinados, sino a partes específicas del árbol. Los proveedores también pueden ajustar los eventos que provocan mediante un seguimiento de los eventos para los que se realizan escuchas.

Para los clientes también es más sencillo recuperar los elementos que provocan eventos, ya que éstos se pasan directamente a la devolución de llamada del evento. Las propiedades del elemento se capturan previamente de forma automática si había una solicitud de caché activa cuando el cliente se suscribió al evento.

En la tabla siguiente se muestra la correspondencia entre WinEvents de Active Accessibility y los eventos de UI Automation.

Seguridad

Algunos escenarios de personalización de IAccessible requieren que se ajuste un IAccessible base y que las llamadas se realicen a través del mismo. Esto podría comprometer la seguridad, ya que un componente que no es totalmente de confianza no debería ser intermediario en una ruta acceso a código.

El modelo de UI Automation evita que los proveedores tengan que llamar a código de otro proveedor a través de este elemento. El servicio principal de UI Automation realiza todas las operaciones de agregación necesarias.

Vea también

Otros recursos

Fundamentos de UI Automation