Diseño y accesibilidad
WCAG 2.2 dentro del sistema de diseño
Cómo convertir foco, tamaño de objetivo y autenticación accesible en reglas reutilizables de producto.
La idea central
Un componente accesible reduce errores repetidos, pero la conformidad se comprueba en el recorrido completo, con contenido y estados reales.
WCAG 2.2 añade criterios que afectan patrones cotidianos: foco no oculto, apariencia del foco, tamaño mínimo de objetivos, movimientos de arrastre, entrada redundante y autenticación accesible. Resolverlos página por página produce inconsistencias.
Un sistema de diseño puede convertir esos criterios en contratos: controles de al menos 24 por 24 píxeles donde aplique, áreas táctiles mayores para móvil, anillos de foco visibles, encabezados sticky que no cubran el elemento enfocado y alternativas a gestos complejos.
Cobertura accesible por capa
Los componentes también necesitan estados completos. Un campo no es accesible solo por tener label; requiere ayuda, error asociado, contraste, orden de foco y comportamiento correcto con zoom y teclado. Esos detalles deben vivir en el componente y en su documentación.
La validación combina automatización y revisión humana. Lint y pruebas detectan atributos o contraste, pero navegación, comprensión, contenido y carga cognitiva necesitan recorridos reales con teclado, lector de pantalla y ampliación.
Convertir criterios en contratos
Un botón define tamaño, contraste, foco, estado disabled y nombre accesible. Un modal define foco inicial, trap, cierre y retorno. Al expresar esos comportamientos como contrato, cada producto recibe una base consistente y las excepciones se vuelven visibles en revisión de código y documentación.
Diseñar foco y objetivos desde el componente
El indicador debe conservar contraste y no quedar cubierto por encabezados sticky. Los icon buttons necesitan una superficie táctil suficiente aunque el icono sea pequeño. En grupos densos, el espaciado puede satisfacer el criterio sin aumentar cada forma, pero móvil suele beneficiarse de 44 píxeles como objetivo práctico.
Formularios y autenticación sin fricción cognitiva
Labels persistentes, ayuda asociada, errores accionables y autocompletado correcto reducen trabajo para todos. La autenticación debe permitir gestores de contraseñas, pegado y alternativas a acertijos cognitivos. Un mensaje anunciado por lector de pantalla debe explicar qué falló y cómo continuar.
Gobernar con pruebas de varias capas
Lint, pruebas unitarias y axe cubren parte de la semántica. La revisión manual añade teclado, zoom, reflow, lector de pantalla y comprensión del contenido. El sistema de diseño debe publicar ejemplos y criterios de aceptación para que la accesibilidad no dependa de la memoria de una sola persona.
Caso didáctico
Un formulario correcto que se vuelve inaccesible dentro de un modal
Un campo tiene label, ayuda y error asociado. Al colocarlo en un modal, el foco queda detrás del diálogo, el encabezado fijo tapa el control y el mensaje de validación aparece lejos del campo. El componente aislado pasa sus comprobaciones, pero la persona no puede completar el recorrido con teclado.
Documenta la entrada y salida del foco, el comportamiento de Escape, el retorno al control de origen y cómo se anuncian los errores. Usa un diálogo modal solo cuando la tarea deba interrumpir el contexto actual. Para formularios extensos, una página puede ofrecer más espacio y una navegación más predecible.
Distingue niveles de conformidad: en WCAG 2.2, foco no oculto en su nivel mínimo y tamaño mínimo del objetivo pertenecen a AA; apariencia del foco pertenece a AAA. Los 24 × 24 píxeles CSS del objetivo mínimo tienen excepciones, incluida separación suficiente. Elegir 44 × 44 como objetivo del sistema puede mejorar el uso táctil, pero no convierte esa decisión en la regla mínima de AA.
Qué elegir y qué implica
| Situación | Decisión | Límite a considerar |
|---|---|---|
| Botón solo con icono | Dar nombre accesible y superficie de interacción suficiente. | El tooltip no sustituye el nombre ni el área objetivo. |
| Error de formulario | Asociar el mensaje al campo y explicar cómo corregir. | Un color de error sin texto deja fuera a parte de los usuarios. |
| Interacción por arrastre | Proporcionar una alternativa de puntero sin arrastrar. | El soporte de teclado por sí solo no cubre ese criterio específico. |
Desliza la tabla para comparar las tres columnas.
Llévalo a la práctica
Recorre el formulario como una tarea completa
- Abre, completa, provoca un error y cierra el formulario usando teclado.
- Revisa zoom, reflujo y visibilidad del foco bajo elementos fijos.
- Comprueba nombres, instrucciones y anuncios con lector de pantalla.
Qué comprobar: La persona identifica su posición, entiende cómo corregir y termina la tarea sin depender de visión, precisión motora o memoria del diseño.
El sistema reduce la repetición
WCAG 2.2 se vuelve manejable cuando sus requisitos viven en decisiones reutilizables. El sistema no garantiza por sí solo un producto accesible, pero evita que cada equipo vuelva a cometer los mismos errores básicos.
Para seguir leyendo
IA y agentes
Agentes con MCP: útiles por diseño, seguros por control
Cómo exponer herramientas a un agente sin convertir cada integración en un permiso implícito.
Cloud y plataforma
La plataforma interna ahora sirve a equipos y agentes
Golden paths, autoservicio y políticas para una organización donde humanos y agentes consumen la misma plataforma.