How to solve accessibility problems 

By Adrián Benavente, Frontend developer & A11y specialist at Coderio.

Hablar de accesibilidad es hablar de igualdad y posibilidad. Porque pensar en que todas las personas puedan tener acceso a los mismos espacios implica, por un lado, partir de la base de que somos diferentes y, por otro, buscar la manera de que esa llegada sea viable para todos. 

En el área del desarrollo web, la accesibilidad es la práctica inclusiva que garantiza el acceso a los sitios, y diseña las herramientas y tecnologías existentes para que las personas con discapacidad puedan usarlas. En otras palabras, que todos los usuarios puedan percibir, comprender, navegar, interactuar y contribuir en la red. 

Empecemos por el principio

Las Single Page Application (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, cargan los contenidos una única vez y son mostrados de manera dinámica por JavaScript en el momento en que son 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. Dejamos de pensar en páginas para pasar a ver 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 sólo nombré algunas, se podría decir que de cierto modo hicieron la web menos accesible por defecto.

Pero, claro, echarle toda la culpa 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 debemos hacer desde el comienzo del proceso del desarrollo y 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, siempre tendrá 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 su contenido.

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. Es por eso que 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

A medida que las formas de desarrollar software avanzan, las tecnologías de asistencia acompañan esta evolución. Seguro que en un futuro próximo 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 sentarnos a esperar que esto suceda y, cuando ocurra, dejar de lado la retrocompatibilidad.

Por último, no olvidemos que, según las WCAG 2.0, 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. 

Update

El borrador de WCAG 3.0 incorpora los conceptos de vistas y estados, desprendiéndose de términos como página o documento, para acortar, 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.

Por Adrián Benavente, Frontend developer & A11y specialist en Coderio.