Icono del sitio IT&ライフハックブログ|学びと実践のためのアイデア集

Guía completa de accesibilidad para búsqueda, filtrado y ordenación: desde la búsqueda interna y la UI de filtros hasta el autocompletado y cómo comunicar el recuento de resultados (WCAG 2.1 AA)

magnifying glass and wind rose on maps

Photo by Monstera Production on Pexels.com

Guía completa de accesibilidad para búsqueda, filtrado y ordenación: desde la búsqueda interna y la UI de filtros hasta el autocompletado y cómo comunicar el recuento de resultados (WCAG 2.1 AA)

Resumen general (puntos clave primero)

  • La UI de búsqueda es la última vía para reducir la sensación de “no puedo encontrarlo”. En accesibilidad, lo importante es la facilidad de entrada, la claridad de los resultados y qué tan claramente se comunican los cambios de estado después de aplicar filtros.
  • Los cinco elementos esenciales son: 1) una etiqueta visible para el campo de búsqueda, 2) recuentos de resultados presentados como texto, 3) filtros totalmente operables con teclado, 4) estados de ordenación y filtrado indicados con claridad, y 5) una ruta alternativa cuando no hay resultados.
  • El autocompletado y la visualización de sugerencias son cómodos, pero cuando se implementan mal suelen causar problemas como que los lectores de pantalla no puedan identificar las sugerencias, que las flechas no funcionen para navegar o que se seleccionen sugerencias automáticamente sin que la persona usuaria lo pretenda.
  • En este artículo organizamos formularios de búsqueda, listas de resultados, paneles de filtros, UI de ordenación, funciones de sugerencias y visualizaciones de filtros en móvil de una manera que pueda usarse directamente en el trabajo real.

Lectores objetivo (específicos): operadores de sitios de comercio electrónico, responsables de sitios municipales o del sector público, desarrolladores de SaaS/sistemas empresariales, diseñadores UI/UX, ingenieros front-end, QA/testers, personal de operaciones de contenido
Objetivo de accesibilidad: Apuntar a la conformidad con WCAG 2.1 AA (relacionado con: 1.3.1, 2.1.1, 2.4.3, 2.4.6, 3.2.2, 3.3.x, 4.1.2, etc.)


1. Introducción: la búsqueda es “la última aliada” para las personas que se pierden

Aunque la navegación y las tablas de contenido estén bien organizadas, las personas usuarias no siempre buscarán de la manera que quienes diseñan esperan. Es muy común que no conozcan el nombre de un producto, no sepan el nombre oficial de un servicio o política, o no puedan imaginar dónde podría estar ubicado un artículo.
En esos momentos, la búsqueda se convierte en la última aliada que hace que las personas sientan: “este sitio se puede usar”. Sin embargo, si esa UI de búsqueda está en un estado en el que

  • no tiene etiqueta, por lo que las personas usuarias no pueden saber qué tipo de campo es,
  • muestra sugerencias que aparecen y desaparecen solas,
  • no deja claro qué cambió después del filtrado, o
  • se convierte en un callejón sin salida cuando no hay resultados,
    entonces ese camino útil se transforma en una barrera.
    Desde la perspectiva de la accesibilidad, la búsqueda no es solo una función para encontrar cosas, sino también una función que apoya la comprensión y la recuperación. En este artículo resumiremos cuidadosamente cómo crear una experiencia de búsqueda en la que cualquier persona pueda buscar con facilidad y también recuperarse si se pierde.

2. Fundamentos del formulario de búsqueda: crear un punto de entrada fácil de usar y fácil de entender

El primer paso en una UI de búsqueda es, ante todo, dejar claro que “este es el campo de búsqueda”. Un ícono de lupa por sí solo no basta; la base es un formulario de búsqueda con una etiqueta visible.

2.1 Estructura mínima recomendada

<form role="search" aria-label="Site search" action="/search">
  <label for="q">Site search</label>
  <input id="q" name="q" type="search" aria-describedby="q-hint">
  <p id="q-hint">Examples: returns, shipping, invoice, accessibility</p>
  <button type="submit">Search</button>
</form>

2.2 ¿Por qué es importante?

  • role="search" ayuda a las tecnologías de asistencia a entender que esta es una “región de búsqueda”.
  • Un <label> proporciona apoyo estable tanto para lectores de pantalla como para entrada por voz.
  • type="search" puede mejorar ligeramente la experiencia de entrada, pero no sustituye a una etiqueta.
  • Si el texto de ayuda está vinculado con aria-describedby, los ejemplos de términos de búsqueda se transmiten de manera natural.

2.3 No dependas solo del placeholder

Una caja de búsqueda que solo contiene un texto tenue de placeholder como “Introducir palabra clave” deja de ser útil en el momento en que alguien empieza a escribir. Las mismas personas que no saben qué buscar son quienes más necesitan ayuda, así que es más amable mantener ejemplos visibles cerca de la etiqueta o en texto de apoyo.


3. Páginas de resultados de búsqueda: hacer visibles en texto el recuento, las condiciones y el orden de clasificación

Una vez que se muestran los resultados, lo primero que las personas usuarias quieren saber es “¿cuántos resultados se encontraron?” y “¿bajo qué condiciones se están mostrando actualmente estos resultados?”. Si esta información depende solo de lo visual, se vuelve muy difícil de entender para usuarios de lectores de pantalla y para personas con diferencias cognitivas.

3.1 Coloca el recuento de resultados cerca del encabezado

<h1>Search results</h1>
<p id="search-summary">Search results for “accessibility”: 25 items</p>

3.2 Comunica también en texto el estado después de los cambios

  • “Categoría: Artículos”
  • “Fecha de publicación: dentro del último año”
  • “Orden: más recientes primero”

Si esta información se muestra solo como chips visuales, puede que no se transmita bien a través de los lectores de pantalla. Listarla como texto y, cuando sea necesario, usar role="status" para anunciar cambios hace la experiencia mucho más estable.

<div id="result-status" role="status" aria-atomic="true" class="sr-only"></div>
<script>
function announceResult(count){
  document.getElementById('result-status').textContent =
    `Search results updated. ${count} items found.`;
}
</script>

3.3 Incluye el término de búsqueda en la descripción

En lugar de decir solo “25 resultados encontrados”, es mejor decir:

“Resultados de búsqueda para ‘accessibility’: 25 elementos”
Incluir el término de búsqueda ayuda a preservar el significado a través de múltiples pestañas o del historial de navegación.


4. Accesibilidad del filtrado: cuanto más se reduce, más cuidado debe tener el diseño

Filtrar es útil, pero como añade más operaciones, puede volverse complejo fácilmente. Cuantas más condiciones haya—rango de precio, categoría, fecha, etiqueta, estado de stock, ubicación, etc.—más difícil se vuelve saber “¿en qué estado estoy ahora?”.
Por eso es importante separar claramente la estructura de las condiciones.

4.1 Agrupa los filtros con fieldset y legend

<fieldset>
  <legend>Filter by category</legend>
  <label><input type="checkbox" name="category" value="article"> Article</label>
  <label><input type="checkbox" name="category" value="news"> News</label>
  <label><input type="checkbox" name="category" value="guide"> Guide</label>
</fieldset>

4.2 ¿Por qué ayuda fieldset?

Para los lectores de pantalla es importante entender no solo cada checkbox individual, sino también “¿a qué grupo pertenece esto?”.
Con un legend, se conserva el contexto “Filtrar por categoría”.

4.3 Deja claro si los filtros se aplican al instante o mediante un botón Aplicar

  • Aplicar instantáneamente al marcar
  • Aplicar después de varias selecciones con un botón de “Aplicar filtros”

Cualquiera de los dos enfoques está bien, pero mezclarlos genera confusión.
Si los filtros se aplican al instante, anuncia el recuento actualizado de resultados mediante status.
Si usas un botón Aplicar, haz que la etiqueta del botón sea clara y guía a las personas usuarias de vuelta a los resultados después de pulsarlo.
La consistencia aquí es muy importante.


5. Ordenación: deja siempre claro el orden actual

La ordenación solo cambia “el orden en que se muestran los resultados”, pero eso puede afectar enormemente el significado de los resultados de búsqueda.
Por eso el orden actual debe comunicarse de forma explícita.

5.1 Un cuadro de selección es la opción más segura

<label for="sort">Sort</label>
<select id="sort" name="sort">
  <option value="relevance">Recommended</option>
  <option value="newest">Newest first</option>
  <option value="oldest">Oldest first</option>
  <option value="price-low">Lowest price first</option>
  <option value="price-high">Highest price first</option>
</select>

5.2 Precauciones al usar un grupo de botones

Algunas UI de ordenación usan una apariencia parecida a pestañas, pero si el estado seleccionado no es claro, resultan difíciles de entender tanto visualmente como mediante lectores de pantalla.
Si usas un grupo de botones, entonces:

  • indica claramente el valor actual también en texto,
  • aplica aria-pressed o aria-current con cuidado, y
  • evita mostrar la misma opción de ordenación en varios lugares.

En general, un elemento select es más robusto.


6. Autocompletado y sugerencias: conveniente, pero la UI más frágil

Una UI que muestra sugerencias mientras las personas escriben en la caja de búsqueda es muy conveniente. Pero desde la perspectiva de la accesibilidad, este también es el lugar donde ocurren más accidentes.

6.1 Problemas comunes

  • Las sugerencias se expanden repentinamente mientras alguien escribe, causando sorpresa
  • Las flechas no funcionan para seleccionar
  • Pulsar Enter confirma una sugerencia en lugar de ejecutar la búsqueda
  • Los lectores de pantalla no pueden saber cuántas sugerencias hay disponibles
  • Las sugerencias pueden pulsarse con el ratón, pero no pueden alcanzarse con el teclado

6.2 Prácticas más seguras para implementaciones reales

Construir una UI personalizada de sugerencias es bastante difícil, así que usar una librería madura o una implementación casi nativa es más seguro.
Si aun así necesitas construir la tuya, sigue estas reglas:

  • Haz explícita la relación entre el campo de entrada y la lista de sugerencias
  • Anuncia los cambios en el número de sugerencias mediante status
  • Usa las flechas para desplazarte por las sugerencias, Enter para confirmar y Esc para cerrar
  • La búsqueda debe seguir siendo posible incluso cuando no haya sugerencias
  • No hagas que la búsqueda dependa de las sugerencias (las personas usuarias deben poder enviar la búsqueda sin seleccionar una)

6.3 Mantén las sugerencias como “apoyo”

El autocompletado es útil, pero no es el núcleo de la búsqueda.
Evita diseños en los que las personas usuarias no puedan avanzar a menos que elijan una sugerencia.


7. Accesibilidad cuando no hay resultados: evita crear un callejón sin salida

Cuando una búsqueda no devuelve resultados, no mostrar nada crea una de las experiencias más duras. En accesibilidad, el momento de cero resultados es exactamente cuando hay que ofrecer un siguiente paso.

7.1 Un buen patrón para mensajes de cero resultados

  • Explica qué ocurrió
  • Explica qué puede probar la persona usuaria a continuación
  • Proporciona una ruta alternativa

Ejemplo:

“No hubo resultados para ‘herramientas gratuitas de verificación de accesibilidad’. Intenta buscar con otras palabras o navega desde la categoría ‘Accesibilidad’.”

7.2 Rutas alternativas eficaces

  • Sugerencias de redacción alternativa
  • Palabras clave populares
  • Lista de categorías
  • Enlace de contacto
  • Páginas visitadas con frecuencia

Diseñar bien el caso de cero resultados se vuelve mucho más fácil si se piensa en él no como un fallo, sino como un momento para compensar una guía insuficiente.


8. UI de filtrado en móvil: precauciones para hojas y modales

En smartphones, los filtros suelen colocarse en paneles fuera de pantalla o en bottom sheets. Los problemas comunes aquí incluyen abrir un modal y luego:

  • el foco no se mueve dentro de él,
  • Tab escapa al fondo,
  • las personas usuarias no pueden volver al lugar en el que estaban al cerrarlo, o
  • después de aplicar filtros, no pueden saber dónde quedaron los resultados.

8.1 Aspectos básicos de una hoja de filtros

  • Al abrirse, mueve el foco al primer elemento interactivo
  • Permite cerrarla con Esc o con un botón “Cerrar”
  • Devuelve el foco al disparador cuando se cierre
  • Después de aplicar filtros, mueve el foco al encabezado de resultados, o anuncia el recuento mediante status

8.2 Una visualización que deje claro que “hay filtros activos”

En móvil, una vez que la pantalla se cierra, es fácil perder de vista las condiciones activas.
Mostrar un resumen de texto encima de la lista, como:

  • “Filtros activos: 2 categorías, 1 filtro de precio”
    resulta muy útil.

9. Errores comunes y soluciones

Error ¿Qué ocurre? Solución
La caja de búsqueda es solo un ícono de lupa Las personas usuarias no pueden saber para qué sirve el campo Añadir una etiqueta visible
El recuento de resultados se muestra solo mediante una imagen o color Las personas usuarias no pueden entender el estado Mostrar el recuento en texto
Los grupos de filtros no tienen encabezado Las personas usuarias no pueden saber para qué sirve cada condición Usar fieldset + legend
La ordenación es solo con íconos El valor actual no queda claro Usar un select con etiqueta
Las sugerencias se confirman automáticamente Provoca acciones no deseadas Separar claramente el significado de Enter
Cero resultados sin orientación Crea un callejón sin salida Mostrar alternativas, categorías y rutas populares
El filtro móvil no puede cerrarse Se vuelve inutilizable Proporcionar Cerrar, Esc y retorno del foco

10. Prueba rápida de cinco minutos: comprobaciones mínimas para UI de búsqueda

  1. El formulario de búsqueda tiene una etiqueta visible
  2. Buscar → revisar resultados → filtrar → ordenar puede completarse usando solo el teclado
  3. El recuento de resultados se muestra como texto
  4. Después de cambiar condiciones, las personas usuarias pueden saber qué cambió (recuento / visualización de condiciones / anuncio)
  5. Los grupos de filtros tienen encabezados (fieldset / legend)
  6. El valor actual de ordenación está claro
  7. Hay una ruta alternativa cuando no hay resultados
  8. En la hoja de filtros móvil, el foco no se pierde
  9. La búsqueda sigue funcionando aunque el autocompletado no esté disponible

11. Valor concreto para el público objetivo

  • Usuarios de lectores de pantalla: los campos de búsqueda, recuentos de resultados y estados de filtrado se vuelven más claros, facilitando mucho la exploración.
  • Usuarios de teclado: el filtrado y la ordenación pueden completarse solo con Tab, reduciendo la confusión.
  • Personas con diferencias cognitivas: la información clara del estado actual y las rutas alternativas cuando no hay resultados reducen la sensación de quedar atrapadas.
  • Personas mayores y usuarios móviles: controles más grandes, redacción más clara e indicaciones explícitas del estado reducen errores.
  • Equipos de operaciones: mejores rutas de búsqueda reducen consultas y abandonos, y ayudan a aprovechar más eficazmente los activos de contenido existentes.

12. Evaluación del nivel de accesibilidad (lo que este artículo pretende lograr)

  • Principales criterios de conformidad WCAG 2.1 AA relacionados
    • 1.3.1 Información y relaciones: formularios de búsqueda, grupos de filtros, estructura de resultados
    • 2.1.1 Teclado: búsqueda completa, filtrado, navegación por sugerencias y aplicación mediante teclado
    • 2.4.3 Orden del foco / 2.4.6 Encabezados y etiquetas: ubicación actual y etiquetado claros
    • 3.2.2 Al recibir entradas: evitar cambios inesperados al hacer selecciones
    • 3.3.2 Etiquetas o instrucciones: pistas de búsqueda, explicaciones de filtros
    • 4.1.2 Nombre, función, valor: listas de sugerencias, anuncios de estado, estados de selección expuestos
  • Mejorar la UI de búsqueda no es solo una cuestión de conformidad AA, sino también una medida práctica que mejora significativamente la capacidad de encontrar información y las tasas de finalización de tareas.

13. Conclusión: la accesibilidad de la búsqueda apoya la libertad de encontrar cosas

  1. Da al campo de búsqueda una etiqueta visible para que cualquier persona pueda entender el punto de entrada.
  2. Presenta claramente en texto el recuento de resultados, las condiciones y el orden para que no se pasen por alto los cambios de estado.
  3. Organiza los filtros con fieldset y legend, y haz que sean totalmente operables con teclado.
  4. Mantén el autocompletado solo como ayuda y no hagas que las personas usuarias dependan de las sugerencias.
  5. Cuando no haya resultados, ayuda a la recuperación mediante redacciones alternativas, categorías y rutas populares.
  6. Diseña la UI de filtros en móvil hasta el nivel de la gestión del foco y el retorno a los resultados.

La búsqueda es una herramienta para las personas que se pierden.
Precisamente por eso es tan importante que esa herramienta sea fácil de usar para todo el mundo.
Espero sinceramente que tu sitio o servicio se convierta en un lugar que dé a las personas la tranquilidad de pensar: “si busco, puedo encontrarlo”.

Salir de la versión móvil