Notas sobre mis aprendizajes: escribir inclusivamente (2/4).

← Artículo anterior

1: UX and UX writing.

Siempre he creído, y sigo creyendo, que el enfoque write-first es beneficioso al diseñar una experiencia, al comenzar con flowcharts y wireframes. Esto asegura que el contenido se integre de manera efectiva y estratégica, logrando propuestas más claras, comprensibles y orientadas al usuario.

Qué hay que tener en cuenta desde el punto de vista de la accesibilidad?

1. Usar lenguaje inclusivo.
Evita palabras que puedan excluir a alguien. Por ejemplo, evitar “ver” o “haz clic aquí” para un CTA, donde un usuario no vidente o con dificultades motoras podría sentirse excluido. En cambio, el verbo “abrir” los incluye. Lo mismo ocurre cuando las palabras están relacionadas con un género en algunos idiomas (como el español). Un ejemplo: evitar usar “Bienvenido”, y usar “Te damos la bienvenida”. Hay que ser conscientes de las palabras que usamos si queremos crear un producto inclusivo en todos los sentidos.

2. Ser contextuales.
Muchas veces, al buscar reducir espacio, se acortan frases que pierden contexto, lo que puede afectar la experiencia. Por ejemplo, usar solo “abrir” en un CTA, sin especificar qué se abrirá al interactuar, siendo mejor “Abrir archivo”. No dar contexto puede ser confuso, especialmente para personas que utilizan lectores de voz o tienen problemas de memoria.

Ejemplo de contenido inclusivo y contextual de un CTA.

3. Mantenerlo simple.
Es una regla básica de UX, pero también afecta la accesibilidad.

• Ser transparentes, mantener una comunicación clara y fácil de leer. Hay que encontrar el equilibrio: poca información podría no ser suficiente, mientras que demasiada puede abrumar al usuario, aunque se pueda creer que aporta mayor claridad o transparencia. Puntualmente, en personas neurodivergentes o con diversidad cognitiva, esto es fundamental. Por lo tanto, el balance es la clave.
• Evitar “ser original” o lenguaje técnico sin necesidad, ya que podría atentar contra la experiencia. Esto se observa frecuentemente en nombres de productos o secciones, donde se evita lo obvio. Para una persona con neurodivergencia, comprender estos conceptos podría ser complejo. No estoy diciendo que a veces no funcione, pero si se hace, debe ser una decisión de marca global que también se encargue de promover esa terminología. Un ejemplo es el verbo “twittear”, que nació como nombre de una marca y hoy nadie se pregunta qué significa, pero su adopción no es simple y lleva tiempo.

4. Diseñar cuándo y dónde.
Por ejemplo, usar un placeholder en un input para indicar el contenido a completar puede complicar la experiencia, ya que este se oculta al comenzar a escribir. El usuario se podría preguntar “Qué tenía que completar en este input? ”. Esto podría confundir a usuarios con dificultades de memoria, especialmente si el formulario es extenso. Otro ejemplo? Complejizar una contraseña con muchas condiciones para hacerla más segura, pero para un producto que no lo necesita. Es bueno que las contraseñas sean seguras? Obvio. Pero es necesario complejizarla en todos los productos sólo porque es una contraseña? No. En productos donde no hay riesgos significativos como la contraseña de una cuenta bancaria, no es necesario. Tenemos que evaluar esas decisiones desde esta perspectiva. El momento de crear una contraseña puede ser muy frustrante para un usuario, pero si además no se dan las indicaciones desde el principio, se podría caer en errores forzados. Una persona no vidente, con diversidad motriz, neurodivergente, etc. podría tardar muchísimo en poder recordar esas reglas de la contraseña e ir y volver para lograr la contraseña válida.

Ejemplo de un input usando el placeholder como helper.

5. Escribir feedback contextual y claro.
El usuario debería poder entender fácilmente el feedback que recibe, ya sea positivo o negativo, y entender qué fue lo que pasó: “Completé la tarea? Cuál es el error? Cómo puedo resolverlo? Qué hice mal? Que me falta?” Mostrar feedback técnico (el famoso “error 404”), ambiguo (“Tuvimos un problema, intentalo mas tarde”) o incompleto (un simple de “Inválido” en un input) no ayuda al usuario en nada. Por ejemplo, una persona que está utilizando un lector y recibe solo un error que dice “inválido” podría tardar mucho en entender el problema.

Ejemplo de un error poco claro.

6. Escribir textos alternativos de calidad.
El texto alternativo es el texto que se esconde visualmente en el código y describe contenido no textual. Debe ser diseñado y pensado como parte de la experiencia.

• Deben diseñarse para todos los elementos no textuales, no solo para imágenes. Deben estar presentes en todos los elementos donde se necesite comprender el contenido sin depender de la vista. Por ejemplo, un esquema o diagrama podría contener texto, pero no sería comprensible sin poder identificar las flechas conectoras.
• Deben ser inclusivos, concisos y equivalentes, sin agregar ningún tipo de valoración en la descripción. Por ejemplo, en lugar de hablar de “personas felices”, deberíamos describir “personas sonriendo”.
• Es recomendable que no tengan más de 250 caracteres.
• Como el contenido de un alt text debe ser significativo, los elementos decorativos no necesitan tenerlo. Sin embargo, es crucial asegurarse de que el texto alternativo no sea evidente para los lectores de voz, dejándolo vacío (alt=””).
• No es necesario especificar “una imagen de…”, “un video de…”. Si el código está bien hecho, ya estará indicado en el tipo de elemento, evitando repetir la información.

Recomiendo visitar la página de w3.org, que ofrece un Alt Decision Tree, que permite entender cuándo y cómo escribirlos.

Artículo siguiente →