Probar componentes por separado: formulario, filtros y diálogo
Para profundizar
Consultar la explicación, las plantillas y las fuentes
Cinco casos didácticos para relacionar una dificultad con un cambio y una forma de comprobarlo. Son situaciones ficticias: no representan experimentos realizados ni resultados comerciales.
- Un error que permite continuar
- Un enlace que anticipa su destino
- Paginación de un catálogo
- Un filtro que comunica el resultado
- Texto más grande y barreras que permanecen
1. Un error que permite continuar
Situación. Una persona completa un formulario de contacto. Al enviarlo aparece «Hay errores» y no sabe qué tiene que cambiar.
Texto inicial: «Hay errores». La frase informa de un fallo, pero no permite localizarlo ni corregirlo.
Propuesta: «Revisa el correo electrónico: falta el símbolo @. Ejemplo: nombre@dominio.es». El mensaje se presenta junto al campo correspondiente y se vincula a él.
Qué implementar. Mantén una etiqueta visible, conserva los datos correctos y relaciona la explicación con el campo. Si hay varios errores, un resumen puede ayudar a localizarlos; debe encajar con la gestión del foco y las notificaciones del formulario.
Cómo comprobarlo. Provoca el error, revisa que pueda localizarse con teclado y con la tecnología de apoyo utilizada en la evaluación y observa si una persona puede corregirlo sin indicaciones. Comprueba también el envío satisfactorio.
Límite. Un formato correcto no demuestra que la cuenta de correo exista. Distingue la validación de formato de otras comprobaciones. Ver la guía de formularios.
2. Un enlace que anticipa su destino
Situación. Un artículo incluye varios enlaces «Más información». Para decidir cuál abrir hay que releer el texto de alrededor.
Texto inicial: «Más información». Puede ser comprensible en algunos contextos, pero aporta poca orientación por sí solo.
Propuesta: «Condiciones de devolución». Si el destino es un documento, añade su formato y otros datos útiles cuando corresponda, por ejemplo «Condiciones de devolución (PDF)».
Qué implementar. Escribe el nombre del destino o de la acción de forma clara. Mantén visible esa información y evita sustituirla por un nombre accesible distinto que contradiga el texto mostrado.
Cómo comprobarlo. Lee el enlace con su contexto, revisa que describa el destino real y pregunta qué espera encontrar una persona al activarlo. Comprueba también que los enlaces se distinguen dentro del párrafo.
Límite. Un enlace descriptivo no resuelve una página de destino confusa o desactualizada. Ver la guía de navegación.
3. Puntos o números para recorrer un catálogo
Situación. Una tienda muestra varias páginas de productos y representa su paginación con pequeños puntos. Se parecen a los indicadores de un carrusel y no explican bien dónde se encuentra la persona.
Propuesta: enlaces «Anterior», números de página y «Siguiente» cuando correspondan; identificación clara de la página actual. En catálogos extensos se pueden abreviar los números sin convertir los saltos omitidos en controles.
Qué implementar. Usa enlaces si cada página tiene su propia URL. Conserva los filtros en los destinos y permite volver a la vista anterior. El estilo debe distinguir la página actual del foco del teclado.
Cómo comprobarlo. Recorre varias páginas con teclado, abre un resultado y vuelve. Comprueba que persisten los filtros y que el estado actual sigue siendo comprensible. Evalúa en móvil el tamaño y la separación de los controles.
Límite. La paginación numerada no es la respuesta automática a cualquier listado. Cargar más o desplazamiento continuo tienen otros compromisos que deben evaluarse según la tarea. Ver los patrones de componentes.
4. Un filtro que comunica el resultado
Situación. Una persona activa un filtro y el listado cambia sin explicación. No sabe si la operación terminó o si quedan resultados.
Propuesta: mostrar un resumen como «8 resultados» y los filtros activos; ofrecer «Quitar filtros» cuando ayude a recuperar la lista. Si no hay coincidencias, explicar el estado y proponer cómo ampliar la búsqueda.
Qué implementar. Si los resultados se actualizan sin navegación, comunica el cambio relevante mediante un mensaje de estado apropiado y conserva el foco en un lugar predecible. Evita anunciar cada pulsación si eso produce ruido innecesario.
Cómo comprobarlo. Ensaya resultados, ausencia de coincidencias, carga lenta y error. Verifica los mensajes con el lector de pantalla empleado en la prueba y revisa que el foco no salte de forma inesperada.
Límite. Anunciar una cifra no aclara por qué un producto no aparece. Las etiquetas de filtros y las reglas de búsqueda también necesitan revisión. Entender mensajes de estado con ARIA.
5. Texto más grande y una barrera que permanece
Situación. Un panel permite aumentar el texto, pero un campo sigue identificado únicamente por un texto de ejemplo que desaparece al escribir.
La mejora útil: el tamaño puede facilitar la lectura a algunas personas.
La barrera pendiente: el campo necesita una etiqueta persistente y asociada correctamente. El aumento de tamaño no crea esa relación.
Qué implementar. Corrige primero la etiqueta y comprueba la base de lectura. Si añades personalización, debe respetar el zoom y no provocar recortes en contenido, tablas, código o controles.
Cómo comprobarlo. Evalúa la tarea antes y después del ajuste. Prueba restablecer valores, cambiar el ancho disponible y recorrer el formulario con teclado. Comprueba la asociación de la etiqueta en el árbol de accesibilidad.
Límite. La utilidad de una preferencia visual no equivale a la conformidad de toda la web. Leer qué solucionan los paneles de accesibilidad.
Convierte un ejemplo en una hipótesis propia
El problema de tu web puede parecerse sin tener la misma causa. Usa la plantilla de hallazgos para registrar qué observaste, qué cambio propones y qué falta por comprobar. Las guías enlazadas desarrollan la implementación y sus fuentes.