Si te encuentras en un proyecto en el cual tienes que hacer las pantallas accesibles, tienes ganas de aprender a hacerlo y no sabes por dónde empezar. ¡Este artículo es para ti!
Aquí vamos a presentar cuáles son los principales conceptos para comprobar si una página es accesible y lo que debe ser hecho para dejarla tal cual.
CONCIACIÓN – ALGUNOS DATOS
Accesibilidad puede involucrar muchos tipos de discapacidad, algunos tipos son:
Hacer nuestras webs accesibles no sólo beneficia a este tipo de personas, nos beneficia a todos, ya que a veces por circunstancias que escapan de nuestro control como una conexión lenta, un brazo roto o simplemente la vejez, no podemos hacer un uso normalizado de la web.
En la web se pueden encontrar muchos artículos y contenidos sobre accesibilidad al buscar por a11y. A título de curiosidad, a11y es un numerónimo (palabra basada en números) para la palabra” accesibility” (similar a i18n para internacionalización).
Accesibilidad es un término que está relacionado con diferentes contextos y, para la web, a11y nos ayuda a identificar los términos relacionados con accesibilidad digital.
Los documentos WCAG (Web Content Accessibility Guidelines) son documentos técnicos que contienen un conjunto de políticas o pautas que debemos seguir para hacer que el contenido de nuestra web sea accesible para las personas con discapacidad.
Actualmente tenemos 2 versiones en las que apoyarnos, la WCAG 2.0 (2008), WCAG 2.1 (2018) y WCAG 2.2 (2022), que no es más que una actualización de la 2.0.
Estos documentos, son generados por la WAI (Web Accessibility Initiative) que forma parte de la W3C (World Wide Consortium, principal organización que rige los estándares de internet) y constan de unas 12-13 pautas organizadas bajo los 4 principios de la accesibilidad (Perceptible, Operable, Comprensible y Robusto).
Para cada pauta, existen criterios de éxito comprobables mediante la combinación de pruebas automatizadas y evaluación humana (por ejemplo, la usabilidad), distribuidos en tres niveles, según el nivel de conformidad/aceptación de los criterios que tienen como requisitos y son: A, AA y AAA.
Como documento de consulta, podéis usar la siguiente guía: https://www.w3.org/WAI/WCAG21/quickref/
Después de echarle un ojo a la importancia de la accesibilidad y su impacto, vamos a ver los principales puntos que deben ser tenidos en cuenta en el momento de desarrollar.
Antes de empezar con los temas de WAI ARIA es necesario saber que se puede hacer accesible todo y cualquier contenido desarrollado que sea bien etiquetado con HTML5, o sea, que el propósito de una etiqueta sea para finalidad en que la misma fue creada. Los lectores de pantalla están por defecto preparados para identificar cada una de las etiquetas standard que forman la web.
En resumen, en el momento de la maquetación, si utilizamos las etiquetas adecuadas para cada ítem en la página ya sería suficiente para que lo mismo esté accesible. Esto significa el HTML semántico es esencial para conseguir una mejor calidad de usabilidad por defecto.
Aunque nos parezca más cómodo, en la maquetación se deben cambiar (siempre que posible) las clásicas “divs” por las debidas etiquetas nativas.
Hay algunas premisas que son fundamentales para una aplicación accesible y las principales son:
Mantener el “focus” con una buena visibilidad a las etiquetas que son “enfocables” como enlaces y botones, por ejemplo.
Por defecto de los browsers actuales, tenemos un enfoque visible y aceptable para que sea accesible (Aunque que lo tengamos, no podemos dejar esta responsabilidad para solo 1 browser específico).
Podemos hacer esto utilizando el CSS y la propiedad “:focus”.
body:focus, *:focus {
outline: 0.125rem solid #08c;
outline-offset: 0.25rem;
}
No son todas las etiquetas web que son “enfocables”, actualmente tenemos las etiquetas interactivas son: a, area, button, details, input, iframe, select, textarea.
No obstante, es posible convertir una div genérica en un elemento que puede recibir “focus” con tabindex (vamos a verlo más adelante) y por tener esta libertad merece la pena recordar que solo recibe “focus” elementos interactivos, o sea, elementos que se pueden interactuar desde el teclado como un botón o un acordeón, por ejemplo.
Solo podemos utilizar un título principal (H1) por página (lo mismo vale para las Single Page Applications o SPA’s)
Podemos utilizar más de un subtítulo (H2…H6), pero que lo mismo traiga sentido para lo que está siendo leído.
Más informaciones en: https://www.w3.org/WAI/tutorials/page-structure/headings/
En la web, las imágenes forman parte no solo de apelo visual de una noticia, también de elemento de interacción que va a mantener motivado el usuario a continuar navegando en aquel sitio, pero ¿cómo convertimos una imagen en accesible? ¿Es necesario que todo sea etiquetado y contenga una descripción o no? Vamos a echar un ojo.
Las imágenes deben tener una descripción cuando tenga sentido tenerla en la línea de lectura a nivel de narrativa (Por ejemplo, una foto de una noticia). Para esto utilizamos el atributo ALT o TITLE (Max.: 130 caracteres)
<img src=”camino_imagen/imagen.jpg" alt=”Empleados mirando sus nuevos proyectos”/>
Imágenes que están involucradas en un enlace (href) deben quedarse con sus atributos vacíos (cuando hay texto en el enlace y lo forma referencia a la imagen), dejando apenas el contenido de texto del enlace.
Cuando la imagen tiene una función (un enlace u otro comportamiento), el atributo ALT se debe representar su funcionalidad.
<a href="/mainpage" class="logo">
<img src=”caminho/imagen.png" alt="Logotipo nuestra empresa - Ir a la home" srcset="">
</a>Imágenes que son decorativas son aquellas que llevan apenas un apelo visual y no traen sentido a narrativa del texto y deben ser ignoradas.
Se aplica a los iconos, por ejemplo.
Para ignorarlos, dejamos los atributos ALT y TITLE vacíos.
<section class="article">
<h1>Bienvenido!</h1>
<img class="decorative-image" src="assets/world.png" alt=""/>
<p>
Lorem Ipsum es simplemente el texto de relleno de las imprentas y archivos de texto. </p>
</section>
Debemos utilizar toda la estructura de un formulario que va a garantizar que los lectores de pantalla a mejor comprender que es un formulario. Mismo que por el diseño de UX no tenga una label, se debe añadirla y ocultarla con CSS.
.wrap .content .article form fieldset {
border-color: transparent;
}
.wrap .content .article form fieldset legend {
opacity: 0;
font-size: 0px;
}
.wrap .content .article form .form-group label {
opacity: 0;
font-size: 0px;
}
¡A tener en cuenta! “display: none” no puede ser leído por los lectores de pantalla.
form action="">
<fieldset>
<legend>En formulário de ejemplo</legend>
<div class="form-group">
<label for="name">nombre:</label>
<input type="text" name="name" id="name" placeholder="Escriba su nombre">
<span class="validator hidden" id="validate-name"></span>
</div>
<div class="form-group">
<label for="email">correo:</label>
<input type="text" name="email" id="email" placeholder="Escriba su correo">
<span class="validator hidden" id="validate-email"></span>
</div>
<div class="form-group">
<label for="message">mensaje:</label>
<textarea name="message" id="message" cols="30" rows="10" placeholder="Escriba su mensaje">
</textarea>
<span class="validator hidden" id="validate-message"></span>
</div>
<button id="send-message" disabled>Enviar!</button>
</fieldset>
</
Por defecto si utilizamos una etiqueta adecuada al tipo de elemento, no debemos utilizar roles para el mismo.
Incorrecto:
<button role="button" id="close-btn">¡Si!</button>
Correcto:
<span role="button" id="close-btn">¡Si!</span>
Es recomendable utilizar las etiquetas adecuadas si es posible, si no puedes utilizar la propiedad role.
Hay componentes que son distintos o no existen en el mundo HTML nativamente. En este caso debemos utilizar las roles y atributos disponibles y Javascript para obtener las funcionalidades adecuadas de lectura e interacción (por ejemplo, un modal).
<!-- Trigger/Open The Modal -->
<button id="myBtn">Open Modal</button>
<!-- The Modal -->
<div id="myModal" class="modal">
<!-- Modal content -->
<div class="modal-content">
<span class="close">×</span>
<p>Some text in the Modal..</p>
</div>
</div>Referencia: https://www.w3schools.com/howto/howto_css_modals.asp
Es un atributo global en que podemos añadir a nuestros componentes customizados opciones de enfoque a través de la tecla TAB.
Si un elemento necesita tener el enfoque o si es necesario añadir una secuencia lógica en el momento de tabular si puede utilizar este atributo.
<section>
<button tabindex="-1">Ignorado</button>
<div role="button" tabindex="0">Butón custom 1</div>
<div role="button" tabindex="1">Butón custom 2</div>
<div role="button" tabindex="2">Butón custom 3</div>
</section>Observaciones
tabindex=“-1” Es un elemento enfocable, pero no navegable por la tecla tab
tabindex=“0” No es un elemento enfocable, pero con el atributo se convierte a un elemento que hace focus y se puede navegar con tab
tabindex=“1--2” La secuencia de focus puede ser controlada a través de los valores numéricos (1—N)
* Tornar un elemento “enfocable” no le añade más funcionalidades de interactivas.
Referencia: https://developer.mozilla.org/es/docs/Web/HTML/Global_attributes/tabindex
Define cual es el lenguaje del elemento. Generalmente puesto en la etiqueta html de una página.
Es posible definir un lenguaje distinto para un o más bloques.
Observaciones
El atributo lang es importante para definir cuál es el idioma de la página o de un bloque de código.
Dejar sin ninguna definición en el HTML va a resultar en la lectura por defecto del idioma configurado en el lector.
(voiceOVer) Para que seas leído correctamente (por un locutor del idioma correspondiente), se debe añadir el idioma en su configuración.
Referencia: https://developer.mozilla.org/es/docs/Web/HTML/Global_attributes/lang
Según la W3C, las aplicaciones de Internet enriquecidas accesibles (WAI-ARIA | Web Accessibility Initiative - Accessible Rich Internet Applications) son un conjunto de atributos que definen formas de hacer que el contenido web y las aplicaciones web (especialmente las desarrolladas con JavaScript) sean más accesibles para las personas con discapacidad. Para esto, ARIA, ofrece a los desarrolladores la opción de agregar información semántica complementaria a nuestros desarrollos:
El conjunto de atributos y funcionalidades es dividido por 3 partes:
Referencia: https://developer.mozilla.org/en-US/docs/Learn/Accessibility/WAI-ARIA_basics
Widgets para marcar elementos de interfaz, por ejemplo, una caja de alerta, botones, checkbox, links, tabs etc.
Document Structure sirve para definición de estructuras de la organización de la página, por ejemplo, header, footer, sidebar, main etc.
Landmarks regiones de la página que son importantes a donde el usuario va a navegar, por ejemplo, búsquedas, contenido principal, formularios etc.
Abajo os comparto algunos roles y ejemplos que suelen ser bien útiles en el desarrollo de una web.
¡Ojo! Añadir las etiquetas lo hacen con que sea leído de acuerdo con el widget tab, pero no su comportamiento, sin embargo, tenemos que crear toda la lógica a través del Javacript.
¡Ojo! No tiene sentido añadir un role a si la etiqueta es la adecuada. En este ejemplo, valdría dejarlo sin la propiedad role.
Si no tenemos control para cambiar la etiqueta, la propiedad role cuadraría como en este ejemplo.
A pesar de que ARIA nos permite modificar sutilmente (o radicalmente) el árbol de accesibilidad de cualquier elemento de la página es lo único que eso cambia.
- ARIA no mejora nada del comportamiento inherente del elemento.
- ARIA no hará que el elemento pueda tener el foco ni le brindará gestores de eventos de teclado. Esa sigue siendo parte de nuestra tarea de desarrollo.
- No es necesario definir aria en los elementos nativos. Es decir, un elemento <input type="checkbox"> no necesita un atributo de ARIA role="checkbox" adicional para anunciarse correctamente.
También vale la pena mencionar que ciertos elementos HTML tienen restricciones sobre los roles y atributos de ARIA que se pueden usar en ellos. Por ejemplo, a un elemento <input type=“password"> no se le puede aplicar un rol/atributo adicional.
Si tienes dudas de cómo crear un componente customizado, es decir, un componente que no existe en el estándar del html5, puedes echarle un vistazo a la web Patterns del ARIA Authoring Practices Guide (APG), allí tendrás la visión de unos cuantos componentes customizados y como desarrollarlos a nivel de etiquetas, roles y manipulación (Javacript).
Cuando hablamos de accesibilidad a nivel de desarrollo, es obligatorio pasar por una secuencia de pruebas.
1. Visual
2. Navegación desde teclado
3. Herramientas automáticas (extensiones)
4. Lector de pantalla
Algunos softwares son utilizados para ayudar con la navegación asistida. Los más utilizados son:
Abajo vamos a echarle un ojo en algunas funcionalidades de los principales (y gratis) lectores de pantalla para windows y Mac.
NVDA - Tenemos algunas teclas de atajo que ayudan a navegar a través de las páginas con los softwares asistidos.
La tecla Shift + tecla de acceso rápido Pasa por elementos en la orden invertida.
Tenemos algunas teclas de atajo que ayudan a navegar a través de las páginas con los softwares asistidos.
En resumen, trabajar con a11y como desarrollador puede parecer un reto gigante al principio, pero después es gratificante hacer una web que sea 100% accesible sin barreras de acceso a los servicios de nuestros clientes en las aplicaciones que creamos. ¡Espero que esta pequeña introducción te aporte algún valor en el momento de picar código!
¡Y recuérdate! Es más fácil crear una web con el pensamiento en accesibilidad que hacer una corrección de algo ya creado. Teniendo esto en cuenta, desarrolle siempre con el pensamiento en accesibilidad.
ifgeekthen.nttdata.com es un blog del grupo NTT DATA. Un proyecto que busca compartir con profesionales del mundo digital temas relacionados con la tecnología y el universo geek.
