KomuraSoft LLC
Contáctenos
Menú

Introducción a la accesibilidad en aplicaciones Windows — UI Automation y cómo prepararse para la obligatoriedad del ajuste razonable

· Actualizado el: · · Accesibilidad, UI Automation, Windows, WinForms, WPF, Ajuste razonable, Lector de pantalla, Ley de eliminación de la discriminación por discapacidad, Aplicaciones empresariales

«Un empleado con discapacidad visual que contratamos en un proceso de selección intermedia no puede usar con un lector de pantalla nuestra aplicación básica de entrada de pedidos. Utiliza el navegador web y el correo sin ningún problema, pero solo con nuestra aplicación empresarial la lectura no funciona bien. ¿Hay alguna forma de solucionarlo?» — cada vez recibimos más consultas de este tipo por parte de los departamentos de sistemas de información de nuestros clientes.

Una de las razones de fondo es el marco legal. La Ley de Eliminación de la Discriminación por Discapacidad, reformada en 2021, entró en vigor el 1 de abril de 2024 y obligó también a las empresas a “proporcionar ajustes razonables” a las personas con discapacidad.1 Y yendo más allá, la relación entre un empleado y su empresa mencionada al principio (el ámbito laboral) corresponde a la Ley de Promoción del Empleo de Personas con Discapacidad, que obliga a los empleadores a proporcionar ajustes razonables desde abril de 2016.2 La idea de que “la accesibilidad es un tema de sitios web y no tiene relación con las aplicaciones Windows internas” ya no se sostiene, ni desde el punto de vista legal ni desde el práctico.

Por otro lado, desde el terreno del desarrollo, creemos que lo más honesto es reconocer que “no se sabe bien qué hacer”. La accesibilidad de las aplicaciones de escritorio de Windows cuenta con mucha menos información que la web, y no existe ninguna solución mágica que se pueda aplicar a posteriori. Sin embargo, tampoco hay que ser pesimistas. Si se comprende el mecanismo con el que el lector de pantalla lee la aplicación (UI Automation) y se cubren lo básico —nombre, teclado y color—, la usabilidad de la aplicación empresarial mejora enormemente. Y buena parte de estas mejoras aumentan la productividad de todos los usuarios, tengan o no una discapacidad.

Este artículo está dirigido a desarrolladores de aplicaciones empresariales y responsables de sistemas de información en Japón, y conecta de un tirón desde un repaso mínimo del marco legal y las normas, pasando por el mecanismo de UI Automation, la implementación en WinForms/WPF, el manejo por teclado, el color y el contraste, las herramientas de verificación, hasta una forma realista de establecer prioridades.

Flujo de este artículoEstructura del artículo que conecta en orden el repaso del marco legal y las normas, el mecanismo de UI Automation, la implementación en WinForms y WPF, el manejo por teclado, el color y el contraste, las herramientas de verificación y el orden de prioridadesMarco legal y normasMecanismo de UI AutomationImplementación en WinForms/WPFManejo por tecladoColor y contrasteHerramientas de verificaciónOrden de prioridades

Figura 1: Este artículo conecta en un solo flujo el marco legal, el mecanismo, la implementación, la verificación y las prioridades.

1. Conclusión principal

  • La provisión de ajustes razonables es obligatoria para las empresas desde el 1 de abril de 2024. Cuando una persona con discapacidad manifiesta la voluntad de que se elimine una barrera, se exige responder dentro de un margen de carga que no sea excesivo. El ámbito laboral está sujeto a la Ley de Promoción del Empleo de Personas con Discapacidad, que obliga al empleador desde abril de 2016.12
  • El ajuste razonable es un proceso de “responder a la solicitud individual mediante diálogo constructivo”, y la adaptación previa de la aplicación corresponde al “acondicionamiento del entorno” (obligación de esfuerzo). No es obligatoria una respuesta previa perfecta; lo importante es no negarse unilateralmente al diálogo.1
  • Los criterios técnicos de accesibilidad se concentran en WCAG (JIS X 8341-3:2016). JIS X 8341-3:2016 es una norma idéntica en contenido a WCAG 2.0, y WCAG2ICT del W3C ofrece la guía de aplicación a software no web. Las aplicaciones de escritorio también se pueden revisar con el mismo criterio.34
  • Los lectores de pantalla leen la aplicación a través de UI Automation (UIA). Las propiedades como Name y ControlType de cada elemento del árbol de UIA, junto con los patrones de control como Invoke, Value y SelectionItem, son el material de la lectura y la operación.5
  • Un botón con Name vacío se lee solo como “botón”. La corrección de máxima prioridad es la asignación de nombres. En WinForms se atiende con AccessibleName y la asociación de Label con el orden de tabulación; en WPF, con AutomationProperties.Name/LabeledBy.67
  • Que se pueda llegar a todas las funciones solo con el teclado es un criterio de conformidad de WCAG (2.1.1) y, a la vez, la propia velocidad de entrada de un operador experto. Preparar el orden de tabulación, las teclas de acceso y la indicación de foco se traduce directamente en eficiencia para todos los usuarios.8
  • Tome como referencia una relación de contraste de texto de al menos 4.5:1 y no comunique información solo con el color. En el tema de contraste (alto contraste), respete los colores del sistema en lugar de colores codificados de forma fija.89
  • La verificación combina FastPass de Accessibility Insights for Windows con la comprobación real mediante lector de pantalla. Como ambos se apoyan en la misma base de UIA, esta preparación también beneficia mutuamente a los activos de pruebas automatizadas de UI como FlaUI.10
  • No es necesario corregir todas las pantallas a la vez. El orden realista es: ① empezar por la pantalla que usa esa persona, ② tratar el desarrollo nuevo de forma estándar, y ③ extender mediante la corrección de los controles comunes.

Resumido en una frase, la accesibilidad consiste en “exponer el nombre y las operaciones correctas en el árbol de UIA, y respetar lo básico del teclado y el color”.

2. Repaso del marco legal y las normas — qué cambió con la «obligatoriedad»

2.1. Ley de Eliminación de la Discriminación por Discapacidad — desde abril de 2024, las empresas también deben «proporcionar ajustes razonables»

La Ley de Eliminación de la Discriminación por Discapacidad es una ley que prohíbe a los organismos administrativos y a las empresas el «trato discriminatorio injusto» hacia las personas con discapacidad y les exige «proporcionar ajustes razonables». Con la reforma de 2021 (era Reiwa 3), lo que hasta entonces era una obligación de esfuerzo para las empresas —proporcionar ajustes razonables— pasó a ser obligatorio, y la ley reformada entró en vigor el 1 de abril de 2024 (era Reiwa 6).1

Según el folleto del Gabinete del Primer Ministro, proporcionar un ajuste razonable significa responder, dentro de un margen de carga que no sea excesivo, cuando una persona con discapacidad manifiesta la necesidad de algún tipo de respuesta para eliminar una barrera existente en la sociedad. Y como el contenido varía según las características de la discapacidad y la situación o el contexto, se da importancia al «diálogo constructivo», en el que la persona con discapacidad y la empresa mantienen conversaciones repetidas para estudiar juntas una propuesta de respuesta. Se establece explícitamente que negarse unilateralmente al diálogo constructivo puede constituir un incumplimiento de la obligación de proporcionar el ajuste razonable.1

Aquí hay dos puntos importantes desde el punto de vista práctico.

  1. No se ha vuelto obligatorio “atenderlo todo de antemano”. Las medidas de mejora previas dirigidas a un número indeterminado de personas con discapacidad —como la revisión de manuales o la capacitación (el aspecto blando) y la accesibilidad física de las instalaciones (el aspecto duro)— se denominan «acondicionamiento del entorno» y son una obligación de esfuerzo.1 Preparar de antemano una aplicación empresarial para que se pueda usar con un lector de pantalla se considera parte de este acondicionamiento del entorno. Cuanto más avanzado esté el acondicionamiento del entorno, con menor carga se podrá proporcionar el ajuste razonable individual.
  2. El ámbito laboral no está sujeto a la Ley de Eliminación de la Discriminación por Discapacidad, sino a la Ley de Promoción del Empleo de Personas con Discapacidad. El mismo folleto indica que el empleo y el trabajo se rigen por lo dispuesto en la Ley de Promoción del Empleo de Personas con Discapacidad.1 Y esta ley, mediante la reforma vigente desde abril de 2016 (era Heisei 28), obliga a los empleadores a prohibir la discriminación por discapacidad en el ámbito laboral y a proporcionar ajustes razonables dentro de un margen que no suponga una carga excesiva.2 La consulta del principio del artículo, sobre «un empleado que no puede usar la aplicación empresarial», era en realidad un ámbito de obligación legal desde mucho antes de 2024.
Ubicación del ajuste razonable y el acondicionamiento del entornoLa relación entre las empresas en general y las personas con discapacidad está sujeta a la Ley de Eliminación de la Discriminación por Discapacidad, cuya obligación de ajuste razonable ante solicitudes individuales mediante diálogo constructivo rige desde abril de 2024; el ámbito laboral está sujeto a la Ley de Promoción del Empleo de Personas con Discapacidad y es obligación del empleador desde abril de 2016; la adaptación previa de la aplicación corresponde al acondicionamiento del entorno, una obligación de esfuerzoEmpresa y persona con discapacidadÁmbito laboral¿Qué ámbito?Ley de Eliminación de la Discriminación por DiscapacidadLey de Promoción del Empleo de Personas con DiscapacidadRespuesta a la solicitud individual mediante diálogo constructivoAjuste razonable（obligatorio desde abril de 2024）Ajuste razonable（obligatorio desde abril de 2016）Adaptación previa de la aplicación = acondicionamiento del entorno（obligación de esfuerzo）

Figura 2: Según el ámbito cambia la ley aplicable; el ajuste razonable es obligatorio, y la adaptación previa corresponde al acondicionamiento del entorno como obligación de esfuerzo.

Cómo se trata legalmente cada caso concreto depende de la situación. Este artículo no entra en la interpretación jurídica y avanza desde el punto de vista de qué puede hacer un técnico cuando se le pide una respuesta. Como fuente primaria, consulte los materiales del Gabinete del Primer Ministro y del Ministerio de Salud, Trabajo y Bienestar.12

2.2. JIS X 8341-3 y WCAG — el «criterio web» también se extiende al software

Los criterios técnicos se concentran en JIS X 8341-3:2016. Esta norma es idéntica a ISO/IEC 40500:2012, y su texto tiene el mismo contenido que WCAG 2.0 del W3C.3 Si se quiere conocer en concreto el contenido de la «accesibilidad», el camino más rápido es leer los criterios de conformidad de WCAG (actualmente ampliados a WCAG 2.1/2.2); WAIC también publica una traducción al japonés.8

La duda de «¿WCAG no es un criterio para el contenido web?» es razonable, pero el W3C, en un Group Note llamado WCAG2ICT (Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies), organiza la forma de aplicar los criterios de conformidad de WCAG 2.0/2.1/2.2 a documentos y software no web.4 Es decir, ideas como «alternativas de texto», «contraste», «manejo por teclado» o «no depender solo del color» se pueden aplicar a las aplicaciones de escritorio de Windows con el mismo marco que en la web. A partir del capítulo 3, este artículo traslada esta forma de pensar a la implementación concreta en WinForms/WPF.

Relación entre JIS X 8341-3 y WCAGJIS X 8341-3:2016 es una norma idéntica de contenido a WCAG 2.0, y WCAG2ICT indica cómo aplicar los criterios de conformidad de WCAG a software no web, por lo que las aplicaciones de escritorio de Windows también se pueden revisar con el mismo marcoNorma idéntica en contenidoWCAG 2.0（W3C）JIS X 8341-3:2016WCAG2ICTAplicación a software no webAplicaciones de escritorio de Windows

Figura 3: JIS X 8341-3:2016 es la norma idéntica a WCAG 2.0, y WCAG2ICT extiende los mismos criterios a las aplicaciones de escritorio.

3. El mecanismo con el que la tecnología de asistencia lee la aplicación — el trío de UI Automation

3.1. El árbol de UIA, las propiedades y los patrones de control

Windows incorpora una base de accesibilidad llamada UI Automation (UIA). UIA es el mecanismo que permite que tecnologías de asistencia, como los lectores de pantalla, obtengan información de la interfaz y la operen por medios distintos de la entrada estándar; hace de intermediario entre la aplicación (el proveedor) y la tecnología de asistencia (el cliente).5

El mundo de UIA se puede entender con el siguiente trío.5

Elemento Función Ejemplos representativos
Árbol de UIA Estructura arbórea con el escritorio como raíz, que continúa hacia ventanas y controles. La tecnología de asistencia recorre este árbol para comprender la interfaz Ventanas, paneles, botones, cuadros de edición
Propiedades Valores que representan las características de cada elemento Name (propósito), ControlType (tipo), AutomationId (identificador), IsEnabled, IsKeyboardFocusable
Patrones de control Vocabulario de «operaciones posibles» según el tipo Invoke (pulsar), Value (leer/escribir el valor), SelectionItem (seleccionar), Toggle (activar/desactivar), ExpandCollapse (expandir/contraer)

Lo que lee el lector de pantalla al enfocar un botón, como «Confirmar pedido, botón», es básicamente la combinación de Name más el tipo de control. Cuando el usuario realiza la operación de «ejecutar», la tecnología de asistencia pulsa ese botón a través del patrón Invoke. Es decir, si el Name y los patrones están correctamente expuestos, se puede leer y operar; si no lo están, aunque se vea en la pantalla equivale a que no existe.

El trío de UI AutomationLa aplicación, como proveedor, expone en el árbol de UIA las propiedades y los patrones de control de cada elemento, y el lector de pantalla, como cliente, lee el Name y el ControlType y opera mediante patrones como InvokeLeeOperaAplicación（proveedor）Árbol de UIAPropiedades（Name, ControlType, etc.）Patrones（Invoke, Value, etc.）Lector de pantalla（cliente）

Figura 4: El lector de pantalla usa para leer y operar las propiedades y los patrones que la aplicación expone en el árbol de UIA.

3.2. El lector de pantalla es un cliente de UIA

Entre los principales lectores de pantalla que se usan en Windows están Narrador, incorporado en Windows; NVDA11, gratuito y de código abierto; y PC-Talker, un producto comercial muy usado en Japón. Aunque cada uno tiene su propio estilo de lectura, la ruta principal para leer la interfaz de una aplicación de escritorio es siempre UIA. Precisamente por eso, la respuesta de la aplicación no consiste en «compatibilidad con un lector de pantalla concreto», sino que se concentra en exponer la información correcta a UIA.

Ruta común de los principales lectores de pantallaSi la aplicación expone la información correcta a UIA, Narrador, NVDA y PC-Talker pueden leer la interfaz por la misma ruta, de modo que la respuesta de la aplicación se concentra en exponer información a UIA en lugar de dirigirse a un lector de pantalla concretoExpone informaciónAplicaciónUI Automation（UIA）NarradorNVDAPC-TalkerLa respuesta se concentra en exponer a UIA

Figura 5: Como todos los lectores de pantalla principales usan UIA como ruta, la respuesta de la aplicación se concentra en exponer información a UIA.

3.3. ¿Cómo se lee un «botón con Name vacío»?

Un ejemplo concreto. Supongamos que en una barra de herramientas hay un botón de guardar que solo muestra el icono de un disquete. Para un usuario que ve, el icono transmite el significado, pero si el Name queda vacío, el lector de pantalla lee este botón únicamente como «botón». Si los botones vecinos de «abrir» e «imprimir» están en la misma situación, el usuario solo oye «botón, botón, botón» y no tiene forma de saber cuál es cuál. La guía de corrección de accesibilidad de Microsoft también menciona los botones sin Name o las imágenes que se leen solo como «Image» como problemas típicos que detienen el trabajo del usuario.7

Afortunadamente, los controles estándar tanto de WinForms como de WPF incorporan la compatibilidad con UIA desde el principio, y en la mayoría de los casos el Name se determina automáticamente a partir del texto o la etiqueta. Casi siempre lo que se rompe es uno de estos tres casos: ① solo hay un icono, sin material para el nombre; ② no hay asociación con una etiqueta; ③ el dibujo personalizado no expone información al árbol de UIA. En los dos capítulos siguientes veremos cómo corregirlo según el framework.

Tres causas típicas de que la lectura se rompaLa lectura se rompe y el elemento se lee únicamente como botón cuando solo hay un icono sin material para el nombre, cuando falta la asociación con una etiqueta, o cuando el dibujo personalizado no expone información al árbol de UIASolo icono, sin materialEl Name queda vacíoSin asociación con etiquetaDibujo personalizado sin informaciónSe lee solo como «botón»

Figura 6: La lectura se rompe casi siempre por uno de estos tres patrones: falta de material para el nombre, falta de asociación o dibujo personalizado.

4. Implementación en WinForms — AccessibleName y el orden de tabulación

4.1. Controles cuyo Text se convierte automáticamente en Name, y los que no

En WinForms, los controles que muestran texto, como Button o CheckBox, usan el valor de la propiedad Text como Name de UIA. En cambio, ComboBox, ListBox, ListView, PictureBox, ProgressBar, TabControl, TextBox, TreeView y otros no convierten el Text en Name. Estos necesitan recibir el nombre por otro medio.6

El método más fácil de mantener es colocar un Label descriptivo justo antes del control objetivo en el orden de tabulación. Si se configura de modo que el TabIndex del control objetivo venga justo después del TabIndex del Label, el texto de ese Label se usa automáticamente como el Name de UIA. Así la etiqueta visible en pantalla coincide con la lectura, y se evita gestionar el texto por duplicado.612

Cuando no se puede colocar un Label, se asigna AccessibleName de forma explícita. Además, si hace falta una descripción adicional se puede asignar AccessibleDescription, y si el rol difiere de la apariencia, también se puede asignar AccessibleRole.13

Cómo se decide el nombre de los controles de WinFormsEn controles como Button, el Text se convierte directamente en el Name de UIA; en controles como TextBox, donde el Text no se reutiliza, se usa el texto del Label colocado justo antes en el orden de tabulación; si no se puede colocar un Label, se asigna AccessibleName explícitamenteSíNoSíNoControl¿El Text se convierte en Name?El Text se convierte directamente en Name¿Hay un Label justo antes en el orden de tabulación?El texto del Label se usa como NameSe asigna AccessibleName explícitamente

Figura 7: El Name de WinForms se decide en este orden: Text, Label anterior en el orden de tabulación y, por último, AccessibleName.

// Botón de barra de herramientas con solo icono: se indica el nombre para la lectura
saveToolStripButton.AccessibleName = "Guardar";

// Botón con solo imagen: nombre + descripción adicional
btnSearchCustomer.AccessibleName = "Buscar cliente";
btnSearchCustomer.AccessibleDescription = "Busca en el maestro de clientes por código o nombre de cliente";

// Para campos donde no se puede colocar un Label justo antes en el orden de tabulación, se asigna directamente
txtOrderNo.AccessibleName = "Número de pedido";

// PictureBox reutilizado para mostrar un gráfico: el rol también se ajusta a la realidad
pictureBoxChart.AccessibleRole = AccessibleRole.Chart;
pictureBoxChart.AccessibleName = "Gráfico de pedidos mensuales";

Como punto de atención: si se asigna AccessibleName una vez en el panel de propiedades de Visual Studio y luego se borra, puede quedar una cadena vacía en el archivo del diseñador que impida la resolución de nombre predeterminada. Elimine la línea correspondiente del archivo del diseñador.6

El problema de la cadena vacía que queda en AccessibleNameSi se asigna AccessibleName una vez en el panel de propiedades y luego se borra, en el archivo del diseñador queda una cadena vacía que impide la resolución de nombre predeterminada, así que se corrige eliminando esa línea del archivo del diseñadorSe asigna AccessibleNameSe borra en el panel de propiedadesQueda una cadena vacía asignadaImpide la resolución de nombre predeterminadaEliminar la línea correspondiente del archivo del diseñador

Figura 8: Aunque se borre en el panel de propiedades, la cadena vacía permanece, así que se corrige eliminando la línea correspondiente del archivo del diseñador.

4.2. Mejoras habituales en las pantallas de entrada de pedidos

Resumimos en una lista de verificación los puntos que solemos corregir con más frecuencia en aplicaciones empresariales.

Situación habitual Problema Cómo corregirlo
ToolStripButton con solo icono Se lee solo como «botón» Asignar AccessibleName
Hay un Label cerca del TextBox, pero el orden de tabulación es irregular El nombre del campo queda vacío o resulta un nombre sin relación Colocar el campo justo después del TabIndex del Label
Se usa PictureBox como sustituto de un botón con el evento Click El rol de botón no se transmite y no se puede pulsar con el teclado Sustituirlo por Button, o asignar AccessibleRole/AccessibleName y añadir soporte de teclado
El encabezado de columna de DataGridView está vacío o solo tiene símbolos Al leer la celda no se entiende el significado de la columna Asignar un nombre de columna con significado en HeaderText
Se agrupa el contenido solo con Panel y el título es una imagen No se sabe a qué grupo de entrada pertenece Usar GroupBox, o convertir el título en un Label

Todas son correcciones de pocas líneas, pero para el usuario de un lector de pantalla marcan la diferencia entre una «pantalla inutilizable» y una «pantalla utilizable».

5. Implementación en WPF — AutomationProperties y AutomationPeer

5.1. AutomationProperties.Name / LabeledBy / HelpText

En WPF, los controles cuyo Content es una cadena de texto, como Button, usan ese contenido como el Name de UIA. Los botones que solo tienen un icono (Image o Path) carecen de material para el Name, así que se indica explícitamente con AutomationProperties.Name, o, si hay un texto visible cercano, se asocia con AutomationProperties.LabeledBy.7

Hay una advertencia importante sobre TextBox. En TextBlock, el Text se reutiliza como Name, pero el Text de TextBox se expone en la propiedad Value de UIA y no se convierte en Name. Para los campos de entrada, la primera opción es asociar el TextBlock de la etiqueta visible mediante LabeledBy. Así la lectura coincide con la visualización en pantalla y también se evita gestionar el texto por duplicado.14

<!-- Campo de entrada: la etiqueta visible se asocia con LabeledBy -->
<TextBlock x:Name="OrderNoLabel" Text="Número de pedido" />
<TextBox
    AutomationProperties.LabeledBy="{Binding ElementName=OrderNoLabel}"
    AutomationProperties.AutomationId="OrderNoTextBox" />

<!-- Botón con solo icono: se indica el nombre y, si hace falta, una descripción adicional -->
<Button
    AutomationProperties.Name="Confirmar pedido"
    AutomationProperties.HelpText="Confirma el pedido en curso y reserva el stock correspondiente">
    <Path Data="{StaticResource CheckIconGeometry}" Width="16" Height="16" />
</Button>
Cómo se decide el nombre de los controles de WPFEn los controles cuyo Content es una cadena, ese contenido se usa como Name; si no lo es, la primera opción es asociar una etiqueta visible cercana con LabeledBy, y si tampoco la hay, se asigna AutomationProperties.Name de forma explícita; el Text de TextBox se expone como Value y no como NameSíNoSíNoControl¿El Content es una cadena?El contenido se convierte en Name¿Hay una etiqueta visible cerca?Asociar con LabeledByAsignar Name explícitamenteText de TextBoxSe expone como Value, no como Name

Figura 9: El Name de WPF se decide en este orden: cadena de Content, LabeledBy y asignación explícita; el Text de TextBox nunca se convierte en Name.

La información adicional que no cabe en el Name se puede exponer con AutomationProperties.HelpText.7 Además, como AutomationId es un identificador que también se usa para localizar elementos en las pruebas automatizadas de UI, decidir la convención de nomenclatura desde la etapa de diseño de la pantalla resulta útil más adelante (se detalla en «Pruebas automatizadas de UI en aplicaciones de escritorio de Windows»).

5.2. AutomationPeer para los controles personalizados

Un control personalizado que se dibuja por sí mismo no puede exponer, tal cual, información con significado al árbol de UIA. En WPF, se sobrescribe OnCreateAutomationPeer de la clase derivada de UIElement y se devuelve una clase derivada de AutomationPeer para exponer el nombre, el tipo y los patrones. Si se hereda de un control existente, heredar del Peer correspondiente (ButtonBaseAutomationPeer para ButtonBase) permite conservar el comportamiento ya implementado.15

Cómo AutomationPeer expone la informaciónUn control personalizado expone su nombre, tipo y patrones al sobrescribir OnCreateAutomationPeer y devolver una clase derivada de AutomationPeer; si hereda de un control existente, hereda del Peer correspondiente para conservar el comportamiento ya implementadoControl personalizadoOnCreateAutomationPeerDevuelve una clase derivada de PeerExpone nombre, tipo y patronesHereda de un control existenteHereda del Peer correspondienteConserva el comportamiento ya implementado

Figura 10: Un control personalizado expone información a UIA devolviendo un Peer desde OnCreateAutomationPeer.

// Ejemplo de control que dibuja de forma personalizada el estado de la línea con una lámpara de color
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 ? "Estado de línea: en línea" : "Estado de línea: fuera de línea";

    private static void OnIsOnlineChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        // Emite el evento de cambio de propiedad de UIA en el instante en que cambia el valor.
        // Sin esto, el lector de pantalla conserva el nombre anterior y no percibe el cambio de estado
        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 Text si es una visualización de estado sin operación

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

Nombrar no es lo único que hace el Peer: también debe notificar el cambio mediante un evento en el instante en que ocurre. Como la tecnología de asistencia no tiene por sí misma un momento para volver a consultar el valor, una implementación que no emite el evento de cambio queda «correcta solo cuando se le vuelve a preguntar», y el cambio de estado no llega al usuario del lector de pantalla.

Flujo para comunicar el cambio de estado al lector de pantallaEn el instante en que cambia el valor del control, AutomationPeer emite el evento de cambio de propiedad de Name, y como la tecnología de asistencia no vuelve a consultarlo por sí misma, sin ese evento se queda con el nombre anterior y no percibe el cambioLector de pantallaAutomationPeerControlLector de pantallaAutomationPeerControlSin el evento, se queda con el nombre anteriorCambia el valor de IsOnlineEmite el evento de cambio de propiedad de NameLee el nuevo estado

Figura 11: El cambio de valor llega al lector de pantalla solo cuando AutomationPeer lo notifica mediante el evento de cambio.

Si el control personalizado tiene operaciones (se puede pulsar, cambiar el valor, seleccionar), se sobrescribe GetPattern para proporcionar interfaces de patrón como IInvokeProvider o IRangeValueProvider.15 El punto clave es que, si el Peer se implementa a fondo en la biblioteca de controles comunes, todas las pantallas que la usan quedan automáticamente compatibles. Esto es la base de la «extensión» que se trata en el capítulo 9.

6. ¿Se puede llegar a todas las funciones solo con el teclado?

El criterio de conformidad 2.1.1 (Teclado) de WCAG exige que todas las funciones del contenido se puedan operar desde una interfaz de teclado.8 Como los usuarios de lectores de pantalla, en principio, no usan el mouse, una función a la que no se puede llegar con el teclado equivale a una función inexistente. Los puntos de revisión son los siguientes.

Aspecto Qué comprobar Principales medios en WinForms / WPF
Orden de tabulación Si el orden de movimiento con Tab coincide con la disposición visual (arriba-izquierda a abajo-derecha) Ordenar el TabIndex, configurar TabStop
Tecla de acceso Si se puede ir directamente a los elementos principales con Alt + letra En WinForms, & en el Text; en WPF, _ en el encabezado
Atajo de teclado Si las operaciones frecuentes (guardar, buscar, confirmar) tienen una tecla propia Asignar Ctrl+S, etc., e indicarlo en el menú
Indicación de foco Si se puede seguir visualmente dónde está el foco en cada momento No eliminar el marco de foco; en el dibujo personalizado, dibujarlo uno mismo
Funciones exclusivas del mouse Si hay funciones que solo se pueden usar con doble clic, clic derecho, arrastre u hover Ofrecer la misma función también con el menú o el teclado
Cuadros de diálogo Si Enter funciona como el botón predeterminado y Esc como cancelar AcceptButton/CancelButton, IsDefault/IsCancel

La guía de accesibilidad de WinForms también menciona como básico colocar la etiqueta justo antes del campo de entrada en el orden de tabulación, y añadir teclas de acceso a los controles y menús a los que el usuario quiera moverse.12

Lo que queremos subrayar es que esto no es un «costo adicional para atender a personas con discapacidad». En un trabajo rutinario como la entrada de pedidos, poder completar la entrada sin apartar las manos de la posición base determina directamente el número de casos que procesa un operador. Un orden de tabulación desordenado o una operación que exige el mouse son defectos que reducen día a día, poco a poco, la productividad de todos los usuarios. La accesibilidad y la eficiencia del teclado no son más que dos nombres para el mismo trabajo (para las prioridades según el entorno de uso, consulte también «Diseño de UX de aplicaciones Windows»).

El doble efecto de preparar el tecladoPreparar el orden de tabulación, las teclas de acceso y la indicación de foco produce a la vez dos efectos, que los usuarios de tecnología de asistencia puedan llegar a la función y la velocidad de entrada de todos los operadores, mientras que una función que solo funciona con el mouse equivale a una función inexistentePreparación del manejo por tecladoLos usuarios de tecnología de asistencia pueden usarlaVelocidad de entrada de todos los operadoresFunción exclusiva del mouseEquivale a una función inexistente

Figura 12: Preparar el manejo por teclado logra a la vez la compatibilidad con tecnología de asistencia y la eficiencia de todos los usuarios, mientras que una función exclusiva del mouse equivale a no tenerla.

7. Color y contraste — 4.5:1 y «no depender solo del color»

7.1. La relación de contraste de referencia es 4.5:1

El criterio de conformidad 1.4.3 (Contraste mínimo) de WCAG exige una relación de contraste de al menos 4.5:1 para el texto y las imágenes de texto, y de al menos 3:1 para el texto grande.8 No es raro que un diseño moderno con texto gris claro sobre fondo blanco no cumpla este criterio. Entre los usuarios de aplicaciones empresariales hay personas cuya vista y percepción del color han cambiado con la edad, y también personas que las usan en entornos con mala iluminación, como una fábrica. Adquiera el hábito de medir con un verificador de contraste al revisar el diseño.

7.2. No comunicar información solo con el color

El criterio de conformidad 1.4.1 (Uso del color) establece que el color no debe ser el único medio visual para transmitir información.8 Los ejemplos típicos en aplicaciones empresariales son los siguientes.

  • Indicar la fila con error solo con texto rojo → añadir un icono de error junto con una columna de mensaje
  • Indicar un campo obligatorio solo con el color de la etiqueta → añadir la marca «*» o «obligatorio»
  • Indicar el estado solo con el color de una lámpara → combinar color con forma o texto («en funcionamiento», «detenido»)

Considerando la diversidad de la percepción del color, esto tampoco es una «atención especial», sino algo básico en el diseño de la visualización.

Sustituir la comunicación que depende solo del colorLa indicación de error solo con texto rojo se sustituye por un icono de error junto con la columna de mensaje, la indicación de campo obligatorio solo con el color de la etiqueta se sustituye añadiendo la marca «obligatorio», y la indicación de estado solo con el color de la lámpara se sustituye combinando forma o textoError solo con texto rojoIcono y texto combinadosObligatorio solo con color de etiquetaAñadir la marca «obligatorio»Estado solo con color de lámparaCombinar forma o texto con el color

Figura 13: Los ejemplos típicos que comunican solo con color se sustituyen combinando iconos, textos o formas.

7.3. Seguimiento del tema de contraste (alto contraste)

Windows tiene el tema de contraste (el antiguo alto contraste), que cambia a una paleta con una fuerte separación entre el primer plano y el fondo; el usuario puede seleccionar y editar los temas integrados, diseñados para lograr una relación de contraste de aproximadamente 7:1 o más.9 El principio del lado de la aplicación es simple: no codificar colores de forma fija y respetar los colores del sistema.

  • WinForms: si se dejan ForeColor/BackColor en sus valores predeterminados, se usa la configuración de colores del usuario. En los lugares con color propio, se determina el estado con SystemInformation.HighContrast, se cambia a una paleta basada en SystemColors y se sigue el cambio de configuración con el evento UserPreferenceChanged.12
  • WPF/WinUI: si se hace referencia a los recursos de la familia SystemColors, la aplicación sigue el cambio de tema. Los lugares rellenados con brochas propias son la causa de que se rompa el diseño.9
Seguimiento del tema de contrasteLos lugares con colores codificados de forma fija se rompen al cambiar al tema de contraste, así que se corrige cambiando a una paleta basada en SystemColors y siguiendo el cambio con el evento de configuración; si ya se hace referencia a los colores del sistema, la aplicación sigue automáticamente la paleta del usuarioCodificado de forma fijaReferencia a colores del sistemaCambio al tema de contraste¿Cómo se especifica el color?La paleta se rompeSigue automáticamente la paleta del usuarioCambiar a SystemColorsSeguir con el evento de cambio de configuración

Figura 14: Solo los lugares con colores codificados de forma fija se rompen con el tema de contraste; con referencia a colores del sistema, la aplicación sigue el cambio automáticamente.

Además, como los usuarios con baja visión suelen usar un porcentaje de escala del sistema operativo (escalado de PPP) alto, el soporte de PPP alto también forma parte de la accesibilidad. Una aplicación cuyo diseño se rompe entre el 125 % y el 200 % ya resulta inutilizable en ese punto. Para más detalles, consulte «Soporte de PPP alto en WinForms» y «Soporte de PPP alto en WPF».

8. La práctica de la verificación — Accessibility Insights y la comprobación real con lector de pantalla

8.1. Accessibility Insights for Windows

Microsoft ofrece Accessibility Insights for Windows como herramienta de verificación de accesibilidad para aplicaciones Windows, con principalmente tres formas de uso.10

  • Live Inspect: basta con posicionar el mouse encima de un elemento o llevarle el foco de teclado para comprobar sus propiedades de UIA (Name, ControlType, patrones, etc.). Es la forma más rápida de ver «cuál es el Name de este botón».
  • FastPass: una verificación ligera que detecta problemas de accesibilidad de alto impacto en menos de 5 minutos. Permite detectar en cada pantalla nueva problemas que se pueden juzgar de forma mecánica, como la falta de Name.
  • Troubleshooting: ayuda a diagnosticar y corregir problemas concretos. Desde los problemas detectados se puede llegar directamente a las guías de corrección específicas de cada framework que también se citan en este artículo.

Con Inspect.exe y AccEvent, incluidos en el Windows SDK, también se pueden comprobar el árbol de UIA y las propiedades, pero se consideran herramientas heredadas, y actualmente se recomienda migrar a Accessibility Insights.10

Las tres formas de usar Accessibility InsightsAccessibility Insights for Windows ofrece Live Inspect para comprobar propiedades de UIA, FastPass para una verificación ligera de problemas de alto impacto y Troubleshooting para el diagnóstico y la ayuda a la corrección, y se recomienda migrar desde herramientas heredadas como Inspect.exeSe recomienda migrarAccessibility InsightsLive InspectFastPassTroubleshootingComprueba propiedades de UIADetecta problemas de alto impactoAyuda al diagnóstico y la correcciónInspect.exe, etc.

Figura 15: Accessibility Insights se usa para comprobar, detectar y diagnosticar, y es el destino de la migración desde las herramientas heredadas.

8.2. Comprobación real con lector de pantalla

La verificación automática de las herramientas solo puede detectar problemas que se puedan juzgar de forma mecánica. Al final, recorra siempre una operación real del negocio con un lector de pantalla. Narrador, incorporado en Windows, se inicia de inmediato con Ctrl+tecla Windows+Entrar, y NVDA se puede instalar de forma gratuita.11 El truco para la comprobación es intentar, sin mirar la pantalla (o con la pantalla apagada) y confiando solo en la lectura, completar una tarea real como «introducir un pedido y confirmarlo». Problemas como que el orden de lectura sea incoherente aunque haya un nombre asignado, o que el foco se escape fuera de un cuadro modal, solo se descubren en la comprobación real.

Combinación de verificación con herramientas y comprobación realLas verificaciones automáticas como FastPass solo pueden detectar problemas que se juzgan de forma mecánica, y el resto se encuentra recorriendo una operación real del negocio con un lector de pantalla, comprobando en el terreno problemas de orden de lectura o de focoVerificación automática de la herramientaProblemas que se juzgan de forma mecánicaQuedan problemas no detectadosComprobación real con lector de pantallaRecorrer una operación del negocioProblemas de orden de lectura o de foco

Figura 16: La verificación automática detecta los problemas mecánicos, y el resto se encuentra con la comprobación real mediante un lector de pantalla.

8.3. Integración en el flujo de desarrollo y sinergia con las pruebas automatizadas de UI

Para que la verificación no dependa de una sola persona, recomendamos incorporar la siguiente lista de verificación en los elementos de revisión de las pantallas nuevas.

# Elemento de comprobación Medio
1 Cero errores en FastPass Accessibility Insights
2 Todos los campos y botones tienen Name Live Inspect
3 Se llega a todas las funciones solo con la tecla Tab Manual
4 Enter/Esc y los atajos principales funcionan Manual
5 Relación de contraste de texto de al menos 4.5:1 Verificador de contraste
6 No se rompe con el tema de contraste Comprobación visual cambiando el tema
7 No se rompe con un escalado del 200 % Comprobación visual cambiando la configuración de pantalla
8 Se puede completar una tarea representativa con el lector de pantalla Narrador/NVDA

Y una cosa más. Las pruebas automatizadas de UI con herramientas como FlaUI se basan en el mismo UIA que el lector de pantalla. El Name y los patrones preparados para la accesibilidad se convierten en piezas del código de prueba, y el AutomationId diseñado para las pruebas facilita la depuración con Live Inspect. A la inversa, una UI que no aparece en el árbol de UIA es invisible tanto para las pruebas como para la tecnología de asistencia. La accesibilidad y la facilidad de prueba son dos caras de la misma inversión («Pruebas automatizadas de UI en aplicaciones de escritorio de Windows»).

Sinergia entre la accesibilidad y las pruebas automatizadas de UIComo el lector de pantalla y las pruebas automatizadas de UI de herramientas como FlaUI se basan en el mismo UIA, el Name y los patrones preparados se pueden usar desde ambos, y una UI que no aparece en el árbol de UIA es invisible para los dosPreparación del árbol de UIAEl lector de pantalla puede leerlaSe puede usar en pruebas automatizadas de UIDos caras de la misma inversiónUI que no aparece en UIAInvisible para ambos

Figura 17: Al estar sobre la misma base de UIA, preparar el árbol de UIA beneficia tanto a la tecnología de asistencia como a las pruebas automatizadas de UI.

9. Cómo establecer prioridades — no corregir todas las pantallas a la vez

Corregir de golpe un sistema troncal con cientos de pantallas no es realista, ni por el costo ni por la calidad. El enfoque que recomendamos consta de las siguientes tres etapas.

  1. Corregir primero las pantallas que esa persona usa en su trabajo. El ajuste razonable es un proceso que responde individualmente a la solicitud de la persona interesada.1 Primero, pida a la propia persona que realice el trabajo real con el lector de pantalla e identifiquen juntos los puntos de atasco. En la mayoría de los casos, las pantallas que se usan en el trabajo diario se reducen a unas pocas o a una docena, y los problemas críticos dentro de ellas (botones sin nombre, botón de confirmación que no se puede pulsar con el teclado) se pueden resolver con correcciones de pocos días.
  2. Tratar el desarrollo nuevo de forma estándar. Añada la lista de verificación del capítulo 8 a la definición de terminado (Definition of Done) y construya las pantallas nuevas ya compatibles desde el principio. A diferencia de una corrección posterior, incorporarlo en el diseño supone un aumento de costo mínimo.
  3. Extender mediante la corrección de los controles comunes. Si se implementa un valor predeterminado de AccessibleName o un AutomationPeer en los componentes comunes de la empresa, como el cuadro de diálogo de búsqueda, la cuadrícula o la entrada de fecha, el efecto llega de una vez a todas las pantallas que los usan. Es una medida con una relación costo-beneficio mucho más alta que tocar una a una las pantallas individuales.
Las tres etapas de prioridad de la correcciónSe corrige primero la pantalla que el usuario emplea en su trabajo, el desarrollo nuevo se trata de forma estándar con la lista de verificación, y la corrección de los controles comunes se extiende a todas las pantallas1. Corregir primero la pantalla que usa el usuario2. Tratar lo nuevo de forma estándar3. Extender mediante los controles comunesBeneficia de una vez a todas las pantallas que los usan

Figura 18: En lugar de corregir todas las pantallas a la vez, se avanza en tres etapas: la pantalla en uso, lo nuevo y los componentes comunes.

Y algo tan importante como la respuesta técnica es el registro del diálogo. El ajuste razonable es un proceso de «dialogar y ajustar de forma individual», no atender por completo todas las solicitudes. Ante una corrección con una carga excesiva, estudiar y acordar con la persona interesada una alternativa (realizar la tarea en otra pantalla, preparar una exportación a CSV, cubrirlo por vía operativa) es también un resultado legítimo del diálogo constructivo.1 Dejar constancia de qué se solicitó, qué se atendió y qué se adoptó como alternativa es la prueba de la integridad de la organización.

Flujo del diálogo constructivo y el registroSe responde a la solicitud de la persona con discapacidad mediante diálogo constructivo, se realiza la corrección si es posible, y si la carga es excesiva se estudia y se acuerda con la persona una alternativa, dejando constancia de qué se solicitó, qué se atendió y qué alternativa se adoptóNoSíSolicitudDiálogo constructivo¿La carga es excesiva?Se atiende con la correcciónSe estudia y acuerda una alternativaSe deja constancia del proceso

Figura 19: En el diálogo constructivo se acuerda con la persona si se hace la corrección o una alternativa, y se deja constancia del proceso.

10. Resumen

  • Con la Ley de Eliminación de la Discriminación por Discapacidad reformada, vigente desde abril de 2024, la provisión de ajustes razonables también se volvió obligatoria para las empresas. El ámbito laboral es obligación del empleador desde 2016 por la Ley de Promoción del Empleo de Personas con Discapacidad. La adaptación previa de la aplicación corresponde al «acondicionamiento del entorno» (obligación de esfuerzo), y cuanto más se avance, más ligera resulta la respuesta individual.
  • Los criterios técnicos se concentran en WCAG (JIS X 8341-3:2016), y gracias a WCAG2ICT se puede aplicar el mismo criterio a las aplicaciones de escritorio.
  • El lector de pantalla lee la aplicación a través de UI Automation. La base es el trío formado por el árbol de UIA, las propiedades (Name/ControlType/AutomationId) y los patrones de control.
  • La máxima prioridad es el Name. Se atiende con AccessibleName y la asociación de Label con el orden de tabulación en WinForms, con AutomationProperties.Name/LabeledBy en WPF, y con AutomationPeer en los controles personalizados.
  • Que se pueda llegar a todas las funciones solo con el teclado es a la vez un criterio de conformidad de WCAG y la productividad de todos los operadores. Prepare el orden de tabulación, las teclas de acceso y la indicación de foco.
  • Una relación de contraste de 4.5:1, no depender solo del color y respetar los colores del sistema en el tema de contraste son las tres bases del color.
  • La verificación combina FastPass + Live Inspect de Accessibility Insights con la comprobación real con Narrador/NVDA, y se incorpora al flujo de desarrollo como lista de verificación para las pantallas nuevas.
  • No corrija todas las pantallas a la vez: avance en el orden de pantalla en uso → tratamiento estándar de lo nuevo → extensión mediante controles comunes. El ajuste razonable es un proceso de diálogo, y el registro del proceso protege a la organización.

Como primer paso, recomendamos elegir una de las pantallas principales de su empresa, ejecutar FastPass de Accessibility Insights for Windows y luego recorrer el trabajo usando solo la tecla Tab. En 30 minutos, la situación actual de su propia aplicación se vuelve sorprendentemente concreta.

Artículos relacionados

Áreas de consultoría relacionadas

KomuraSoft LLC atiende consultas sobre la corrección de accesibilidad de aplicaciones empresariales WinForms/WPF (compatibilidad con lectores de pantalla, preparación del manejo por teclado, compatibilidad con el tema de contraste), la implementación de AutomationPeer en controles comunes, y el diagnóstico de la situación actual y el establecimiento de prioridades con Accessibility Insights. Puede empezar desde la etapa de “quiero comprobar si un empleado puede usar nuestra aplicación con un lector de pantalla”.

Referencias

  1. Gabinete del Primer Ministro (Cabinet Office), Folleto «Desde el 1 de abril de 2024 se ha vuelto obligatoria la provisión de ajustes razonables». Sobre la entrada en vigor el 1 de abril de 2024 de la Ley de Eliminación de la Discriminación por Discapacidad reformada en 2021, que obliga a las empresas a proporcionar ajustes razonables; que la provisión del ajuste razonable responde, dentro de un margen de carga que no sea excesivo, a la manifestación de voluntad de una persona con discapacidad; la importancia del diálogo constructivo y que la negativa unilateral puede constituir un incumplimiento de la obligación; que el «acondicionamiento del entorno», como medida de mejora previa dirigida a un número indeterminado de personas con discapacidad, es una obligación de esfuerzo; y que el empleo y el trabajo se rigen por la Ley de Promoción del Empleo de Personas con Discapacidad. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  2. Ministerio de Salud, Trabajo y Bienestar, Prohibición de la discriminación contra las personas con discapacidad y obligación de proporcionar ajustes razonables en el ámbito laboral. Sobre la obligación, impuesta a los empleadores por la Ley de Promoción del Empleo de Personas con Discapacidad reformada y vigente desde abril de 2016, de prohibir la discriminación por discapacidad en el ámbito laboral y de proporcionar ajustes razonables dentro de un margen que no suponga una carga excesiva, y sobre las directrices de ajuste razonable y otros materiales relacionados. ↩ ↩2 ↩3 ↩4

  3. Comité de la Base de Accesibilidad Web (WAIC), Explicación de JIS X 8341-3:2016. Sobre que JIS X 8341-3:2016 es una norma idéntica a ISO/IEC 40500:2012, que el texto de la norma tiene el mismo contenido que WCAG 2.0, y sobre el alcance del contenido web que contempla la norma. ↩ ↩2

  4. W3C, Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT). Sobre el Group Note del W3C que muestra cómo aplicar los principios, las pautas y los criterios de conformidad de WCAG 2.0/2.1/2.2 a documentos y software no web. ↩ ↩2

  5. Microsoft Learn, UI Automation Specification. Sobre cómo UI Automation proporciona información de la interfaz a tecnologías de asistencia como los lectores de pantalla y permite la operación por medios distintos de la entrada estándar, y sobre la composición de los elementos, el árbol, las propiedades, los patrones de control, los tipos de control y los eventos de UIA. ↩ ↩2 ↩3

  6. Microsoft Learn, WinForms: Setting the accessible name on a control. Sobre que el Text se reutiliza como Name de UIA en algunos controles, pero no en ComboBox, ListBox, ListView, PictureBox, ProgressBar, TabControl, TextBox, TreeView, etc.; que colocar el control objetivo justo después del TabIndex del Label hace que el texto del Label se use como Name; y sobre la asignación explícita de AccessibleName y el problema de la cadena vacía que queda en el archivo del diseñador. ↩ ↩2 ↩3 ↩4

  7. Microsoft Learn, WPF: Setting the accessible name on a button. Sobre que el Content de Button se reutiliza de forma predeterminada como Name de UIA, que un botón sin nombre impide que el lector de pantalla lea su propósito, y sobre la asociación con TextBlock mediante AutomationProperties.LabeledBy y la asignación explícita de AutomationProperties.Name. ↩ ↩2 ↩3 ↩4

  8. W3C / traducción del Comité de la Base de Accesibilidad Web (WAIC), Web Content Accessibility Guidelines (WCAG) 2.1, traducción al japonés. Sobre el criterio de conformidad 1.4.3 (Contraste mínimo) con 4.5:1 para el texto y 3:1 para el texto grande, el criterio de conformidad 1.4.1 (Uso del color) que exige no usar el color como único medio visual, y el criterio de conformidad 2.1.1 (Teclado) sobre la posibilidad de operar todas las funciones con el teclado. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  9. Microsoft Learn, Contrast themes. Sobre que el tema de contraste usa una paleta restringida con una relación de contraste de aproximadamente 7:1 o más, la selección de temas integrados y la edición de colores, y sobre que los recursos de la familia SystemColor se definen en pares de primer plano y fondo y siguen automáticamente el cambio de tema. ↩ ↩2 ↩3

  10. Microsoft Learn, Accessibility testing. Sobre los tres escenarios de Accessibility Insights for Windows —Live Inspect (comprobación de propiedades de UIA mediante hover/foco), FastPass (detección de problemas de alto impacto en menos de 5 minutos) y Troubleshooting— y la recomendación de migrar desde herramientas heredadas como Inspect y AccEvent. ↩ ↩2 ↩3

  11. Equipo japonés de NVDA, NVDA en japonés. Sobre NVDA, el lector de pantalla gratuito y de código abierto para Windows, y la provisión de su versión en japonés. ↩ ↩2

  12. Microsoft Learn, Walkthrough: Creating an Accessible Windows-based Application. Sobre colocar un Label descriptivo justo antes del campo de entrada en el orden de tabulación, la tecla de acceso mediante & en el Text, la determinación del alto contraste con SystemInformation.HighContrast y el uso de SystemColors, el seguimiento del evento UserPreferenceChanged, y la combinación de indicios visuales con la información transmitida por color. ↩ ↩2 ↩3

  13. Microsoft Learn, Providing Accessibility Information for Controls. Sobre las propiedades AccessibleName, AccessibleDescription, AccessibleRole y AccessibleDefaultActionDescription de los controles de WinForms, y su forma de configuración. ↩

  14. Microsoft Learn, WPF: Setting the accessible name on an edit field. Sobre que el Text de TextBlock se reutiliza como Name de UIA, pero el Text de TextBox se expone como Value de UIA, y sobre asociar un TextBlock de etiqueta a TextBox mediante AutomationProperties.LabeledBy, o bien asignar AutomationProperties.Name. ↩

  15. Microsoft Learn, UI Automation of a WPF Custom Control. Sobre cómo un control personalizado sobrescribe OnCreateAutomationPeer y devuelve una clase derivada de AutomationPeer, la herencia de la clase Peer correspondiente al control base, la provisión de proveedores de patrón mediante GetPattern, y la sobrescritura desde XAML mediante los atributos de AutomationProperties. ↩ ↩2

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿La accesibilidad de las aplicaciones empresariales es una obligación legal?
La Ley de Eliminación de la Discriminación por Discapacidad, reformada en 2021, entró en vigor el 1 de abril de 2024 y obliga también a las empresas a proporcionar ajustes razonables a las personas con discapacidad. El ajuste razonable es una respuesta que, cuando una persona con discapacidad lo solicita, elimina una barrera concreta dentro de un margen de carga que no sea excesivo; adaptar de antemano una aplicación para que sea fácil de usar se sitúa dentro del "acondicionamiento del entorno", una obligación de esfuerzo. Cabe señalar que el ámbito laboral, como la relación entre un empleado y su empresa, no depende de la Ley de Eliminación de la Discriminación por Discapacidad sino de la Ley de Promoción del Empleo de Personas con Discapacidad, que desde la reforma vigente en abril de 2016 obliga a los empleadores a proporcionar ajustes razonables. Es decir, la situación de "un empleado que no puede usar la aplicación empresarial" ya era, desde antes, un ámbito de obligación legal. Qué y hasta dónde se debe atender depende de cada situación concreta, por lo que conviene confirmar las fuentes primarias del Gabinete del Primer Ministro y del Ministerio de Salud, Trabajo y Bienestar, y decidirlo a través del diálogo con la persona interesada.
¿Cómo leen los lectores de pantalla las aplicaciones de escritorio de Windows?
Lectores de pantalla como Narrador o NVDA leen la interfaz de la aplicación a través de una base de accesibilidad llamada UI Automation (UIA). La aplicación expone los elementos de la pantalla en una estructura llamada árbol de UIA, y cada elemento tiene propiedades como Name (el propósito) y ControlType (el tipo), además de patrones de control como Invoke (pulsar) o Value (valor). El lector de pantalla lee esta información como, por ejemplo, "Confirmar pedido, botón", y opera el elemento a través de los patrones. Los controles estándar de WinForms y WPF incorporan este mecanismo desde el principio, así que el trabajo principal del desarrollador consiste en no dejar el Name vacío, permitir el manejo con teclado e implementar esta información en los controles personalizados.
En una aplicación WinForms ya existente, ¿por dónde conviene empezar?
El atajo más directo es ejecutar primero FastPass de Accessibility Insights for Windows sobre la pantalla objetivo, para detectar los controles con Name vacío y los problemas de orden de tabulación. Las correcciones conviene empezarlas por asignar AccessibleName a los botones que solo tienen icono, colocar el Label justo antes del campo de entrada en el orden de tabulación para que queden asociados, y ordenar el TabIndex para que coincida con la disposición visual. Después, active Narrador o NVDA y recorra una operación real del negocio sin mirar la pantalla, para comprobar en qué puntos se atasca. No es necesario corregir todas las pantallas a la vez: lo realista es empezar por las pantallas que realmente usan las personas afectadas, y tratar las pantallas nuevas con una lista de verificación como respuesta estándar.
¿Qué hay que hacer para el alto contraste (temas de contraste)?
La base consiste en respetar los colores del sistema en lugar de codificar colores de forma fija. En WinForms, esto significa dejar ForeColor/BackColor en sus valores predeterminados o usar SystemColors, determinar el estado con SystemInformation.HighContrast y seguir los cambios mediante el evento UserPreferenceChanged. En WPF o WinUI, si se hace referencia a los recursos de la familia SystemColors, la aplicación sigue automáticamente el cambio de tema. Además, abandone la comunicación que "depende solo del color", como mostrar un error únicamente en rojo, y combine iconos y texto. Incluso en el tema normal, tomar como referencia el criterio de WCAG de una relación de contraste de texto de al menos 4.5:1 mejora la legibilidad tanto en entornos con mala iluminación como para usuarios de mayor edad.
¿La accesibilidad también ayuda a las pruebas automatizadas de UI?
Sí, ayuda. Las herramientas de pruebas automatizadas de UI, como FlaUI, se basan en el mismo UI Automation que los lectores de pantalla. El Name, el ControlType y los patrones de control que se preparan para la accesibilidad se pueden usar directamente desde el código de prueba, y el AutomationId diseñado para las pruebas estabiliza la identificación de los elementos. A la inversa, una UI dibujada de forma personalizada que no aparece en el árbol de UIA resulta invisible tanto para los lectores de pantalla como para las pruebas. La accesibilidad y las pruebas automatizadas son inversiones sobre la misma base, así que mejorar una de ellas también reduce el costo de la otra.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.

Contactar
Volver al blog