UX Writing para lectores de pantalla

En el diseño de un producto digital, se dedica tiempo considerable a pulir cada palabra. El microcopy – esas pequeñas piezas de texto en botones, etiquetas, mensajes – es muy importante para guiar, informar y facilitar la interacción del usuario. Pero, ¿con qué frecuencia nos detenemos a pensar cómo esa misma palabra se interpreta cuando es verbalizada por un lector de pantalla?

A veces, el foco sobre lo visual hace olvidar que una parte de los usuarios interactúa con nuestros productos digitales a través de tecnologías de asistencia. Muchas personas dependen de cómo las tecnologías de asistencia interpretan el contenido y si nuestro contenido no está optimizado para estas tecnologías, estamos creando barreras enormes que la mayoría de las veces impedirán que nuestro producto sea usable.

En este artículo vamos a sumergirnos en el mundo del "ux writing" para lectores de pantalla. Veremos por qué es muy importante para la accesibilidad digital, cómo está transformando la manera en que creamos contenido y, sobre todo, cómo puedes implementarlo de manera efectiva en tus productos.

Cómo navegan los usuarios de lectores de pantalla

Antes de comenzar, lo primero de todo es comprender el origen. Para ello, vamos a ver un pequeño vídeo de una demostración con el lector de pantalla de la Universidad de California(abre nueva pestaña).

De esta pequeña demostración podemos sacar varias conclusiones importantes:

• Muchos usuarios configuran sus lectores de pantalla para hablar a velocidades que podrían parecer incomprensibles para quienes no están acostumbrados.
• Los usuarios no consumen el contenido de arriba a abajo, sino que saltan entre elementos según sus necesidades.
• Al saltar entre elementos, es fácil perder el contexto si el contenido no está bien estructurado y etiquetado.

Es importante entender que los usuarios de lectores de pantalla rara vez navegan una página completa de principio a fin. En su lugar, utilizan atajos para saltar entre diferentes tipos de elementos:

• Entre encabezamientos en sus diferentes niveles (h1, h2, h3...).
• Entre elementos interactivos (enlaces, botones, campos de formulario).
• Entre puntos de referencia (landmarks) o regiones importantes (navegación, contenido principal, pie de página)
• Entre elementos de tipo de lista.

Y muchas más posibilidades de navegación. Esta forma de navegación es similar a cómo se escanea de manera visual una página buscando puntos de interés, pero en este caso, se depende completamente de la estructura semántica del contenido.

Textos genéricos en elementos interactivos

Ahora vamos a ver diferentes errores comunes y habituales a la hora de redactar los contenidos de nuestro producto.Para comenzar, veamos uno de los errores más comunes y perjudiciales: el uso de textos genéricos para enlaces y botones. Contenidos como "Haz clic aquí", "Leer más", "Ver detalles" o simplemente "Más" son problemáticas por varias razones. 

Vamos a verlo con un ejemplo:

En este ejemplo, tenemos varios elementos de tipo card que podrían estar representando un listado de artículos en un blog de noticias sobre tecnología. Como hemos visto, la navegación no es lineal, es decir, un usuario de lector de pantalla no suele recorrer la página de inicio a fin.

Si el usuario quiere saltar sobre los diferentes elementos de enlaces, el lector de pantalla irá mencionando "Leer más", "Leer más" y "Leer más". Lo podemos visualizar de manera muy sencilla a través del menú de enlaces que nos da el lector de pantalla:

En este caso, existen dos posibles soluciones: o bien añadimos más información y afectamos al visual poniendo "Leer más sobre avances en inteligencia artificial", "Leer más sobre computación cuántica", o añadimos esta información sin afectar al visual y solamente dando al lector de pantalla esta información. 

Para ello se pueden utilizar varias técnicas a nivel de desarrollo: usando técnicas de hide content(abre nueva pestaña), añadiendo aria-label(abre nueva pestaña), etc.

Como el público objetivo de este artículo es no técnico, no vamos a profundizar en cómo resolverlo técnicamente, pero si en como se debería de dar este información al equipo de desarrollo. 

La manera más efectiva es añadir anotaciones de accesibilidad focalizadas en como debemos de proporcionar esta información al lector de pantalla a través del handoff:

Otros errores comunes que siguen este mismo patrón, sería, por ejemplo utilizar texto como "Haz clic aquí" ya que no describe el resultado de la acción y, en este caso, si que se debería de cambiar el propósito del enlace.

Escribir para la función, no para la apariencia visual

Otro error frecuente es describir la apariencia visual del control en lugar de su función. Frases como "Pulsa el botón verde" o "Busca el icono de la rueda dentada" son inútiles para alguien que no percibe esos atributos visuales.

El lector de pantalla ya informará del rol ("botón", "menú", "casilla de verificación"), siempre que se utiliza una buena estructura y buen uso del HTML Semántico(abre nueva pestaña). Nuestro texto debe centrarse en qué hace ese elemento.Es decir, evita:

• Instrucciones: Para guardar, haz clic en el icono del disquete.
• Navegación: Usa el menú de la izquierda.
• Ajustes: Activa el interruptor azul.

Y preferiblemente usa:

• Instrucciones: Para guardar los cambios, selecciona el botón "Guardar".
• Navegación: Accede a las opciones desde el menú principal.
• Ajustes: Activa la opción "Notificaciones por correo".

Iconos y botones sin alternativa textual

De forma similar, los botones que solo contienen un icono (una papelera para borrar, un lápiz para editar, una "X" para cerrar) son completamente ambiguos para un lector de pantalla si no se les proporciona un nombre accesible o texto alternativo.

Visualmente, podemos inferir su función por el contexto y la iconografía, pero un lector de pantalla solo podría anunciar el rol del elemento "botón" si no hay más información.

Aquí es donde entran de nuevo en juego técnicas como aria-label o el texto oculto visualmente.

Lo importante es definir cuál es el texto descriptivo que debe asociarse a ese icono para que el desarrollador pueda implementarlo correctamente:

• Icono de papelera: "Eliminar elemento" o "Borrar mensaje".
• Icono de 'X': "Cerrar cuadro de diálogo".
• Icono de lápiz: "Editar perfil" o "Modificar datos".

Mensajes de estado, errores y éxito

Una parte fundamental de la interacción del producto es recibir feedback: ¿se ha enviado el formulario? ¿hubo un error? ¿se guardaron los cambios? Visualmente, esto se suele comunicar con mensajes que aparecen en la pantalla, cambios de color o animaciones.

Para un usuario de lector de pantalla, estos cambios dinámicos pueden pasar completamente desapercibidos si no se gestionan adecuadamente. Es frustrante rellenar un formulario, pulsar "Enviar" y no saber si ha funcionado o si hay un error que corregir.

Es por ello, que es fundamental establecer en todo momento un feedback claro sobre el estado.

Adicionalmente, los mensajes de error y éxito deben ser concisos y específicos. Un buen ejemplo podría ser el siguiente:

A la hora de redactar estos mensajes hay que describir lo sucedido y explicar cómo solucionarlo. El mensaje debe ser claro, usar un lenguaje positivo y ser directo.

Malos ejemplos sobre mensajes de error(abre nueva pestaña), podrían ser los siguientes: 

• Lenguaje técnico como "error de publicación de formulario", "error no especificado" y "error 0x0000000643".
• Palabras como "prohibido", "ilegal" y "olvidaste".
• "por favor" porque implica una elección.
• "Lo siento" porque no ayuda a solucionar el problema.
• "Válido" e "inválido" porque no aportan nada al mensaje.
• Lenguaje humorístico e informal como "oops".

Lo realmente importante es lograr claridad. No uses errores generales. No tienen sentido fuera de contexto mensajes como: "se produjo un error", "selecciona una opción", etc. Cada error requiere un mensaje diferente.

La línea entre indicar una acción y describir una condición es fina, pero elegir el enfoque correcto también es necesario para la claridad y la naturalidad. Hay que decidir si lo más útil en un momento es una instrucción directa (qué hacer ahora) o una descripción (una regla, un estado o un requisito). Por ejemplo:

• Para un campo vacío, "Introduce tu nombre" es más claro y natural que "El nombre debe tener un valor" que suena robótico, pasivo e innecesariamente formal.
• Para comunicar una limitación o requisito, "El nombre debe tener 20 caracteres o menos" es claro y directo, en cambio "Introduce un nombre que tenga 20 caracteres o menos" la instrucción se mezcla con la regla y alarga la frase.
• En un campo de contraseña con requisitos, "Crea una contraseña" es poco descriptivo, en cambio "Debe contener al menos 8 caracteres, una mayúscula y un número." separa la instrucción de la regla consiguiendo una mejora de la claridad.

Un usuario de lector de pantalla agradecerá esta precisión. Las instrucciones directas le dicen qué hacer. Las descripciones claras le ayudan a entender los requisitos sin tener que descifrar frases largas y poco naturales que mezclan acción y condición.

Conclusión

Como hemos visto a lo largo del artículo, pequeños cambios en nuestros textos —evitar indicaciones visuales, proporcionar contexto a enlaces genéricos, o redactar mensajes de error claros— pueden derribar barreras para quienes utilizan tecnologías asistivas.

Para profundizar en estas técnicas, te invitamos a nuestro taller práctico "UX Writing para lectores de pantalla"(abre nueva pestaña). El taller está diseñado para diseñadores UX, redactores y cualquier profesional involucrado en la creación de productos digitales, sin necesidad de conocimientos técnicos previos.

El taller se celebrará el viernes 18 de abril a las 17:00 hora España y 12:00 hora Argentina.