Accesibilidad web básica para tu app: por dónde empezar

Una app web accesible es una que se puede usar solo con teclado, con un lector de pantalla, con el texto ampliado y sin depender del color. En la práctica eso significa botones y enlaces de verdad, campos de formulario con etiqueta, un foco visible, contraste suficiente y ventanas de diálogo que manejan bien el foco. La referencia habitual es WCAG 2.2 en nivel AA. En una app hecha con IA puedes encontrar la mayoría de los problemas en una media hora de pruebas, y los arreglos suelen ser cambios pequeños en componentes que se repiten en todas partes: arreglas uno y se arreglan muchas pantallas.

En esta guía verás a quién afecta y por qué importa, los problemas que más aparecen en apps hechas con Lovable, Bolt, v0 o Cursor, una prueba rápida que puedes hacer tú, los arreglos y cómo evitar que vuelvan.

¿Por qué importa la accesibilidad en una app pequeña?

Parte de tus usuarios navega con teclado por una discapacidad motriz o por gusto, usa lector de pantalla porque es ciega o tiene baja visión, amplía la página al 200% o no distingue ciertos colores. Muchos más están en una situación parecida de forma temporal: un brazo enyesado, el sol de frente en la pantalla del teléfono, un lugar ruidoso. Una app que no pueden usar es una app que abandonan.

También hay un lado legal. Esto es un resumen en lenguaje sencillo, no asesoría legal; consulta con un abogado para tu caso:

• En la Unión Europea, la Ley Europea de Accesibilidad (European Accessibility Act) se aplica desde el 28 de junio de 2025 a una serie de productos y servicios para consumidores, entre ellos el comercio electrónico y algunos servicios bancarios y de transporte. Las microempresas que prestan servicios (menos de 10 personas y facturación anual o balance de no más de 2 millones de euros) quedan exentas de los requisitos de servicios, pero las excepciones se interpretan de forma estricta.
• En Estados Unidos, sitios y apps han sido objeto de muchas demandas bajo la Ley de Estadounidenses con Discapacidades (ADA), y los organismos públicos tienen reglas propias de accesibilidad web.
• Varios países de América Latina tienen normas de accesibilidad web, sobre todo para el sector público; revisa las del país donde operas.
• Los clientes públicos y las empresas grandes suelen pedir información de accesibilidad en sus procesos de compra.

WCAG 2.2 se publicó como recomendación del W3C en octubre de 2023 y es la versión a la que apuntan la mayoría de los requisitos nuevos.

¿Qué problemas de accesibilidad suelen tener las apps hechas con IA?

Las herramientas de IA muchas veces parten de librerías de componentes construidas sobre piezas accesibles, y eso ayuda. Los problemas aparecen en las partes hechas a medida y en los detalles:

1. div con clic. Una tarjeta o una fila con onClick pero sin rol de botón o enlace no se alcanza con Tab ni se activa con Enter.
2. Botones de solo icono sin nombre. Un icono de papelera se anuncia como "botón" en el lector de pantalla, sin pista de lo que hace.
3. Campos con el placeholder como única etiqueta, que desaparece apenas escribes y suele ser demasiado tenue para leerse.
4. Texto gris clarito sobre blanco para la información secundaria, por debajo del contraste exigido.
5. El contorno de foco eliminado con outline: none porque "se veía feo", y el usuario de teclado queda perdido.
6. Modales y menús desplegables hechos a mano que no llevan el foco al diálogo, no se cierran con Escape y dejan que Tab se escape detrás.
7. Estados indicados solo con color, como un punto rojo o verde sin texto.
8. Mensajes de error y de éxito que aparecen en pantalla pero el lector nunca anuncia.
9. Campos de contraseña que bloquean pegar, lo que rompe los gestores de contraseñas.

¿Cómo pruebo mi app en 30 minutos?

1. Solo teclado (10 minutos)

Deja el mouse a un lado. Usa Tab y Mayús+Tab para moverte, Enter y Espacio para activar, Escape para cerrar y las flechas dentro de los menús. Recorre el registro, la tarea principal de tu app y la configuración. Anota cada lugar donde no llegas a algo, no ves dónde estás o te quedas atascado.

2. Zoom y contraste (5 minutos)

Amplía el navegador al 200%. El contenido debería reacomodarse sin superponerse ni obligar a desplazarse de lado en páginas normales. Después ejecuta la auditoría de accesibilidad de Lighthouse o la extensión axe DevTools en tus pantallas principales; las dos señalan fallos de contraste, etiquetas faltantes y textos alternativos ausentes.

3. Lector de pantalla (15 minutos)

En Mac, activa VoiceOver con Comando+F5. En Windows, NVDA es gratuito. Intenta completar una tarea con los ojos cerrados o la pantalla atenuada. Escucha qué anuncia cada botón y si se leen los errores.

Las herramientas automáticas encuentran una parte útil de los problemas, pero no todos. Las pruebas con teclado y lector de pantalla atrapan el resto, sobre todo en flujos como el pago o el onboarding.

¿Qué arreglos pesan más?

Usa los elementos correctos. Un enlace que lleva a otra parte es un <a href>; una acción es un <button>. Así obtienes foco, teclado y el anuncio correcto sin hacer nada más.

Ponle nombre a cada botón de icono:

<button type="button" aria-label="Eliminar factura" onClick={onEliminar}>
  <IconoPapelera aria-hidden="true" />
</button>

Etiqueta cada campo con una etiqueta visible conectada a él:

<label htmlFor="correo">Correo del trabajo</label>
<input id="correo" type="email" autoComplete="email" />

Cumple el contraste. WCAG AA pide al menos 4,5:1 para texto normal y 3:1 para texto grande y para elementos importantes de la interfaz, como bordes de campos e indicadores de foco.

Muestra el foco. Si quitas el contorno por defecto, reemplázalo con un estilo claro en :focus-visible.

Haz los objetivos lo bastante grandes. WCAG 2.2 agrega un tamaño mínimo de 24 por 24 píxeles CSS para la mayoría de los controles, o suficiente espacio alrededor de los más chicos.

Anuncia los cambios. Pon los errores junto al campo y conéctalos con aria-describedby; usa una región en vivo educada (aria-live="polite") para avisos y mensajes de estado.

Usa el diálogo de tu librería. Si tu proyecto incluye Radix, shadcn/ui o una librería parecida, usa sus componentes de diálogo, menú y popover en vez de hacerlos a mano; ya manejan el foco y la tecla Escape.

Permite pegar y autocompletar en el login. El criterio de autenticación accesible de WCAG 2.2 busca que no obligues a recordar ni transcribir códigos y contraseñas, y los gestores de contraseñas son la forma habitual de cumplirlo.

¿Cómo evito que los problemas vuelvan?

• Agrega eslint-plugin-jsx-a11y al proyecto, para que los errores comunes aparezcan como advertencias mientras construyes.
• Arregla primero los componentes compartidos (botón, campo, diálogo, tabla) y pídele a tu herramienta de IA que los reutilice en vez de generar otros nuevos.
• Suma una pasada con teclado de los flujos principales a tu lista de publicación.
• Incluye la accesibilidad en las instrucciones a tu herramienta de IA, por ejemplo "todo elemento interactivo debe ser un botón o enlace con nombre accesible". Nuestra guía para revisar código generado por IA explica cómo controlar lo que produce.

Respuestas rápidas

¿Alcanza con un widget de accesibilidad (overlay)? No. Los overlays no corrigen el marcado de fondo, y muchos usuarios de lectores de pantalla cuentan que les estorban. Arregla los componentes.

¿A qué nivel de WCAG debería apuntar? El nivel AA de WCAG 2.2 es el objetivo habitual en apps comerciales y al que se refiere la mayoría de las normas.

¿La accesibilidad ayuda al SEO? De forma indirecta. Los encabezados correctos, los textos de enlace y los textos alternativos ayudan a los buscadores a entender las páginas, y esas mismas costumbres sirven para el SEO de apps React SPA.

¿Cuánto tarda arreglarlo? Depende de cuántos componentes a medida tenga la app. Empezar por los compartidos suele cubrir rápido la mayoría de las pantallas.

¿Quieres una revisión experta?

Si prefieres que alguien pruebe y arregle los flujos principales, nuestros planes de mantenimiento de software incluyen este tipo de trabajo, y el desarrollo de software a medida cubre rehacer componentes como corresponde. La revisión gratuita de tu app es un buen punto de partida, o escríbenos. El W3C resume en inglés lo nuevo de WCAG 2.2.