¿Qué son las pruebas de accesibilidad? (Ejemplos)

¿Qué son las pruebas de accesibilidad?

Pruebas de accesibilidad es un tipo de prueba de software que se realiza para confirmar que una aplicación es utilizable por personas con discapacidades, incluidos usuarios con deficiencias visuales, auditivas, motoras, cognitivas y relacionadas con la edad. Es un subconjunto de pruebas de usabilidad y verifica que el producto funcione con la tecnología de asistencia que estos usuarios utilizan a diario.

La tecnología de asistencia ayuda a las personas con discapacidad a utilizar un producto de software. Algunos ejemplos comunes son:

• Software de reconocimiento de voz – Convierte las palabras habladas en texto que sirve como entrada para la computadora.
• Software lector de pantalla – Lee en voz alta el texto y los elementos de la interfaz que se muestran en la pantalla.
• Software de ampliación de pantalla – Amplía ciertas partes del monitor para facilitar la lectura a los usuarios con baja visión.
• Teclados especializados – Diseñado para usuarios con dificultades de control motor para facilitar la tarea.ping más fácil.
• Interruptor y ojo-tracdispositivos rey – Permitir a los usuarios con discapacidades motoras graves navegar y seleccionar elementos de la interfaz.

¿Por qué realizar pruebas de accesibilidad?

Razón 1: Atender al mercado de usuarios con discapacidades.

Según la Organización Mundial de la Salud, alrededor de 1.3 millones de personas, es decir, aproximadamente una de cada seis en todo el mundo, viven con una discapacidad significativa.

• Una de cada diez personas tiene una discapacidad grave.
• Una de cada dos personas mayores de 65 años tiene capacidades reducidas.

Las discapacidades incluyen ceguera, sordera, deficiencias motoras, trastornos cognitivos y otros problemas de salud crónicos. Un producto diseñado para ser accesible puede llegar a este amplio mercado, y la mayoría de los defectos de accesibilidad se pueden prevenir cuando las pruebas de accesibilidad se integran en el ciclo de vida normal de las pruebas de software.

Razón 2Cumplir con la legislación de accesibilidad.

Gobiernos de todo el mundo han promulgado leyes que exigen que los productos informáticos sean accesibles para las personas con discapacidad. Algunos ejemplos destacados son:

• Estados Unidos: Ley de Estadounidenses con Discapacidades (ADA, 1990) y Sección 508 de la Ley de Rehabilitación.
• Reino Unido: Ley de Igualdad de 2010 (que sustituyó a la Ley de Discriminación por Discapacidad de 1995).
• Unión Europea: Ley Europea de Accesibilidad, que entró en vigor para muchos productos y servicios en junio de 2025, y la norma EN 301 549.
• Australia: Ley de Discriminación por Discapacidad de 1992.
• Irlanda: Ley de Discapacidad de 2005.
• Canadá: Ley de Accesibilidad de Canadá de 2019.

Las pruebas de accesibilidad son esenciales para garantizar el cumplimiento legal en todos los mercados donde se vende su producto.

Razón 3Evitar posibles demandas.

Grandes empresas han sido demandadas repetidamente porque sus productos digitales no eran accesibles. Algunos casos destacados incluyen:

• Federación Nacional de Ciegos (NFB) contra Target (2006, resuelto en 2008).
• Acuerdo entre NFB y AOL (1999).
• Robles v. Domino's Pizza (2019), donde Estados Unidos SupremEl Tribunal confirmó un fallo que establece que la ADA se aplica a sitios web y aplicaciones móviles.
• Gil v. Winn-Dixie (2017), el primer veredicto judicial en Estados Unidos que obligó a reparar un sitio web inaccesible.

Las demandas por accesibilidad web en Estados Unidos han aumentado cada año, con más de 4,000 casos digitales relacionados con el Título III de la ADA presentados anualmente desde 2022. Desarrollar productos accesibles desde el principio evita estos costos y protege la marca.

¿Qué discapacidades apoyar?

Una solicitud debe brindar apoyo a personas con discapacidades como:

Tipo de discapacidad	Discapacidad Description
Discapacidad visual	Ceguera total, daltonismo o baja visión. Sensibilidad a los efectos estroboscópicos y de destellos visuales.
Discapacidad física	Incapacidad para usar el ratón o el teclado con una sola mano. Escasas habilidades motoras, incluyendo limitación del movimiento de las manos o lentitud muscular.
Discapacidad Cognitiva	Dificultades de aprendizaje, mala memoria o problemas para seguir situaciones complejas.
Discapacidad de alfabetización	Dificultades de lectura como la dislexia.
discapacidad auditiva	Problemas auditivos, incluyendo sordera y discapacidad auditiva. Incapacidad para oír sonidos o para oírlos con claridad.

Normas y pautas de accesibilidad

Los programas de pruebas de accesibilidad se basan en un pequeño conjunto de estándares ampliamente adoptados. Comprender qué estándar se aplica a su mercado es el primer paso antes de elaborar cualquier plan de pruebas.

• WCAG 2.2 – Publicadas por el W3C en octubre de 2023, las Pautas de Accesibilidad para el Contenido Web 2.2 son el referente mundial actual. Definen tres niveles de conformidad: A (básico), AA (el mínimo legal en la mayoría de los países) y AAA (el más alto).
• WCAG 3.0 – Un borrador de trabajo del W3C que introduce un modelo de puntuación basado en resultados. Aún está en desarrollo y no ha reemplazado a las WCAG 2.2.
• Sección 508 – Norma de contratación pública federal de EE. UU. que exige que la tecnología electrónica y de la información adquirida por las agencias federales cumpla con los criterios WCAG 2.0 Nivel AA.
• 301 549 – Norma europea armonizada para la accesibilidad a las TIC, utilizada para demostrar el cumplimiento de la Ley Europea de Accesibilidad.
• Título III de la ADA – La legislación estadounidense sobre derechos civiles se aplica a los sitios web y aplicaciones móviles de establecimientos públicos; los tribunales suelen utilizar las directrices WCAG 2.1 o 2.2 AA como referencia.

La mayoría de los equipos tratan WCAG 2.2 Nivel AA como su objetivo de trabajo porque es a la vez la base legal común y un objetivo práctico de ingeniería.

¿Cómo hacer pruebas de accesibilidad?

Las pruebas de accesibilidad se pueden realizar de dos maneras:

1. Manual
2. Automático

Las pruebas de accesibilidad pueden resultar difíciles para quienes no están familiarizados con las discapacidades. Lo ideal es contar con la participación de usuarios con discapacidad o especialistas en accesibilidad que puedan describir las dificultades del mundo real. Las técnicas que se describen a continuación abarcan las principales categorías de discapacidad.

1) Discapacidad de visión

Imagina que no puedes ver nada y necesitas usar el sitio web XYZ. Tu única opción práctica es un lector de pantalla. Un lector de pantalla es un software que narra el contenido de una página web, incluyendo texto, enlaces, botones de opción, imágenes y videos, para que un usuario ciego pueda percibir la interfaz. Algunos lectores de pantalla populares son: MANDÍBULAS, NVDA, Apple VoiceOver y Android Replicar.

Cuando inicias JAWS y luego abres un navegador, JAWS anuncia el título de la página. Si mueves el foco a la barra de direcciones, JAWS dice "Barra de direcciones" y luego lee cada carácter que escribes. Por ejemplo, typing google.com genera un anuncio como el siguiente:

Address Bar, w, w, w, period, g, o, o, g, l, e, period, c, o, m.
When the page finishes loading, JAWS announces "Google.com home page".
When focus reaches the search field, JAWS announces "Google search, edit".

Un lector de pantalla narra palabra por palabra dentro de los campos de texto, anuncia los enlaces como «enlace» y los botones como «botón», de modo que un usuario ciego pueda identificar cada control. Si un sitio web está mal diseñado, el lector de pantalla puede identificar erróneamente algunos elementos; por ejemplo, un enlace con formato de texto plano puede interpretarse como contenido, ocultando una acción crucial al usuario. El coste para la empresa se traduce en una pérdida real de ingresos.

2) Daltonismo

El daltonismo significa que una persona no puede percibir ciertos colores correctamente. El daltonismo rojo-verde es la forma más común. Si un sitio web depende en gran medida del color rojo para transmitir información, un usuario con daltonismo rojo-verde podría no comprender el mensaje.

Los equipos de diseño nunca deberían usar solo el color para comunicar información. Un botón de error rojo es más accesible si además está resaltado, etiquetado con un icono y acompañado de texto descriptivo. El blanco y el negro siguen siendo la paleta universal más segura, y herramientas como el complemento Stark o los simuladores de daltonismo del navegador ayudan a detectar problemas a tiempo.

3) Baja visión

Los usuarios con baja visión u otras afecciones de la retina necesitan apoyo adicional para utilizar el sitio:

1. Evite usar texto muy pequeño. Las WCAG recomiendan un tamaño de fuente predeterminado que se ajuste cómodamente sin necesidad de zoom.
2. Asegúrese de que el diseño se ajuste correctamente al texto cuando se amplía hasta un 200 % (un criterio de éxito de WCAG 2.2). Las líneas no deben cortarse y el contenido no debe superponerse.
3. Mantenga una relación de contraste mínima de 4.5:1 para texto normal y de 3:1 para texto grande.

4) Discapacidades motoras y otras discapacidades

Un requisito fundamental de accesibilidad es que todo el sitio web debe poder utilizarse sin ratón. Todos los enlaces, botones, botones de opción, casillas de verificación, ventanas emergentes, menús desplegables y controles deben ser accesibles y manejables únicamente con el teclado.

Por ejemplo, Un usuario con movilidad reducida en las manos podría no poder usar el ratón. Si no se puede acceder a las casillas de verificación o a los enlaces con la tecla Tab, el usuario no podrá usar esas funciones.

Alternative text should be provided for every image, audio file, and video so that screen readers can convey their meaning. Keyboard shortcuts should be available for important actions, and skip-to-content links should let keyboard users bypass repeated navigation.

El foco debe ser siempre visible. Al pulsar la tecla Tab, el control resaltado debe destacar claramente. Un foco visible ayuda a los usuarios con baja visión o daltonismo a seguir el flujo de la página y facilita una navegación predecible para todos.

Usuarios con discapacidades auditivas Por lo general, se puede ver el contenido visual de un sitio web, pero el audio y el video presentan problemas. Todos los videos deben incluir subtítulos, y todos los archivos de audio deben incluir una transcripción o texto descriptivo. Por ejemplo, un video tutorial sobre cómo reservar un boleto de avión debe incluir subtítulos precisos para que un usuario sordo pueda seguirlo.

Ejemplos de casos de prueba para pruebas de accesibilidad

La siguiente lista de verificación se utiliza para certificar las pruebas de accesibilidad de una aplicación web típica. Úsela como punto de partida y amplíela con los criterios de éxito de WCAG 2.2 relevantes para su producto.

1. ¿Se proporcionan atajos de teclado para cada operación y cuadro de diálogo del ratón?
2. ¿La documentación para el usuario explica cómo utilizar la aplicación con tecnologías de asistencia?
3. ¿El orden de tabulación es lógico para que la navegación fluya de forma natural?
4. ¿Se proporcionan teclas de acceso directo para los menús principales?
5. ¿La aplicación es compatible con todos los sistemas operativos y lectores de pantalla a los que está dirigida?
6. ¿Se comunica claramente el tiempo de respuesta de cada pantalla o página para que los usuarios sepan cuánto tiempo deben esperar?
7. ¿Todas las etiquetas están escritas correctamente y vinculadas mediante programación a sus controles?
8. ¿La elección de colores es flexible y se ha probado con simuladores de daltonismo?
9. ¿Se utilizan las imágenes, los iconos y los emojis de forma que los usuarios finales puedan comprenderlos?
10. ¿La aplicación proporciona alertas de audio cuando resultan útiles?
11. ¿Puede el usuario ajustar o silenciar los controles de audio y vídeo?
12. ¿Puede el usuario modificar las fuentes predeterminadas para la impresión y el texto en pantalla?
13. ¿Puede el usuario ajustar o desactivar las pantallas que parpadean, giran o se mueven?
14. Confirme que el color nunca se utiliza como único medio para transmitir información.
15. ¿Sigue siendo visible el resaltado cuando se invierten los colores del sistema? Compruébelo cambiando las relaciones de contraste.
16. ¿Existen transcripciones o subtítulos de audio y vídeo disponibles para los usuarios con discapacidad auditiva?
17. ¿Se ofrece formación a los usuarios con discapacidad para ayudarles a familiarizarse con la aplicación?
18. ¿Se puede acceder a todos los controles interactivos, operarlos y descartarlos utilizando únicamente el teclado?

Cómo la IA está cambiando las pruebas de accesibilidad

La IA es reshaping Las pruebas de accesibilidad se realizan de tres maneras prácticas. Primero, los escáneres de aprendizaje automático ahora leen el DOM renderizado junto con modelos de visión artificial para detectar problemas que las herramientas basadas en reglas pasan por alto, como texto alternativo inapropiado o combinaciones de colores que fallan en diseños reales. Segundo, la IA generativa sugiere soluciones legibles para humanos, incluyendo mejor texto alternativo, mensajes de error más claros y atributos ARIA para componentes personalizados. Tercero, la IA prioriza los hallazgos según su impacto en el usuario, de modo que los equipos pueden invertir su presupuesto en los problemas más importantes. Herramientas como Deque axe AI, Evinced, UserWay y Siteimprove ahora incluyen funciones de IA. La IA no reemplaza las pruebas manuales con lectores de pantalla ni la investigación de usuarios con personas con discapacidad, pero reduce considerablemente la carga de trabajo de la clasificación manual y ayuda a que la accesibilidad se integre desde las primeras etapas del ciclo de desarrollo.

Mitos de las pruebas de accesibilidad

A continuación, se presentan algunos mitos comunes sobre las pruebas de accesibilidad, junto con los datos reales:

Mito: Crear un sitio web accesible es costoso.

Hecho: No lo es. Considerar la accesibilidad durante el diseño, junto con las pruebas básicas, ahorra dinero en comparación con las adaptaciones posteriores y reduce los costosos retrabajos.

Mito: Convertir un sitio web inaccesible en uno accesible requiere demasiado tiempo y es costoso.

Hecho: No es necesario aplicar todas las correcciones a la vez. Empiece por los cambios que tengan mayor impacto en los usuarios con discapacidades y vaya implementando el resto en versiones posteriores.

Mito: La accesibilidad es simple y aburrida.

Hecho: Las páginas aún pueden ser visualmente ricas y entractivo al tiempo que cumple con las directrices WCAG 2.2. El W3C desaconseja explícitamente las versiones solo de texto a favor de una experiencia única y accesible para todos.

Mito: La accesibilidad está reservada únicamente a usuarios ciegos y discapacitados.

Hecho: Seguir las pautas de accesibilidad mejora la usabilidad general y beneficia a todos los usuarios, incluidos aquellos que utilizan dispositivos móviles, bajo la luz del sol intensa o en entornos ruidosos.

Preguntas Frecuentes