Disponibilidad de UX e interfaces para todos

1) Por qué es importante

Legal y éticamente: la interfaz no debe excluir a las personas con discapacidad visual, auditiva, motora, cognitiva.
Efecto empresarial: más usuarios, mayor conversión y retención, mejor SEO y calidad de código.
Operativa: la disponibilidad es un proceso, no un «fix aleatorio».

2) Fundamentos y Principios (POUR)

Perceptible: contraste, texto alternativo, subtítulos.
Operable: todo está disponible desde el teclado, enfoque visible, pausa/parada de animaciones.
Understandable: navegación predecible, errores claros, lenguaje simple.
Robust (Fiabilidad): semántica HTML/ARIA correcta, compatible con tecnologías de asistencia.

3) Semántica, titulares y ARIA

Las marcas semánticas anteriores a ARIA son: 'button', 'nat', 'form', 'table', según lo previsto.
Jerarquía de títulos: uno 'h1' por página, seguido de la estructura lógica 'h2' - 'h3'.
Landmarks: 'header', 'main', 'aside', '<football', 'nat' - ayudan a los captores de pantalla.
ARIA sólo si es necesario: 'role', 'aria-label', 'aria-describedby', 'aria-expanded', 'aria-live'.
Estados/errores a través de 'aria-invalid', 'aria-errormessage'.

4) Teclado y control de enfoque

Control completo del teclado: 'Amb/Shift + Nat' - orden, 'Enter/Space' - activar, 'Amb' - salida.
Foco visible siempre; no desactivar outline.
Trampas de enfoque: en los modales - enfoque cíclico, volver el foco a la fuente después del cierre.
Los elementos ocultos no deben caer en el orden ^ ('display: none', 'aria-hidden =' true ').
Enlaces de skip: «Ir al contenido principal» - al principio de la página.

5) Color, contraste y tipografía

Contraste de texto: al menos 4. 5:1 para texto plano y 3:1 para texto grande.
No confíe sólo en el color: duplique con un icono/patrón/firma.
Tamaño de los objetivos de clicking: mínimo 40-48 px, suficientes campos alrededor.
Fuentes: auriculares legibles, interlínea 1. 4–1. 6, longitud de línea 45-90 caracteres.

6) Movimiento, animaciones y brote epileptogénico

Respete el indicador del sistema preferidos-reducidos-motion: agregue animaciones simplificadas/desactive el paralaje.
Evite los parpadeos> 3 veces/sec.
Todos los movimientos automáticos deben tener Pause/Stop/Hide.

7) Formularios, errores y validación

Vincule explícitamente etiquetas y campos: '<label for = «id»>'.
Playsholder no es una marca.
Mensajes de error cerca del campo y en el resumen de errores en la parte superior; enlazar a través de 'aria-describedby'.
Explique el formato de entrada, ejemplo, máscara; especifique las unidades y la moneda.
No restablezca los campos rellenados cuando se produzca un error; mantenga el enfoque en el campo problemático.

html
<label for="email">Эл. почта</label>
<input id="email" name="email" type="email" aria-describedby="email-hint email-err">
<div id="email-hint" class="hint">Мы не рассылаем спам</div>
<div id="email-err" class="error" role="alert">Укажите адрес в формате name@example.com</div>

8) Componentes e interactivos: patrones

Botones vs referencia: acción = '<button>', transición = '<a>'.
Taba/acordeones: flechas de navegación, 'aria-controls',' aria-selected '.
Modales/diálogos: 'role =' dialog '', 'aria-modal =' true '', trampa de enfoque, 'Amb' cierra.
Tooltip/Popover: disponibilidad por teclado, los temporizadores no interfieren con la lectura.
Drag & Drop: alternativas - botones «subir/bajar», flechas de teclado; eventos no sólo con el ratón.

9) Medios de comunicación: vídeo/audio/gráficos

Vídeo: subtítulos, transcripción (transcript), pista alternativa de descripciones de audio (AD).
Audio: descifrado de texto.
Gráficos/gráficos: resumen de texto («lo que es importante»), tabla de datos, firmas descriptivas de ejes.
Áreas vivas: 'aria-live =' polite '/' assertive '- cuidado de no «gritar» con demasiada frecuencia.

10) Tablas y listas

11) i18n, local y RTL

El atributo 'lang' en la raíz html; formatos locales de números/fechas/monedas.
Soporte RTL (árabe/hebreo): espejado de iconos, orden de navegación, cursores.
Evite las palabras cosidas en los iconos (el texto debe ser traducible).
Formulaciones simples, evitar la jerga; glosario de términos.

12) Tiempo, sesiones, capchas y alternativas

Taimauts - con advertencia y posibilidad de prolongar.
CAPTCHA: prefiera alternativas (preguntas, analizadores de bots invisibles, confirmación por correo/teléfono); si se utiliza - una alternativa de texto y no sólo visual.
Autenticación: soporte para gestores de contraseñas, «mostrar contraseña», WebAuthn.

13) Disponibilidad para discapacidades sensoriales y motoras

Los gestos deben tener equivalentes a un clic/teclado.
No requiera retenciones prolongadas/tapas dobles sin alternativa.
«Pointer cancellation»: la acción debe llevarse a cabo por liberación, no por «click» para dar la oportunidad de cancelar.

14) Estados, notificaciones y alertas

Utilice 'role =' status '/' alert 'para mensajes dinámicos.
No solapes el foco con pancartas «pegajosas».
Notificaciones Toast: con pausa cuando se enfoca/hover y se accede desde el teclado.

15) Plan de prueba (manual y auto)

• Pasar todos los scripts clave sólo por el teclado.
• Comprobar la visibilidad del enfoque en cada elemento.
• Ampliar hasta un 200%: la interfaz se mantiene funcional sin el scroll horizontal.
• Activar el modo de sistema «reducción de movimiento»: las animaciones no interfieren.
• Pase el script con el screenrider (NVDA/VoiceOver), asegúrese de que las funciones/etiquetas/orden son correctos.

• Lentes de disponibilidad a nivel de componente.
• Comprobar el contraste, los textos alternativos, el orden de los títulos, la validez de ARIA.
• Snapshots de semántica (role tree) para pantallas críticas.

16) Métricas de calidad de disponibilidad

A11y Coverage: proporción de componentes con hojas de cheques completadas.
Keyboard-only Pass Rate: porcentaje de scripts que pasa el teclado.
Contrast Violations/1k elementos.
SR Flow Time: tiempo para pasar el script con el screenrider.
User-feedback: quejas sobre disponibilidad, tiempo de reacción y correcciones.

17) Lista de verificación del componente

• La semántica/función correcta sin ARIA redundante
• Las etiquetas firmadas, 'aria-' son correctas
• Control completo del teclado, enfoque visible
• Contraste de texto/iconos/límites en la norma
• Los errores y estados son expresados por el screenrider
• Respeto a los preferentes-reducidos-motion
• Tamaño del área de clicability ≥ 40-48 px
• La localización y RTL no rompen el diseño

18) Anti-patrones

«Botones Div» sin rol/teclado.
Ocultar el foco 'outline: none' sin alternativa.
Playsholder en lugar de label.
Errores sólo en color.
Modales sin trampa de enfoque y sin 'Amb'.
Drag-only sin teclado.
Alquiler de coches largos/paralaje sin opción de desactivar.

19) Roles y proceso

A11y-propietario en el comando (Product/Design/Dev).
La definición de DoD incluye la disponibilidad.
Rugido de diseño: comprobar el contraste, el enfoque, las etiquetas.
Código de rugido: semántica/ARIA, prueba con teclado.
Auditorías periódicas y un plan de mejoras.

20) Implementación por iteraciones

• Semántica/encabezados, contraste, enfoque y teclado, formas básicas y errores.

• Modales, tabas/acordeones, tablas/gráficos con resumen de texto, subtítulos de vídeo, animación reducida.

• Autotestas en CI, RTL/i18n, métricas, auditorías periódicas, formación de equipos.

21) Plantillas y pinceladas

html
<div role="dialog" aria-modal="true" aria-labelledby="dlg-title" aria-describedby="dlg-desc">
<h2 id="dlg-title">Подтвердите действие</h2>
<p id="dlg-desc">Эта операция необратима.</p>
<button>Отмена</button>
<button>Подтвердить</button>
</div>

html
<a class="skip-link" href="#main">Перейти к основному содержимому</a>
<main id="main">...</main>

css
@media (prefers-reduced-motion: reduce) {
{ animation-duration: 0.01ms!important; animation-iteration-count: 1!important; transition: none!important; }
}

22) Mini preguntas frecuentes

¿Se necesita una «versión separada para las personas con discapacidad visual»?
No. Una versión adaptable y accesible para todos con configuración.

¿Es suficiente comprobar sólo el contraste?
No. El contraste es sólo una parte. Necesita teclado, enfoque, semántica, errores de forma, medios de comunicación, etc.

¿La ARIA lo decidirá todo?
ARIA no corregirá la semántica incorrecta. Primero las etiquetas correctas, luego los refinamientos ARIA.

Resultado

La accesibilidad es una disciplina de sistema: la semántica → el teclado foco → el contraste/color → las formas/faltas → los medios de comunicación/gráficos → i18n/RTL → el test-plan y las partidas de nacimiento. Haga que la disponibilidad forme parte de la cultura de DoD y del equipo, y su producto será verdaderamente versátil, confiable y cómodo para todos.