Construye cobertura alrededor de las tareas del cliente
Enumera las rutas y resultados que generan valor: encontrar un servicio, buscar, añadir un artículo, reservar, iniciar sesión, pedir ayuda o pagar. Para cada uno, nombra los componentes que pueden cambiar de forma o fallar: navegación, filtros, tarjetas, tablas, imágenes, banners, formularios, cajones (drawers) y widgets embebidos. Prueba anchos donde tu contenido se vea constreñido, no simplemente un catálogo de modelos de teléfono actuales. Prueba justo por debajo, en y justo por encima de cada punto de corte (breakpoint).
Incluye teléfonos de ancho estrecho y medio, un ancho tipo tablet, portátil, escritorio ancho y el modo horizontal cuando cambie la tarea.
Usa títulos largos, resultados vacíos, errores de validación, insignias de precio, direcciones completas y etiquetas más largas cuando esos estados existan.
Demuestra reflujo, lectura y zoom
Confirma que la página tiene la configuración de viewport adecuada y luego busca desplazamiento horizontal a nivel de página. Imágenes fijas, campos anchos, márgenes negativos, paneles fuera de lienzo y banners son causas comunes. El criterio Reflow de WCAG 2.1 describe contenido con desplazamiento vertical a un ancho equivalente a 320 CSS pixels, incluyendo un viewport de 1280 píxeles al 400% de zoom. Si ese criterio está en el alcance, prueba el escenario de zoom real. Un mapa, vídeo o tabla de datos puede necesitar un diseño bidimensional, pero mantiene ese desplazamiento dentro del componente y permite que la página circundante haga reflujo.
Revisa encabezados, contenido principal, pies de página, barras fijas, diálogos y resúmenes de errores en cada límite probado.
Reorganiza la información para una pantalla estrecha; no elimines silenciosamente un requisito, detalle de precio o ruta de ayuda.
Somete a estrés contenido y formularios
Operaciones de contenido pueden causar fallos responsive sin un despliegue de CSS. Prueba el encabezado aprobado más largo, varias insignias, una imagen faltante, un filtro seleccionado, un aviso legal extenso y un campo rellenado por el navegador. Cuando las columnas se apilan, confirma que el orden de lectura y por teclado sigue teniendo sentido. Completa el formulario real en un dispositivo pequeño: abre controles, corrige un error y envía. Prueba widgets de terceros en la página de tipo producción porque su contenedor, estado de consentimiento, fuentes y estilos pueden alterar el resultado.
Refleja las longitudes y combinaciones máximas probables, pero no incluyas datos de clientes ni de pago en la evidencia de QA.
Abre avisos, chat, promociones y mensajes de validación simultáneamente; ninguno debe cubrir la acción principal o el campo enfocado.
Ejercita cada vía de entrada
Una pantalla grande no garantiza un ratón, y una pantalla pequeña no garantiza solo entrada táctil. La media feature hover prueba si una entrada primaria puede hacer hover cómodamente, por lo que el hover debe mejorar la experiencia y no ser la única ruta a una acción o explicación. Prueba teclado y puntero en escritorio, tap y desplazamiento en un dispositivo táctil, y dispositivos de entrada mixta donde sea relevante. Revisa botones de cerrar compactos, steppers, chips, calendarios y acciones con iconos. WCAG 2.2 Target Size (Minimum) especifica un tamaño objetivo de 24 por 24 CSS pixels con excepciones definidas, incluyendo espaciado y enlaces en línea. Es un criterio con alcance y excepciones, no una promesa de que cada control de 24 píxeles sea igualmente fácil para todas las personas.
Recorre la página con Tab. El foco debe permanecer visible, seguir un orden sensato e entrar y salir de menús y diálogos de forma predecible.
Haz que una revelación esencial por hover esté disponible mediante foco, tap o un control visible, y evita comportamientos confusos en el primer toque.
Verifica activos y rendimiento en condiciones de restricción
Una imagen puede caber en su contenedor y aún así ser el archivo equivocado para el dispositivo. Comprueba que los medios se mantengan contenidos, reserven espacio de diseño cuando proceda, conserven su recorte útil y soliciten candidatos adecuados. Srcset y sizes dan al navegador información para elegir entre las fuentes de imagen suministradas; no garantizan una petición determinada. Usa el throttling de DevTools para descubrir problemas temprano, pero sus controles de CPU y red simulan condiciones relativas al equipo de desarrollo. Vuelve a comprobar las rutas clave en un dispositivo real y una conexión real. Inspecciona fuentes, medios hero, carruseles, trabajo del lado cliente y scripts de terceros por demoras, cambios de diseño o taps bloqueados.
Captura la ruta, el viewport, la conexión real o simulada, y qué se volvió lento o inestable; compara condiciones equivalentes.
Cuando sea seguro, retrasa los embeds no esenciales en una versión de prueba para saber si la tarea central sigue siendo usable.
Remedia como trabajo proactivo de uptime
Para Status Is UP, la preparación responsive es una optimización proactiva de disponibilidad: identifica una ruta de dispositivo que bloquee al usuario, corrige su causa, demuestra la reparación y evita recurrencias. No es una afirmación de que una alerta de monitorización pueda juzgar cada defecto de diseño o interacción. Prioriza por impacto en la tarea y alcance. Antes del despliegue, prueba anchos adyacentes y el recorrido cambiado en hardware real. Planifica una reversión para cambios en navegación compartida, estilos, scripts, pagos o integraciones. Después del lanzamiento, repite los pasos de comprobación y adjunta la evidencia al registro del cambio.
Indica la ruta, dispositivo o viewport, orientación, entrada, estado, resultado esperado, resultado real y una captura redactada.
Prefiere una corrección en el componente, regla de layout, token o entrega de imagen en lugar de una anulación por ruta; asigna un responsable y un plan de retirada para las excepciones.