Accesibilidad e interacción

Foco, tamaño de zona pulsable, teclado y estados. Lo que es norma con número, separado de lo que es criterio.

Cómo leer esta guía

Citado, Verificado, Decisión Sensa. Sin marca = trabajo pendiente.

Esta guía cubre foco e interacción. El contraste está en Color; el movimiento y prefers-reduced-motion, en Animación.

Zona pulsable

(Verificado — WCAG 2.5.8, nivel AA) El objetivo para entrada por puntero es de al menos 24 × 24 px CSS, salvo excepciones. La principal: si es más pequeño, vale si al centrar un círculo de 24 px de diámetro sobre cada uno, los círculos no se solapan con otro objetivo. También quedan fuera los objetivos en línea dentro de un texto y aquellos cuya presentación viene impuesta y no es modificable.

24 px es el mínimo legal de AA, no una buena cifra de diseño. El criterio hermano 2.5.5 (AAA) pide 44 × 44, que coincide con lo que recomienda Apple para el toque.

Decisión Sensa. 44 px como objetivo real en táctil. Cuando el elemento visible tiene que ser más pequeño, se amplía el área con un pseudo-elemento en lugar de agrandar el botón:

.icon-btn { position: relative; }
.icon-btn::after {
  content: ''; position: absolute; inset: -10px;  /* 24px visual → 44px pulsable */
}

Foco

(Verificado — WCAG 2.4.7, nivel AA) «Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible». Corto y tajante: si se puede llegar con el teclado, el foco tiene que verse.

(Citado — Rauno) «Box shadow should be used for focus rings, not outline» — el outline no sigue el border-radius en algunos navegadores y se ve un rectángulo alrededor de un botón redondeado. Y «focusable elements in a sequential list should be navigable with ↑ ↓».

Decisión Sensa. Nunca outline: none sin sustituto. Usamos :focus-visible para que el anillo aparezca con teclado y no al hacer clic con ratón, y el anillo debe pasar 3:1 contra lo que tiene al lado (WCAG 1.4.11, ver Color).

.btn:focus-visible {
  outline: none;
  box-shadow: 0 0 0 3px var(--focus-ring);
}

No todo se comunica con la vista

(Citado — Apple) La accesibilidad no es una capa que se añade: Apple recomienda diseñar pensando en que la gente usa la interfaz con VoiceOver, con control por conmutador, con texto ampliado o sin oír el sonido. La idea que más se olvida: no uses un único sentido o modo para transmitir algo importante.

Decisión Sensa. Todo icono que actúa como botón lleva nombre accesible. Los estados (cargando, error, éxito) se anuncian, no sólo se pintan. Y el orden del DOM es el orden de lectura: si el orden visual y el del DOM no coinciden, quien navega con teclado se pierde.

Interacción

(Citado — Rauno), reglas que se incumplen a diario:

• «Toggles should immediately take effect, not require confirmation».
• «Buttons should be disabled after submission to avoid duplicate network requests».
• «Hover states should not be visible on touch press, use @media (hover: hover)».
• «To open immediately on press, dropdown menus should trigger on mousedown».
• «Inputs should not auto focus on touch devices as it will open the keyboard».
• «Disable the default iOS tap highlight with -webkit-tap-highlight-color».

Anti-patrones

• outline: none sin anillo de foco alternativo. Es el fallo de accesibilidad más común y el más fácil de arreglar.
• div con onClick en lugar de button: sin teclado, sin rol, sin foco.
• Iconos sin nombre accesible.
• Zonas pulsables de 16 px pegadas unas a otras.
• Deshabilitar el zoom con user-scalable=no.
• Errores de formulario señalados sólo con borde rojo.
• Orden del DOM distinto del orden visual.

Checklist de revisión

• ¿Se puede recorrer toda la interfaz con el teclado?
• ¿Se ve el foco en cada parada, y pasa 3:1?
• ¿Las zonas pulsables llegan a 24 px, o a 44 en táctil?
• ¿Los controles son elementos nativos (button, a, input)?
• ¿Cada icono interactivo tiene nombre accesible?
• ¿Los estados se anuncian, además de pintarse?
• ¿Coincide el orden del DOM con el visual?
• ¿Funciona con zoom al 400 % (ver Layout)?

Lo que falta

• WAI-ARIA Authoring Practices no está archivado. Es la referencia para patrones de componente (combobox, dialog, tabs) y debería estar.
• Nada sobre lectores de pantalla concretos ni sobre cómo probarlos.
• Formularios: mensajes de error, aria-live, asociación label/campo — merecen sección propia.