Range Slider

El slider es un control de exploración, no de precisión. Cuando el usuario tiene un valor exacto en mente (por ejemplo "quiero exactamente $1,450") un campo de texto es más rápido y menos frustrante que buscar el píxel donde el handle coincide con ese número. El slider brilla cuando el usuario quiere explorar un rango sin un número fijo en la cabeza: ajustar volumen, filtrar precios de forma aproximada, acotar fechas. La regla de oro: si el usuario podría teclear el valor en menos tiempo del que le toma arrastrarlo, usa input. USWDS y NN/G coinciden en que el rango y el valor relativo deben importar más que la exactitud para justificar un slider.

Baymard es categórico: los sliders que controlan valores numéricos de filtrado deben ir siempre acompañados de campos de texto que actúen como fallback. El usuario explora con el slider y afina con el input, y el input también es la única vía para llegar a un valor exacto cuando el slider no lo permite. La combinación slider + input es el único patrón que satisface a la vez exploración y precisión: el slider para ajuste grueso, el campo de texto para control fino. Los dos inputs deben reflejar en tiempo real lo que se arrastra y permitir edición directa que mueva los handles.

En las pruebas de usabilidad de Baymard (18 sitios de e-commerce), más de la mitad de los sujetos malinterpretaron los dual-point range sliders, operándolos como si fueran un slider de un solo valor: movían el handle equivocado o creían que solo seleccionaban un máximo. Un participante textual: "Minimum?! No. Argh, this is freaking difficult." La solución no es asumir que la convención es conocida sino explicitarla: resaltar con color el track entre los dos handles, diferenciar visualmente cada handle, y añadir una etiqueta clara como "Mín $200 – Máx $800". Smashing recomienda flechas en los handles para reforzar que cada uno se mueve independientemente.

El handle visual de un slider puede ser pequeño (16–20 px de diámetro) pero su área interactiva real, incluyendo padding invisible, debe cumplir los umbrales WCAG. El criterio 2.5.8 Target Size (Minimum, AA, obligatorio desde WCAG 2.2) exige 24×24 CSS px; el 2.5.5 Target Size (Enhanced, AAA) eleva el mínimo a 44×44 CSS px. Material Design 3 recomienda 48 dp para el thumb en Android. La técnica práctica es agregar un pseudo-elemento invisible o padding alrededor del handle para alcanzar el área táctil objetivo sin alterar el tamaño visual del thumb. Un handle de 12 px sin expansión es imposible de usar con el pulgar o con temblor en las manos.

Un range slider dual accesible no es un solo widget sino dos elementos focusables independientes, cada uno con role="slider". El patrón Multi-Thumb de WAI-ARIA APG exige que cada thumb declare aria-valuenow (valor actual), aria-valuemin y aria-valuemax (rango permitido), más una etiqueta vía aria-label. Cuando el valor no es intuitivo numéricamente (fechas, tallas, monedas) aria-valuetext aporta la cadena legible ("$120" en vez de "120"). Para handles dependientes, donde el mínimo del handle máximo es el valor del handle mínimo, el aria-valuemin y aria-valuemax de los sliders dependientes deben actualizarse al cambiar el otro. Omitir cualquier atributo vuelve el control opaco para lectores de pantalla.

<div
  role="slider"
  aria-label="Precio mínimo"
  aria-valuemin="0"
  aria-valuemax="800"
  aria-valuenow="120"
  aria-valuetext="$120"
  tabindex="0"
></div>

<div
  class="slider-handle"
  style="left: 15%"
></div>

// Sin role, sin aria-valuenow,
// sin min/max: el lector de
// pantalla no anuncia nada.

Un slider que solo responde a clic y arrastre es inaccesible para usuarios de teclado. El patrón Slider de WAI-ARIA APG define el modelo de interacción completo: las flechas Arriba/Derecha aumentan un paso, Abajo/Izquierda lo disminuyen; Home y End saltan al primer y último valor permitidos; PageUp y PageDown (opcionales pero muy recomendados) hacen saltos grandes para rangos amplios. En dual-handle, Tab y Shift+Tab mueven el foco entre los dos handles, y el orden de tabulación permanece constante independientemente de la posición visual de cada handle dentro del slider. Implementar solo mousedown/touchstart bloquea por completo al usuario de teclado.

Un slider stepped sin ticks visibles es un slider continuo disfrazado: el usuario no sabe en qué valores puede detenerse. Los ticks deben aparecer bajo el track, con etiquetas solo en los valores clave (no en cada paso si son muchos) para que no se solapen en mobile. Smashing recomienda espaciar los ticks críticos al menos 65 px en todas las anchuras de pantalla, lo que permite acomodar unos 5 ticks legibles en los 400 px típicos de móvil; USWDS sugiere step="10" en un rango 0–100 para evitar precisión excesiva. Por encima del handle, o en un tooltip flotante, el valor actual debe actualizarse sin latencia perceptible durante el arrastre, nunca esperar al mouseup para revelarlo.

Cuando los valores se concentran en una fracción del rango, una escala lineal convierte gran parte del track en zona vacía. Baymard documentó que en sliders lineales el 50% del ancho llega a controlar apenas 2–5% de los productos disponibles, mientras un 5% del track abarca el 50% restante: el usuario arrastra centímetros para moverse $10, o no puede acertar el píxel exacto entre dos valores. La solución es una escala logarítmica, un histogram slider que muestra la distribución real de ítems (patrón de Airbnb), o una escala basada en inventario que divide los productos en intervalos de igual conteo. En cualquier caso, el rango mostrado en los inputs numéricos siempre debe reflejar valores reales, no posiciones de píxel.