Tema: accessibility
-
Señales de juego accesibles en color: comunicar el estado con algo más que el tono
Combina el color con símbolos estables, patrones y etiquetas, y prueba la señal completa a la escala real del juego en lugar de confiar solo en una paleta predefinida.
-
Interfaces sensibles al locale: reglas de plural de Intl, fechas y disposición de derecha a izquierda
Formatear números, fechas y tiempos relativos con los objetos Intl del navegador en lugar de aritmética de cadenas, elegir las formas de plural mediante las categorías de Intl.PluralRules en vez de n == 1, maquetar con propiedades lógicas de CSS para que un documento con dir=rtl se refleje a sí mismo, y dejar espacio para el texto que se expande al traducirse.
-
Texto de cuerpo legible: longitud de línea, interlineado y contraste
Tres propiedades deciden si un texto largo se lee cómodamente: la longitud de línea (el criterio AAA de las WCAG la limita a 80 caracteres), el interlineado (debe ser posible al menos 1,5 veces el tamaño de la fuente sin que el diseño se rompa) y el contraste (4,5:1 para texto normal, 3:1 para texto grande). Fijarlos en unidades relativas para que las personas usuarias puedan ampliar el texto y reespaciarlo.
-
Iconos SVG: marcado en línea, un sprite con use, o un elemento img
El SVG en línea puede estilizarse con currentColor y CSS, pero repite bytes en cada aparición; un sprite del mismo origen referenciado con use se almacena en caché una sola vez y sigue respetando el color del texto; un img es cacheable pero opaco para CSS. Elegir según el papel de cada icono, mantener los iconos decorativos ocultos para la tecnología de asistencia, y dimensionar cada icono para que nada se desplace mientras se carga el sprite.
-
Texto de cuerpo legible: medida, interlineado y contraste
Tres propiedades determinan si un texto largo se puede leer cómodamente: la longitud de línea (el criterio AAA de WCAG la limita a 80 caracteres), el interlineado (debe ser posible al menos 1,5 veces el tamaño de fuente sin romper el diseño) y el contraste (4,5:1 para texto normal, 3:1 para texto grande). Establecerlos en unidades relativas para que los usuarios puedan cambiar el tamaño y el espaciado del texto.
-
Modo oscuro con prefers-color-scheme, color-scheme y light-dark()
El modo oscuro consta de tres partes: la media query prefers-color-scheme para detectar la elección del usuario, la propiedad color-scheme (y la etiqueta meta) para indicar al navegador qué esquemas admite la página de modo que los controles de formulario, las barras de desplazamiento y el lienzo la sigan, y light-dark() o propiedades personalizadas para intercambiar los valores de la paleta sin duplicar reglas.
-
Selectores estables y espera automática en pruebas de extremo a extremo de navegador
Dos causas dominan las pruebas de navegador inestables (flaky): selectores que se rompen o coinciden con el elemento equivocado, y esperas fijas (sleeps) que dan por supuesto el tiempo. Localizar los elementos por rol, etiqueta o id de prueba, hacer que cada localizador coincida exactamente con un elemento, y sincronizar mediante aserciones con reintento y comprobaciones de accionabilidad en lugar de tiempo.
-
Formularios accesibles: etiquetas, mensajes de error y autocompletado
Asociar cada control con una etiqueta mediante for e id, marcar los campos obligatorios en el texto y con el atributo, usar tokens de autocompletado para que los navegadores y la tecnología de asistencia conozcan el propósito de un campo, e informar los errores en un resumen más mensajes por campo enlazados con aria-describedby.
-
dialog frente a popover: comportamiento modal, la capa superior y el descarte ligero
dialog con showModal() es modal: capa superior, página inerte, ::backdrop, Escape, closedby y form method=dialog; el atributo popover convierte cualquier elemento en una superposición de capa superior no modal que un botón alterna sin script, y que se descarta ligeramente en el estado auto. Usar dialog para prompts bloqueantes y formularios, popover para menús, tooltips y toasts.
-
Subtítulos y cues de subtítulos descriptivos en videojuegos: conservar el significado, la sincronización y la legibilidad
Representa los diálogos y los eventos sonoros relevantes con cues sincronizados, gestiona los solapamientos de forma deliberada y ofrece una presentación legible antes de la primera escena con voz.
-
¿Qué esperan las personas que activan la reducción de movimiento que se elimine: toda animación, el movimiento amplio o solo la reproducción automática?
Pregunta abierta: el ajuste de reducción de movimiento dice «reduce», no «none», y las guías sugieren conservar transiciones pequeñas con significado mientras se elimina el parallax, los zooms y la reproducción automática; ¿existe evidencia sobre lo que realmente quieren los usuarios que activan el ajuste, y sobre si sus expectativas difieren según el motivo (trastorno vestibular, distracción, batería, preferencia)?
-
Roles ARIA: por qué un elemento HTML nativo supera a un div con un rol
La primera regla del W3C sobre el uso de ARIA es preferir un elemento o atributo HTML nativo que ya tenga la semántica y el comportamiento requeridos; ARIA solo cambia lo que se comunica a la tecnología de asistencia, nunca lo que hace el elemento. Un div con role=button sigue necesitando que se le añadan a mano la capacidad de recibir foco, el manejo de teclas y los estados, y cada error de este tipo resulta invisible en las pruebas visuales.
-
Navegación por teclado en widgets compuestos: tabindex itinerante, teclas de flecha y Escape
Tab y Shift+Tab se mueven entre componentes; las teclas de flecha se mueven dentro de un componente como una lista de pestañas, una barra de herramientas, un menú o un grupo de radio. Implementarlo con un tabindex itinerante (un elemento en tabindex=0, el resto en -1) o aria-activedescendant, cerrar las superficies transitorias con Escape, y nunca atrapar el foco sin una salida anunciada.
-
Gestión del foco en interacciones de página única: diálogos, cambios de ruta y elementos eliminados
Cuando una página cambia sin una carga completa, el foco del teclado debe moverse de manera deliberada: hacia un diálogo cuando se abre y de vuelta a su disparador cuando se cierra, hacia el encabezado de la nueva vista después de un cambio de ruta del lado del cliente, y hacia un vecino razonable cuando se elimina el elemento enfocado. De lo contrario, el foco recae en el body del documento y las personas que usan lector de pantalla vuelven al principio.
-
prefers-reduced-motion: qué animaciones reducir y cómo hacerlo
La característica de medios prefers-reduced-motion indica si el usuario ha pedido al sistema operativo menos movimiento; sus valores son no-preference y reduce. Respétala sustituyendo el movimiento amplio (parallax, zooms, desplazamientos, movimiento con reproducción automática) por fundidos o cambios instantáneos, conservando las transiciones de estado pequeñas que aportan significado, y aplica la misma regla a las animaciones controladas por script.
-
Action maps de Unity: contextos, control schemes y rebinding persistente
Organiza las acciones semánticas por contexto de juego, distingue los esquemas de dispositivo de la activación de mapas y define un ciclo de vida completo para la reasignación de controles.
-
Accesibilidad: los cuatro principios de las WCAG aplicados en la práctica
Las WCAG 2.2 agrupan todos los criterios de conformidad en cuatro principios: perceptible, operable, comprensible y robusto. Conocer los fallos más habituales de cada uno (falta de alternativas textuales, trampas de teclado, contraste insuficiente, campos sin etiqueta, objetivos demasiado pequeños) permite detectar muchas barreras sin herramientas especiales; el nivel AA es el objetivo habitual.
-
¿Qué proporción de los defectos de accesibilidad hallados en auditorías manuales o por usuarios había superado las comprobaciones automáticas en CI y de qué tipo eran los que escaparon?
Pregunta abierta: la guía del W3C WAI sobre herramientas de evaluación indica que algunas comprobaciones de accesibilidad no se pueden automatizar y requieren intervención manual. En sitios que ejecutan un verificador automático en cada build, ¿qué proporción de los defectos hallados después en una auditoría manual o notificados por usuarios había pasado ese verificador y qué tipos de defecto explican la diferencia?
-
Áreas táctiles y tipos de puntero: dimensionar controles para dedos y ratón
WCAG 2.2 exige que los objetivos del puntero midan al menos 24 por 24 píxeles CSS en el nivel AA, con excepciones por espaciado, enlaces en línea y controles equivalentes, y 44 por 44 en el nivel AAA. Las características de medios pointer y hover indican si la entrada principal es gruesa o precisa y si puede hacer hover, de modo que el diseño pueda ampliar los controles y prescindir de interacciones solo con hover cuando el puntero es un dedo.
-
Fundamentos de accesibilidad: perceptible, operable, comprensible y robusto
WCAG organiza sus requisitos en cuatro principios; los fallos más comunes en sitios de contenido son la falta de alternativas de texto, el uso del color como única señal, las trampas de teclado, el bajo contraste y los controles sin etiqueta.
Legible por máquina: JSON