Es necesario entender unas bases
Como decía en mi anterior artículo de accesibilidad (la parte uno, siendo éste la segunda); creo que es necesario conocer unos mínimos sobre accesibilidad donde escribía sobre a quienes debemos tener en cuenta a la hora de desarrollar (a toda la gente posible), algunos consejos del Consorcio W3C y teniendo en cuenta las llamadas Pautas de Accesibilidad al Contenido Web (WCAG) 2.1.
¿Qué debemos tener en nuestras webs y aplicaciones?
Partamos de la base que esto es CSS, HTML y JavaScript, sin tener en cuenta como deberemos implementar la solución de forma específica, así pues si se usa Vue.js, React, Angular o cualquier otra librería o framework de desarrollo es posible que haya pequeños o grandes detalles que cambien.
Deberemos tener muy presente en usar elementos semánticos siempre que podamos ya que, componentes con los que podemos interactuar como los botones, links o elementos de formulario: inputs, dropdowns, datepickers… son «focusables» si no lo cambiamos (cosa que no deberíamos).
Dichos elementos interactuables suelen usar unas teclas por defecto de forma nativa para navegar por ellos y si hacemos algún componente a medida deberemos intentar salvo que desarrollemos una ayuda contextual usar las que por defecto usan los controles nativos.
Ejemplos:
Tab(para avanzar al siguiente elemento)Shift + Tab(para retroceder al elemento anterior)Teclas de flecha(para moverte dentro del componente como en un dropdown)Espacio(para activar elementos como los checkboxes)Intro(para activar elementos como los botones de submit)
Una vez hayamos pensado bien las necesidades de un componente a medida existen multitud de ideas que pueden ayudar a mejorar la accesibilidad, más allá de añadir alt a las etiquetas img, tener en cuenta el contraste de color, que nuestro texto tenga un tamaño mínimo para su buena lectura…
Se dan multitud de situaciones en las que necesitamos que el contenido sea visible en dispositivos de pantalla pequeños como los móviles, por ello debemos añadir la etiqueta correcta en el <head></head> del HTML evitando en la medida de lo posible cosas como la siguiente: maximum-scale=1.
/**
* Metatag en el <head></head>
*/
<meta name="viewport" content="width=device-width, initial-scale=1">Otro de los habituales para mi se da cuando necesitamos añadir contenido oculto a la vista del usuario vidente para que sea accesible para lectores de pantalla, para ello podemos usar una clase de CSS que evita que nuestro contenido (textos por ejemplo) sean visibles porque no existen en diseño.
/**
* https://github.com/h5bp/html5-boilerplate/blob/master/src/css/main.css#L119-L133
*/
.u-visually-hidden {
border: 0;
clip: rect(0 0 0 0);
height: 1px;
margin: -1px;
overflow: hidden;
padding: 0;
position: absolute;
width: 1px;
}
<span class="link">Slides <span class="u-visually-hidden">sobre: Nociones sobre fuentes Web</span></span>Elementos de formulario
En los elementos de formulario cada input debe tener cuatro factores claramente interpretables por el usuario con el sistema que utilice y que a su vez serán expuestos al API de accesibilidad. Sin olvidarnos de añadir (aunque sea oculto visualmente si el diseño así lo necesita), como ya vimos antes un label.
Nota:
rolenameolabelstatevalue
Sabiendo esto, ya tenemos como movernos con las teclas habituales de un control nativo, podemos ocultar contenido visualmente y tenemos en cuenta los cuatro factores que debemos exponer al API de accesibildad. Así que vamos manos a la obra con un breve checklist.
Checklist para controles personalizados
- ¿Podemos acceder al control personalizado con el que queremos interactuar con el teclado?
- ¿Podemos controlar el control personalizado con el teclado?
- ¿Podemos controlar el control personalizado con gestos?
- ¿Podemos controlar el control personalizado con tecnologías que ayuden a la accesibilidad?
- ¿Podemos controlar el control personalizado con las teclas o gestos standard para un control de este tipo?
- ¿Se puede ver fácilmente el control personalizado cuando se hace focus?
- ¿Tiene el control personalizado un
labelque se expone como nombre al API de accesibilidad? - ¿Tiene el control personalizado un
roleque se expone al API de accesibilidad? - ¿Tiene el control personalizado estados de interfaz que se exponen al API de accesibilidad?
- El control personalizado tiene un
label, una descripción e iconos perceptibles y accesibles por usuarios con baja visión. - El control se puede usar correctamente cuando el usuario tenga el modo de Alto Contraste activo en su sistema operativo.
Por tanto, deberemos hacer que todos los elementos interaccionables de nuestra página web han de poder hacérseles foco (como ya dije antes) y verse claramente. Si debemos hacerlos vía JavaScript podremos usar el método nativo .focus(), pero no está de más recordar que no debemos eliminar el :focus «porque quede feo». Podemos cambiarlo, hacerlo más elegante o hacerlo usable cuando nuestro usuario navegue con teclado únicamente.
Nota:
- Focusable
- Se puede usar el método
.focus()de JavaScript
¿Qué más? Todos estos elementos por defecto tienen de forma implícita un TAB order, que no es ni más ni menos que irán haciéndose foco uno detrás de otro en el mismo orden que se encuentran en el DOM si no lo cambiamos activamente.
Nota:
- Posibles valores del
tabindex-1(no son focusables)0(el estado normal)Más de uno(aparecerán en dicho orden)
Otro tema a tener en cuenta son los skip-links que sirven para saltar de cosas no tan importantes como una barra de navegación o un aside con diferentes elementos al contenido al que queremos acceder.
/**
* Ejemplo de código que podríamos usar en los skip-links
*/
.accessible-hidden {
position: absolute;
top: 0;
left: -99999px;
height: 1px;
width: 1px;
clip: rect(1px, 1px, 1px, 1px);
white-space: nowrap;
}
.accessible-hidden:focus {
position: fixed;
top: 0;
left: 0;
background: #fff;
padding: 10px;
etc etc...
}¿Te ha gustado? Espero que así sea. ¿Crees que se echa de menos algo? Si es algo que sea básico y no esté repetido una y otra vez en cada artículo sobre accesibilidad no dudes en decírmelo en Twitter.
