Accesibilidad de las aplicaciones Windows — UI Automation y la obligatoriedad del ajuste razonable

«Un empleado con discapacidad visual no puede usar nuestra aplicación central de entrada de pedidos con un lector de pantalla. Maneja el navegador web y el correo sin problema, pero en nuestra aplicación empresarial sola los anuncios no funcionan.» Cada vez oímos más consultas de este tipo por parte de los departamentos de sistemas de información de los clientes.

El punto de partida para resolver este problema es mirar qué le está diciendo a la tecnología de asistencia, no cómo se ve la pantalla. Windows tiene UI Automation (UIA), el mecanismo a través del cual los lectores de pantalla leen la información de una aplicación. Una vez que se entiende cómo funciona y se cubren lo básico del nombre, el teclado y el color, la usabilidad de una aplicación empresarial mejora de forma sustancial.¹

En el plano legal, las aplicaciones Windows internas tampoco quedan fuera. La reforma de 2021 de la Ley de Eliminación de la Discriminación por Discapacidad entró en vigor el 1 de abril de 2024, y también las empresas están ahora obligadas a prestar ajustes razonables. El ámbito laboral, como en el ejemplo inicial, corresponde a la Ley de Promoción del Empleo de Personas con Discapacidad y es una obligación del empleador desde abril de 2016. El capítulo 2 ordena esta diferencia.²³

La accesibilidad de las aplicaciones de escritorio de Windows cuenta con menos información que la web, y no hay forma de resolverlo todo de una vez a posteriori. Gran parte de las mejoras necesarias, sin embargo, también eleva la productividad de todos los usuarios, con o sin discapacidad.

Este artículo está dirigido a desarrolladores de aplicaciones empresariales japonesas y a responsables de sistemas de información. Trata el marco legal y las normas, y el funcionamiento de UIA, y después pasa a la implementación en WinForms/WPF, al manejo por teclado, al color y el contraste, a la verificación y a cómo priorizar las correcciones.

flowchart TB
    accTitle: El flujo de este artículo
    accDescr: La estructura de este artículo, que conecta en orden el marco legal y las normas, el funcionamiento 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 la forma de fijar prioridades
    law["Marco legal y normas"] --> uia["Funcionamiento de UI Automation"]
    uia --> impl["Implementación en WinForms/WPF"]
    impl --> kb["Manejo por teclado"]
    kb --> color["Color y contraste"]
    color --> verify["Herramientas de verificación"]
    verify --> prio["Cómo fijar prioridades"]

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

1. Primero la conclusión

Tres puntos que conviene retener al inicio.

1. Separe el ajuste razonable individual de la mejora previa del entorno. El ajuste razonable es un proceso de respuesta a una solicitud mediante diálogo constructivo, dentro de un margen que no sea una carga excesiva. Las empresas están obligadas desde abril de 2024, y los empleadores en el ámbito laboral desde abril de 2016. Corregir una aplicación de antemano corresponde a la «mejora del entorno» (un deber de esfuerzo), que es otra cosa que dejar cada pantalla perfecta desde el principio.²³
2. La base técnica es exponer información a UIA, más lo básico del nombre, el teclado y el color. El Name y el ControlType del árbol de UIA, y patrones como Invoke, Value y SelectionItem, son el material del anuncio y de la operación. La asignación de nombres va primero. WinForms lo resuelve con AccessibleName y la asociación entre un Label y el orden de tabulación; WPF, con AutomationProperties.Name/LabeledBy; además se ordenan el manejo por teclado, un esquema de color guiado por una relación de contraste de 4,5:1 y presentaciones que no dependen solo del color.¹⁴⁵⁶
3. Verifique y corrija a partir del trabajo real. Combine FastPass de Accessibility Insights con comprobaciones prácticas con un lector de pantalla, y recorra en este orden las pantallas de las que depende el usuario, luego las pantallas nuevas y después los controles compartidos. Las mismas mejoras también ayudan a las pruebas automatizadas de UI como FlaUI, que se apoyan en la misma base de UIA.⁷

Los criterios técnicos se pueden ordenar en torno a WCAG. JIS X 8341-3:2016 es una norma idéntica con el mismo contenido que WCAG 2.0, y WCAG2ICT ofrece orientación para aplicarla a software no web. La sección 2.2 entra en el detalle.⁸⁹

Si quiere leer según su objetivo, empiece por el capítulo siguiente.

En una frase, la accesibilidad consiste en «exponer nombres y operaciones correctos en el árbol de UIA, y respetar lo básico del teclado y el color».

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (16 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

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

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

Esta sección separa tres preguntas: qué se convirtió en obligación, dónde encajan las correcciones previas y qué ley rige en el ámbito laboral.

Los ajustes razonables por parte de las empresas pasaron de un deber de esfuerzo a una obligación

La Ley de Eliminación de la Discriminación por Discapacidad prohíbe a los órganos administrativos y a las empresas el «trato discriminatorio injusto» a las personas con discapacidad y les exige «prestar ajustes razonables». Con la reforma de 2021 (Reiwa 3), la prestación de ajustes razonables por parte de las empresas, hasta entonces un deber de esfuerzo, se convirtió en obligación, y la reforma entró en vigor el 1 de abril de 2024 (Reiwa 6).²

El folleto del Gabinete lo explica como responder, dentro de un margen que no sea una carga excesiva, cuando una persona con discapacidad expresa el deseo de que se elimine una barrera. Como el detalle cambia según el tipo de discapacidad, la escena y la situación, es importante el «diálogo constructivo», en el que la persona y la empresa examinan juntas las opciones. El folleto indica de forma explícita que negarse unilateralmente al diálogo puede constituir una infracción de la obligación de prestar el ajuste.²

Trate las correcciones previas de la aplicación como «mejora del entorno»

No se volvió obligatorio tenerlo todo listo de antemano. Las medidas que se toman de antemano para un número indeterminado de personas con discapacidad, como revisar manuales, formar y hacer accesibles las instalaciones, se llaman «mejora del entorno» y se sitúan como un deber de esfuerzo.²

Dejar una aplicación empresarial en un estado que un lector de pantalla pueda usar de antemano puede verse como un esfuerzo de este lado de la mejora del entorno. Cuanto más haya avanzado esa mejora, más ligera es la carga de prestar un ajuste razonable individual.

Donde intervienen empleados, mire la Ley de Promoción del Empleo de Personas con Discapacidad

El empleo y el trabajo corresponden a la Ley de Promoción del Empleo de Personas con Discapacidad, no a la Ley de Eliminación de la Discriminación por Discapacidad. El folleto del Gabinete también anota esta distinción.²

Bajo la Ley de Promoción del Empleo de Personas con Discapacidad, la reforma vigente desde abril de 2016 (Heisei 28) obliga a los empleadores a abstenerse de discriminación por discapacidad en el empleo y a prestar ajustes razonables dentro de un margen que no sea una carga excesiva. La pregunta inicial, «un empleado no puede usar la aplicación empresarial», está por tanto en el territorio de la obligación desde mucho antes de 2024.³

flowchart TB
    accTitle: Dónde encajan el ajuste razonable y la mejora del entorno
    accDescr: La relación entre una empresa general y una persona con discapacidad corresponde a la Ley de Eliminación de la Discriminación por Discapacidad, y prestar ajustes razonables respondiendo a una solicitud individual mediante diálogo constructivo es obligatorio desde abril de 2024; el ámbito laboral es una obligación del empleador desde abril de 2016 bajo la Ley de Promoción del Empleo de Personas con Discapacidad; corregir una aplicación de antemano corresponde a la mejora del entorno, un deber de esfuerzo
    scene{"¿Qué escena?"} -->|Empresa y una persona con discapacidad| kaisho["Ley de Eliminación de la Discriminación por Discapacidad"]
    scene -->|Empleo y trabajo| koyou["Ley de Promoción del Empleo de Personas con Discapacidad"]
    kaisho --> moushide["Responder a solicitudes individuales mediante diálogo constructivo"]
    moushide --> hairyo["Prestación de ajustes razonables (obligación desde abril de 2024)"]
    koyou --> koyougimu["Prestación de ajustes razonables (obligación desde abril de 2016)"]
    kaisho -.-> kankyo["Correcciones previas de la aplicación = mejora del entorno (deber de esfuerzo)"]
    kankyo -.-> moushide

Figura 2: La ley aplicable depende de la escena; el ajuste razonable es una obligación, y las correcciones previas corresponden a la mejora del entorno, un deber de esfuerzo.

Cómo se trata un caso concreto en derecho depende de la situación. Este artículo no entra en la interpretación jurídica; parte del punto de vista de lo que un ingeniero puede hacer cuando se le pide responder. Como fuentes primarias, véanse los materiales del Gabinete y del Ministerio de Salud, Trabajo y Bienestar.²³

2.2. JIS X 8341-3 y WCAG — los «criterios de la web» también se extienden al software

Cuando se leen los criterios técnicos con detalle, ordenarlos en torno a WCAG da la vista más clara. JIS X 8341-3:2016, WCAG y WCAG2ICT se relacionan así.⁸⁶⁹

A la pregunta «¿WCAG no es una norma para contenido web?», WCAG2ICT es el puente. Su nombre completo es Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies.⁹

Ideas como las alternativas de texto, el contraste, el manejo por teclado y no transmitir información solo con el color se aplican a una aplicación de escritorio de Windows en el mismo marco. A partir del capítulo 3, este artículo las traduce a implementación en WinForms/WPF.

flowchart TB
    accTitle: La relación entre JIS X 8341-3 y WCAG
    accDescr: JIS X 8341-3:2016 es una norma idéntica con el mismo contenido que WCAG 2.0, y WCAG2ICT muestra cómo aplicar los criterios de conformidad de WCAG a software no web, de modo que una aplicación de escritorio de Windows se puede inspeccionar en el mismo marco
    wcag["WCAG 2.0 (W3C)"] ---|Norma idéntica con el mismo contenido| jis["JIS X 8341-3:2016"]
    wcag --> ict["WCAG2ICT"]
    ict --> soft["Aplicado a software no web"]
    soft --> app["Aplicaciones de escritorio de Windows"]

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

3. Cómo lee la tecnología de asistencia una aplicación — el trío de UI Automation

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

UI Automation (UIA), integrada en Windows, es la base de accesibilidad que media entre la aplicación y la tecnología de asistencia. La aplicación expone la información de la interfaz como «proveedor», y la tecnología de asistencia, como un lector de pantalla, la obtiene como «cliente». El manejo de la interfaz por medios distintos de la entrada estándar también lo hace posible este mecanismo.¹

Empiece por entenderlo como un trío: la estructura de la pantalla, la naturaleza de cada elemento y las operaciones disponibles.¹

Por ejemplo, el anuncio «Confirmar pedido, botón» cuando un botón recibe el foco es, a grandes rasgos, la combinación de Name y tipo de control. Cuando el usuario da una orden de ejecución, la tecnología de asistencia pulsa el botón a través del patrón Invoke.

Es decir, que un botón esté dibujado en pantalla y que un botón sea legible y operable por la tecnología de asistencia son dos cosas distintas. Si Name y los patrones no se exponen correctamente, el botón podría no existir, aunque se vea en pantalla.

flowchart TB
    accTitle: El trío de UI Automation
    accDescr: La aplicación, como proveedor, expone las propiedades y los patrones de control de cada elemento en el árbol de UIA; el lector de pantalla, como cliente, anuncia Name y ControlType y opera a través de patrones como Invoke
    app["Aplicación (proveedor)"] --> tree["Árbol de UIA"]
    tree --> prop["Propiedades (Name, ControlType, etc.)"]
    tree --> pat["Patrones (Invoke, Value, etc.)"]
    sr["Lector de pantalla (cliente)"] -->|Anuncia| prop
    sr -->|Opera| pat

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

3.2. Un lector de pantalla es un cliente de UIA

Los principales lectores de pantalla en Windows son Narrator, integrado, NVDA, libre y de código abierto,¹⁰ y PC-Talker, un producto comercial muy usado en Japón.

Cada uno tiene su propio estilo de anuncio, pero la vía principal para leer la interfaz de una aplicación de escritorio es UIA en todos los casos. El trabajo del lado de la aplicación se reduce por tanto a exponer información correcta a UIA, no a apuntar a un lector de pantalla concreto.

flowchart TB
    accTitle: La vía común de los principales lectores de pantalla
    accDescr: Si la aplicación expone información correcta a UIA, Narrator, NVDA y PC-Talker pueden leer todos la interfaz por la misma vía, de modo que el trabajo del lado de la aplicación no apunta a un lector de pantalla concreto sino que se reduce a exponer a UIA
    app["Aplicación"] -->|Expone información| uia["UI Automation (UIA)"]
    uia --> nar["Narrator"]
    uia --> nvda["NVDA"]
    uia --> pct["PC-Talker"]
    app -.-> goal["El trabajo se reduce a exponer a UIA"]

Figura 5: Los principales lectores de pantalla pasan todos por UIA, de modo que el trabajo de la aplicación se reduce a exponer a UIA.

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

Suponga que una barra de herramientas tiene un botón Guardar que solo muestra un icono de disquete. Aunque el propósito sea claro a la vista, si Name queda vacío el lector de pantalla no anuncia nada más que «botón». Si los «Abrir» e «Imprimir» vecinos están en el mismo estado, el usuario oye solo «botón, botón, botón» y no puede distinguirlos.

Los botones sin Name y las imágenes anunciadas solo como «Image» aparecen en las guías de corrección de Microsoft como problemas típicos que detienen el trabajo del usuario.⁵

Los controles estándar de WinForms/WPF admiten UIA desde el principio, y en la mayoría Name se deriva automáticamente del texto o de una etiqueta. Las tres formas típicas en que se rompe son las siguientes.

Los dos capítulos siguientes conectan este triaje con las correcciones de WinForms y de WPF.

flowchart TB
    accTitle: Tres formas típicas en que se rompe el anuncio
    accDescr: El anuncio se rompe cuando no hay material para un nombre porque el control es solo un icono, cuando no hay asociación con una etiqueta, o cuando el dibujo personalizado no pone información en el árbol de UIA, y el control acaba anunciado solo como botón
    c1["Solo icono, sin material"] --> broken["Name acaba vacío"]
    c2["Sin asociación de etiqueta"] --> broken
    c3["El dibujo personalizado no expone nada"] --> broken
    broken --> result["Anunciado solo como botón"]

Figura 6: Los anuncios rotos suelen reducirse a tres patrones: falta de material para un nombre, falta de asociación o dibujo personalizado.

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

4.1. Controles cuyo Text se convierte en Name de forma automática, y controles cuyo Text no

Primero, comprobar si el control es de un tipo cuyo Text se usa como nombre

En WinForms, incluso entre los controles que muestran texto, algunos usan Text como Name de UIA y otros no.⁴

Use una etiqueta visible y asigne AccessibleName donde no pueda colocar una

El enfoque más fácil de mantener es colocar un Label descriptivo inmediatamente antes del control objetivo en el orden de tabulación. Si el TabIndex del control objetivo viene justo después del TabIndex del Label, el texto del Label se usa como Name de UIA. La presentación y el anuncio coinciden, y se evita mantener el texto dos veces.⁴¹¹

Donde no pueda colocar un Label, asigne AccessibleName de forma explícita. También puede asignar AccessibleDescription para información complementaria, y AccessibleRole cuando el rol deba coincidir con lo que el control hace de verdad.¹²

flowchart TB
    accTitle: Cómo se decide el nombre de un control WinForms
    accDescr: En Button y controles similares, Text se convierte en el Name de UIA tal cual; en controles como TextBox cuyo Text no se reutiliza, se usa el texto de un Label colocado inmediatamente antes en el orden de tabulación; donde no se puede colocar un Label, se asigna AccessibleName de forma explícita
    ctrl["Control"] --> qtext{"¿Text se convierte en Name?"}
    qtext -->|Sí| usetext["Text se usa como Name tal cual"]
    qtext -->|No| qlabel{"¿Label inmediatamente antes en el orden de tabulación?"}
    qlabel -->|Sí| uselabel["El texto del Label se usa como Name"]
    qlabel -->|No| explicit["Asignar AccessibleName de forma explícita"]

Figura 7: Un Name de WinForms se decide en el orden Text, el Label inmediatamente anterior en el orden de tabulación y después AccessibleName.

// Botón de barra de herramientas solo con icono: asignar el nombre para el anuncio de forma explícita
saveToolStripButton.AccessibleName = "Guardar";

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

// Campo de entrada donde no se puede colocar un Label inmediatamente antes en el orden de tabulación: asignarlo directo
txtOrderNo.AccessibleName = "Número de pedido";

// PictureBox reutilizado como gráfico: hacer coincidir el rol con lo que es de verdad
pictureBoxChart.AccessibleRole = AccessibleRole.Chart;
pictureBoxChart.AccessibleName = "Gráfico de pedidos mensuales";

Cuando borró el nombre pero el anuncio predeterminado no vuelve

Si asigna AccessibleName una vez en el panel Propiedades de Visual Studio y después lo borra, puede quedar un valor con una cadena vacía en el archivo de diseñador. Si ese valor bloquea la resolución de nombre predeterminada, elimine la línea del archivo de diseñador.⁴

flowchart TB
    accTitle: El problema de un AccessibleName de cadena vacía que permanece
    accDescr: Si asigna AccessibleName una vez en el panel Propiedades y después lo borra, queda un valor de cadena vacía en el archivo de diseñador y bloquea la resolución de nombre predeterminada, se corrige eliminando la línea del archivo de diseñador
    set["Asignar AccessibleName"] --> erase["Borrarlo en el panel Propiedades"]
    erase --> remain["Queda un valor de cadena vacía"]
    remain --> block["Bloquea la resolución de nombre predeterminada"]
    block -.-> fix["Eliminar la línea del archivo de diseñador"]

Figura 8: Borrar el valor en el panel Propiedades deja una cadena vacía, corríjalo eliminando la línea del archivo de diseñador.

4.2. Mejoras frecuentes en una pantalla de entrada de pedidos

Esta es una lista de verificación de los puntos que más a menudo corregimos en aplicaciones empresariales.

Cada una es una corrección de unas pocas líneas, pero para un usuario de lector de pantalla es la diferencia entre una pantalla que no puede usar y una que sí.

5. Implementación en WPF — AutomationProperties y AutomationPeer

5.1. AutomationProperties.Name / LabeledBy / HelpText

Dé a un botón su nombre mediante Content de cadena o una asignación explícita

En un control cuyo Content es una cadena, como un Button de WPF, ese contenido se usa como Name de UIA. Un botón que solo contiene un Image o un Path, en cambio, no tiene material para un nombre. O bien se asigna de forma explícita con AutomationProperties.Name, o bien, si hay texto visible cerca, se asocia con AutomationProperties.LabeledBy.⁵

En un TextBox, separe el «nombre» del «valor de entrada»

El Text de un TextBlock se reutiliza como Name, pero el Text de un TextBox se expone en la propiedad Value de UIA y no se convierte en Name. Aunque el campo tenga un valor, eso por sí solo no le dice al usuario para qué sirve el campo.¹³

Para un campo de entrada, la primera opción es asociar el TextBlock de etiqueta visible mediante LabeledBy. La presentación y el anuncio coinciden, y se evita mantener el texto dos veces.¹³

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

<!-- Botón solo con icono: asignar el nombre de forma explícita y añadir un complemento si hace falta -->
<Button
    AutomationProperties.Name="Confirmar pedido"
    AutomationProperties.HelpText="Confirma el pedido en curso y reserva el inventario">
    <Path Data="{StaticResource CheckIconGeometry}" Width="16" Height="16" />
</Button>

flowchart TB
    accTitle: Cómo se decide el nombre de un control WPF
    accDescr: Un control cuyo Content es una cadena usa ese contenido como Name; si no, la primera opción es asociar una etiqueta visible cercana mediante LabeledBy, y si no hay ninguna se asigna AutomationProperties.Name de forma explícita; el Text de un TextBox se expone como Value, no como Name
    ctrl["Control"] --> qc{"¿El Content es una cadena?"}
    qc -->|Sí| auto["El contenido se convierte en Name"]
    qc -->|No| ql{"¿Etiqueta visible cerca?"}
    ql -->|Sí| lb["Asociar mediante LabeledBy"]
    ql -->|No| nm["Asignar Name de forma explícita"]
    tbx["Text del TextBox"] -.-> val["Expuesto como Value, no como Name"]

Figura 9: Un Name de WPF se decide en el orden Content de cadena, LabeledBy y después una asignación explícita; el Text de un TextBox no se convierte en Name.

HelpText y AutomationId tienen roles distintos del nombre

La información complementaria que no cabe en Name se expone mediante AutomationProperties.HelpText.⁵ AutomationId es un identificador que también se usa para localizar elementos en las pruebas automatizadas de UI. Decidir una convención de nombres en la fase de diseño de pantalla se nota en las pruebas posteriores.

En resumen, Name es el propósito, HelpText el complemento y AutomationId el identificador. Cómo se usan en las pruebas automatizadas se trata con detalle en «Pruebas de UI automatizadas para aplicaciones de escritorio de Windows».

5.2. Los controles personalizados necesitan un AutomationPeer

Un control dibujado a medida no puede, por sí solo, exponer información con sentido en el árbol de UIA. En WPF se exponen el nombre, el tipo y los patrones sobrescribiendo OnCreateAutomationPeer en una clase derivada de UIElement y devolviendo una clase derivada de AutomationPeer.¹⁴

Si hereda de un control existente, herede también del Peer correspondiente. En ButtonBase, por ejemplo, usar ButtonBaseAutomationPeer permite reutilizar el comportamiento ya implementado.¹⁴

flowchart TB
    accTitle: Cómo AutomationPeer expone la información
    accDescr: Un control personalizado expone el nombre, el tipo y los patrones sobrescribiendo OnCreateAutomationPeer y devolviendo una clase derivada de AutomationPeer; si hereda un control existente, hereda el Peer correspondiente y reutiliza el comportamiento ya implementado
    custom["Control personalizado"] --> ov["OnCreateAutomationPeer"]
    ov --> peer["Devolver una clase derivada de Peer"]
    peer --> pub["Exponer nombre, tipo y patrones"]
    inherit["Hereda un control existente"] -.-> basepeer["Heredar el Peer correspondiente"]
    basepeer -.-> reuse["Reutilizar el comportamiento implementado"]

Figura 10: Un control personalizado devuelve un Peer desde OnCreateAutomationPeer para exponer información a UIA.

// Ejemplo de un control que dibuja a medida el estado de la línea como 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 la línea: en línea" : "Estado de la línea: sin conexión";

    private static void OnIsOnlineChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        // Emitir el evento de cambio de propiedad de UIA en el momento en que cambia el valor. Sin él,
        // el lector de pantalla conserva el nombre antiguo y nunca se entera del 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; // Text encaja en una presentación de estado sin operaciones

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

Notifique los cambios de estado, no solo el nombre actual

El ejemplo anterior combina dos cosas: devolver un nombre que refleja el estado actual, y emitir un evento de cambio de la propiedad Name cuando cambia IsOnline.

El trabajo del Peer no es solo devolver el nombre, sino también señalar el cambio con un evento en el momento en que ocurre. La tecnología de asistencia no tiene un momento propio para volver a pedir un valor; sin el evento, la implementación es «correcta solo cuando se vuelve a preguntar», y los usuarios de lector de pantalla nunca se enteran de que el estado ha cambiado.

sequenceDiagram
    accTitle: Cómo un cambio de estado llega al lector de pantalla
    accDescr: En el momento en que cambia el valor del control, el AutomationPeer emite un evento de cambio de la propiedad Name; la tecnología de asistencia no vuelve a pedir por sí sola, así que sin el evento conserva el nombre antiguo y nunca se entera del cambio
    participant c as Control
    participant p as AutomationPeer
    participant s as Lector de pantalla
    c->>p: Cambia el valor de IsOnline
    p->>s: Emite un evento de cambio de la propiedad Name
    s->>s: Anuncia el nuevo estado
    Note over s: Sin el evento, permanece el nombre antiguo

Figura 11: Un cambio de valor llega al lector de pantalla solo cuando el AutomationPeer lo señala con un evento de cambio.

Si el control tiene operaciones, implemente los patrones y póngalos en componentes compartidos

En controles personalizados que se pueden pulsar, que tienen un valor modificable o que se pueden seleccionar, sobrescriba GetPattern y proporcione interfaces de patrón como IInvokeProvider e IRangeValueProvider.¹⁴

Si construye el Peer en la biblioteca de controles compartidos, cada pantalla que la use queda conforme de forma automática. Esa es la base del despliegue que describe el capítulo 9.

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

El criterio de conformidad 2.1.1 de WCAG (Teclado) exige que toda la funcionalidad sea operable a través de una interfaz de teclado.⁶ Los usuarios de lector de pantalla por lo general no usan ratón, de modo que una función a la que no se puede llegar con el teclado es la misma que una función que no existe.

6.1. Compruebe el movimiento, la ejecución y la posición actual

Compruebe no solo el orden de tabulación, sino también que se puedan ejecutar las operaciones principales y que el foco actual sea visible.

La guía de accesibilidad de WinForms también cita, como bases, colocar una etiqueta inmediatamente antes de un campo de entrada en el orden de tabulación y dar teclas de acceso a los controles y menús a los que el usuario quiere moverse.¹¹

6.2. El trabajo de teclado también mejora la eficiencia de entrada de todos los usuarios

Esto no es solo «un coste extra para apoyar a las personas con discapacidad». En un trabajo rutinario como la entrada de pedidos, si el operador puede completar la entrada sin dejar la posición de reposo decide cuántas operaciones saca adelante.

Un orden de tabulación revuelto o una operación que exige el ratón es un defecto que recorta un poco cada día la productividad de todos los usuarios. El trabajo de accesibilidad y la eficiencia de teclado son dos nombres para el mismo trabajo. Para las prioridades según el entorno de uso, véase también «Diseño de UX para apps de Windows».

flowchart TB
    accTitle: El doble efecto del trabajo de teclado
    accDescr: Poner en orden el orden de tabulación, las teclas de acceso y la indicación de foco produce dos efectos a la vez, que los usuarios de tecnología de asistencia puedan alcanzar las funciones y la velocidad de entrada de todos los operadores, mientras que una función usable solo con el ratón es la misma que una función que no existe
    seibi["Manejo por teclado puesto en orden"] --> a11y["Los usuarios de tecnología de asistencia pueden trabajar"]
    seibi --> speed["Velocidad de entrada de todos los operadores"]
    mouse["Funciones solo con ratón"] -.-> none["Equivalente a funciones inexistentes"]

Figura 12: El trabajo de teclado aporta a la vez soporte de la tecnología de asistencia y eficiencia para todos los usuarios; una función solo con ratón equivale a una función inexistente.

7. Color y contraste — 4,5:1 y «no solo con el color»

7.1. La guía de la relación de contraste es 4,5:1

El criterio de conformidad 1.4.3 de WCAG (Contraste (mínimo)) 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.⁶

Los diseños que ponen texto gris claro sobre fondo blanco incumplen este criterio más a menudo de lo que se piensa. Tenga presentes a las personas cuya visión y percepción del color han cambiado con la edad y a quienes trabajan en lugares mal iluminados como fábricas, y haga hábito medir con un comprobador de contraste en la revisión de diseño.

7.2. No transmita información solo con el color

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

Teniendo en cuenta la diversidad de la visión del color, esto también es una base del diseño de presentación, no una «medida especial».

flowchart TB
    accTitle: Sustituir la información transmitida solo con el color
    accDescr: Una presentación que muestra errores solo en texto rojo se sustituye por un icono de error y una columna de mensaje al lado, una que muestra campos obligatorios solo por el color de la etiqueta recibe un marcador Obligatorio, y una que muestra el estado solo por el color de la lámpara se sustituye por forma o texto junto al color
    err["Errores solo en texto rojo"] --> erra["Añadir un icono y un texto"]
    req["Obligatorio solo por el color de la etiqueta"] --> reqa["Añadir un marcador Obligatorio"]
    lamp["Estado solo por el color de la lámpara"] --> lampa["Combinar el color con forma o texto"]

Figura 13: Sustituya las pistas típicas solo de color por un icono, un marcador, o forma y texto junto al color.

7.3. Seguir los temas de contraste (alto contraste)

Los temas de contraste de Windows (antes alto contraste) son esquemas de color que separan con fuerza el primer plano y el fondo. Los temas integrados están diseñados para una relación de contraste de unos 7:1 o más, y los usuarios pueden seleccionarlos y editarlos.¹⁵

Del lado de la aplicación, no codifique colores de forma fija; respete los colores del sistema. Lo que hay que hacer en cada marco es lo siguiente.

Para los ajustes concretos de WinForms, véase la guía de Microsoft; para los colores del tema, la documentación de los temas de contraste.¹¹¹⁵

flowchart TB
    accTitle: Seguir los temas de contraste
    accDescr: Los sitios donde los colores están codificados de forma fija se rompen al pasar a un tema de contraste, así que pase a un esquema basado en SystemColors y siga mediante el evento de cambio de ajustes; si referencia los colores del sistema, la interfaz sigue los colores del usuario de forma automática
    theme["Pasar a un tema de contraste"] --> qh{"¿Cómo se especifican los colores?"}
    qh -->|Codificados de forma fija| broken["El esquema de color se rompe"]
    qh -->|Referencias a colores del sistema| ok["Sigue los colores del usuario de forma automática"]
    broken -.-> fix["Pasar a SystemColors"]
    fix -.-> ev["Seguir mediante el evento de cambio de ajustes"]

Figura 14: Solo los colores codificados de forma fija se rompen bajo un tema de contraste; las referencias a colores del sistema siguen de forma automática.

Incluya sobrevivir al alto DPI en la misma comprobación

Los usuarios con baja visión suelen trabajar con un factor de escala del sistema operativo alto (escalado DPI), de modo que el soporte de alto DPI también forma parte de la accesibilidad. Una aplicación cuya disposición se rompe entre el 125 % y el 200 % es inutilizable en ese entorno.

Para el detalle, véase «Compatibilidad de WinForms con pantallas de alto DPI» y «Compatibilidad de WPF con alto DPI».

8. La verificación en la práctica — Accessibility Insights y comprobaciones prácticas con lector de pantalla

8.1. Accessibility Insights for Windows

Accessibility Insights for Windows de Microsoft ofrece tres formas de trabajo, según el objetivo.⁷

Inspect.exe y AccEvent, incluidos en el Windows SDK, también pueden mostrar el árbol de UIA y las propiedades, pero están situados como herramientas heredadas, y ahora se recomienda pasar a Accessibility Insights.⁷

flowchart TB
    accTitle: Los tres modos de Accessibility Insights
    accDescr: Accessibility Insights for Windows ofrece Live Inspect para comprobar propiedades de UIA, FastPass para una comprobación ligera de problemas de alto impacto y Troubleshooting para ayudar a diagnosticar y corregir problemas, y se recomienda la migración desde herramientas heredadas como Inspect.exe
    ai["Accessibility Insights"] --> live["Live Inspect"]
    ai --> fast["FastPass"]
    ai --> ts["Troubleshooting"]
    live --> livef["Comprobar propiedades de UIA"]
    fast --> fastf["Detectar problemas de alto impacto"]
    ts --> tsf["Ayudar a diagnosticar y corregir"]
    legacy["Inspect.exe y otros"] -.->|Migración recomendada| ai

Figura 15: Accessibility Insights tiene tres modos, comprobar, detectar y diagnosticar, y es el reemplazo recomendado de las herramientas heredadas.

8.2. Comprobaciones prácticas con un lector de pantalla

Pasar una comprobación automática y poder completar un trabajo real son dos cosas distintas. Las herramientas solo pueden detectar problemas que se pueden juzgar de forma mecánica, así que termine siempre recorriendo una operación de negocio con un lector de pantalla.

Primero, inicie Narrator con Ctrl+tecla Windows+Entrar, o instale el NVDA gratuito.¹⁰ Después elija una tarea representativa como «introducir un pedido y confirmarlo» e intente completarla solo con los anuncios, sin mirar la pantalla o con la pantalla apagada.

Problemas como un orden de anuncio incoherente pese a tener nombres asignados, o un foco que se escapa de un cuadro de diálogo modal, solo se encuentran con este tipo de comprobación práctica.

flowchart TB
    accTitle: Combinar la verificación con herramientas y las comprobaciones prácticas
    accDescr: Una comprobación automática como FastPass solo puede detectar problemas que se pueden juzgar de forma mecánica; para el resto, recorra operaciones reales de negocio con un lector de pantalla y encuentre problemas de orden de anuncio y de foco sobre el terreno
    tool["Comprobación automática con herramienta"] --> kikai["Problemas que se pueden juzgar de forma mecánica"]
    tool -.-> nokori["Quedan problemas indetectables"]
    nokori --> sr["Comprobación práctica con un lector de pantalla"]
    sr --> task["Recorrer una operación de negocio"]
    task --> mieru["Problemas de orden de anuncio y de foco"]

Figura 16: Use la comprobación automática para listar los problemas mecánicos, y encuentre el resto con comprobaciones prácticas con un lector de pantalla.

8.3. Integrarlo en el flujo de desarrollo y la sinergia con las pruebas automatizadas de UI

Para que la verificación no dependa de personas concretas, recomendamos añadir la siguiente lista de verificación a los puntos de revisión de cada pantalla nueva.

Reutilice el trabajo de UIA también para las pruebas automatizadas

Las pruebas automatizadas de UI con FlaUI y herramientas similares se basan en el mismo UIA que usan los lectores de pantalla. El Name y los patrones que se preparan para la accesibilidad se convierten en piezas del código de prueba, y el AutomationId que diseñó para las pruebas también facilita la depuración en Live Inspect.

A la inversa, una interfaz 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 las dos caras de la misma inversión. Para el detalle, véase «Pruebas de UI automatizadas para aplicaciones de escritorio de Windows».

flowchart TB
    accTitle: La sinergia entre accesibilidad y pruebas automatizadas de UI
    accDescr: Los lectores de pantalla y las pruebas automatizadas de UI como FlaUI se basan en el mismo UIA, de modo que el Name y los patrones que se preparan se pueden usar desde ambos, y una interfaz que no aparece en el árbol de UIA es invisible para ambos
    uia["Árbol de UIA puesto en orden"] --> sr["Los lectores de pantalla pueden leerlo"]
    uia --> test["Las pruebas automatizadas de UI pueden usarlo"]
    sr -.-> both["Dos caras de la misma inversión"]
    test -.-> both
    hidden["Interfaz ausente de UIA"] -.-> invisible["Invisible para ambos"]

Figura 17: Como ambos se asientan sobre la misma base de UIA, poner en orden el árbol de UIA ayuda tanto a la tecnología de asistencia como a las pruebas automatizadas de UI.

9. Cómo priorizar — no corrija todas las pantallas a la vez

Rehacer de golpe un sistema central con cientos de pantallas no es realista ni en coste ni en calidad. Recomendamos proceder en las tres etapas siguientes.

9.1. Empiece por las pantallas de las que depende ese usuario en el trabajo

El ajuste razonable es un proceso de respuesta individual a la solicitud de la persona.² Haga primero que la persona opere su trabajo real con un lector de pantalla, e identifique juntos dónde se atasca.

En la mayoría de los casos, las pantallas usadas en el día a día se reducen a un puñado o a una docena. Los problemas críticos entre ellas, como botones sin nombre o un botón de confirmar que no se puede pulsar con el teclado, se resuelven con correcciones medidas en días.

9.2. Haga el desarrollo nuevo conforme de serie

Añada la lista de verificación del capítulo 8 a la Definition of Done. La línea es que las pantallas nuevas se construyen conformes desde el principio. A diferencia de adaptar a posteriori, incorporarlo en el diseño añade solo un coste pequeño.

9.3. Extienda por las pantallas corrigiendo los controles compartidos

Implemente valores predeterminados de AccessibleName y AutomationPeer en los diálogos de búsqueda, cuadrículas, entradas de fecha y similares compartidos internamente. Corrija un componente compartido y la corrección surte efecto de golpe en cada pantalla que lo usa. Es un movimiento más rentable que corregir las pantallas una a una.

flowchart TB
    accTitle: Las tres etapas de priorización de las correcciones
    accDescr: Empiece por las pantallas de las que depende el usuario en el trabajo, haga el desarrollo nuevo conforme de serie con la lista de verificación y extienda a cada pantalla corrigiendo los controles compartidos
    s1["1. Empezar por las pantallas de las que depende el usuario"] --> s2["2. Desarrollo nuevo conforme de serie"] --> s3["3. Extender a través de los controles compartidos"]
    s3 -.-> all["Surte efecto de golpe en cada pantalla que los usa"]

Figura 18: En lugar de rehacer todas las pantallas de golpe, proceda en tres etapas: las pantallas en uso, el desarrollo nuevo y los componentes compartidos.

9.4. Registre el curso del diálogo, no solo las correcciones

Tan importante como el trabajo técnico es el registro del diálogo. El ajuste razonable es un proceso de hablar y ajustar caso por caso, no de satisfacer por completo cada solicitud.

En correcciones que serían una carga excesiva, considerar y acordar alternativas con la persona, como realizar la tarea en otra pantalla, ofrecer una exportación CSV o cubrirla por operación, es un resultado legítimo del diálogo constructivo.²

Registrar qué se pidió, qué se hizo y qué se ofreció como alternativa es lo que demuestra la buena fe de la organización.

flowchart TB
    accTitle: El flujo del diálogo constructivo y del registro
    accDescr: Responder a una solicitud de una persona con discapacidad mediante diálogo constructivo, llevar a cabo las correcciones posibles, en las correcciones que serían una carga excesiva considerar y acordar una alternativa con la persona, y registrar qué se pidió, qué se hizo y qué se ofreció como alternativa
    req["Solicitud"] --> talk["Diálogo constructivo"]
    talk --> q{"¿Carga excesiva?"}
    q -->|No| kaishu["Responder con una corrección"]
    q -->|Sí| alt["Considerar y acordar una alternativa"]
    kaishu --> rec["Registrar el curso de los hechos"]
    alt --> rec

Figura 19: En el diálogo constructivo, acuerde con la persona una corrección o una alternativa y deje constancia de cómo transcurrió.

10. Resumen

Separar el marco legal, la técnica y el procedimiento hace visible el punto de partida.

En lo legal, el ajuste razonable por parte de las empresas es obligatorio desde abril de 2024, y por parte de los empleadores en el ámbito laboral desde 2016. Corregir una aplicación de antemano corresponde a la «mejora del entorno» (un deber de esfuerzo), y cuanto más haya avanzado, más ligera es la respuesta individual. Registre también el curso del diálogo.

En lo técnico, inspeccione las aplicaciones de escritorio en torno a WCAG (JIS X 8341-3:2016) a través de WCAG2ICT. La base es el árbol de UIA, sus propiedades (Name/ControlType/AutomationId) y los patrones de control. La asignación de nombres, de máxima prioridad, se trata con AccessibleName y Label más orden de tabulación en WinForms, AutomationProperties.Name/LabeledBy en WPF y un AutomationPeer para controles personalizados.

Encima, ponga en orden el orden de tabulación, las teclas de acceso y la indicación de foco para que se pueda llegar a todas las funciones solo con el teclado. En el color, tome una relación de contraste de 4,5:1 como guía, no dependa solo del color y respete los colores del sistema bajo los temas de contraste. Estas mejoras también elevan la productividad de todos los operadores.

El procedimiento sigue el orden pantallas de las que depende el usuario, desarrollo nuevo conforme de serie y extensión a través de los controles compartidos. Combine FastPass y Live Inspect de Accessibility Insights con comprobaciones prácticas en Narrator/NVDA, e intégrenlos en el flujo de desarrollo como lista de verificación de las pantallas nuevas.

Como primer paso, recomendamos elegir una de sus pantallas principales, ejecutar FastPass de Accessibility Insights for Windows y después recorrer el trabajo solo con la tecla Tab. En 30 minutos verá, de forma sorprendentemente concreta, dónde está su aplicación ahora.

Artículos relacionados

• Pruebas de UI automatizadas para aplicaciones de escritorio de Windows ── el funcionamiento de UI Automation y pruebas resistentes a roturas con FlaUI
• Diseño de UX para apps de Windows: prioridades según el entorno de uso
• Compatibilidad de WinForms con pantallas de alto DPI ── Por qué se ve borroso o se rompe el diseño en monitores 4K, y cómo abordarlo de forma realista
• Compatibilidad de WPF con alto DPI ── causas y soluciones del desenfoque pese a que «debería ser resistente al DPI»
• Por qué KomuraSoft crea sitios web con el sistema de diseño de la Agencia Digital de Japón — El bajo coste y la calidad pueden coexistir
• Fuentes japonesas y las trampas de los caracteres — JIS2004, selectores de variantes de ideogramas y caracteres externos en aplicaciones empresariales

Ámbitos de consultoría relacionados

KomuraSoft LLC se ocupa de las correcciones de accesibilidad de aplicaciones empresariales WinForms/WPF (soporte de lectores de pantalla, manejo por teclado, soporte de temas de contraste), de la implementación de AutomationPeer para controles compartidos y del diagnóstico del estado actual y la priorización con Accessibility Insights. Está bien empezar en la etapa de «queremos comprobar si un empleado puede usar nuestra aplicación con un lector de pantalla».

• Desarrollo de aplicaciones para Windows
• Consultoría técnica y revisión del diseño
• Contacto

Referencias

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 una aplicación empresarial es una obligación legal?

La reforma de 2021 de la Ley de Eliminación de la Discriminación por Discapacidad entró en vigor el 1 de abril de 2024, y también las empresas están ahora obligadas a prestar ajustes razonables a las personas con discapacidad. El ajuste razonable consiste en eliminar una barrera individual, dentro de un margen que no sea una carga excesiva, cuando una persona con discapacidad lo solicita; adaptar de antemano una aplicación para que sea más fácil de usar se sitúa como un deber de esfuerzo llamado mejora del entorno. El ámbito laboral, como la relación entre un empleado y la empresa, corresponde a la Ley de Promoción del Empleo de Personas con Discapacidad y no a la ley antidiscriminación, y la reforma vigente desde abril de 2016 obliga allí a los empleadores a prestar ajustes razonables. Es decir, la situación en la que un empleado no puede usar una aplicación empresarial lleva tiempo en el territorio de la obligación. Qué atender y hasta dónde depende de cada caso, así que conviene confirmar las fuentes primarias del Gabinete y del Ministerio de Salud, Trabajo y Bienestar, y decidirlo mediante el diálogo con la persona interesada.

¿Cómo lee un lector de pantalla una aplicación de escritorio de Windows?

Lectores de pantalla como Narrator y NVDA leen la interfaz de una 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 (propósito) y ControlType (tipo), además de patrones de control como Invoke (pulsar) y Value (valor). El lector de pantalla anuncia esta información como «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, de modo que el trabajo principal del desarrollador es no dejar Name vacío, hacer la interfaz operable con el teclado e implementar la información en los controles personalizados.

En una aplicación WinForms ya existente, ¿por dónde conviene empezar?

El camino más corto es ejecutar FastPass de Accessibility Insights for Windows sobre la pantalla objetivo y listar los controles con Name vacío y los problemas de orden de tabulación. Empiece las correcciones por asignar AccessibleName a los botones que solo tienen icono, asociar un Label colocándolo inmediatamente antes del campo de entrada en el orden de tabulación, y ordenar TabIndex para que coincida con el orden visual. Después inicie Narrator o NVDA, recorra una operación real del negocio sin mirar la pantalla y compruebe dónde se atasca. No hace falta corregir todas las pantallas a la vez; es realista empezar por las pantallas que alguien usa de verdad y tratar las pantallas nuevas como conformes de serie con una lista de verificación.

¿Qué hay que hacer para el alto contraste (temas de contraste)?

La regla básica es respetar los colores del sistema en lugar de codificar colores de forma fija. En WinForms, deje ForeColor/BackColor en sus valores predeterminados o use SystemColors, detecte el estado con SystemInformation.HighContrast y siga un cambio mediante el evento UserPreferenceChanged. En WPF y WinUI también, la interfaz sigue un cambio de tema de forma automática mientras referencie los recursos de la familia SystemColors. Al mismo tiempo, deje de transmitir información solo con el color, por ejemplo mostrar un error únicamente en rojo, y añada un icono o un texto. Incluso en el tema normal, tomar como guía el criterio de WCAG de una relación de contraste de texto de al menos 4,5:1 hace la interfaz más legible en un taller mal iluminado y para usuarios de más edad.

¿El trabajo de accesibilidad también ayuda a las pruebas automatizadas de UI?

Sí. Las herramientas de pruebas automatizadas de UI como FlaUI se basan en el mismo UI Automation que usan 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 un AutomationId diseñado para las pruebas estabiliza la identificación de los elementos. A la inversa, una interfaz dibujada a medida que no aparece en el árbol de UIA es invisible tanto para los lectores de pantalla como para las pruebas. La accesibilidad y las pruebas automatizadas son inversiones en la misma base, de modo que poner en marcha una también reduce el coste 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.