Password field eye icon behaviour

[aweell]

Traslado aquí un resumen de la propuesta del equipo de TU Wallet:

Nos hemos dado cuenta que este componente no sigue el comportamiento natural, dado que el comportamiento natural debería ser este:

Os hacía esta propuesta dado que en las aplicaciones más populares este componente se comporta al revés. Considerando por ello, un comportamiento con el que está familiarizado el usuario y más natural.

Adjunto como ejemplo una captura de Instagram y Tiktok donde:
La password se muestra oculta, el icono es ojo tachado.
La password está visible, el icono es ojo abierto.
Y el estado default de este componente es ojo cerrado.

[aweell]

El dilema mostrar el estado vs mostrar la acción que va a realizar el usuario en su máxima expresión.

Podemos encontrar ejemplos que apunten también en la otra dirección en los login de aplicaciones ampliamente usadas, como puede ser google. Incluso Edge (El navegador de Microsoft lo provee nativamente en sus inputs type="password")

Partiendo de que lo ideal sería utilizar un elemento de texto que indique la acción a realizar. Si planteamos ese escenario:

• Cuando la contraseña está oculta, el texto de la acción debería leer "Mostrar"
• Cuando la contraseña sea visible, el texto de la acción debería leer "Ocultar"

Si el icono fuera junto con esta acción textual, tal y como está ahora ese icono se alinearía con el texto de la acción. Si simplificamos y eliminamos ese texto, es lo que nos encontramos en la implementación actual.

En otros casos, puede interesar no tanto mostrar la acción a realizar sino el estado del elemento. Por poner un ejemplo que todos podamos conocer de cerca: Las capas de Figma presentan, al hacer hover sobre ellas, su estado, es decir, si están bloqueadas o visibles.

Aquí podemos debatir si a nivel de diseño la prioridad es que el usuario entienda de un vistazo en qué estado está la capa vs las acciones disponibles. Diría que en el caso de Figma es lo primero. Pero y en el caso de un password Field?

Un mantra del diseño de experiencia con formularios es que cualquier contraseña debe estar enmascarada por defecto (safety reasons) por lo que por defecto, el modelo mental del usuario ya contempla el estado de una password por defecto como enmascarado, por lo que la acción del toggle adyacente va a hacer lo contrario a mi estado por defecto (independientemente del icono que el diseñador haya decidido pintar ahí).

Dicho esto, podemos realmente considerar más natural el comportamiento de las apps que compartes?

Realmente podría considerarse "mas natural" cualquiera de los dos escenarios, dependiendo de si la óptica desde la que se mira es que simboliza un estado o por el contrario simboliza una acción.

Para evitar generar ambiguedades sobre lo que simboliza el icono, lo correcto aquí es utilizar un texto.

[philipthird]

Buenas @aweell,
Siguiendo esta conversación, ¿consideráis que el comportamiento natural es como aparece actualmente en Mistica?
Más que una acción, es un icono indicativo de si la password está abierta o cerrada. En el ejemplo que comentabas de Google, no se resuelve con un ojo abierto o cerrado, sino con un check.

En casi todos los ejemplos que hemos visto, el icono del ojo cerrado indica password oculta y está por defecto en el input,
Si genera confusión el icono, podemos incluir texto como hace Airbnb. Quizá incluso sea mejore la accesibilidad.

[aweell]

Buenas @philipthird,

Técnicamente ahora mismo es una acción, es un elemento interactivo (botón) a través del cual el usuario puede modificar el estado de la mascara del valor del input. De hecho, para las tecnologías asistivas, ese elemento describe lo que va a ocurrir al interactuar con el: "Mostrar contraseña" / "Ocultar contraseña"

Si nos ceñimos a lo puramente técnico, si uso un botón, el estado debería describirse en otro elemento no interactivo, de manera que tengo información de los dos. Por un lado un elemento de texto que me indica el estado actual del valor del input (está enmascarado / no está enmascarado) y por otro una acción que me permite modificar ese estado (Enmascarar valor / Desenmascarar valor). Podemos asumir en este caso que los usuarios videntes tienen un feedback directo del estado del input mediante el valor del mismo (Si aparecen asteriscos el estado es enmascarado y si veo mi password, no lo está)

El caso que pasas con el checkbox puede resolver los dos a la vez ya que comunica el estado y el usuario entiende que al interactuar con el va a modificarlo. En tu ejemplo la acción la define Mostrar contraseña y el estado lo controla internamente el checkbox indicándole al usuario si esta checked o unchecked.

Existe la posibilidad de que un botón se comporte semánticamente como un checkbox, utilizando aria-pressed, sin embargo, en la propia documentación del atributo añaden lo siguiente:

The first rule of ARIA use is "if you can use a native feature with the semantics and behavior you require already built in, instead of repurposing an element and adding an ARIA role, state or property to make it accessible, then do so." If we employ native HTML semantics with , we can toggle the label instead of toggling the pressed state, removing the need for the aria-pressed attribute.

Esto es precisamente lo que estamos haciendo actualmente en el componente, hacemos un toggle de la label a las tecnologías asistivas para que cambie "Mostrar" u "Ocultar" en función del estado de la máscara.

Como comenté anteriormente, para evitar ambigüedades sobre si visualmente ese icono debería representar el estado o la acción que desencadena interactuar con el botón. La evolución debería ser utilizar un texto.

Ahora bien, utilizar un texto plantea otro problemas tanto a nivel de diseño y usabilidad que habría que tener en cuenta, dado que los campos de contraseña suelen tener un mínimo de caracteres requeridos, dependiendo de el espacio disponible, las preferencias de tamaño de texto del usuario o el idioma, puede generar ellipsis en el valor del campo, lo que definitivamente no es deseado.

Como conclusión del análisis podríamos resumir:

• Si se usa un botón, mantenerlo como el actual
• Si se usa un checkbox, el estado es interno pero la ubicación del checkbox se solapa con otros elementos como texto de ayuda o error, supone replantear esto no solo para el password sino para otros controles que puedan tener acciones parecidas en el trailing icon.
• Si se usa un texto, evita la ambiguedad, pero genera otros problemas como que se genere ellipsis en el texto, dependiendo del espacio disponible, las preferencias de tamaño de texto del usuario o el idioma del locale.

La preguntas que nos surgen después del análisis son las siguientes:

• Que motiva a abrir esta discussion en primer lugar? Existe actualmente algún indicio de que los usuarios no están entendiendo el propósito del botón?
• Que la representación del icono es el desencadenante de esta confusión es una hipótesis o tenemos datos que puedan justificar este cambio en el componente?