coastdigitalgroup/coastai-skills

Sistema de Estados Interactivos

Propósito

El skill Sistema de Estados Interactivos proporciona un marco de trabajo para definir cómo los componentes de la UI responden a la entrada del usuario. Garantiza que cada elemento interactivo (botones, enlaces, campos de entrada, tarjetas) tenga una retroalimentación visual clara, consistente y accesible en todos los modos de interacción (ratón, teclado, táctil). Este sistema elimina la ambigüedad para los desarrolladores y garantiza una sensación de alta calidad y respuesta para el usuario final.

Casos de uso

• Definir el comportamiento de componentes para un sistema de diseño o biblioteca de UI.
• Auditar un sitio existente para detectar interacciones "muertas" o no responsivas.
• Garantizar el cumplimiento de WCAG 2.2 para indicadores de foco, tamaño de objetivo y affordances interactivas.
• Estandarizar patrones de retroalimentación (por ejemplo, que todas las acciones destructivas se comporten igual).

Cuándo NO usarlo

• Contenido estático: Elementos puramente informativos que no tienen interacción de clic, toque o teclado.
• Diseño de animación experimental: Donde el objetivo es una animación compleja y no estándar en lugar de retroalimentación funcional de estado.
• Valores por defecto del navegador: Si el proyecto confía estrictamente en elementos nativos del navegador sin estilo (aunque esto es raro para diseños de sitios web profesionales).

Entradas

1. Inventario de componentes: Una lista de todos los elementos interactivos en el diseño.
2. Sistema de color de marca: Escalas de color primario, secundario y semántico existentes.
3. Objetivo de accesibilidad: (por ejemplo, Nivel AA de WCAG) que dicta las relaciones de contraste para los estados.

Salidas

1. Matriz de estados: Un mapa completo que muestra los estados Por defecto, Hover, Foco, Activo y Deshabilitado para cada componente.
2. Directrices de interacción: Reglas para transiciones, duración (ms) y funciones de easing.
3. Especificación de accesibilidad: Definiciones explícitas para anillos de foco y señales visuales solo para teclado.

Flujo de trabajo

1. Identificar elementos interactivos

Categorizar los elementos por su tipo de interacción:

• Acciones: Botones, enlaces, elementos de menú.
• Entradas: Campos de texto, casillas de verificación, botones de opción, selectores.
• Contenedores: Tarjetas cliqueables, encabezados de acordeón, pestañas.

2. Definir la paleta de estados

Determinar cómo cambian las variables visuales por estado:

• Hover (Ratón): Ligero cambio en color de fondo, borde o elevación (sombra).
• Foco (Teclado): Un anillo o contorno de alto contraste. Debe ser distinto del estado Hover.
• Activo/Presionado: "Compresión" visual (por ejemplo, ligero oscurecimiento o reducción de escala) para indicar un clic/toque exitoso.
• Deshabilitado: Opacidad reducida y eliminación de señales interactivas (cambia el cursor).
• Visitado (Enlaces): Un color distinto para enlaces navegados (crítico para sitios con mucho contenido).

3. Establecer la lógica de foco

Diseñar un "Estilo de foco global" que garantice que los usuarios de teclado siempre sepan dónde están.

• Regla: El indicador de foco debe tener una relación de contraste de al menos 3:1 contra el fondo Y contra el estado sin foco del componente.
• Regla (WCAG 2.2 SC 2.4.11): El indicador de foco nunca debe estar completamente oculto por otro contenido (por ejemplo, un encabezado fijo que cubre un elemento enfocado al hacer scroll). Al menos una parte del indicador debe permanecer siempre visible.

4. Optimizar para táctil (Móvil)

Dado que los estados hover no existen en dispositivos táctiles:

• Asegurar que los estados active proporcionen retroalimentación inmediata.
• Verificar que los objetivos táctiles cumplan con WCAG 2.2 SC 2.5.8 (mínimo 24x24px), y preferir 44x44px donde el diseño lo permita para un alcance cómodo del pulgar.
• Eliminar la información dependiente de hover (usar tooltips al tocar o etiquetas persistentes).

5. Documentar las transiciones

Definir cómo ocurre el cambio:

• Duración: 150ms a 250ms es estándar para cambios de estado.
• Easing: ease-in-out o cubic-bezier(0.4, 0, 0.2, 1).

Reglas de decisión

• Persistencia del estado: Los indicadores de foco deben permanecer visibles mientras el elemento tenga el foco.
• Affordance primero: Los elementos interactivos deben parecer "cliqueables" en su estado por defecto (por ejemplo, los botones deben tener más peso visual que las etiquetas no cliqueables).
• Sin estados solo de color: No confiar únicamente en el color para indicar un estado (por ejemplo, un estado de error debe incluir un cambio de icono o grosor de borde).
• Retroalimentación inmediata: Las respuestas interactivas deben sentirse instantáneas (tiempo de inicio <100ms).

Restricciones

• Accesibilidad: Los indicadores de foco no se pueden "ocultar" mediante CSS outline: none sin proporcionar una alternativa robusta.
• Responsividad: Los estados deben funcionar en pantallas pequeñas sin depender del hover del ratón.
• Rendimiento: Evitar sombras de caja pesadas o filtros complejos en estados que se activan con frecuencia (como hover) para prevenir thrashing de diseño.

Patrones de fallo comunes

• El foco "invisible": Eliminar el anillo de foco por defecto del navegador y no reemplazarlo, haciendo que el sitio sea inutilizable para usuarios de teclado.
• Lógica solo de hover: Colocar información crítica o acciones dentro de un estado hover, haciéndolas inaccesibles en móvil.
• Estados activos vagos: Botones que no cambian al hacer clic, lo que lleva a los usuarios a hacer clic varias veces.
• Estados deshabilitados confusos: Elementos que parecen deshabilitados pero en realidad son cliqueables, o viceversa.

Criterios de validación

• Cada elemento interactivo tiene un estado Hover, Foco y Activo definido.
• Los indicadores de foco cumplen con el requisito de contraste 3:1 y nunca están completamente ocultos por otro contenido (WCAG 2.2 SC 2.4.11).
• Los objetivos táctiles cumplen al menos 24x24px (WCAG 2.2 SC 2.5.8), preferiblemente 44x44px.
• Ninguna información crítica está oculta detrás de una interacción solo de hover.
• Los estados deshabilitados son visualmente distintos y tienen pointer-events: none (o lógica equivalente).
• El sistema incluye una directriz clara de transición/animación para los estados.