Prompts de accesibilidad para revisiones de UI en React y Flutter: prompts copiables y pasos sencillos para revisar teclado, orden de foco, etiquetas, contraste y lectores de pantalla.

La mayoría de los problemas de accesibilidad no son cambios de diseño enormes. Son detalles pequeños que deciden si alguien puede usar tu UI o no.
Lo que suele fallar primero es bastante consistente. Una página puede verse bien, pasar una revisión visual rápida y aun así ser difícil de usar con teclado o lector de pantalla.
Estos son los puntos donde las UIs tienden a fallar primero:
La parte complicada es lo fácil que es introducir regresiones. Un cambio “pequeño” como cambiar un botón por un icono, envolver una tarjeta en un manejador de gestos o añadir un dropdown personalizado puede eliminar el soporte por teclado, romper el orden de foco o eliminar una etiqueta sin que nadie lo note.
Un escenario común: un formulario en React recibe un nuevo icono de “borrar” dentro de un input. Parece útil, pero el icono no es focalizable, no tiene nombre y captura eventos de clic. Ahora los usuarios de teclado no pueden activarlo, y los usuarios de lectores de pantalla escuchan un control sin etiqueta.
Este artículo te da dos cosas: prompts copiables que puedes usar con tu código UI (React y Flutter), y un flujo de revisión repetible que puedes ejecutar en minutos. El objetivo no es la perfección desde el primer día, sino detectar los problemas que bloquean a usuarios reales.
Si construyes pantallas de producto pero no eres especialista en accesibilidad, esto es para ti. También encaja con equipos que usan herramientas de generación por chat como Koder.ai, donde los cambios en la UI pueden ocurrir rápido y necesitas chequeos rápidos y consistentes. Si quieres un punto de partida práctico, estos prompts de accesibilidad para revisiones de UI en React y Flutter están diseñados para reutilizarse cada vez que publiques UI.
Si solo tienes 15 minutos para revisar una pantalla, estas comprobaciones encuentran los problemas que más a menudo bloquean a las personas. Funcionan tanto para React como para Flutter, y encajan bien en los prompts de accesibilidad para revisiones de UI.
Intenta moverte por la página sin ratón. Usa Tab y Shift+Tab para moverte, Enter y Space para activar, y las flechas donde un widget parezca un menú, pestañas o una lista.
Una señal clara: si quedas atrapado dentro de un modal, o no puedes alcanzar un control clave (por ejemplo, “Cerrar”), algo está mal.
Al avanzar con Tab, el foco debería seguir el diseño visual (de arriba abajo, izquierda a derecha) y nunca saltar a áreas ocultas. El foco también debe ser obvio. Si el diseño usa contornos sutiles, confirma que siguen siendo visibles sobre fondos claros y oscuros.
Un lector de pantalla debe anunciar un nombre útil para cada elemento interactivo. “Button” no es suficiente. Los iconos necesitan una etiqueta accesible, y los campos de formulario necesitan una etiqueta que se mantenga conectada incluso cuando los placeholders desaparecen.
Revisa texto pequeño, texto deshabilitado y texto en botones con color. También prueba el zoom: aumenta el tamaño de fuente y asegúrate de que el diseño no se solape ni recorte contenido clave.
Cuando algo cambia (error, carga, éxito), los usuarios no deberían tener que adivinar. Usa texto de error en línea cerca del campo, anuncia errores de formulario y deja claros los estados de carga.
Si construyes pantallas en Koder.ai, pídele que “verifique el flujo solo con teclado, el orden de foco y las etiquetas para lectores de pantalla de esta página”, y luego revisa el resultado usando los pasos anteriores.
El trabajo de accesibilidad va más rápido cuando decides qué vas a revisar y qué significa “suficiente” antes de tocar componentes. Un alcance ajustado también hace que los prompts de accesibilidad para revisiones de UI en React y Flutter sean más útiles, porque el modelo puede centrarse en pantallas reales e interacciones reales.
Empieza con 2 a 4 recorridos de usuario críticos, no con todo el producto. Buenas opciones son las tareas que los usuarios deben completar para obtener valor y aquellas que pueden bloquearlos si fallan.
Para la mayoría de apps, eso es algo como iniciar sesión, un flujo principal de “crear o comprar” (checkout, reserva, envío) y un área de cuenta como ajustes o perfil.
Luego anota las pantallas exactas de cada recorrido (aunque sean solo 5 a 8 pantallas). Incluye también los estados “intermedios”: mensajes de error, estados vacíos, estados de carga y diálogos de confirmación. Ahí es donde a menudo se rompen el foco y la salida del lector de pantalla.
Un ejemplo concreto: si construyes una pequeña pantalla de CRM en Koder.ai, delimítala a “iniciar sesión -> abrir Contactos -> añadir contacto -> guardar -> ver mensaje de éxito.” Ese flujo toca formularios, validación, diálogos y anuncios.
Sé práctico. Apunta a expectativas al estilo WCAG AA, pero tradúcelo a comprobaciones sencillas que puedas aplicar rápido: el teclado funciona de punta a punta, el foco es visible y lógico, los nombres y etiquetas tienen sentido, y el contraste es legible.
Usa un formato simple de aprobado/fallo para no perder tiempo debatiendo. Para cada pantalla captura:
Esto mantiene la revisión consistente entre React y Flutter y facilita pasar los problemas a otra persona sin volver a explicar el error.
Cuando pidas una revisión de accesibilidad, lo más rápido es ser específico: qué componente, qué acción de usuario y cómo se ve el estado “bueno”. Estos prompts funcionan mejor cuando pegas el código del componente junto con una breve descripción de lo que la UI debe hacer.
Si usas un generador por chat como Koder.ai, añade el prompt justo después de generar una pantalla o componente para que los problemas se arreglen antes de propagarse por la app.
Review this React component for keyboard navigation issues.
- Can every interactive element be reached with Tab and activated with Enter/Space?
- List the exact problems you see in the code.
- Propose fixes with small code edits.
Check focus order and focus visibility.
- Describe the expected focus order for a keyboard-only user.
- Point out where focus could get lost (modals, menus, drawers).
- Tell me exactly where to add :focus-visible styles (which elements, which CSS).
Find missing accessible names.
- Identify inputs, buttons, and icons without clear labels.
- Suggest label + htmlFor, aria-label, aria-labelledby, or visible text.
- If there is helper/error text, connect it with aria-describedby.
Identify interactive elements that are not buttons/links.
- Find div/span with onClick, custom dropdowns, and clickable cards.
- Suggest correct semantics (button/a) or add role, tabIndex, and keyboard handlers.
List screen reader announcements that will be confusing.
- Predict what a screen reader will announce for key controls.
- Rewrite UI text to be shorter and clearer.
- Suggest aria-live usage for status changes (loading, errors, saved).
Antes de enviar un prompt, incluye estos detalles para obtener arreglos útiles, no consejos genéricos:
Si deseas resultados consistentes, pega un fragmento del árbol de widgets (o la pantalla completa) y pide comprobaciones específicas. Estos prompts funcionan mejor cuando incluyes: el árbol de widgets, cómo se accede a la pantalla y cualquier gesto personalizado.
Review this Flutter widget tree for keyboard navigation and focus traversal.
Call out focus traps, missing focus order, and places where Tab/Shift+Tab will feel confusing.
Suggest exact widget changes (Focus, FocusTraversalGroup, Shortcuts, Actions).
Check this screen for missing Semantics labels, hints, and tap targets.
Point to the exact widgets that need Semantics(label/hint), tooltip, or exclusion.
Also flag controls under 48x48 logical pixels and suggest fixes.
Find custom gestures that break accessibility (GestureDetector/Listener).
Replace them with accessible widgets or add keyboard + semantics support.
If a gesture is required, describe how a keyboard user triggers the same action.
Audit error messages and validation on this form.
What should be announced to a screen reader, and when?
Suggest how to expose errors via Semantics and focus movement after submit.
Propose a consistent focus highlight style across screens.
It should be obvious on dark/light themes and work with keyboard navigation.
Show a small code example using FocusTheme/ThemeData.
Espera respuestas que mencionen patrones concretos:
FocusTraversalGroup y establece FocusTraversalOrder solo cuando sea necesario.Semantics (o MergeSemantics) para controles compuestos y evita etiquetas duplicadas.InkWell, IconButton, ListTile, SwitchListTile en lugar de GestureDetector cuando sea posible.Shortcuts + Actions para entradas no textuales (por ejemplo, Enter para activar, Escape para cerrar).Un ejemplo mínimo para que una tarjeta personalizada se comporte como un botón:
Semantics(
button: true,
label: 'Add payment method',
hint: 'Opens the add card screen',
child: Focus(
child: InkWell(
onTap: onPressed,
child: Card(child: child),
),
),
)
Una revisión rápida de teclado y foco detecta problemas que también afectan a lectores de pantalla y dispositivos de conmutador. Hazla en un flujo de páginas real (no en un único botón) y toma notas para poder volver a comprobar la misma ruta más tarde.
Empieza escogiendo un “camino feliz” que seguiría un usuario, como iniciar sesión, abrir ajustes y guardar.
Mantenlo simple: nombre de la página, qué pulsaste, qué pasó y qué esperabas. Ese pequeño registro facilita confirmar que un refactor en React o un cambio de widget en Flutter no rompió silenciosamente el acceso por teclado.
Los lectores de pantalla no “ven” tu UI. Dependen de nombres, roles y mensajes cortos que expliquen qué cambió. Si el nombre falta o es vago, la app se vuelve un juego de adivinanzas.
Empieza por los campos de formularios. Cada campo necesita una etiqueta real que se mantenga incluso cuando el campo está rellenado. Los placeholders son pistas, no etiquetas, y suelen desaparecer en cuanto el usuario escribe.
Las acciones solo con icono son otro fallo común. Un icono de papelera, un lápiz o un menú de tres puntos necesita un nombre significativo que describa la acción, no la forma. “Eliminar proyecto” es mejor que “Button” o “Papelera”.
Los encabezados y las etiquetas de sección importan porque forman el esquema de la página. Usa encabezados para reflejar la estructura, no solo el estilo. Un usuario de lector de pantalla saltará por encabezados para encontrar “Facturación” o “Miembros del equipo”, así que esas etiquetas deben coincidir con el contenido.
Los mensajes de error deben ser específicos y accionables. “Entrada no válida” no basta. Di qué falló y qué hacer a continuación, por ejemplo “La contraseña debe tener al menos 12 caracteres” o “El correo electrónico no tiene @”.
Usa estos prompts cuando revises una pantalla (o cuando pidas a una herramienta como Koder.ai que actualice componentes):
Muchas pantallas cambian sin recargar la página: guardar un perfil, añadir un ítem, cargar resultados. Asegúrate de que esas actualizaciones se anuncien.
Para React, usa una región aria-live (polite para “Guardado”, assertive para errores críticos). Para Flutter, usa Semantics y muestra mensajes de estado visibles (por ejemplo, un banner o SnackBar) para que se lean, no solo se muestren. Una comprobación rápida: activa “Guardar” y confirma que escuchas un mensaje corto como “Cambios guardados” sin mover el foco del botón.
Puedes detectar la mayoría de problemas de contraste y claridad en minutos si te concentras en los lugares donde la gente pelea: texto pequeño, iconos, anillos de foco y colores de estado. Esto es una parte práctica de los prompts de accesibilidad para revisiones de UI en React y Flutter porque es fácil de verificar y de arreglar.
Empieza revisando una pantalla al 100% y luego al 200%. Si algo se vuelve difícil de leer, suele ser un problema de contraste, peso o espaciado, no un “problema del usuario”.
Revisa estos cinco lugares primero:
Una regla sencilla: si necesitas entrecerrar los ojos, tus usuarios también lo harán. Si dudas sobre un par de colores, cambia temporalmente el texto a negro puro o blanco puro. Si la legibilidad mejora mucho, el contraste era insuficiente.
La visibilidad del foco a menudo se pasa por alto. Asegúrate de que el contorno de foco sea suficientemente grueso y no del mismo color que el fondo. Si tienes un estado “seleccionado” en una lista, debe diferenciarse incluso en escala de grises (por ejemplo, con un icono, subrayado o borde claro).
En móvil, la claridad visual también trata de interacción táctil. Botones y acciones solo con icono deben tener áreas de toque generosas y espacio suficiente para evitar pulsaciones erróneas.
Haz una revisión rápida de temas: cambia a modo oscuro y, si tu app lo soporta, ajustes de alto contraste. Revisa texto sobre superficies, divisores y anillos de foco. Un error común es un anillo de foco que desaparece en modo oscuro o un icono “inactivo” que casi se confunde con el fondo.
Si generas UI rápidamente en una herramienta como Koder.ai, añade un paso extra: pide un “pase de contraste y anillos de foco” después del primer diseño, antes de pulir los visuales.
La mayoría de los bugs de accesibilidad se repiten porque parecen pequeños retoques de UI, no cambios de comportamiento del producto. Cuando ejecutes prompts de accesibilidad para revisiones de UI en React y Flutter, vigila primero estos patrones.
El texto placeholder no es una etiqueta. Un placeholder desaparece cuando alguien escribe, y muchos lectores de pantalla no lo tratan como nombre del campo. Usa una etiqueta visible real (o un nombre accesible explícito) para que el input sea comprensible vacío, rellenado y con errores.
Los estilos de foco se eliminan porque “se ven mal”. Eso suele dejar perdidos a los usuarios de teclado. Si cambias el outline por defecto, reemplázalo por algo igual de claro: un anillo fuerte, un cambio de fondo y suficiente contraste con la página.
Otro culpable recurrente son los botones falsos. En React es tentador usar un div con onClick, y en Flutter un Container con GestureDetector. Sin semántica adecuada, el soporte por teclado y los lectores de pantalla sufren. Los controles nativos (button, a, TextButton, ElevatedButton) te dan foco, rol, estado deshabilitado y comportamiento de activación por defecto.
Los bugs de foco en diálogos y formularios son sutiles pero molestos. Tras cerrar un modal o guardar un formulario, el foco suele saltar al inicio de la página o desaparecer. Pasa cuando no se restaura el foco al control que abrió el diálogo, o cuando la acción de guardar vuelve a renderizar la pantalla y elimina el foco. Entonces los usuarios deben volver a buscar dónde estaban.
El uso excesivo de ARIA (o Semantics en Flutter) también puede romper cosas. Añadir roles y etiquetas por todas partes puede entrar en conflicto con lo que el elemento nativo ya proporciona, provocando anuncios dobles o nombres erróneos.
Una comprobación rápida de “problemas repetidos” que puedes pedir al revisar una pantalla:
Si generas UI por chat (por ejemplo en Koder.ai), incluye estas comprobaciones como criterios de aceptación para que el primer borrador ya evite las trampas comunes.
Imagina una pantalla sencilla de Ajustes: un formulario de perfil (Nombre, Email), dos toggles (Notificaciones por email, Modo oscuro), un botón “Guardar cambios” y un toast que aparece tras guardar.
Empieza con el teclado. El orden de foco esperado debe coincidir con el orden visual, de arriba abajo y de izquierda a derecha. Tabbing nunca debe saltar al área del toast, al pie de página o a un menú oculto.
Un pase rápido que funciona para la mayoría de revisiones:
Ahora comprueba qué anuncia un lector de pantalla. Cada control necesita un nombre, rol y estado claros. Por ejemplo: “Nombre, campo de texto, obligatorio” y “Notificaciones por email, switch, activado”. Si el campo Email tiene un error, debe anunciarse al entrar en el campo y cuando aparece el error (por ejemplo: “Email, campo de texto, inválido, Introduce un correo válido”). El botón Guardar debe leerse como “Guardar cambios, botón” y mostrarse deshabilitado solo si además comunicas por qué.
Para contraste, revisa texto normal, texto placeholder y mensajes de error. También verifica el anillo de foco: debe ser fácil de ver tanto en fondos claros como oscuros. Los estados de error no deben depender solo del color rojo. Añade un icono, texto claro o ambos.
Convierte lo que encuentres en una lista corta de arreglos:
Si construyes en Koder.ai, pega la descripción de la pantalla y tus hallazgos en el chat y pídele que actualice la UI en React o Flutter para que coincida con el comportamiento esperado de teclado y lector de pantalla.
Si quieres que los prompts de accesibilidad para revisiones de UI en React y Flutter den resultados a largo plazo, trátalos como un hábito repetible, no como una limpieza puntual. La meta es ejecutar el mismo pequeño conjunto de comprobaciones cada vez que añades una pantalla o un componente.
Mantén una única “definición de hecho” para cambios en UI. Antes de publicar cualquier cosa, haz un pase rápido que cubra teclado, foco, nombres y contraste. Lleva solo minutos si lo haces a menudo.
Aquí tienes una lista rápida que puedes usar en casi cualquier UI:
Guarda tus mejores prompts como plantillas. Una forma sencilla es mantener un “prompt de revisión React” y uno de “revisión Flutter” que pegues al final de cada solicitud de cambio. Luego añade una línea corta que describa el nuevo componente y cualquier comportamiento especial (modal, stepper, lista con scroll infinito).
Vuelve a ejecutar las mismas comprobaciones en cada nuevo componente antes de publicar, incluso si parece repetitivo. Los problemas de accesibilidad suelen introducirse por ediciones pequeñas: un nuevo botón solo con icono, un dropdown personalizado, un mensaje toast o una trampa de foco en un diálogo.
Si trabajas con Koder.ai, pega los prompts en el chat y pide arreglos concretos, no mejoras generales. Luego usa el modo de planificación para revisar el impacto antes de aplicar cambios. Toma una instantánea antes del pase de accesibilidad y usa rollback si una corrección rompe el diseño. Eso hace más seguro iterar en orden de foco y semántica sin miedo.
Después de tu pase de accesibilidad, puedes tratarlo como una puerta de liberación: exporta el código fuente para tu flujo de repositorio, o despliega y aloja la app y conecta un dominio personalizado cuando estés satisfecho con los resultados.