Detección de barreras de accesibilidad con TAW

El Test de Accesibilidad Web (TAW) es una herramienta en línea que ayuda a evaluar la accesibilidad de sitios web según las directrices del estándar WCAG (Web Content Accessibility Guidelines). Diseñada para identificar problemas de accesibilidad, TAW es especialmente útil para desarrolladores, diseñadores y responsables de contenido que desean crear experiencias inclusivas para todos los usuarios, incluidas personas con discapacidad.

Al igual que Wave, TAW es una herramienta de validación automática de barreras de accesibilidad web.

Esta herramienta evalúa criterios como:
• Texto alternativo en imágenes.
• Contraste de colores.
• Navegación mediante teclado.
• Uso correcto de etiquetas HTML y roles ARIA.

¿Cómo utilizar TAW?

Para utilizar TAW debemos visitar su sitio web oficial. Allí encontraremos un formulario en el que introducir la URL de la página que queremos revisar. Además, dentro de las opciones podremos elegir entre nivel A, nivel AA y nivel AAA. Tras introducir la dirección de la página que queremos evaluar debemos pulsar el botón analizar.

Tras unos segundos se nos cargará la página de resultados.

A diferencia de Wave y otras herramientas automáticas TAW no dispone de widget para revisar páginas en local. Además TAW utiliza WCAG 2.1 frente a otras herramientas que poco a poco van incorporando WCAG 2.2.

Comparando herramientas

Si realizamos una evaluación con TAW y Wave podremos comprobar que los informes de resultados son parecidos pero no exactamente iguales. Esto se debe a que los algoritmos de detección de barreras utilizados por TAW y Wave no son iguales aunque utilicen los criterios e interpretaciones definidos en WCAG.

TAW proporciona la información en español y portugués por lo que se hace más sencillo de consultar para personas que desarrollen o diseñen en estas lenguas.

Lo ideal es poder utilizar estas dos herramientas para procurar que todas las barreras posibles sean solucionadas. Siempre recordando que las herramientas automáticas de validación de barreras de accesibilidad no son 100% efectivas ni fiables.

Detección de barreras de accesibilidad con Wave

WAVE (Web Accessibility Evaluation Tool) es una herramienta en línea gratuita desarrollada por WebAIM (Web Accessibility In Mind). Su propósito es ayudar a identificar errores y áreas de mejora en sitios web para garantizar el cumplimiento de las directrices de accesibilidad, como las WCAG (Web Content Accessibility Guidelines). WAVE no solo resalta los problemas, sino que también proporciona sugerencias para corregirlos.

El acceso a WAVE es sencillo: basta con visitar la página de Wave, ingresar la URL del sitio web a evaluar, y recibir un análisis detallado sobre elementos clave de accesibilidad.

También podemos instalar el Widget de Wave para Chrome o Firefox. Esto nos permitirá evaluar contenido en local por lo que resulta indispensable para desarrolladores que están trabajando en contenidos aún no publicados.

Wave es una herramienta ideal para conocer el estado de accesibilidad de una página web y aunque la información que nos ofrece es muy valiosa no hay que olvidar los límites y realidades de las herramientas automáticas.

Detección y validación de barreras de accesibilidad con herramientas automáticas

La accesibilidad web es fundamental para garantizar que todas las personas, independientemente de sus habilidades o discapacidades, puedan acceder y utilizar los contenidos en línea.
Para los desarrolladores y diseñadores las herramientas automáticas de validación de la accesibilidad ofrecen una manera eficiente de identificar problemas de accesibilidad en sus sitios web. Sin embargo, este tipo de herramientas automáticas poseen ventajas y limitaciones que deben ser conocidas por estos diseñadores y desarrolladores.

Algunas cuestiones, como el significado contextual del contenido, la calidad de los textos alternativos o la utilidad de la navegación, requieren juicio humano. Esto implica que algunos criterios de éxito de WCAG deben ser validados por una persona ya que hoy por hoy las herramientas automáticas carecen del conocimiento y la identificación del contexto de un contenido para poder identificar si existe una barrera de accesibilidad o no. Por ejemplo, una herramienta automática puede dar por válida la siguiente descripción para una imagen que se utiliza como botón cancelar: ‘iconCancel12.jpg’, o indicar que hay problemas por usar ARIA aunque se esté utilizando de forma apropiada.

Estas herramientas tampoco pueden apreciar posibles problemas de usabilidad o inconsistencias entre los mecanismos de navegación de varias páginas.

Unido a todo esto se ha de indicar que muchas de las herramientas automáticas de validación de barreras de accesibilidad no detectan los cambios dinámicos realizados mediante Javascript en los contenidos por lo que en muchos casos de webApps desarrolladas con ReactJS o Angular pueden incorporar multitud de barreras de accesibilidad indetectables para este tipo de herramientas.

Los resultados de las evaluaciones realizadas por estas herramientas necesitan ser interpretados y aplicados por personas con conocimientos básicos en accesibilidad y desarrollo web. Sin este conocimiento, las correcciones pueden no ser efectivas o incluso empeorar la accesibilidad. Con esto se indica que es falsa la afirmación de que gracias a estas herramientas el desarrollador no requiere ningún conocimiento de accesibilidad web.

A pesar de todo esto las herramientas automáticas de validación de la accesibilidad son necesarias para ayudar a la detección temprana de muchas barreras de accesibilidad y deberían ser de uso obligatorio para los desarrolladores y diseñadores de contenido.

Introducción a Markdown

Markdown es un lenguaje de marcado ligero diseñado para facilitar la escritura de texto formateado de manera sencilla y sin distracciones. Su propósito principal es convertir texto plano en HTML sin necesidad de aprender complejas etiquetas o reglas de maquetado.
Este formato de texto se ha convertido en una herramienta esencial para desarrolladores, escritores y creadores de contenido por su simplicidad, versatilidad y beneficios, especialmente en términos de accesibilidad y fácil mantenimiento.

Markdown fue creado por Aaron Swartz y John Gruber en 2004 con la intención de que los documentos fueran fáciles de escribir y leer en su forma original, y a la vez, que pudieran convertirse fácilmente en HTML para la web. Su estructura se basa en texto plano, lo que significa que cualquier persona puede leer y escribir Markdown con un editor de texto básico.
Markdown es ampliamente utilizado en blogs, documentación técnica, ficheros README de proyectos en GitHub, foros y mensajes en algunas redes sociales.

Dentro de las ventajas de Markdown se destacan su simplicidad y su portabilidad.
Markdown utiliza una sintaxis mínima que es fácil de aprender. No necesitas herramientas sofisticadas ni experiencia previa para comenzar a escribir.
Los archivos Markdown son simplemente texto plano, lo que significa que son extremadamente ligeros y se pueden abrir en cualquier dispositivo o sistema operativo.
Además de todo esto se ha de indicar que Markdown se puede convertir fácilmente a formatos más ricos como HTML, PDF, DOCX o incluso ePub, usando herramientas automáticas.

Cómo Escribir con Markdown

La sintaxis de Markdown es extremadamente sencilla, principalmente se utilizan algunos caracteres especiales al comienzo de línea o para indicar el comienzo y la finalización de un bloque marcado semánticamente.

Texto en Negrita y Cursiva

Para marcar en negrita un texto se usa doble asterisco.
Para marcar en  cursiva, se usa un solo asterisco.

Ejemplos:

**Este texto está en negrita**
*Este texto está en cursiva*

Encabezados

Los encabezados se crean utilizando el símbolo # al comienzo de una línea. El número de # define el nivel del encabezado (de 1 a 6).

Ejemplo:

# Encabezado de nivel 1
## Encabezado de nivel 2
### Encabezado de nivel 3

Enlaces

Los enlaces se crean utilizando corchetes para el texto y paréntesis para la URL.

Ejemplo:

Visita mi blog [Programar a ciegas](https://programaraciegas.net) para leer más artículos como este.

Listas

Se pueden crear listas ordenadas o desordenadas utilizando un marcador al comienzo de línea.

• Listas no ordenadas: Utiliza guiones (-) o asteriscos (*).
• Listas ordenadas: Usa números seguidos de un punto (1., 2., etc.).

Ejemplos:

- Elemento 1 de una lista desordenada
- Elemento 2 de una lista desordenada

1. Primer elemento de una lista ordenada
2. Segundo elemento de una lista ordenada

Imágenes

El formato que se utiliza para mostrar imágenes es similar al formato empleado para los enlaces, pero con un signo de exclamación al principio. Ejemplo:

![Texto alternativo que describe la imagen](ruta/a/la/imagen.jpg)

Bloques de Código

Para marcar bloques de código, se utiliza tres acentos graves («`) antes y después del código.

Ejemplo:

```
func saludo() {
print("¡Hola, Markdown!")
}


```

Markdown admite otras marcas para resaltar citas, maquetar datos tabulares y otros elementos semánticos.

La importancia de los encabezados para la accesibilidad web y móvil

Cuando navegamos por una interfaz web o una aplicación móvil, probablemente no somos conscientes de la importancia que tienen los encabezados. Para la mayoría de los usuarios estas marcas semánticas sólo se aprecian por un cambio de tamaño del texto o por un resaltado de su aspecto visual pero para personas con discapacidad visual o cognitiva resultan imprescindibles para comprender mejor la interfaz que están navegando.

¿Qué son los encabezados?

Los encabezados son elementos que organizan y estructuran el contenido de una página o pantalla. En HTML, estos se definen mediante marcas semánticas o etiquetas como <h1>, <h2>, <h3>, y así sucesivamente hasta <h6>. En interfaces móviles, los encabezados suelen representarse como texto destacado o títulos que dividen secciones de contenido y utilizan atributos de la API de accesibilidad para que esos bloques de texto sean identificados como encabezados semánticos.

Para los usuarios sin discapacidad visual, los encabezados facilitan una comprensión visual rápida del contenido y su jerarquía. en cambio, para los usuarios que dependen de tecnologías de asistencia como lectores de pantalla, los encabezados son mucho más que un simple formato: son un mapa estructural que permite moverse rápidamente por la página o la app.

Por ejemplo, una persona ciega que usa un lector de pantalla puede saltar entre los encabezados para encontrar secciones específicas sin tener que escuchar todo el contenido desde el principio. Esto es especialmente útil en páginas con mucho texto o pantallas móviles con varias secciones de información.
Para las personas con discapacidad cognitiva esta estructura de encabezados les permite asimilar y comprender cómo se ha estructurado la información y los elementos de navegación en la interfaz.

Encabezados en WCAG

Las Pautas de Accesibilidad para el Contenido Web (WCAG) incluyen un criterio específico que aborda la correcta implementación de los encabezados. Este criterio está relacionado con el principio de Perceptible y se resume así:

Criterio 2.4.10 – Encabezados de sección (Section Headings)

Este criterio establece que, si el contenido está dividido en secciones, cada una debe contar con un encabezado descriptivo que refleje su propósito o tema. Esto no solo mejora la navegación, sino también la comprensión del contenido. Puedes leer más detalles sobre el criterio 2.4.10 en la página oficial del W3C.

Para cumplir con este criterio debemos asegurarnos de:
• Usar encabezados de forma jerárquica y lógica (por ejemplo, <h1> para el título principal, <h2> para subtítulos, etc.).
• Los encabezados deben ser descriptivos. Un encabezado como “Servicios” es claro, pero uno como “Más información” es ambiguo.
• Evitar saltos innecesarios en los niveles de encabezado (por ejemplo, pasar de un <h1> directamente a un <h3> sin un <h2> intermedio).

Buenas prácticas

A la hora de estructurar los contenidos de una interfaz web o de una pantalla de una aplicación es aconsejable seguir los siguientes puntos:
1. Respetar una estructura jerárquica

El encabezado principal de la página o pantalla debe ser un <h1>. A partir de ahí, usa <h2> para las subsecciones principales, <h3> para las subsecciones de estas, y así sucesivamente. Esto crea un flujo lógico que las tecnologías de asistencia pueden interpretar fácilmente.

Ejemplo en HTML:

<h1>Recetas saludables</h1>
<h2>Desayunos</h2>
<h3>Zumos y batidos saludables</h3>
<h3>Tostadas con aguacate</h3>
<h2>Cenas</h2>
<h3>Ensaladas ligeras</h3>
<h3>Sopas nutritivas</h3>

2. Prohibido usar encabezados para aplicar un estilo visual a un texto

Es común usar etiquetas de encabezado simplemente porque hacen el texto más grande o más llamativo. Esto es un error, ya que confunde a los usuarios de lectores de pantalla. Si es necesario aplicar un estilo concreto a un texto grande sin que sea un encabezado, es aconsejable usar estilos CSS en lugar de etiquetas como <h1>.

3. Los encabezados deben ser claros y concisos

Un buen encabezado es breve y refleja con precisión el contenido de su sección. Por ejemplo, “Configuración avanzada” es mejor que “Detalles sobre las configuraciones avanzadas”.

Cómo comprobar la accesibilidad de los encabezados

Muchas herramientas automatizadas para la detección de barreras de accesibilidad identifican la mayoría de problemas relacionados con el criterio WCAG 2.4.10. Tanto Wave como Lighthouse o Axe pueden detectar si falta algún encabezado o si se han utilizado de manera incorrecta.
En cualquier caso es muy recomendable realizar una verificación manual utilizando un lector de pantallas como NVDA, VoiceOver, TalkBack o JAWS. Todos estos lectores de pantalla incorporan funciones para navegar por encabezados o mostrar una lista con los encabezados detectados.

Los Beneficios y Desafíos de la Accesibilidad en Herramientas Low-Code y No-Code para la Creación de Software

En los últimos años, el auge de las herramientas low-code y no-code ha revolucionado la manera de desarrollar software. Estas plataformas han permitido el acceso al desarrollo de software, permitiendo que personas sin conocimientos avanzados de programación puedan crear sus propias aplicaciones, automatizaciones y sitios web. Sin embargo, para personas con discapacidad, estas herramientas presentan barreras significativas de accesibilidad.

¿Qué son las Herramientas Low-Code y No-Code?

Las herramientas low-code y no-code son paquetes de aplicaciones que permiten crear aplicaciones mediante interfaces gráficas y flujos visuales, reduciendo o eliminando la necesidad de escribir código manualmente. Estas plataformas están diseñadas para ser intuitivas, ofreciendo funciones como arrastrar y soltar (drag-and-drop), plantillas preconstruidas y bloques modulares para construir aplicaciones rápidamente.
Herramientas de lowCode como OutSystems, o Mendix presentan interfaces visualmente sencillas pero que contienen multitud de barreras de accesibilidad que impiden que un producto de apoyo como un lector de pantallas pueda transmitir la información a la persona ciega o interactuar con los elementos de la herramienta para colocar los componentes que darán forma al nuevo software.
Pero, además, herramientas noCode como Webflow o Bubble, enfocadas en la creación de aplicaciones y sitios web, además de resultar inaccesibles para personas que utilicen productos de apoyo, crean contenidos web que presentan barreras de accesibilidad perpetuando así el problema de una Web no accesible.

Beneficios de las Herramientas Low-Code y No-Code

Uno de los mayores beneficios es la posibilidad de que personas sin experiencia técnica puedan materializar sus ideas tecnológicas. Ya no es necesario depender exclusivamente de desarrolladores o equipos técnicos para crear prototipos o soluciones funcionales.
Además, la velocidad con la que se puede pasar de la idea a un producto mínimo viable (MVP) es uno de los mayores atractivos de estas plataformas. Las empresas pueden lanzar productos en menos tiempo, respondiendo más rápido a las necesidades del mercado.

Un gran poder conlleva una gran responsabilidad

La posibilidad de crear rápidamente y sin demasiados conocimientos nuevas experiencias y contenidos digitales es algo muy atractivo para muchas personas que bien no pueden o no quieren invertir mucho tiempo y esfuerzo en aprender aspectos del desarrollo de software. El problema es que este tipo de herramientas no permiten modificar la forma en que se generan esos contenidos y experiencias y en muchos casos lo hacen incluyendo barreras de accesibilidad. No está claro quién es la persona responsable de solucionar este problema: la persona que utiliza la herramienta pero no puede o no quiere aprender a desarrollar software o la empresa que ha creado la herramienta pero que no quiere complicar la experiencia de creación incluyendo aspectos de accesibilidad para así resultar una herramienta más atractiva a personas que no se quieren complicar con aspectos técnicos del desarrollo de software.

Iniciativas para Mejorar la Accesibilidad

Afortunadamente, algunas plataformas están comenzando a abordar estos desafíos. Por ejemplo, Webflow ha incorporado herramientas que permiten a los diseñadores agregar etiquetas y descripciones accesibles a los elementos. Bubble ofrece cierta flexibilidad para personalizar cómo se presentan los componentes en una aplicación para que sean más accesibles. Sin embargo, aún queda un largo camino por recorrer para garantizar que estas herramientas sean completamente inclusivas para todos los usuarios en esos contenidos web generados sin ninguna línea de código por parte de la persona que los crea.
Además, estas soluciones y parches siempre están enfocadas en el software generado y no en el uso de la propia herramienta por lo que los creadores de estas herramientas sólo piensan en personas con discapacidad como posibles clientes y no como posibles trabajadores o creadores.
Los hechos mencionados en el artículo publicado en el 2010 con el título La accesibilidad en crisis para los desarrolladores ciegos parece que siguen presentes en la sociedad actual.