Las SPA son aplicaciones o sitios que, en lugar de hacer una petición al servidor cada vez que el usuario interactúa con la página, los contenidos se cargan una única vez y son mostrados de manera dinámica por JavaScript en el momento en que sean requeridos, ya sea en su totalidad o de manera parcial y asíncrona, sin necesidad de recargar toda la página. Esto permite una navegación más fluida, con menor consumo de recursos, similar a la de una aplicación nativa.

A su vez, a los desarrolladores nos permitió granularizar mucho más nuestra arquitectura, dejando de pensar en páginas, para pasar a verlo todo en términos de componentes. También facilitó la depuración de errores ya que todo lo que necesitamos es un navegador y las developer tools del framework o librería que estemos usando.

Sin embargo, y a pesar de todas sus bondades, de las que solo nombré las más superficiales ya que este no es un artículo dedicado enteramente a las SPA, se podría decir que de cierto modo hicieron la web menos accesible por defecto.

Claro que, echarle toda la culpa de esto a las SPA, no sería lo más razonable. Un cambio de paradigma no es más que una nueva manera de pensar y hacer las cosas. Por eso quiero compartir una serie de implementaciones que deberemos hacer desde el comienzo del proceso del desarrollo, que, junto con las verificaciones básicas de siempre, garantizarán que nuestras SPA cumplan con el principio 2 de las WCAG 2.0 que es ser operables.

Manejo del foco

Como la pestaña no se recarga al navegar entre vistas, el lector de pantalla no avisará de ningún cambio de contenido a no ser que se le indique explícitamente. Para ello, una técnica muy común es ubicar el foco en el primer encabezado.

function onNavigate() {
    document.getElementById('titulo-seccion').focus();
}

Pero las etiquetas de encabezado no son elementos enfocables, por lo que hay que otorgarles esta característica, colocándoles el atributo tabindex. Le daremos un valor de -1, para evitar que interfiera en el flujo de navegación de la tecla TAB.

<section>
    <h2 id="titulo-seccion" tabindex="-1">Título de la sección</h2>
    <p>Aquí el contenido...</p>
</section>

Lo anterior también aplica a los casos en donde un botón o enlace realiza un scroll dentro de la vista, hasta otra parte de la misma. Siempre se debería poner el foco donde comienza el contenido al que llevaremos al usuario.

Título del documento

Al existir un único documento HTML, este tendrá siempre el mismo título. El usuario podría no saber en qué pantalla se encuentra, en caso de irse a otra pestaña del navegador y luego volver. Por eso, debemos modificar el texto de la etiqueta <title> mediante JS, al cambiar de vista, para que refleje el contenido de esta.

document.title = "Mi maravilloso sitio | Quiénes somos"

Semántica HTML

A veces, los frameworks de desarrollo de SPA, si no son bien utilizados, pueden forzar malas prácticas como el uso excesivo de etiquetas <div>, lo que puede degradar o hasta arruinar por completo la experiencia de usuarios de tecnologías asistivas. Mantener siempre una correcta semántica HTML, resulta imprescindible.

<header>
  <h1>Mi página</h1>
  <nav>
    <ul>
      <li>
        <a href="/home">Inicio</a>
      </li>
      <li>
        <a href="/nosotros">Nosotros</a>
      </li>
      <li>
        <a href="/portfolio">Portfolio</a>
      </li>
      <li>
        <a href="/contacto">Contacto</a>
      </li>
    </ul>
  </nav>
</header>
<main>
  <section>
    <h2>Nosotros</h2>
    <p>Bla, bla...</p>
  </section>
  ...
</main>
<footer>
  <p>@adrian.benavente.dev</p>
</footer>

Conclusión

La tecnología avanza y con ella las formas de desarrollar software, y las tecnologías de asistencia también hacen lo propio para acompañar esta evolución. Seguro que en un futuro próximo cada vez encontraremos un mejor soporte para SPA por parte de los distintos agentes de usuario que utilizan las personas con discapacidades, o, tal vez, las herramientas de desarrollo de SPA incorporen mejoras de accesibilidad. Mientras tanto, no podemos simplemente sentarnos a esperar que esto suceda, y mucho menos, cuando ocurra, dejar de lado la retrocompatibilidad.

Por último, no olvidemos que, según las WCAG, en una declaración de conformidad un documento es o no es accesible, pero nunca puede ser parcialmente accesible; en ese caso se considera que no lo es, y se lo excluye. Ahora bien, una SPA consta de un solo documento. ¿Se va entendiendo el punto?

ACTUALIZACIÓN: el borrador de WCAG 3.0 ya incorpora los conceptos de vistas y estados, desprendiéndose de términos como página o documento, acortando así la brecha con el vocabulario actual y ajustándose para incluir a las SPA. Sin embargo, esta versión no verá la luz antes de 2023.

Colaborar

Buy Me a Coffee
Invitame un café en cafecito.app