7 errores comunes de accesibilidad (y cómo evitarlos)

Es probable que ya hayas oído hablar de accesibilidad digital, y sabes que es importante optimizar tu producto online para personas con discapacidad. Es comprensible que te sientas abrumado con toda la información y las tareas que debes realizar para mejorar tu producto. Tal vez hayas llegado a la conclusión de que es tan complicado que necesitas contratar a un experto para que haga el trabajo. Mientras tanto, ¡a usted le importa! Sólo que no sabes cómo empezar.

No se preocupe: solucionar o evitar estos problemas no suele llevar tanto tiempo. Eso si sabes dónde buscar y qué hacer en su lugar. En los años que llevo trabajando como desarrollador web e ingeniero de software front-end, me he encontrado con muchos problemas de accesibilidad. A menudo, se reducen al mismo conjunto de puntos. En la mayoría de los casos, un enfoque que tenga en cuenta la accesibilidad no requiere mucho tiempo. No es más difícil ni más caro. Es hacer tu trabajo diario con una mentalidad diferente lo que mejora enormemente la accesibilidad.

Pero vayamos al grano: permítame explicarle cuáles son los problemas de accesibilidad más comunes y, lo que es más importante: cómo evitarlos.

Error 1: Mal marcado semántico

Evitar los problemas de accesibilidad no requiere trabajo adicional. Simplemente requiere un trabajo diferente

Uno de los errores que se cometen con más frecuencia y que lamentablemente tiene mayores consecuencias es el mal marcado semántico. Si conoce un poco de HTML, sabrá que una página consta de elementos definidos por etiquetas HTML, por ejemplo <h1> y <p>. La mayoría de los elementos son semánticos: describen claramente su significado de forma legible por humanos y máquinas.

Si visualizas el código fuente de cualquier página web, también observarás una gran cantidad de elementos <div> y <span>; estos son los elementos no semánticos. Estos elementos son contenedores genéricos, que no aplican ningún significado a su contenido.

Los lectores de pantalla se basan en gran medida en el HTML semántico. Forman un árbol de accesibilidad basado en la semántica de la página. Un usuario con un lector de pantalla puede saltar de un elemento a otro utilizando atajos. Le indica cuáles son botones, cuáles son encabezados, dónde está la navegación, cómo se relaciona la información de la página con otros elementos de la misma, etc.

Uso excesivo de elementos no semánticos

Si se utilizan elementos <div> y <span> donde debería haber un elemento semántico, se pierde información esencial al instante. Los usuarios con discapacidad visual no pueden ver la estructura del sitio web basándose en lo que ven. No pueden ver los botones ni el menú de navegación. La página web se convierte en un gran montón de contenido desestructurado. Peor aún, a menudo los elementos interactivos -como los botones- se vuelven completamente inutilizables. Cuando navego por la web, a menudo encuentro elementos <span> controlados por JavaScript, con estilo de botón. El JavaScript está escrito para que se active con un clic del ratón. Esto funciona bien para cualquiera que pueda utilizar un ratón, pero no se puede controlar con el teclado, y a menudo es imposible que un usuario de lector de pantalla lo encuentre.

Consejo: utilice HTML semántico

Si parece un botón y se comporta como tal, debe ser un botón.

Mi consejo para evitar este comportamiento no deseado probablemente no sea una sorpresa: utilizar elementos HTML semánticos apropiados tanto como sea posible. Los únicos casos en los que deberías usar elementos <div> y <span> son cuando no hay ningún otro elemento disponible para transmitir significado. Por lo general, esto se reduce únicamente a fines decorativos.

El uso de elementos semánticos aumentará exponencialmente la accesibilidad de su página web. Esto se debe a que contienen información para el navegador sobre cómo deben utilizarse. Además, como desarrollador o ingeniero, incluso le ahorrará tiempo. No tendrás que pensar en imitar el comportamiento de, por ejemplo, un botón, porque ya funciona así de forma predeterminada.

Utilización de elementos semánticos erróneos

Otro error común en esta categoría es elegir el elemento semántico equivocado. Esto es a menudo el resultado de elegir un elemento por su aspecto en lugar de por su comportamiento o su propósito. Tal vez no usaste un <button> nativo porque pensaste que se veía feo. O quizá te saltaste unos cuantos niveles de encabezado y elegiste un <h4> en lugar de un <h2>, porque te gustaba que tuviera un tamaño de fuente más pequeño. Esto es un error; para eso tenemos CSS.

Consejo: elija un elemento por su significado

Utiliza elementos HTML para estructurar tu contenido basándote en el significado de cada elemento, no en su apariencia. A continuación, aplica estilos a tu gusto con CSS.

Consejo: utilice herramientas automatizadas

Una buena forma de ayudarte con la semántica es utilizar una herramienta de validación HTML. Algunas herramientas lo incluyen en las pruebas de accesibilidad automatizadas, como axe Tools. Recuerde que las herramientas automatizadas no pueden probarlo todo y a menudo incluyen falsos positivos y negativos. Pero pueden ayudar a detectar rápidamente errores que podrías haber pasado por alto. La mejor opción es combinar pruebas automatizadas y manuales para la accesibilidad.

Error 2: Etiquetas de formularios mal estructuradas

Si parece un botón y se comporta como un botón, debe ser un botón.

Este error también tiene mucho que ver con el HTML semántico. No te equivoques: ¡diseñar e implementar un formulario usable, accesible y de aspecto agradable es todo un reto!

El formulario de inicio de sesión de Easy LMS. Las etiquetas se desplazan hacia arriba al rellenar un campo del formulario, por lo que permanecen visibles.

La entrada y la etiqueta no están vinculadas

Cada formulario tiene un campo de entrada y una etiqueta que lo describe. Por ejemplo, tengo tres campos de entrada: "Nombre", "Dirección de correo electrónico" y "Empresa". Podría añadir los nombres encima de las entradas en texto sin formato (por ejemplo, dentro de un elemento <span>). Desgraciadamente, un usuario de lector de pantalla encontrará tres entradas de texto vacías sin indicación de lo que debe rellenar.

Consejo: emparejar etiqueta y entrada

Utilizar elementos HTML semánticos para las etiquetas ya es un gran avance, pero si realmente quieres ayudar a tus usuarios, también deberías emparejar tu etiqueta y tu entrada. Ahora el navegador sabe que los dos van juntos. En Easy LMS, diríamos: ¡beneficio!

Utilizar atributos de marcador de posición como etiquetas

Otro error de accesibilidad es omitir las etiquetas y utilizar atributos de marcador de posición en las entradas. Es una mala práctica por un par de razones. En primer lugar, no suele estar disponible para muchas tecnologías de asistencia. En segundo lugar, en cuanto un usuario escribe la entrada (o autocompleta el formulario), las etiquetas desaparecen. Así es difícil comprobar si hay errores en el formulario. Por último, un marcador de posición es una pista adicional, no una etiqueta.

Consejo: No sustituya una etiqueta por un marcador de posición

Nunca omita las etiquetas en un formulario. Si tiene que hacerlo, utilice marcadores de posición sólo para proporcionar pistas adicionales a los usuarios (videntes) en los formularios. Pero aún mejor: no utilice atributos de marcador de posición en absoluto y asegúrese de que la información importante sobre el formulario esté disponible para todos.

Error 3: Utilizar enlaces no descriptivos

¿Cuántas veces se ha encontrado con enlaces que dicen "haga clic aquí", "lea más" o "vaya a esta página"? Supongo que más de las que pueda contar. Una de las razones por las que esto es una mala práctica es que no permite entender el propósito del enlace fuera de contexto. Con las tecnologías de asistencia, los usuarios pueden navegar rápidamente por los enlaces de una página. Imagina que un lector de pantalla te comunica lo siguiente: "Aquí, enlace. Leer más, enlace. Esta página, enlace". Eso no le dice nada, ¿verdad?

Consejo: incluya el asunto de la página en el enlace

¿Cómo evitarlo? En la mayoría de los casos, se puede solucionar fácilmente incluyendo el asunto o el título de la página a la que se hace referencia dentro del enlace. Te pondré un ejemplo: puedes obtener más información sobre diferentes tipos de discapacidad en este artículo del W3C. Ahora el lector de pantalla comunicará: "diferentes tipos de discapacidad, enlace". ¡Beneficio!

Consejo: optimice los enlaces repetidos

Me imagino que no querrás incluir el título en cada enlace "Leer más" bajo una lista de artículos. Añadiría mucho desorden a la página. Hay una serie de diferentes enfoques sobre cómo hacer accesibles los enlaces "leer más", y difiere según el caso de uso cuál funcionaría mejor. En el resumen de este blog, optamos por optimizar los enlaces para lectores de pantalla añadiendo una etiqueta aria que incluye el título del artículo.

Error 4: Depender de las imágenes como única forma de transmitir información

Como soy un pensador visual, sé lo fácil que puede ser entender algo a partir de una imagen en lugar de leer un texto. No voy a afirmar que utilizar imágenes para explicar o hacer referencia en una explicación sea malo. De hecho, animaría a todo el mundo a utilizar imágenes de esa manera, ya que para algunas deficiencias (como la dislexia) en realidad mejora la accesibilidad. Sin embargo, utilizar imágenes como única forma de transmitir información es una mala práctica.

En todo el mundo, alrededor de 43 millones de personas son ciegas y unos 295 millones padecen deficiencias visuales de moderadas a graves. Esta cifra no solo incluye la ceguera total, sino también, por ejemplo, la pérdida de visión central o periférica y la visión borrosa. Si depende de las imágenes para explicar sus argumentos, corre el riesgo de que parte de su público se pierda gran parte de la información.

Capturas de pantalla

Un ejemplo real de este problema es explicar cómo utilizar una interfaz mediante capturas de pantalla. El texto se limita a decir: "haga clic en el botón marcado en la captura de pantalla" o "establezca su configuración como se hace en la siguiente captura de pantalla". Sin estas imágenes, saber qué hacer con esas instrucciones es imposible. Teniendo en cuenta que este tipo de artículos suelen encontrarse en bancos de conocimientos, documentación o tutoriales, resulta aún más problemático.

Ejemplo de una captura de pantalla de nuestro Centro de ayuda. El texto que acompaña al artículo de ayuda dice "Puede ajustar la configuración de su categoría de Pase seleccionando Editar".

Consejo: el texto debe ser comprensible sin imágenes

Su público debe ser capaz de entender la información sin las imágenes. Con instrucciones tanto en texto como en imágenes, su lector puede elegir su forma preferida de tomar la información o tiene un recurso en caso de impedimento. Un truco que utilizo personalmente es escribir el texto en su totalidad y añadir las imágenes después, como hice para este artículo del blog. De este modo, no caeré en la trampa de omitir información porque era visible en una imagen mientras escribía.

Falta de texto alternativo

A menudo, las imágenes informativas que encontrará en los sitios web tienen un texto alternativo pobre o no lo tienen en absoluto. El objetivo de los textos alternativos es describir la imagen para los usuarios de lectores de pantalla. Si se deja vacío, los usuarios de lectores de pantalla no sabrán qué hay en la imagen o si se han perdido alguna información importante.

Consejo: añada textos alternativos a las imágenes funcionales e informativas

El texto alternativo se comunicará a un usuario que no pueda ver la imagen (correctamente). Yo animaría a todo el mundo a no ignorar esto, sino a añadir un texto alternativo descriptivo claro para la imagen. Esto se puede hacer en el código fuente. En un CMS, a menudo hay un campo de entrada dedicado para ello.

Consejo: trate de forma diferente las imágenes decorativas para lectores de pantalla

A veces, las imágenes sólo se añaden como decoración para hacer una página más atractiva visualmente. A veces es mejor que un lector de pantalla omita por completo las imágenes. Existen diferentes enfoques sobre cómo manejar textos alternativos en función del objetivo de la imagen.

Texto en imágenes

El texto en imágenes tampoco es comprensible para las personas con discapacidad visual. Te sorprendería la cantidad de texto que hay dentro de las imágenes (basta con mirar en cualquier plataforma de redes sociales). Una vez más, esto no es malo por sí solo, pero asegúrate de añadir el texto en una descripción o como texto alternativo también.

Error 5: Mal contraste de colores

Elegir un elemento HTML por su significado, no por su aspecto

El texto de bajo contraste fue el problema de accesibilidad más comúnmente detectado por las pruebas automatizadas realizadas por WebAIM. Esto no sólo es problemático para las personas que padecen baja visión, sino que también afecta a las personas con deficiencia de visión cromática (distintos tipos de daltonismo). Alrededor de 1 de cada 12 hombres y 1 de cada 200 mujeres tienen algún grado de deficiencia de visión cromática. Algunas personas ni siquiera son conscientes de que la padecen. Si miras la imagen de abajo, ¿qué número ves?

Which number do you see? Image source

Si ve 74, es posible que tenga una visión cromática normal. Si ve 21 o no ve ningún número, es posible que tenga una deficiencia de visión cromática rojo-verde. En ese caso, es posible que te hayas encontrado con páginas web con partes difíciles de leer.

En las WCAG se define un Criterio de éxito para cuando el contraste entre el texto y su fondo es lo suficientemente alto como para que las personas con visión moderadamente baja puedan leerlo. Las directrices de WCAG se clasifican en tres niveles de conformidad. En Easy LMS, nuestro objetivo es el nivel AA. Estos ratios de contraste son 4,5:1 para texto pequeño y 3:1 para texto grande.

Consejo: utilice una herramienta para comprobar el contraste de color

Entonces, ¿cómo averiguar si el contraste del texto es lo suficientemente alto? Existen muchas herramientas de contraste de color disponibles que puede utilizar para realizar pruebas en su página web. También puede comprobar el contraste de color manualmente introduciendo los códigos de color del primer plano y del fondo en un comprobador de contraste en línea.

Consejo: utilice tonos más oscuros o más claros de un color

Un problema que suele surgir con este asunto es que los colores utilizados en la interfaz de usuario coinciden con los colores del logotipo de la marca. Esto puede dificultar la solución, ya que los colores parecen formar parte de la identidad de la marca. Una buena práctica es utilizar un tono más oscuro o más claro del color deseado para mejorar el contraste. Ajustamos los colores de Easy LMS por este motivo ¡hace un par de años!

Utilizar el color como única forma de transmitir información

Antes he mencionado los problemas que se derivan de utilizar imágenes como única forma de transmitir información. Lo mismo ocurre con los colores. Los colores rojo y verde se utilizan a menudo como única forma de informar sobre los estados de éxito y error. Por desgracia, el daltonismo rojo-verde es el tipo más común de daltonismo. Para estos usuarios afectados, el rojo y el verde se verán iguales.

Consejo: ofrezca múltiples formas de comunicar los estados

Está bien seguir utilizando el rojo y el verde para estos fines, pero asegúrate de proporcionar siempre otra forma de comunicar los estados, como texto, formas diferentes o iconos (etiquetados).

Error 6: No proporcionar una indicación visual del enfoque actual

La mayoría de los usuarios navegan por sus ordenadores con un dispositivo señalador, como un ratón o un trackpad en un portátil. En los dispositivos móviles, utilizamos los dedos en una pantalla táctil. Para algunos usuarios esto es difícil o imposible debido a su discapacidad. Algunos ejemplos son la parálisis, la falta de una parte del cuerpo, la artritis o las lesiones por esfuerzo repetitivo. En estos casos, los usuarios suelen cambiar a un teclado o a un dispositivo de entrada alternativo que pueda imitar el comportamiento del teclado. Los usuarios con discapacidad visual suelen utilizar un teclado junto con su lector de pantalla o gestos en sus dispositivos móviles.

Si pulsas la tecla Tab del teclado, puedes saltar entre elementos interactivos de una página web, como botones y enlaces. Puedes probarlo en esta página: después de cada tabulación, verás una indicación visual de tu ubicación en la pantalla.

Estilos de enfoque CSS

En CSS, puedes añadir estilos para varios estados diferentes de los botones, como "hover", "focus" y "active". A menudo, algunos o todos estos estados se omiten y el botón no cambia de aspecto con la interacción. En este caso, un usuario de teclado está volando a ciegas.

Consejo: aplique estilos de enfoque junto con los estilos hover

Mientras añades estilos para el estado hover de los botones, es una buena práctica añadirlos también para los estados focus. Lo ideal es que el estilo de enfoque sea más evidente que el estilo hover, por lo que también puedes añadirlos por separado en un tono diferente.

Contorno de enfoque del navegador

Un indicador básico de enfoque es proporcionado automáticamente por el navegador web y normalmente se muestra como un borde. Si acaba de navegar por esta página, es posible que lo haya visto. Lamentablemente, este contorno suele desactivarse con CSS, por razones estéticas. Pero con el contorno desactivado y sin estilos de enfoque, es imposible navegar por una página web sólo con el teclado.

Consejo: no desactive el contorno

Los usuarios de ratón no verán el contorno del navegador que se ve al desplazarse por una página web con un teclado. No deshabilites este contorno con CSS, ya que es una ayuda esencial para los usuarios con discapacidad. También funciona muy bien como respaldo en caso de que tus estilos de enfoque sean demasiado confusos o falten por accidente.

Tenga en cuenta que los indicadores de enfoque del teclado de los navegadores pueden variar y adoptar distintas formas. Por eso, no puedes fiarte completamente de ellos. Por otro lado, se necesitarían muchas pruebas para saber con seguridad si tus estilos de enfoque son lo suficientemente claros para los usuarios con discapacidad. Por eso te aconsejo que siempre tengas ambos.

Error 7: Utilizar iconos sin etiquetar en botones y enlaces

Los iconos de los programas informáticos se reconocen con el uso repetido.

Los iconos son una forma estupenda de evitar el desorden en su producto en línea. Además, pueden mejorar la accesibilidad para diversas discapacidades, siempre que no sean ambiguos. La mayoría sabemos que un icono de lápiz significa "editar" y una papelera, "borrar". Cuando utilizamos iconos en una interfaz de usuario, es mejor ceñirse a los que conocemos para evitar adivinanzas. Pero incluso así, en términos de accesibilidad, muchas cosas pueden salir mal.

Los iconos pueden utilizarse junto a su correspondiente etiqueta de texto o solos. La mayoría de las veces, no se proporciona ninguna etiqueta cuando están solos. Por ejemplo, añado un botón de icono para una acción de edición, con sólo un icono de un lápiz dentro. Si no añado una etiqueta de texto para este icono, el botón se convierte en un botón vacío. Así es: un lector de pantalla me comunicará: "Botón". Eso no es muy útil.
Más aún: Estoy suponiendo que el usuario sabrá que el icono de un lápiz significa "editar". Pero no lo sé con certeza.

Consejo: añada una etiqueta a los iconos

Si el icono es una parte importante de su Interfaz de Usuario, entonces es mejor añadir una etiqueta. Puede hacerlo añadiendo un aria-label en el icono. Una segunda forma es añadir texto que oculta para pantallas, pero es visible para usuarios de lectores de pantalla. Lo mejor es añadir un atributo de título también. De esta forma, si un usuario pasa el ratón por encima, se mostrará la etiqueta.

Botones con iconos en el panel de control de Easy LMS que muestran un título al pasar el ratón por encima.

Consejo: ocultar iconos decorativos

Si has añadido un icono puramente como azúcar en la parte superior y la información es comprensible sin él, entonces lo mejor es ocultar el elemento para usuarios de lectores de pantalla.

Conclusión: no trabajes más; trabaja más inteligentemente

Pensar que tienes que cambiar estas cosas puede seguir siendo un poco abrumador. Cuando conocí la accesibilidad, tuve la misma reacción. Hay tanto que aprender y tantos tipos diferentes de discapacidad. Es difícil hacer una interfaz de usuario perfecta para todo el mundo.

Pero quiero decirte: no se trata de revisar tu producto o tu sitio web. He descubierto que la mejor manera de que esto funcione es integrarlo en tu flujo de trabajo. La próxima vez que cree o itere sobre la parte del producto, aplico lo que he aprendido sobre accesibilidad de inmediato. De esta forma, podemos mejorar la accesibilidad paso a paso. Como aconseja uno de mis héroes de la accesibilidad Léonie Watson: "No tiene que ser perfecto; sólo tiene que ser un poco mejor que ayer". ¡Predica!