Orden visual y orden de lectura en accesibilidad

Cuando diseñamos o desarrollamos productos digitales, solemos centrarnos en cómo se ven los elementos en pantalla. Nos preocupamos por la alineación, el balance visual, la jerarquía tipográfica… Pero hay algo que a menudo pasa desapercibido: el orden en el que realmente se lee el contenido.

Ese "orden de lectura" no lo define el diseño visual, sino el código. Y aquí es donde empieza el problema: lo que un usuario ve como una composición clara y estructurada, puede ser incomprensible para personas que usan un lector de pantalla.

¿Qué es el orden de lectura y por qué no es lo mismo que el orden visual?

• Orden visual: Cómo organizas los elementos en la pantalla para guiar la mirada del usuario (ejemplo: un hero image con un titular grande y un botón llamativo).
• Orden de lectura: El orden en que un lector de pantalla (como JAWS o VoiceOver) recorre los elementos de la página. Depende del código, no del diseño.

¿Qué dicen las WCAG (Web Content Accesibility Guidelines) sobre el orden visual y el orden de lectura?

Si no estás al corriente, las WCAG (Web Content Accessibility Guidelines) son el estándar internacional para accesibilidad web. Este estándar se basa en 4 principios y cada uno de estos criterios desarolla una serie de criterios. En su criterio 1.3.2 (Meaningful Sequence - Nivel A)(abre nueva pestaña), son claras como el agua: 

"Cuando el orden en que se presenta el contenido afecta su significado, el orden de lectura correcto debe ser programáticamente determinable."

Esto quiere decir que el orden del DOM(abre nueva pestaña) debe seguir una secuencia lógica incluso si CSS lo reordena visualmente, pero... ¿qué implica esto en la práctica?. Bueno, pues tres cosas:

• Si un usuario desactiva los estilos (CSS), el contenido debe seguir teniendo sentido.
• Los lectores de pantalla deben anunciar la información en un orden que no confunda ni desoriente.
• Si se usan posicionamiento absolutos, fijos o pejagosos deben de continuar teniendo coherencia.

Ejemplo simple: Ficha de producto

Consideremos el siguiente diseño de una ficha de producto para un comercio electrónico (puedes probar a hacer scroll para comprobar el comportamiento del botón):

Añadir al carrito

SPEED TRAINER

795 €

Las icónicas zapatillas Speed Trainer. Diseño minimalista con un ajuste tipo calcetín y suela innovadora para máximo confort y estilo. Perfectas para el día a día o para ocasiones especiales.

Talla

39 40 41 42 43

Nuevo

Este diseño, aunque visualmente atractivo, presenta un problema serio de orden de lectura. Veamos la estructura esquemática del código HTML subyacente:

<div>
  <!-- El botón está al principio del HTML,
       aunque visualmente aparece al final -->
  <button>Añadir al carrito</button>
  <h1>SPEED TRAINER</h1>
  <img src="zapatilla.jpg" alt="...">
  <p>795 €</p>
  <p>
    Las icónicas zapatillas Speed Trainer...
  </p>
  <div>
    <!-- Opciones de talla -->
  </div>
</div>

¿Puedes identificar el problema? El botón "Añadir al carrito" está posicionado visualmente en la parte inferior de la pantalla, pero en el código HTML aparece antes que toda la información del producto. Esto viola directamente el criterio 1.3.2 de las WCAG.

Esto se puede apreciar claramente si quitamos los estilos y vemos el resultado del HTML sin CSS:

Añadir al carrito

SPEED TRAINER

795 €

Las icónicas zapatillas Speed Trainer. Diseño minimalista con un ajuste tipo calcetín y suela innovadora para máximo confort y estilo. Perfectas para el día a día o para ocasiones especiales.

Talla

39 40 41 42 43

Nuevo

Pero, ¿por qué es esto un problema?

Un lector de pantalla anunciará "añadir al carrito, botón" antes de que el usuario conozca qué producto está viendo, su precio o sus características. Además, los usuarios que navegan con teclado encontrarán el foco en el botón de compra antes de acceder a la información del producto y seleccionar la talla.

Para corregir este problema y cumplir con este criterio, deberíamos restructurar nuestro HTML de la siguiente manera:

<div>
  <h1>SPEED TRAINER</h1>
  <img src="zapatilla.jpg" alt="...">
  <p>795 €</p>
  <p>
    Las icónicas zapatillas Speed Trainer...
  </p>
  <div>
    <!-- Opciones de talla -->
  </div>
  <!-- De esta manera, será el último elemento
       en ser alcanzable -->
  <button>Añadir al carrito</button>
</div>

Ejemplo avanzado: Tarjeta de producto con múltiples elementos

Veamos ahora el caso de las tarjetas de producto. Si probamos a navegar con el teclado o un lector de pantalla, la experiencia y el contexto es confuso:

La estructura HTML muy simplificada de la tarjeta de producto sería algo como esto:

<li>
  <span>-20%</span>
  <img alt="Zapatillas Ultra Boost">
  <span>★★★★☆ (4.2)</span>
  <h2>Zapatillas Ultra Boost</h2>
  <span>119.99€</span>
  <span>149.99€</span>
  <p>Zapatillas de running con tecnología...</p>
  <button>Añadir a la cesta</button>
</li>

Pero, ¿qué es lo que falla exactamente?

El código HTML prioriza elementos visualmente secundarios. Por ejemplo, el badget del "-20%" aparece antes que el título del producto en el flujo del lectura. El lector de pantalla narra algo parecido a lo siguiente:

«-20%. Zapatillas Ultra Boost, imagen. estrella negra estrella negra... 4.2. Encabezamiento de nivel 2, Zapatillas Ultra Boost. 119.99 €. 149.99 €. Zapatillas de running con tecnología... Añadir a la cesta, botón»

Ahora te pregunto, ¿crees que ese orden tiene sentido? ¿tú te enteras de algo?. Puede que si, pero vas a necesitar revisar varias veces este texto para intentar averiguar la contextualización que te falta para interpretar el contenido correctamente.

Es como si en un supermercado te pusieran la caja registradora antes de las estanterías. ¿Cómo vas a comprar algo que no has visto ni elegido?

Ahora vamos a ver los errores que existen y una posible solución:

• El primer problema es que orden en el código debe ser igual a la orden de la experiencia esperada. Es decir, primero debería de ir el título. Luego el nombre, precio y detalles. Al final, el botón de acción y la imagen. Con este orden, el lector de pantalla anuncia el contenido con una estructura lógica parecida a la siguiente: «Titulo -> Descripción -> Descuento -> Precio antes de descuento -> Precio después del descuento -> Valoración -> Añadir a la cesta -> Imagen». Esto es un orden propuesto que podría encajar, pero es algo subjetivo que podría tener ligeras modificaciones como en qué lugar se debería de anunciar la imagen o la valoración.
• El segundo problema es que existen elementos visuales que necesitan más contexto. El «-20%» no es un adorno y necesita más contexto adicional para que se comprenda de manera adecuada. También pasa con las estrellas de valoración (★★★★☆) se deben de complementar con contenido textual adicionalmente para que se anuncien con sentido.

Una estructura HTML muy simplificada y que tendría más sentido podría ser algo parecido a lo siguiente: 

<li>
  <h2>Zapatillas Ultra Boost</h2>
  <p>Zapatillas de running con tecnología...</p>
  <div>
    <span>
      <span class="sr-only">Descuento del </span>
      -20%
    </span>
    <span>
      <span class="sr-only">Precio original: </span>
      149.99€
    </span>
    <span>
      <span class="sr-only">Precio con descuento: </span>
      119.99€
    </span>
  </div>
  <div>
    <span class="sr-only">Valoración de 4.2 sobre 5 estrellas</span>
    <span aria-hidden="true">★★★★☆ (4.2)</span>
  </div>
  <button>Añadir a la cesta</button>
  <img alt="Vista frontal de las zapatillas running Ultra Boost en color azul marino..." src="...">
</li>

Ahora el orden de los elementos tiene mucho más sentido. También hacemos uso de la clase sr-only que tiene como objetivo que solo los lectores de pantalla puedan anunciar su contenido sin necesidad de que fuera de manera visual. La declaración CSS de esta clase sería algo parecido a lo siguiente:

<style>
  .sr-only {
    position: absolute;
    width: 1px;
    height: 1px;
    padding: 0;
    margin: -1px;
    overflow: hidden;
    clip: rect(0, 0, 0, 0);
    white-space: nowrap;
    border: 0;
  }
</style>

Y por último, hacemos uso del atributo aria-hidden que oculta el contenido de la etiqueta a los lectores de pantalla. Así evitamos que el lector de pantalla anuncie <<estrella negra estrella negra estrella negra...>>.

Con esta solución aplicada el lector de pantalla lo anunciaría en el siguiente orden:

«Encabezamiento de nivel 2, Zapatillas Ultra Boost. Zapatillas de running con tecnología.... Descuento del -20%. Precio original: 149.99 €. Precio con descuento: 119.99€. Valoración de 4.2 sobre 5 estrellas. Añadir a la cesta, botón. Vista frontal de las Zapatillas Ultra Boost de color azul marino, imagen»

Mucho mejor ahora, ¿no?.

Conclusión

A lo largo de este artículo, hemos explorado la crucial diferencia entre el orden visual y el orden de lectura en el diseño web, centrándonos en el criterio 1.3.2 de las WCAG. Hemos visto cómo este principio aparentemente simple puede tener un impacto profundo en la accesibilidad de nuestros productos digitales.

Si bien es cierto que no hemos profundizado en cuestiones más avanzadas (como conseguir posicionar los elementos visualmente en el orden correcto independientemente del orden que definamos en el HTML), es cierto que el objetivo era la compresión de la importancia de la secuencia y como puede afectar a la contextualización que realizamos.

Llévate estos 3 puntos que considero los más importantes:

• El orden visual no siempre coincide con el orden de lectura, y es este último el que determina la experiencia de los usuarios de tecnologías de asistencia.
• El criterio 1.3.2 de las WCAG nos exige que el orden del contenido en el código HTML siga una secuencia lógica y significativa, independientemente de cómo se presente visualmente.
• Incluso en diseños complejos, como las tarjetas, es importante mantener una estructura de código que priorice la comprensión y la navegación lógica. Solo tenemos que pensar cúal es el orden más lógico por el que se debería de empezar a leer.