Marta llegó al selector de fecha con una mano en el teclado y otra en la libreta donde apuntaba los pasos que fallaban. Había pedido una cita en una biblioteca municipal; el formulario anunciaba con claridad que podía completarse sin ratón. Al entrar en el selector, el foco desapareció. Pulsó Tab una vez, dos, diez veces. La pantalla cambió de mes, pero ella no podía saber dónde estaba ni alcanzar el botón de confirmar. Esc pulsó una ventana que no devolvía el cursor al campo inicial. Después de varios minutos, abandonó el trámite y escribió una queja breve: “Con teclado me quedo atrapada”.
Puede acabar en una carpeta de sugerencias, convertirse en un ticket técnico con una etiqueta vaga o desencadenar una conversación verificable. La diferencia no depende de que el equipo declare que escucha. Depende de si puede describir el obstáculo, reproducirlo, acordar qué tendría que cambiar para retirarlo y devolver el resultado a la persona que lo encontró. La accesibilidad empieza a ser una responsabilidad compartida cuando una experiencia frustrante deja una huella capaz de modificar el servicio.
Una queja no es una especificación#
El informe de Marta no decía qué atributo debía tener el código ni qué componente sustituir. No era su trabajo hacerlo. Pedía, sin tecnicismos, poder terminar una tarea que el servicio le había invitado a hacer. Convertir esa petición en “el teclado no funciona” habría sido insuficiente: no indica en qué punto se rompe el recorrido, qué resultado espera la persona ni cómo comprobar que la solución no crea otra barrera.
El informe de Marta no decía qué atributo debía tener el código ni qué componente sustituir.
El equipo decidió registrar cuatro hechos antes de proponer una corrección. Primero, el objetivo: escoger una fecha, confirmar una cita y recibir comprobante sin usar puntero. Segundo, el recorrido exacto: enlace de reserva, campo de servicio, selector de fecha, franja horaria y confirmación. Tercero, la observación: al abrir el selector, el foco entra en controles que no se anuncian; al cerrarlo, no vuelve al campo que lo abrió; dentro de la ventana, Tab circula sin alcanzar una salida previsible. Cuarto, el impacto: el trámite se vuelve inacabable para quien utiliza teclado, y la alternativa telefónica no tiene el mismo horario ni la misma inmediatez.
Esa descripción evita dos errores frecuentes. El primero es tratar a Marta como una excepción que necesita asistencia personal. Una persona puede preferir o necesitar teclado por discapacidad, lesión temporal, fatiga, una configuración de voz o simplemente eficacia. El producto no necesita conocer su motivo para ofrecer una interacción coherente. Una alternativa es equivalente solo si permite la misma acción, con información y plazos comparables, sin obligar a revelar una dificultad.
Reproducir no significa poner a prueba a quien avisó#
La mañana siguiente, dos diseñadores y una desarrolladora reprodujeron la incidencia en un entorno de prueba. Empezaron con el teclado, sin extensiones especiales y con el lector de pantalla que usaba el equipo para sus comprobaciones habituales. Encontraron pronto el ciclo de foco, pero descubrieron algo más incómodo: el selector también podía cerrarse sin devolver la posición al formulario. Quien veía la pantalla podía recuperar el hilo con el ratón; quien dependía del orden de foco recibía silencio.
Reproducir sirve para pasar de una impresión a evidencia, no para obligar a la persona que se quejó a demostrar repetidamente que merece ser creída. Por eso el equipo no pidió a Marta una videollamada ni información sobre su situación personal. Le respondió que había empezado a investigar, le explicó el recorrido que intentaba replicar y le ofreció participar solo si quería revisar una solución posterior. El consentimiento para probar no debe ser el precio de que una incidencia se tome en serio.
El hallazgo también reveló una causa organizativa. El selector procedía de una biblioteca de componentes actualizada por otro equipo. En la revisión visual se había comprobado el contraste y el tamaño de letra, pero nadie poseía el criterio de aceptación para el comportamiento del foco. El defecto no era solo un fallo de código; era un vacío en la definición de “terminado”. Cuando ningún rol debe demostrar que un recorrido puede iniciarse, transitarse y cerrarse mediante teclado, esa comprobación queda a merced de la memoria o la buena voluntad.
Convertir el obstáculo en criterios de aceptación#
La corrección empezó por formular un resultado, no por elegir una solución vistosa. El ticket quedó abierto con criterios que cualquier integrante pudiera revisar:
- Al abrir el selector, el foco llega a un elemento anunciado que explica cómo elegir la fecha. - Todas las opciones operables se alcanzan con teclado en un orden comprensible; no existe un ciclo sin salida. - Escape cierra el selector y devuelve el foco al campo que lo activó. - Tras elegir una fecha, el valor se comunica de forma perceptible y el usuario puede continuar hasta la confirmación. - El mismo recorrido se comprueba en escritorio y móvil con teclado externo, y no depende de instrucciones ocultas.
Los criterios hacen visible una decisión que antes vivía repartida entre diseño, desarrollo y control de calidad. También permiten distinguir una reparación real de un parche. Añadir un enlace de “ayuda” junto al selector no cumple el objetivo si obliga a abandonar el formulario. Mover el foco de manera automática tampoco basta si una persona pierde el contexto. La pregunta útil es simple: ¿puede alguien completar la tarea con control sobre dónde está y qué ocurrirá después?
Para evitar que la urgencia empujara otra solución frágil, el equipo revisó tres opciones. La primera era ajustar el componente existente; la segunda, reemplazarlo por un campo con entrada manual y validación clara; la tercera, posponer la publicación del rediseño hasta contar con una prueba. Eligieron una combinación de la primera y la segunda: el selector obtuvo navegación de teclado estable y el campo permitió escribir una fecha en formato explicado. No se presentó como “modo accesible”, porque ofrecer una ruta secundaria puede convertir la diferencia en estigma. Era la misma función, mejor resuelta para todas las personas.
Probar la reparación en condiciones reales#
El control técnico confirmó que las nuevas pruebas automatizadas detectaban un ciclo de foco. Eso era importante, pero no suficiente. Una prueba puede verificar que existen elementos enfocables y pasar por alto que el orden carece de sentido cuando el calendario cambia de mes. El equipo preparó tres recorridos: reservar la primera cita disponible, elegir una fecha concreta y cambiar de servicio antes de confirmar. Documentaron la expectativa en cada paso y registraron tanto los bloqueos como las dudas.
Marta aceptó revisar el cambio en una sesión breve, desde su propio ordenador y sin que el equipo mirara su pantalla salvo cuando ella decidió compartirla. Completó el primer recorrido sin ayuda. En el segundo señaló que el anuncio del mes llegaba después de los días, de modo que podía elegir una fecha sin saber de qué mes era. No era el problema original, pero sí una consecuencia que la prueba técnica no había mostrado. El equipo corrigió el orden y volvió a ensayar. La devolución útil no consiste en obtener un “sí, funciona”; consiste en dejar que el uso real cuestione las suposiciones del arreglo.
Devolver la decisión, no solo cerrar el ticket#
Tras desplegar la corrección, el equipo no envió un mensaje automático de agradecimiento. Escribió a Marta en lenguaje corriente: había localizado un selector que atrapaba el foco; se modificó su navegación y se añadió una entrada de fecha clara; se comprobó el recorrido con teclado y se detectó una mejora adicional en el anuncio del mes. También explicó qué seguía pendiente: otros formularios usaban el mismo componente y se revisarían durante las dos semanas siguientes. Incluyó un canal directo para informar si el problema reaparecía, sin pedirle que narrara de nuevo toda la historia.
Esa respuesta cumple una función práctica. Permite a quien avisó evaluar si la organización entendió el daño, devuelve información que puede evitar un nuevo intento fallido y crea un compromiso verificable. Decir “hemos mejorado la accesibilidad” no admite contraste. Decir “Escape devuelve el foco al campo de fecha y Tab alcanza confirmar” sí. La precisión no es un tecnicismo defensivo: es una forma de respeto.
El circuito puede mantenerse con una ficha mínima por incidencia: fecha, recorrido afectado, barrera observada, criterio de aceptación, responsable, prueba realizada, decisión de despliegue y mensaje de devolución. Conviene revisar las fichas cada mes para encontrar componentes o prácticas que acumulan quejas. Si tres personas quedan atrapadas en menús distintos, quizá no existan tres problemas aislados, sino una regla de diseño que necesita cambiar.
La próxima vez que llegue una queja de accesibilidad, el primer paso no debería ser prometer que se trasladará al equipo correspondiente. Debe ser nombrar el recorrido y la salida que falta. Después, acordar cómo se sabrá que la salida existe, probarla sin convertir a nadie en objeto de examen y explicar lo que cambió. Marta no pidió una lección sobre accesibilidad. Pidió poder reservar una cita. Devolverle esa capacidad, junto con una explicación comprobable, es la decisión de producto que convierte escuchar en responsabilidad.
