Este es el tercero de una serie que estoy escribiendo sobre experiencias web accesibles. En el primer artículo, “La ADA y el diseño universal: ¿Por qué desarrollamos experiencias web accesibles?“Discutí el “por qué” del diseño digital accesible. En “La ADA y el diseño universal: construyendo un plan mejor”, hablé sobre cómo crear personajes, recorridos de usuario, mapas de sitios y wireframes coherentes con los principios del diseño universal. En este artículo, analizaré técnicas para hacer que las experiencias web sean accesibles para lectores de pantalla y otros dispositivos de asistencia.

Imagínese esta experiencia: accede a un sitio web para buscar información importante que necesita para hacer su trabajo, o para pedir que le renueven una receta médica importante, o para descargar el nuevo álbum que acaba de lanzar su banda favorita.

Navegas hasta el sitio, pero tienes que buscar durante cinco minutos antes de encontrar la barra de búsqueda. (Estaba enterrada en la parte inferior del pie de página, debajo del aviso de copyright). Encuentras un formulario que tiene la etiqueta “formulario”. El formulario tiene un campo de texto que tiene la etiqueta “genérico” y te pide que ingreses “campo de texto”. En la parte inferior, hay un botón con la etiqueta “botón”. Mientras intentas descifrarlo todo, la página se agota y tienes que comenzar de nuevo. (Apareció una alerta de cuenta regresiva para advertirte, pero no te diste cuenta).

¿Cómo va tu experiencia hasta ahora? ¿Encontraste lo que necesitabas? ¿Sientes que tu tiempo valió la pena? ¿O estás listo para abandonar el sitio y probar en otro lugar?

Esto es análogo a la experiencia de alguien que accede a un sitio web con un lector de pantalla u otra tecnología de asistencia cuando el sitio no ha sido desarrollado de acuerdo con las mejores prácticas de diseño de sitios web accesibles.

ARIA al rescate

Para abordar este creciente problema, el W3C creó elIniciativa de Accesibilidad Web: Aplicaciones de Internet enriquecidas y accesibles(WAI-ARIA, o simplemente ARIA). ARIA es un marco de atributos que se pueden agregar a elementos HTML para brindar contexto adicional e información alternativa basada en texto. Los atributos ARIA hacen que las aplicaciones web sean más accesibles para las personas que usan lectores de pantalla, pantallas braille, navegación solo con teclado y otras tecnologías de asistencia.

Tenga en cuenta que los atributos ARIAsoloMejorar las experiencias web para quienes utilizan tecnologías de asistencia. Mi premisa en esta serie ha sido que el diseño web accesible hace que los sitios web sean mejores para todos, no solo para las personas con discapacidades. Creo que eso es cierto incluso en este caso, porque ARIA nos obliga a analizar en profundidad la organización y las interacciones de nuestras experiencias web.

Como explicaré en mi primera práctica recomendada, la mejor solución no es crear una experiencia separada para los usuarios con discapacidades. Si estás usando ARIA para modificar sustancialmente tu experiencia web, te recomiendo que en lugar de eso reconsideres la experiencia que estás creando para todos. Muchas correcciones de ARIA se volverán innecesarias… y tus sitios web serán mejores para todos.

Mejores prácticas para ARIA

#1: Comience con HTML semántico

No utilices ARIA de calidad en HTML de mala calidad. Cuando desarrolles sitios que utilicen HTML semántico bien formado, no necesitarás depender en gran medida de los atributos ARIA para hacerlos accesibles.

Si su aplicación web utiliza undivelemento como un botón, una función ARIA puede informar a los lectores de pantalla que es un botón:

div tabIndex=”0″ role=”button” aria-pressed=”false”Ordenar Batido/div

¿Pero por qué no utilizar HTML semántico?

buttonPedir batido/button

Es más adaptable, más legible por máquinas e incluso puede mejorar su SEO.

Hay algunos escenarios en los que no se puede utilizar HTML semántico:

• Es el código de otra persona y no tienes autoridad para cambiarlo.
• Es un código heredado y no tienes presupuesto para arreglarlo.
• Las pantallas y dispositivos requeridos no admiten el elemento semántico.
• HTML5 no especifica el elemento semántico que necesitas.

En estos casos, no tienes más opción que fijar elementos genéricos con atributos ARIA. Pero siempre que puedas elegir, utiliza HTML semántico.

#2: Diseñar un mejor DOM

Es posible que ya sepa cómo un modelo de objetos de documento (DOM) bien estructurado puede mejorar el SEO. Esto ocurre con mayor frecuencia cuando JavaScript manipula el DOM, a veces de maneras que los motores de búsqueda tienen dificultades para rastrear. Pero incluso algunas prácticas de SEO rudimentarias se basan fundamentalmente en el DOM.

Cuando se encadenan un montón dedivyspanLos elementos, los motores de búsqueda y las tecnologías de asistencia no tienen una estructura que los guíe. Solo ven una colección de contenido genérico.

En lugar de eso, organice su contenido de manera lógica ensección, artículo, aparte, h1-h6, y otros elementos semánticos. Haga que la estructura del documento sea mucho más explícita y que las tecnologías de asistencia puedan navegar con mayor facilidad. (Las arañas de los motores de búsqueda también se lo agradecerán).

#3: Recortar el árbol de accesibilidad

El árbol de accesibilidad de un documento web es una transformación del DOM, que el navegador genera y pone a disposición de las tecnologías de asistencia. Es a la vez más y menos que el DOM. Los navegadores eliminan información superflua y añaden información adicional (a veces computacional) para ayudar a las personas que utilizan tecnologías de asistencia.

Inspeccione el árbol de accesibilidad de su aplicación web para ver qué información se enviará a las tecnologías de asistencia. ¿Qué información importante falta? ¿Qué información superflua está incluida? ¿Qué información genérica podría ser más precisa?

Haz una lista y luego vuelve a las prácticas recomendadas n.° 1 y n.° 2. ¿Puedes agregar la información faltante al DOM? ¿Esa información superflua debería estar en tu aplicación web? ¿Puedes usar HTML semántico más informativo?

Si puede arreglar el árbol de accesibilidad con las técnicas anteriores, hágalo. Esto generará una estructura de documento más clara y un código más limpio. Los motores de búsqueda y las tecnologías de asistencia lo entenderán mejor.

Pero habrá ocasiones en las que no se pueda arreglar el árbol de accesibilidad de estas formas. En ese caso, es hora de usar un poco de ARIA.

#4: Aplique de forma ligera los puntos de referencia ARIA y otros roles

Analizamos brevemente los roles de ARIA en el ejemplo n.° 1. Te recomiendo que utilices HTML semántico en su lugar.

Sin embargo,HTML5 no especifica todos los elementos semánticos que podrías necesitarpara crear su aplicación web. Incluso cuando lo hace, algunos elementos no son compatibles con todas las pantallas y dispositivos. Estos elementos incluyen características comunes de las experiencias web modernas, como menús desplegables y de hamburguesa, ventanas emergentes y alertas.

Los roles ARIA cierran la brecha de accesibilidad al definir explícitamente el rol semántico de un elemento. Los puntos de referencia ARIA son un subconjunto de roles que definen las áreas de contenido principales de un documento, como un menú de navegación o una herramienta de búsqueda.

Las alertas, por ejemplo, transmiten información urgente que el usuario debe leer de inmediato. Sin embargo, no existealertaElemento en HTML para transmitir esta urgencia a las tecnologías de asistencia. Aquí es donde entra en juego la función ARIA.

p role=”alert”El número CSV es necesario para completar su pedido./p

Con el”alerta”conjunto de roles, los lectores de pantalla anunciarán inmediatamente la alerta y leerán el texto que contiene.

#5: Complete los espacios vacíos finales con estados y propiedades ARIA

Por último, tenemos los estados y propiedades de ARIA. Estos atributos de ARIA tienen un lugar en las experiencias web accesibles, pero debes usarlos solo después de aprovechar al máximo las prácticas 1 a 4.

En mi agencia, más del 90 % del uso de atributos ARIA se reduce a los roles y puntos de referencia en el n.° 4 y tres propiedades ARIA:

• etiqueta ariapara describir elementos sin etiqueta de texto visible, como menús de hamburguesa
• aria-etiquetadaporpara identificar otro elemento cuyo texto etiqueta el elemento
• aria-descrita porpara identificar otro elemento que tenga información adicional sobre el elemento

Conclusión

Al crear experiencias web accesibles, saber cuándo no usar etiquetas ARIA es tan importante como saber cuándo sí. Utilice la lente de ARIA para examinar sus aplicaciones web más profundamente. Hágalas lo más accesibles posible sin agregar ARIA, luego utilice los roles, propiedades y estados de ARIA para completar el resto del proceso. Terminará con una aplicación de Internet enriquecida que funcione mejor para todos.