Cuando un componente de la interfaz de usuario recibe el foco de teclado, el indicador de foco debe cumplir una relación de contraste mínima de 3:1 frente al color adyacente y cubrir al menos el perímetro de un contorno sólido de 2 píxeles CSS alrededor del elemento con foco, o un área de indicador equivalente. El criterio es una de las pocas adiciones de WCAG que especifica una geometría medible en lugar de un comportamiento.

Los anillos de foco predeterminados del navegador que los diseñadores llevan quince años eliminando por razones estéticas no superan esta medición en la mayoría de los sitios en producción auditados. Los estilos de foco personalizados tienden a utilizar contornos de 1 píxel o colores de acento de bajo contraste que parecen correctos en las herramientas de diseño, pero que puntúan por debajo de 3:1 frente al fondo del elemento con foco.

La cifra importa aunque el criterio sea AAA: indica qué ocurriría si un futuro regulador anclara a WCAG 2.2 nivel AAA, o si un contrato de licitación elevara este criterio concreto.

Establezca un contorno de 2 píxeles CSS con un color que puntúe al menos 3:1 frente al fondo del elemento; verifíquelo con un comprobador de contraste y no a ojo. Donde el sistema de diseño anule el foco del navegador, exponga un token de estilo de foco que los diseñadores no puedan bajar accidentalmente por debajo del umbral de contraste.

El objetivo táctil de cada entrada de puntero debe ser de al menos 24 por 24 píxeles CSS, excepto cuando el objetivo está en línea dentro de una oración, cuando el agente de usuario lo dimensiona, cuando hay un objetivo equivalente disponible o cuando la función del objetivo es esencial. El criterio mide el objetivo táctil, no el icono visible.

El criterio detecta un patrón de interfaz de usuario específico: las barras de iconos densas, especialmente en editores, paneles de control y cabeceras de tablas de datos. La mayoría de las bibliotecas de botones de icono tienen por defecto tamaños de icono visibles de 16×16 o 20×20 dentro de un objetivo táctil ligeramente mayor. Cuando el objetivo táctil también está por debajo de 24×24, el criterio falla — y los diseñadores de barras de herramientas reducen habitualmente los espacios para encajar más iconos en un espacio horizontal limitado.

Establezca un token de objetivo táctil mínimo de 24 por 24 píxeles CSS en el sistema de diseño, aplicado mediante relleno en lugar de las dimensiones propias del icono. Donde las barras de herramientas no puedan acomodar el umbral, añada el espaciado adecuado para que los objetivos adyacentes no caigan dentro de la exclusión por solapamiento del criterio. Proporcione un equivalente a nivel de ajustes (un menú más amplio) para las superficies genuinamente reducidas.

El paso de autenticación de un sitio web o aplicación no puede depender de una prueba de función cognitiva — resolver un rompecabezas, transcribir una imagen distorsionada, reconocer objetos en una cuadrícula — salvo que se proporcione un método de autenticación alternativo, se disponga de un mecanismo de asistencia o se aplique una excepción de reconocimiento de objetos. Memorizar una contraseña se considera una prueba de función cognitiva, por eso los gestores de contraseñas están expresamente contemplados.

La mayoría de los CAPTCHA basados en imágenes fallan este criterio directamente. Lo mismo ocurre con los desafíos de «hacer clic en los cuadrados con semáforos», las pruebas de transcripción de texto distorsionado y cualquier flujo que pegue un código de un solo uso en un campo pero deshabilite la interacción de pegado. El patrón se concentra en los flujos de inicio de sesión, restablecimiento de contraseña y creación de cuenta — exactamente los puntos de mayor importancia donde quedar bloqueado tiene el mayor coste.

Los flujos de autenticación son también el área donde el alcance del criterio es más contundente, porque el fallo no degrada la experiencia — la termina.

Reemplace los CAPTCHA de función cognitiva por una alternativa no cognitiva — atestación basada en dispositivo, enlaces mágicos, claves de acceso o puntuación de riesgo invisible. Permita el autocompletado del gestor de contraseñas. Garantice que copiar y pegar funciona en los campos de código de un solo uso. Donde sea imprescindible mantener un CAPTCHA, proporcione una alternativa de audio que no requiera a su vez transcribir habla distorsionada.

Cuando un componente de la interfaz de usuario recibe el foco de teclado, el elemento con foco no debe estar completamente oculto por el contenido creado por el autor. La oclusión parcial está permitida a este nivel (un encabezado fijo que solape la mitad superior de un campo con foco está permitido); la oclusión total no lo está.

La colisión más frecuente es un encabezado fijo — a veces un banner de cookies o un widget de chat flotante — que solapa el campo del formulario con foco cuando un usuario de teclado accede a él mediante tabulación. Los sitios en producción que añadieron un encabezado fijo a un formulario existente durante el ciclo de rediseño de 2020–22 pasaron habitualmente por alto el comportamiento de foco y desplazamiento porque el formulario original fue redactado antes de que existieran los elementos fijos.

Establezca scroll-margin-top (o scroll-padding-top en el contenedor de desplazamiento) igual a la altura de cualquier superposición fija. Compruebe que al tabular a través de un formulario largo, el elemento con foco quede completamente visible por debajo de cualquier encabezado. Combínelo con estilos de foco visible para que el usuario pueda ver dónde se ha desplazado el foco.

La funcionalidad que utiliza un movimiento de arrastre también debe poder operarse mediante una acción de puntero único — un toque, un clic o un equivalente que no requiera movimiento sostenido del puntero. Las interacciones de arrastrar y soltar no están prohibidas; simplemente no pueden ser el único camino disponible hacia la función.

Las interfaces de reordenación de listas y las de estilo kanban ofrecen con frecuencia solo la reordenación mediante arrastre. Lo mismo ocurre con los controles deslizantes implementados como controles arrastrables sin un campo de número o entrada de texto correspondiente, y con las interfaces de recorte de imagen que requieren un arrastre para establecer los límites. El criterio los detecta en todos estos casos.

Para cada interacción de arrastre, proporcione una alternativa equivalente de toque o clic — botones «subir» y «bajar» junto a los elementos de lista arrastrables, una entrada numérica junto a un control deslizante, un modo de clic para establecer límites en el recortador. Donde la alternativa esté oculta en un menú contextual, garantice su accesibilidad mediante teclado.

Dentro del mismo proceso autenticado, no se debe exigir al usuario que introduzca la misma información dos veces — salvo que la reintroducción sea esencial, que la entrada anterior ya no sea válida o que la información implique seguridad (la confirmación de contraseña durante la creación de cuenta es la excepción canónica). Tanto el autocompletado como la selección a partir de valores introducidos previamente satisfacen el criterio.

Los flujos de pago en varios pasos, los formularios de solicitud de múltiples páginas y las solicitudes de visados o permisos suelen pedir la misma dirección, nombre o información de contacto en dos pasos separados porque los pasos fueron construidos por equipos distintos y nunca se reconciliaron. Los valores introducidos previamente por el usuario no se conservan en una sesión compartida entre los pasos.

Persista los valores introducidos por el usuario a lo largo de los pasos de un mismo proceso; rellene previamente los campos coincidentes en los pasos siguientes; o exponga un control de «usar la misma dirección» con un solo clic. El patrón suele aflorar durante el mapeo del proceso más que durante la auditoría del front-end, por lo que una revisión del flujo entre equipos es el paso práctico de corrección.

Si se proporciona un mecanismo de ayuda — un enlace de contacto, un enlace de ayuda, un widget de chat, un teléfono de soporte, un enlace de autoservicio — debe aparecer en la misma posición relativa en todas las páginas donde se proporcione. El criterio no exige que haya ayuda; solo que, donde la haya, su ubicación sea consistente.

El criterio es sencillo en principio y detecta un conjunto reducido de sitios que tienen un enlace «Contacte con nosotros» en el encabezado en algunas páginas, en el pie de página en otras y dentro de un widget de chat flotante en un tercer conjunto de páginas — con frecuencia el resultado de varias secciones del sitio gestionadas por equipos distintos con plantillas separadas.

Audite la ubicación del mecanismo de ayuda en todas las plantillas; establezca una única ubicación canónica (encabezado, pie de página permanente o widget flotante) y corrija los casos atípicos. La corrección rara vez es técnica; es un paso de gobernanza de contenido y plantillas.

La prima AAA de 2.4.11: cuando un componente de la interfaz de usuario recibe el foco de teclado, el elemento con foco no debe estar oscurecido por el contenido del autor en absoluto. La oclusión parcial está prohibida a este nivel — un encabezado fijo que cubra cualquier parte del campo con foco falla.

Las mismas colisiones de superposición fija que provocan los fallos de 2.4.11 persisten en 2.4.12. Los sitios que adoptaron scroll-margin-top para satisfacer el criterio mínimo siguen tendiendo a dejar unos pocos píxeles CSS de solapamiento en alturas de ventana de casos extremos. En AAA, ese solapamiento es el fallo.

Ajuste scroll-margin-top para superar cómodamente la altura de todas las superposiciones creadas por el autor, incluidas las dinámicas (banners de cookies que aparecen en la primera visita, widgets de chat que se expanden al pasar el cursor). Añada pruebas de regresión explícitas para el comportamiento de tabulación en formularios en los tamaños de ventana más habituales.

La prima AAA de 3.3.8: la autenticación no puede depender de una prueba de función cognitiva, sin excepciones. Las excepciones de reconocimiento de objetos y contenido personal que se aplican en AA no se aplican aquí. Las pruebas de memoria, las pruebas de transcripción y los desafíos de reconocimiento de imágenes fallan a este nivel.

Incluso los sitios que reemplazaron los CAPTCHA tradicionales por desafíos de reconocimiento de objetos (la excepción AA) fallan 3.3.9. El criterio es la señal del grupo de trabajo sobre hacia dónde debe ir la autenticación: alejarse por completo de los desafíos cognitivos y avanzar hacia la verificación basada en dispositivo o biométrica.

Adopte las claves de acceso (WebAuthn) como mecanismo de autenticación principal; trate la contraseña más clave de acceso como un estado de transición y no como un destino final. Donde se haya mantenido el reconocimiento de imágenes para la puntuación de riesgo, ejecútelo en el servidor a partir de señales de comportamiento en lugar de como un desafío visible para el usuario.