25 buenas prácticas Front que ayudan a la Accesibilidad.

Hace algunos años parecía que la Accesibilidad pasaría de solo ser aplicada en sitios web gubernamentales a convertirse en la forma de desarrollar software.

La expectativa era más grande que la tímida realidad: la responsabilidad social, la mejora del posicionamiento en buscadores, el acceso a un mayor número de usuarios, las obligaciones legales o la simplicidad en el diseño no fueron razones suficientes para la universalización de estas técnicas. Y, menos aún, en aplicaciones internas, aunque sean usadas en grandes empresas por cientos de personas de distintos países. En ellas, el beneficio corporativo no parece lo suficientemente importante, el SEO es intrascendente y son más permisivos con las malas prácticas.

Entonces, ¿cuáles son las razones por las que no ha tenido el alcance esperado? En este escenario, ¿es útil para un profesional del desarrollo conocer aspectos de accesibilidad?

Desarrollo Front-end y accesibilidad

Aún hoy existen falsos mitos que impiden tener mayor relevancia. Por ejemplo, se sigue pensando que la accesibilidad está dirigida solo a un número muy reducido de personas o personas con alguna discapacidad. Se ignora que este grupo seguirá aumentando con el paso de los años en una población cada vez más envejecida.

Además, olvidamos que la accesibilidad de una web, también, hace que se vea correctamente en todos los dispositivos o en circunstancias adversas de iluminación o de ruido. Sigue existiendo la creencia errónea de su incompatibilidad con una buena estética o de que genera un coste muy elevado y, por tanto, poco rentable.

En el proceso de creación de productos accesibles, el desarrollo Front-end es una pieza indispensable y su trabajo debe permitir al usuario llegar, comprender e interaccionar con el contenido reflejando los cambios que se produzcan en la web en los elementos del DOM.

Webs más accesibles

A continuación, comprobaremos que las buenas prácticas de siempre junto con otras técnicas y consejos pueden hacer una web mucho más accesible:

1 - Respeta siempre la semántica del HTML. No uses un <div> para todos los elementos. Si no utilizas las etiquetas correctas algunos usuarios perderán la referencia que estas proporcionan.

2 - Usa el atributo role para dar más información del contenido o de la función del elemento. Por ejemplo:

<div role="contentinfo">
    El ministerio de educación….
</div>

<div role="alert">
    Este contenido no está disponible.
</div>

No pongas más de un role en el mismo elemento, revisa que la etiqueta no entre en conflicto con el role añadido y no cambies ni reiteres la semántica que tenga por defecto cuando la suya propia es específica.

Por ejemplo: <nav> <article> <button> no es necesario role="navigation", role="article"y role="button" respectivamente.

3 - No te olvides de poner encabezados, usarlos jerárquicamente de forma correcta y no simularlos con CSS sin la etiqueta correspondiente. Ayudarán a la comprensión y estructuración del contenido. Ojo, ten cuidado al meter un encabezado en un web component que se reutiliza en distintos sitios de la página porque podrías saltarte la jerarquía y confundir a el usuario.

4 - Aunque sí es posible usar más de un H1 en una página, no es lo más recomendable desde el punto de vista de la accesibilidad para no confundir a los usuarios.

5 - Permite que el usuario pueda acceder al contenido usando la tecla “Tabulador”. Para ello, usa el atributo tabindex=”0” para mantener el elemento en su orden natural y tabindex=”-1” para quitarlo de este orden. Utilízalo en botones, pestañas, menús desplegables y campos de texto. Pero, no uses tabindex en encabezados, imágenes, o títulos.

6 - Es una mala práctica muy habitual eliminar el foco por defecto por motivos decorativos:

:focus {
    outline: 0;
}

Indica al diseñador que tome otra alternativa estética usando, por ejemplo, box-shadow o border con colores que cumplan los criterios de
accesibilidad y, de esta manera, no prescindir de esta ayuda visual relevante.

7 - En las imágenes no decorativas coloca el atributo alt=”” con la información relativa a esa imagen y lo mismo para los logotipos en los que aparezca texto. No uses imágenes no decorativas como background en el CSS.

8 - En las imágenes decorativas coloca también el mismo atributo alt=”” esta vez vacío. Es obligatorio.

9 - Los breadcrumbs deben estar hechos con listados y con enlaces, del mismo modo que las barras de navegación.

10 - Usa siempre en los resaltados <strong> en lugar de "font-weight: bold"".

11 - No añadas texto relevante dentro de el CSS con content.

12 - Usa lo menos posible position: absolute. Al ampliar la pantalla podría tapar contenidos.

13 - Permite que el usuario pueda hacer zoom de, al menos, un 200%:

<meta name="viewport" content="width=device-width;initial-scale=1.0; maximum-scale:2.0; user-scalable=1" />

14 - No debes ocultar la barra de scroll horizontal con overflow-x: hidden; ya que, al hacer zoom, algunos usuarios pueden necesitarla.

15 - Indica el idioma de la página con el atributo <html lang=""> para el contenido general e incorpóralo también dentro de la página si lo hubiera en algún párrafo específico con otro idioma. Así, harás posible la traducción de la página completa en dispositivos.

16 - Usa siempre medidas relativas para el tamaño de la fuente.

17 - No es recomendable usar frameworks JS que usen componentes con poca flexibilidad y que generen un exceso de capas innecesarias y poco accesibles.

18 - Ten cuidado al usar flex-direction, order o prácticas de Pull and Push en responsive ya que cambian el orden de los elementos y se dispondrán de manera distinta al DOM pudiendo afectar a las personas que usan lectores de pantalla. Puedes hacer comprobaciones de todo esto visualizando la página sin cargar la CSS.

19 - Añade información en los enlaces relevante para los lectores de pantalla y oculta el resto mediante la técnica de estilos text-indent:

<a href="”incripcion.html”">
    Inscripción
    <span class="”texto_oculto”">
        Inscripción para el curso 2020
    </span>
</a>

.texto_oculto {
    text-indent:-9999em;
}

Si hubieras añadido display: none o visibility:hidden no estaría disponible en los
lectores de pantalla.

20 - No olvides la buena práctica de los formularios para relacionar los label con su input con for y su id correspondiente:

<label for="”nombre”">Nombre</label>
<input type="text" name="nombre" id="nombre">

21 - Si tienes un elemento con una indicación visual gráfica puedes añadir aria-label para clarificar su propósito. Por ejemplo, si tuviéramos un botón de menú con la imagen de la hamburguesa:

<button class="hamburguer" 
   aria-label="menu"
</button>

22 - Con aria-checked podemos proporcionar información accesible del estado chequeado o no, true o false, alternado con JS. Como ejemplo podemos realizar un Swicth a partir de un botón.

<button role="switch" 
        aria-checked="false"
        class="toogle">
            Enable
</button>         

En este ejemplo no será necesario añadir una clase para cambiar el estilo de encendido. Lo correcto será:

.toogle[aria-checked=”true”] {
   background-color: green;
}

ARIA proporciona múltiples atributos para añadir semántica, modificar la
originaria o crear la no existente en HTML. Es recomendable que amplíes
información sobre ello.

23 - Usa Chrome Vox Lite, un lector de pantalla de Chrome que te resultará de gran utilidad.

24 - Utiliza Lighthouse de Chrome para testear la accesibilidad, del mismo modo que usas Console, Elements, Network... para tu trabajo de desarrollo. Esta herramienta, además, te da consejos y links a artículos de gran interés para mejorar.

25 - Y, por último, para muchos casos pueden existir varias formas de llegar a un buen resultado. No te conformes, busca, comprueba, investiga...

Conclusión

Estas prácticas son solo el comienzo de otras muchas que habrá que realizar para que, junto con la implicación y colaboración de los diseñadores, los creadores de contenidos, el Product Owner, los usuarios de todo tipo y su valiosísimo feedback, podamos beneficiarnos todos de productos cada día más accesibles y, en definitiva, mejores.

Referencias:

Google developers: accesibilidad.

ARIA in html.

Twitter de Olga Carreras.

Twitter de Sergio Luján.