Lograr un equilibrio entre elementos seleccionados nativos y personalizados.

¡Aquí está el plan! Vamos a construir un elemento de selección con estilo. No sólo el exterior, sino también el interior. Control total del peinado. Además vamos a hacerlo accesible. No vamos a intentar replicar todo lo que hace el navegador por defecto con un selectelemento nativo. Literalmente vamos a utilizar un selectelemento cuando se utiliza cualquier tecnología de asistencia. Pero cuando se utiliza un mouse, mostraremos la versión con estilo y la haremos funcionar como un elemento de selección.

Eso es lo que quiero decir con selecciones “híbridas”: son tanto una selectselección nativa como una alternativa con estilo en un patrón de diseño.

Seleccionar, menú desplegable, navegación, menú… el nombre importa

Mientras investigaba para este artículo, pensé en muchos nombres que se mencionan cuando se habla de selecciones, los más comunes son “desplegable” y “menú”. Hay dos tipos de errores de nomenclatura que podemos cometer: dar el mismo nombre a cosas diferentes, o dar nombres diferentes a la misma cosa. Un seleccionado puede sufrir ambos errores.

Antes de continuar, permítanme intentar aclarar el uso de “menú desplegable” como término. Así es como define el significado del menú desplegable:

Menú desplegable: un componente interactivo que consta de un botón que muestra y oculta una lista de elementos, generalmente al pasar el mouse, hacer clic o tocar. La lista no es visible de forma predeterminada hasta que comienza la interacción. La lista normalmente muestra un bloque de contenido (es decir, opciones) encima de otro contenido.

Muchas interfaces pueden aparecer en un menú desplegable. Pero simplemente llamar a un elemento “menú desplegable” es como usar “pez” para describir un animal. ¿Qué tipo de pez es? No es lo mismo un pez payaso que un tiburón. Lo mismo ocurre con los menús desplegables.

Al igual que hay diferentes tipos de peces en el mar, hay diferentes tipos de componentes de los que podríamos estar hablando cuando usamos la palabra “desplegable”:

• Menú: una lista de comandos o acciones que el usuario puede realizar dentro del contenido de la página.
• Navegación: una lista de enlaces utilizados para navegar a través de un sitio web.
• Seleccionar: un control de formulario ( select) que muestra una lista de opciones para que el usuario seleccione dentro de un formulario.

Decidir de qué tipo de menú desplegable estamos hablando puede ser una tarea confusa. Aquí hay algunos ejemplos de toda la web que coinciden con cómo clasificaría esos tres tipos diferentes. Esto se basa en mi investigación y, a veces, cuando no puedo encontrar una respuesta adecuada, en la intuición basada en mi experiencia.

Etiqueta de diagrama	guion	Tipo desplegable
1	El menú desplegable espera que se envíe una opción seleccionada dentro de un contexto de formulario (por ejemplo, Seleccionar edad)	Seleccionar
2	El menú desplegable no necesita una opción activa (por ejemplo, una lista de acciones: copiar, pegar y cortar)	Menú
3	La opción seleccionada influye en el contenido. (por ejemplo, lista de clasificación)	Menú o Seleccionar (más sobre esto más adelante)
4	El menú desplegable contiene enlaces a otras páginas. (por ejemplo, un “meganav” con enlaces a sitios web)	Navegación de divulgación
5	El menú desplegable tiene contenido que no es una lista. (por ejemplo, un selector de fechas)	Algo más que no debería llamarse menú desplegable

No todo el mundo percibe e interactúa con Internet de la misma manera. Nombrar interfaces de usuario y definir patrones de diseño es un proceso fundamental, aunque con mucho espacio para la interpretación personal. Toda esa variación es lo que impulsa la población de las tierras desplegables.

Hay un tipo desplegable que es claramente un menú. Su uso es un tema candente en las conversaciones sobre accesibilidad. No hablaré mucho sobre esto aquí, pero permítanme enfatizar que el menuelemento está en desuso y ya no se recomienda. Y aquí hay una explicación detallada sobre los menús incluidos y los botones de menú, incluido por qué la función de menú ARIA no debe usarse para la navegación del sitio.

Ni siquiera hemos tocado otros elementos que caen en un área bastante gris que hace que la clasificación de los menús desplegables sea aún más confusa debido a la falta de casos de usos prácticos de la comunidad WCAG.

Uff... eso fue mucho. Olvidémonos de este número de menús desplegables y centrémonos exclusivamente en el tipo de menú desplegable que es claramente un selectelemento.

Vamos a hablar acerca deselect

Diseñar controles de formulario es un viaje interesante. Como dice MDN, está lo bueno, lo malo y lo feo. Lo bueno son cosas como formlas que son solo un elemento a nivel de bloque al que darle estilo. Lo malo son cosas como casillas de verificación, que se pueden hacer pero son algo engorrosas. selectDefinitivamente está en un terreno feo.

Se han escrito muchos artículos al respecto e, incluso en 2020, sigue siendo un desafío crear selecciones personalizadas y algunos usuarios todavía prefieren las nativas simples.

Entre los desarrolladores, el selectcontrol de formulario es, con diferencia, el más frustrante, principalmente debido a su falta de compatibilidad con estilos. La lucha de UX detrás de esto es tan grande que buscamos otras alternativas. Bueno, supongo que la primera regla selectes similar a ARIA: evita usarlo si puedes.

Podría terminar el artículo aquí mismo con "No usar select, punto". Pero seamos realistas: un select sigue siendo nuestra mejor solución en diversas circunstancias. Eso podría incluir escenarios en los que trabajamos con una lista que contiene muchas opciones, diseños con poco espacio o simplemente falta de tiempo o presupuesto para diseñar e implementar un excelente componente interactivo personalizado desde cero.

selectRequisitos personalizados

Cuando tomamos la decisión de crear una selección personalizada, incluso si es “simple”, estos son los requisitos con los que generalmente tenemos que trabajar:

• Hay un botón que contiene la opción seleccionada actualmente.
• Al hacer clic en el cuadro se alterna la visibilidad de la lista de opciones (también llamada cuadro de lista).
• Al hacer clic en una opción en el cuadro de lista se actualiza el valor seleccionado. El texto del botón cambia y el cuadro de lista se cierra.
• Al hacer clic fuera del componente se cierra el cuadro de lista.
• El disparador contiene un pequeño icono de triángulo que apunta hacia abajo para indicar que hay opciones.

Algo como esto:

Algunos de ustedes pueden estar pensando que esto funciona y que está listo. Pero espera… ¿funciona para todos? No todo el mundo utiliza un ratón (o una pantalla táctil). Además, un elemento nativo selectviene con más funciones que obtenemos de forma gratuita y no están incluidas en esos requisitos, como por ejemplo:

• La opción marcada es perceptible por todos los usuarios independientemente de sus capacidades visuales.
• El componente puede interactuar con un teclado de forma predecible en todos los navegadores (por ejemplo, usando teclas de flecha para navegar, Enterseleccionar, Esccancelar, etc.).
• Las tecnologías de asistencia (por ejemplo, lectores de pantalla) anuncian claramente el elemento a los usuarios, incluida su función, nombre y estado.
• Se ajusta la posición del cuadro de lista. (es decir, no se corta de la pantalla).
• El elemento respeta las preferencias del sistema operativo del usuario (por ejemplo, alto contraste, combinación de colores, movimiento, etc.).

Aquí es donde la mayoría de las selecciones personalizadas fallan de alguna manera. Eche un vistazo a algunas de las principales bibliotecas de componentes de la interfaz de usuario. No mencionaré ninguno porque la web es efímera, pero pruébalo. Probablemente notarás que el componente seleccionado en un marco se comporta de manera diferente a otro.

Aquí hay características adicionales a tener en cuenta:

• ¿Se activa inmediatamente una opción de cuadro de lista al navegar con un teclado?
• ¿Puedes usar Entery/o Spaceseleccionar una opción?
• ¿La Tabtecla salta a la siguiente opción en el cuadro de lista o salta al siguiente control de formulario?
• ¿Qué sucede cuando llegas a la última opción en el cuadro de lista usando las teclas de flecha? ¿Simplemente permanece en el último elemento, vuelve a la primera opción o, lo peor de todo, el foco pasa al siguiente control de formulario?
• ¿Es posible saltar directamente al último elemento del cuadro de lista usando la Page Downtecla?
• ¿Es posible desplazarse por los elementos del cuadro de lista si hay más de los que están actualmente a la vista?

Esta es una pequeña muestra de las características incluidas en un selectelemento nativo.

Una vez que decidimos crear nuestra propia selección personalizada, obligamos a las personas a usarla de una manera determinada que puede no ser la que esperan.

Pero se pone peor. Incluso el nativo selectse comporta de manera diferente entre navegadores y lectores de pantalla. Una vez que decidimos crear nuestra propia selección personalizada, obligamos a las personas a usarla de una manera determinada que puede no ser la que esperan. Esa es una decisión peligrosa y es en esos detalles donde vive el diablo.

Construyendo una selección “híbrida”

Cuando creamos una selección personalizada simple, estamos haciendo una compensación sin darnos cuenta. En concreto, sacrificamos la funcionalidad a la estética. Debería ser de otra manera.

¿Qué pasa si, en cambio, entregamos una selección nativa de forma predeterminada y la reemplazamos por una más agradable desde el punto de vista estético, si es posible? Ahí es donde entra en acción la idea de selección “híbrida”. Es “híbrido” porque consta de dos selecciones, mostrando la adecuada en el momento adecuado:

• Una selección nativa, visible y accesible por defecto
• Una selección personalizada, oculta hasta que sea seguro interactuar con un mouse

Comencemos con el marcado. Primero, agregaremos un nativo selectcon optionelementos antes del selector personalizado para que esto funcione. (Explicaré por qué en un momento).

Cualquier control de formulario debe tener una etiqueta descriptiva. Podríamos usar label, pero eso enfocaría la selección nativa cuando se hace clic en la etiqueta. Para evitar ese comportamiento, usaremos a spany lo conectaremos al select usando aria-labelledby.

Finalmente, debemos decirle a Assistive Technologies que ignore la selección personalizada, usando aria-hidden="true". De esa manera, solo anuncian la selección nativa, pase lo que pase.

spanMain job role/spandiv  select aria-labelledby="jobLabel"    !-- options --    option/option  /select  div aria-hidden="true"     !-- The beautiful custom select --  /div/div    

Esto nos lleva al estilo, donde no sólo hacemos que las cosas se vean bonitas, sino que también manejamos el cambio de una selección a otra. Sólo necesitamos unas cuantas declaraciones nuevas para que suceda toda la magia.

Primero, tanto las selecciones nativas como las personalizadas deben tener el mismo ancho y alto. Esto garantiza que las personas no vean diferencias importantes en el diseño cuando ocurre un cambio.

.selectNative,.selectCustom {  position: relative;  width: 22rem;  height: 4rem;}

Hay dos selecciones, pero sólo una puede dictar el espacio que las contiene. El otro debe estar absolutamente posicionado para sacarlo del flujo de documentos. Hagámoslo con la selección personalizada porque es el "reemplazo" que se usa sólo si puede serlo. Lo ocultaremos de forma predeterminada para que nadie pueda acceder a él todavía.

.selectCustom {  position: absolute;  top: 0;  left: 0;  display: none;}

Aquí viene la parte "divertida". Necesitamos detectar si alguien está usando un dispositivo en el que el desplazamiento es parte de la entrada principal, como una computadora con un mouse. Si bien normalmente pensamos en consultas de medios para puntos de interrupción receptivos o verificar la compatibilidad con funciones, también podemos usarlo para detectar la compatibilidad con el desplazamiento mediante @media query (hover :hover), que es compatible con todos los principales navegadores. Entonces, usémoslo para mostrar la selección personalizada solo en dispositivos que tienen el desplazamiento:

@media (hover: hover) {  .selectCustom {    display: block;  }}

Genial, pero ¿qué pasa con las personas que usan un teclado para navegar incluso en dispositivos con función flotante? Lo que haremos es ocultar la selección personalizada cuando la selección nativa esté enfocada. Podemos alcanzar una combinación de hermanos adyacente ( +). Cuando la selección nativa esté enfocada, oculte la selección personalizada junto a ella en el orden DOM. (Es por eso que la selección nativa debe colocarse antes de la personalizada).

@media (hover: hover) {  .selectNative:focus + .selectCustom {    display: none;  }}

¡Eso es todo! ¡El truco para cambiar entre ambas selecciones está hecho! Hay otras formas CSS de hacerlo, por supuesto, pero esta funciona muy bien.

Por último, necesitamos una pizca de JavaScript. Agreguemos algunos detectores de eventos:

• Uno para eventos de clic que activan la selección personalizada para abrir y revelar las opciones
• Uno para sincronizar ambos valores seleccionados. Cuando se cambia un valor de selección, el otro valor de selección también se actualiza
• Uno para los controles básicos de navegación del teclado, como navegación con las teclas Upy Down, selección de opciones con las teclas Entero Spacey cierre de selección conEsc

Pruebas de usabilidad

Realicé una prueba de usabilidad muy pequeña en la que pedí a algunas personas con discapacidades que probaran el componente de selección híbrida. Se probaron los siguientes dispositivos y herramientas utilizando las últimas versiones de Chrome (81), Firefox (76) y Safari (13):

• Dispositivo de escritorio que usa solo mouse
• Dispositivo de escritorio que usa solo teclado
• VoiceOver en MacOS usando el teclado
• NVDA en Windows usando el teclado
• VoiceOver en iPhone y iPad usando Safari

Todas estas pruebas funcionaron como se esperaba, pero creo que esto podría incluir aún más pruebas de usabilidad con personas y herramientas más diversas . Si tiene acceso a otros dispositivos o herramientas, como JAWS, Dragon, etc., cuénteme cómo va la prueba.

Se encontró un problema durante la prueba. Específicamente, el problema estaba en la configuración de VoiceOver "Puntero del mouse: mueve el cursor de VoiceOver". Si el usuario abre la selección con un mouse, se abrirá la selección personalizada (en lugar de la nativa) y el usuario no experimentará la selección nativa.

Lo que más me gusta de este enfoque es cómo utiliza lo mejor de ambos mundos sin comprometer la funcionalidad principal:

• Los usuarios de dispositivos móviles y tabletas obtienen la selección nativa, que generalmente ofrece una mejor experiencia de usuario que una selección personalizada, incluidos beneficios de rendimiento.
• Los usuarios del teclado pueden interactuar con la selección nativa de la forma que esperarían.
• Las tecnologías de asistencia pueden interactuar con la selección nativa como de costumbre.
• Los usuarios del mouse pueden interactuar con la selección personalizada mejorada.

Este enfoque proporciona una funcionalidad nativa esencial para todos sin el enorme esfuerzo de código adicional para implementar todas las características nativas.

No me malinterpretes. Esta técnica no es una solución única para todos. Puede funcionar para selecciones simples, pero probablemente no funcione para casos que impliquen interacciones complejas. En esos casos, necesitaríamos usar ARIA y JavaScript para complementar los espacios y crear una selección personalizada verdaderamente accesible.

Una nota sobre selecciones que parecen menús

Echemos un vistazo al tercer escenario de Dropdown-land. Si recuerdas, es un menú desplegable que siempre tiene una opción marcada (por ejemplo, ordenar algún contenido). Lo clasifiqué en el área gris, ya sea como menú o selección.

Esta es mi línea de pensamiento: hace años, este tipo de menú desplegable se implementaba principalmente mediante un archivo select. Hoy en día es común verlo implementado desde cero con estilos personalizados (accesibles o no). Lo que terminamos con un elemento de selección que parece un menú.

A selectes un tipo de menú. Ambos tienen una semántica y un comportamiento similares, especialmente en un escenario que involucra una lista de opciones donde siempre hay una marcada. Ahora, permítanme mencionar el criterio WCAG 3.2.2 Sobre entrada (Nivel A):

Cambiar la configuración de cualquier componente de la interfaz de usuario no debería causar automáticamente un cambio de contexto a menos que se haya informado al usuario sobre el comportamiento antes de usar el componente.

Pongamos esto en práctica. Imagine una lista ordenable de estudiantes. Visualmente, puede resultar obvio que la clasificación es inmediata, pero eso no es necesariamente cierto para todos. Entonces, al usar select, corremos el riesgo de no cumplir con las pautas WCAG porque el contenido de la página cambió y reorganizar significativamente el contenido de una página se considera un cambio de contexto.

Para asegurar el éxito del criterio, debemos advertir al usuario sobre la acción antes de interactuar con el elemento, o incluir un buttoninmediatamente después de la selección para confirmar el cambio.

label for="sortStudents"  Sort students  !-- Warn the user about the change when a confirmation button is not present. --  span(Immediate effect upon selection)/span/labelselect ... /select

Dicho esto, usar selecto crear un menú personalizado son buenos enfoques cuando se trata de menús simples que cambian el contenido de la página. Sólo recuerde que su decisión dictará la cantidad de trabajo necesario para que el componente sea totalmente accesible. Este es un escenario en el que se podría utilizar el enfoque de selección híbrida.

Ultimas palabras

Toda esta idea comenzó como un inocente truco de CSS pero, después de toda esta investigación, recordé una vez más que crear experiencias únicas sin comprometer la accesibilidad no es una tarea fácil.

Crear componentes seleccionados realmente accesibles (o cualquier tipo de menú desplegable) es más difícil de lo que parece. Las WCAG proporcionan una excelente orientación y mejores prácticas, pero sin ejemplos específicos y diversos casos de uso práctico, las directrices son en su mayoría aspiracionales. Eso sin mencionar el hecho de que el soporte de ARIA es tibio y que selectlos elementos nativos se ven y se comportan de manera diferente en todos los navegadores.

La selección "híbrida" es solo otro intento de crear una selección atractiva y al mismo tiempo obtener tantas funciones nativas como sea posible. No mire este experimento técnico como una excusa para restar importancia a la accesibilidad, sino más bien como un intento de servir a ambos mundos. Si tiene los recursos, el tiempo y las habilidades necesarias, hágalo bien y asegúrese de probarlo con diferentes usuarios antes de enviar su componente al mundo.

PD: Recuerde utilizar un nombre propio al crear un componente "desplegable".