La accesibilidad (A11y) a menudo se considera “es bueno tenerla”. No lo es.

Riesgo legal: La ADA (Ley de Estadounidenses con Discapacidades) se aplica a los sitios web. Las demandas han aumentado un 300%.
Tamaño del mercado: el 15% del mundo tiene una discapacidad. Se trata de un segmento de clientes enorme.
SEO: A11y y SEO se superponen en un 90%. El HTML semántico gana en ambos. Si bloqueas a un usuario ciego, bloqueas GoogleBot.

Por qué Maison Code habla de esto

En Maison Code Paris, actuamos como la conciencia arquitectónica de nuestros clientes. A menudo heredamos stacks “modernos” construidos sin una comprensión fundamental de la escala.

Discutimos este tema porque representa un punto de inflexión crítico en la madurez de la ingeniería. Implementarlo correctamente diferencia un MVP frágil de una plataforma resistente de nivel empresarial.

No lo hacemos sólo por los juicios. Lo hacemos porque la “libra púrpura” (poder adquisitivo de los hogares con discapacidad) vale 274 mil millones de dólares sólo en el Reino Unido. Lo hacemos porque existen los “efectos de corte de bordillo”. (Se hicieron cortes en las aceras para sillas de ruedas, pero ayudan a los cochecitos y las maletas). Los subtítulos se hicieron para personas sordas, pero ayudan a las personas que ven videos en el Metro. A11y mejora la experiencia para todos.

1. HTML semántico: la base

Deja de usar <div> para todo.

Botón: <botón>, no <div onClick>.
Encabezado: <h1>, no <div class="text-3xl">.
Navegación: <nav>, no <div>. Los lectores de pantalla dependen de estas etiquetas para navegar. Si utiliza un botón div, un usuario ciego no podrá acceder a él con la tecla Tabulador. No pueden hacer clic en él. Es un muro.

2. El estilo “Anillo de enfoque”

Los diseñadores odian el contorno azul: “esquema: ninguno”. NUNCA elimine el contorno a menos que lo reemplace. Los usuarios de teclado (con problemas motores) confían en el anillo de enfoque para saber dónde se encuentran. Utilice :focus-visible para mostrarlo solo a los usuarios del teclado, no a los usuarios del mouse.

/* Buena experiencia de usuario */
botón: foco {
  esquema: ninguno; /* Ocultar valor predeterminado */
}

botón:enfoque-visible {
  contorno: 2px solid var(--color-electric);
  desplazamiento de contorno: 2px;
}

3. Etiquetas ARIA (cerrando la brecha)

Cuando las señales visuales fallan, utilice ARIA. Ejemplo: un icono “X” para cerrar un modal. Visualmente: es obvio. Audiblemente: Se lee “Imagen”. Solución: <button aria-label="Cerrar Modal">X</button>. Regla: Utilice HTML nativo primero. Utilice ARIA sólo cuando HTML no sea suficiente. No use role="button" en un div si puede usar un <button>.

4. Contraste de color (el fracaso número uno)

El texto gris sobre un fondo gris ligeramente más claro parece “moderno”. Es ilegible para usuarios con baja visión (y para personas que miran su teléfono al sol). Necesita una relación de contraste de 4,5:1 para el cuerpo del texto. Utilice la “Descripción general de CSS” de Chrome DevTools para comprobar todos los colores. Además, admita Modo oscuro correctamente. El modo de alto contraste es fundamental para las personas mayores.

5. Pruebas automatizadas (The Pipeline)

Integramos Axe-core en el proceso de desarrollo. Un humano no puede captarlo todo.

Linting: eslint-plugin-jsx-a11y detecta <img> que faltan etiquetas alt.
Tiempo de ejecución: @axe-core/react registra errores en la consola durante el desarrollo.
CI/CD: Pa11y se ejecuta en proceso. Si la accesibilidad cae por debajo del 90%, la compilación falla.

# Ejecutando Pa11y en CLI
npx pa11y https://maisoncode.paris

6. El enlace “Saltar al contenido”

Un usuario ciego no quiere escuchar su Mega Menú (50 enlaces) en cada carga de página. Agregue un enlace oculto en la parte superior: “Saltar al contenido principal”. Se vuelve visible en Focus. <a href="#main" class="sr-only focus:not-sr-only">Saltar al contenido</a> Este es el sello distintivo de un sitio profesional.

7. Sensibilidad al movimiento (trastornos vestibulares)

Algunas animaciones provocan náuseas. Respete la configuración del sistema operativo del usuario: “prefiere movimiento reducido”.

@media (prefiere-movimiento-reducido: reducir) {
  * {
    duración de la animación: 0,01 ms! Importante;
    duración de la transición: 0,01 ms! Importante;
  }
}

Si te piden quietud, dales quietud.

8. Prueba del lector de pantalla (manual)

La automatización detecta el 30% de los errores. Debes probar manualmente. Activa VoiceOver (Mac) o NVDA (Windows). Cierra los ojos. Intente comprar un producto en su sitio. Si no puedes… estás roto. Este ejercicio de empatía cambia la forma de codificar.

10. La Carga Cognitiva (Neurodiversidad)

La accesibilidad no es sólo física. Es mental. Para los usuarios con TDAH o autismo, una interfaz caótica resulta abrumadora. Pautas:

Consistencia: la navegación debe realizarse en el mismo lugar en todas las páginas.
Claridad: Sin jerga. Utilice un lenguaje sencillo.
Calma: evita la reproducción automática de vídeos. Evite las luces intermitentes (riesgo de epilepsia). Una interfaz tranquila es una interfaz de alta conversión.

11. La revolución del control por voz (Siri / Dragon)

Los usuarios con discapacidades motoras utilizan el control por voz. “Haga clic en Agregar al carrito”. Si su botón está codificado como <div onClick=...>, el software de voz no puede verlo. Busca “Botones”. Si utiliza HTML semántico, el control por voz funciona de inmediato. “Desplácese hacia abajo. Haga clic en Pagar”. Este es el futuro del comercio “Manos libres” (Conducir, Cocinar). A11y habilita el comercio por voz.

12. La prueba de zoom (baja visión)

Los usuarios con baja visión hacen zoom al 200% o 400%. ¿Se rompe tu diseño? ¿Se superponen las letras? Tipografía fluida: utilice unidades rem, no px. font-size: 1rem respeta la configuración del navegador del usuario. font-size: 16px fuerza su configuración. Pruebe su sitio con un zoom del 200%. Si el menú desaparece, has fallado.

13. El estudio de caso legal (Domino’s)

En Robles v. Domino’s Pizza, la Corte Suprema denegó la petición de Domino. El fallo se mantiene: la ADA se aplica al mundo digital. Domino’s argumentó: “La ley se redactó en 1990, antes que la web”. El Tribunal dijo: “La intención es la igualdad de acceso. El medio no importa”. La lección: Esperar una “Ley Web” específica es una estrategia perdedora. El riesgo es retroactivo. Lo pueden demandar hoy por un sitio que construyó hace 3 años. La remediación es 10 veces más costosa que construirla bien la primera vez.

14. La Lista de Verificación de Auditoría (WCAG 2.1 AA)

No adivines. Sigue la lista.

Perceptible: texto alternativo, subtítulos, contraste.
Operable: Navegación por teclado, Sin parpadeo, Límites de tiempo ajustables.
Comprensible: navegación consistente, identificación de errores, predecible.
Robusto: Compatible con tecnología de asistencia (ARIA). Imprime esta lista. Pégalo a tu monitor. Cada RP debe pasar esta lista de verificación.

La IA revolucionará la accesibilidad. Texto alternativo generativo: modelos como GPT-4 Vision pueden subtitular automáticamente 10 000 imágenes en 1 hora. Simplificación en tiempo real: la IA puede reescribir textos legales complejos en “inglés sencillo” para usuarios con discapacidades cognitivas. Navegación por voz: “Agente, cómpreme los zapatos rojos”. Estamos construyendo estas características hoy. La accesibilidad está pasando del “Cumplimiento” a la “Asistencia”.

16. La experiencia del desarrollador (DX)

Escribir código accesible es un código más limpio. El HTML semántico es más fácil de leer que la sopa “div”. El botón es más claro que div class="btn". Hacer cumplir A11y mejora el estado del código base. Reduce la deuda técnica. Hace que la incorporación de nuevos desarrolladores sea más rápida. Buen DX = Buena UX.

17. La trampa del índice de pestañas (no utilice números enteros positivos)

Un error común es tabindex="1". Esto obliga al orden. Si reorganiza el DOM, el orden de tabulación se rompe. Regla:

tabindex="0": Hacer que un div sea enfocable (en orden natural).
tabindex="-1": hazlo enfocable mediante programación (JS), pero salta a través de Tab.
tabindex="1": NUNCA USE ESTO. Lucha contra el navegador. Deje que el DOM dicte el orden.

18. El requisito de HTML válido (análisis)

Los lectores de pantalla son navegadores. Analizan tu HTML. Si tiene etiquetas abiertas o ID duplicadas, el analizador adivina. A veces adivina mal. Regla: Tu HTML debe validarse. Utilice el validador W3C. HTML roto = accesibilidad rota. Es el error inesperado el que acaba con la experiencia. Escribe un código válido.

19. El Costo de Mantenimiento (Código Limpio)

El código accesible es más barato de mantener. ¿Por qué? Porque fuerza la estructura. Si usa <div> en todas partes, su CSS se convierte en una pesadilla de selectores anidados .card div div span. Si usa <artículo> <h1> <p>, su CSS es simple. Desacopla el estilo de la estructura. Esto hace que la refactorización sea más segura. A11y es técnicamente una métrica de calidad del código. Invierta en ello.

20. Conclusión

La accesibilidad está codificada con empatía. Significa que te preocupas por todos los usuarios, no sólo por aquellos con una visión perfecta y un control motor fino. Le protege de demandas. Mejora tu SEO. Abre tu mercado. No hay ningún inconveniente.

¿Te demandaron recientemente?

Auditamos y solucionamos las infracciones de accesibilidad.

Auditar mi A11y. Contrate a nuestros arquitectos.