Aprendizajes al desarrollar precios accesibles en Mercado Libre
El día de hoy, 19 de mayo, es el “Global Accessibility Awareness Day” (GAAD) por eso nos parece oportuno compartir los aprendizajes que tomamos para mejorar la accesibilidad en los productos que desarrollamos en Mercado Libre.
Los precios de los productos pueden ser accesibles, es decir asequibles, pero tienen que transmitirse correctamente. Inmersos en una cultura “user centricity”, buscamos mejorar la experiencia de navegación de las personas usuarias de nuestro sitio. Es por ello que nos embarcamos en el desafío de hacer los precios “accesibles” a lectores de pantalla, tecnología asistiva que representa el contenido de texto e imagen como salida de voz o braille. En Mercado Libre iniciamos un recorrido para mejorar la accesibilidad de los usuarios en nuestros productos, entendiendo que muchos de los obstáculos y barreras surgen a partir de la manera en que los desarrolladores de software pensamos, diseñamos y construimos los productos y servicios.
Un elemento transversal en las experiencias del usuario de Mercado Libre que mantiene su vigencia a lo largo del tiempo es el Precio, y en sus variadas versiones disponibles e implementaciones, detectamos que se anunciaba de manera poco comprensible y con valores inexactos a personas usuarias de lectores de pantalla.
Para generar interfaces que puedan ser comprensibles, perceptibles, operables y robustas, comenzamos a implementar mejoras de accesibilidad en nuestro Design System Andes, centrándonos en esta nota en un componente específico para web.
¿Cuáles fueron nuestros primeros pasos?
La idea principal fue entonces el desarrollo de un componente Precio, AKA MoneyAmount, que los equipos puedan adoptar, con sus diferentes variantes desde un enfoque único y consistente en Mercado Libre, que sumó grandes aprendizajes sobre tecnologías asistivas, navegadores, implementaciones y experiencias concretas.
Desafíos encontrados
Con este escenario iniciamos nuestro recorrido:
La verbalización través de los lectores de pantalla depende de varios factores:
- el navegador (agente de usuario) y su forma de exponer el árbol de accesibilidad,
- el sistema operativo,
- el lector de pantalla y su configuración,
- la voz utilizada (sintetizador). El mismo lector de pantalla, en el mismo sistema, operativo con el mismo navegador pero con diferentes voces puede leer el mismo texto de manera muy diferente,
- la sintaxis y formateo del código.
Encontramos concretamente los siguientes desafíos:
Saltos del foco en modo exploración de lectores de pantalla
Cuando el usuario recorre la región de precios, se producen diferentes saltos en la navegación secuencial, anunciando currency, valores y caracteres por separado, lo que resulta poco intuitivo e inconsistente.
Currency “$”
El símbolo currency “$” es verbalizado como dólares por el lector de pantalla, independientemente del idioma/región, generando inconsistencia con el país. El diccionario de pronunciación del lector de pantalla podría sustituir este comportamiento, pero no creemos que la solución deba depender del usuario.
Caracter separador enteros y decimales
Cada país o región da formato a las cifras de diferentes maneras con uso de caracteres separadores para enteros (con separador de millares) y decimales para así identificar la relación entre los dígitos de un mismo precio, por ejemplo, en México se separan los millares con coma, mientras que en Argentina se separan con punto.
Referencia: Separador de millares — Wikipedia, la enciclopedia libre
Precios anteriores y descuentos sin contexto
Generar contexto al usuario para reconocer la variación de un precio es fundamental en la toma de decisiones y esto no se anunciaba en absoluto.
¿Qué hicimos entonces?
Luego de hacer un análisis exhaustivo de la situación, comenzamos con una etapa de validación, para ello nos basamos en 3 pilares: especificaciones y estándares, validaciones de referentes en la temática y comprobaciones con personas usuarias de lectores de pantalla.
Especificaciones
En la documentación oficial de HTML y accesibilidad brindada por WHATWG y W3C WAI-ARIA obtuvimos información y prácticas de autores para diferentes componentes. Incluso sabiendo que estas recetas no son perfectas y no dan siempre las mejores experiencias a todas las personas usuarias, las capitalizamos como puntapié inicial del análisis.
Son fuentes de referencia necesaria que permiten validar la calidad de nuestro código y aunque sabiendo que el soporte de la especificación no es siempre estable, buscábamos ser precisos en nuestra implementación.
Validaciones técnicas
Queríamos lograr una solución robusta en la verbalización sabiendo que no había una solución general y era necesario no expresar un precio equivocado a personas usuarias de lectores de pantalla.
Primero hicimos pruebas con caracteres separadores y observamos resultados inestables según combinaciones de motores de voz (TTS) o configuración de puntuación en lectores de pantalla.
Referencias:
- * verbaliza sólo cifras a la izquierda del separador de centavos, ignorando las restantes
- “-” verbaliza cifra por cifra
- “ok” verbaliza cientos, miles, millones
- “S/s” sin separador
Luego, analizamos documentación de diferentes referentes en accesibilidad y documentación de soluciones aplicadas por equipos fuera de Mercado Libre, pero no encontramos implementaciones específicas para nuestro caso.
Documentos de equipos de accesibilidad:
Personas referentes:
Cabe destacar que los navegadores no dan siempre el soporte esperado a lectores de pantalla, aún siendo implementadas las especificaciones de accesibilidad generadas por WAI-ARIA, por eso es importante validar con Accessibility Support para encontrar una solución soportada en gran medida.
Experiencia de personas usuarias
Por último y no menos importante, las implementaciones que generamos necesitaban ser validadas por personas usuarias para poder identificar si la experiencia estaba siendo eficiente. Para ello nos apoyamos en organizaciones como Nahual IT e itgrarte fundación que nos ayudaron a reconocer puntos clave.
¿Cómo lo implementamos?
Para dar solución a los saltos del foco en modo exploración, currency “$” y caracter separador enteros y decimales lo primero que hicimos fue quitar de la navegación para usuarios de lectores de pantalla la representación del precio visual. Para ello utilizamos el atributo aria-hidden en el elemento contenedor. Este atributo ARIA nos permite ocultar un elemento del árbol de accesibilidad utilizado por las tecnologías asistivas para que lo ignoren.
Observaciones: El precio está compuesto por diferentes clases que permiten aplicar estilo a su presentación visual.
<div class="" aria-hidden="true">
<span class="currency">$</span>
<span class="fraction">22.999</span>
<span class="cents">08</span>
</div>Es importante aclarar que este atributo no debe ser utilizado en elementos enfocables por teclado o con tabindex=”0” dado que genera inconsistencia entre el foco con tecla TAB y el modo exploración de los lectores de pantalla que ignoraran al elemento.
Analizando los desafíos que tuvimos a la hora de encontrar una solución robusta y las pruebas realizadas, decidimos verbalizar el precio con el siguiente formato:
{entero} pesos con {decimales} centavos.
Siendo {entero} el número sin separador de millares, ejemplo: 10000 y {decimales} la cantidad de centavos.
Para lograr la verbalización específica al lector de pantalla, utilizamos una clase CSS Screen Reader Only que nos permite ocultar visualmente la expresión pero que es alcanzable en la navegación de estas tecnologías.
<style>
.sr-only {
border: 0;
clip: rect(0 0 0 0);
clip-path: inset(50%);
height: 1;
margin: 0 -1px -1px 0;
overflow: hidden;
padding: 0;
position: absolute;
width: 1;
}
</style>Quedando nuestro bloque de código finalmente así:
<div class="sr-only">22999 pesos con 08 centavos.</div>
<div class="" aria-hidden="true">
<span class="currency">$</span>
<span class="fraction">22.999</span>
<span class="separator">,</span>
<span class="cents">08</span>
</div>Disclaimer: Los lectores de pantalla no requieren ni necesitan, generalmente, el agregado de verbosidad al contenido textual, pero sí para nuestra implementación.
En algunas pruebas evaluadas se pensaba aplicar directamente el atributo aria-label para asignar un nombre programático al contenedor del precio:
<div class="" aria-label="22999 pesos con 08 centavos.">
<span class="currency">$</span>
<span class="fraction">22.999</span>
<span class="separator">,</span>
<span class="cents">08</span>
</div>Lo cual también es leído únicamente por lectores de pantalla pero la especificación ARIA nos indicaba que sólo se debe aplicar a elementos con roles implícitos o explícitos, desestimando esa implementación.
Con respecto al desafío de “Precios anteriores y descuentos sin contexto”, a fin de dar solución al enunciado de un precio actual y uno anterior, aplicamos el mismo enfoque para dar contexto en la diferenciación de precios agregando el texto “Antes” y a continuación el texto “Ahora” al precio actual.
Dado que la etiqueta nativa HTML <s> (texto tachado visualmente) no anuncia ninguna semántica a los lectores de pantalla, al menos en las pruebas realizadas y en la documentación validada, generamos este bloque de código:
<div class="sr-only">Antes: 24999 pesos.</div>
<s class=”” aria-hidden=”true”>
<span class="currency">$</span>
<span class="fraction">24.999</span>
</s><div class="sr-only">Ahora: 22999 pesos con 08 centavos.</div>
<div class="" aria-hidden="true">
<span class="currency">$</span>
<span class="fraction">22.999</span>
<span class="separator">,</span>
<span class="cents">08</span>
</div>
Éste es el resultado final de todo este recorrido:
Con esta implementación logramos una precisa pronunciación de precios, priorizando la sensibilidad del dato y no una solución para determinado lector de pantalla.
Aprendizajes
El contexto es fundamental para percibir la información y poder generar experiencias coherentes para todo el conjunto de usuarios. Entendemos que es importante prevenir que la información programática difiera de la información visual y para ello validamos comportamientos esperados con la experiencia de personas usuarias de tecnologías asistivas.
Descubrimos que las especificaciones difieren entre navegadores y lectores de pantalla, como también que el soporte y la adopción a nuevos o mejorados estándares no siempre van de la mano, además de que los navegadores compensan las malas implementaciones obligando a tomar decisiones poco robustas, es decir con soluciones que funcionan bien para algunos pero mal para otros.
Las prácticas de autor, enfoques o recetas no generan siempre buenas experiencias y es importante evaluar la consistencia dentro de nuestros productos pero también en los productos más utilizados del mercado.
A partir de todo este recorrido generamos conocimiento y experiencias que queremos compartir con la comunidad, como así también nosotros fuimos receptores de buenas prácticas generadas por otros productos.
De esta manera logramos complementarnos y actuar en sinergia en pos de ponerle fin a esta paradoja: Precios altos o bajos, ¡pero accesibles!
Conoce también las experiencias y aprendizajes que tuvimos con esta iniciativa para Android en el artículo escrito por Juan Ignacio Unzurrunzaga y la historia desde la perspectiva iOS desarrollada por Ana Calderon y Laura Sarmiento.
