Dar sentido a WAI-ARIA: una guía completa

1. HTML
2. ARIA
3. Roles
4. Estados y propiedades (también conocidos como atributos ARIA)
5. Gestión de enfoque
6. Errores comunes
   1. Usar un aria-labelledbyatributo que haga referencia a una identificación que no existe
   2. No mover el foco al modal cuando se abre
   3. Agregar roles que duplican HTML
   4. Agregar tabindex="0"a cada elemento
   5. Uso de roles secundarios sin roles principales
   6. Uso role="menu"para navegación
7. Cómo validar ARIA
8. Marcos y bibliotecas de componentes
9. Conclusión

En este artículo, Kate Kalcevich explica cuándo usar ARIA y cómo usarlo correctamente para que pueda utilizar ARIA de una manera que sea útil para las muchas personas discapacitadas que utilizan tecnología de asistencia para navegar por Internet. ¡Vamos a sumergirnos!

Este artículo ha contado con el amable apoyo de nuestros queridos amigos de Fable , quienes permiten que su equipo adquiera las habilidades y la confianza necesarias para crear productos inclusivos. Si está listo para incorporar las voces de las personas con discapacidades a sus procesos de capacitación en accesibilidad y desarrollo de productos, reserve una llamada con ellos para obtener más información.

La Iniciativa de Accesibilidad Web: Aplicaciones Ricas de Internet Accesibles (WAI-ARIA) es una especificación técnica que proporciona orientación sobre cómo mejorar la accesibilidad de las aplicaciones web. Mientras que las Pautas de accesibilidad al contenido web (WCAG) se centran más en el contenido web estático, WAI-ARIA se centra en hacer que las interacciones sean más accesibles.

Las interacciones en la web tienen fama de ser inaccesibles y muchas veces forman parte de las funciones más críticas como:

• presentar una solicitud de empleo,
• comprar en una tienda en línea, o
• reservar una cita médica.

Actualmente soy el Jefe de Innovación en Accesibilidad en Fable, una empresa que conecta a organizaciones con personas con discapacidades para realizar investigaciones de usuarios y pruebas de accesibilidad y brinda capacitación personalizada para que los equipos digitales adquieran las habilidades necesarias para crear productos inclusivos.

Como instructor de desarrollo web accesible, dedico mucho tiempo a examinar el código fuente de sitios web y aplicaciones web, y ARIA es una de las cosas que veo que los desarrolladores hacen más mal uso.

HTML

Cuando usa elementos HTML como input, selecty button, hay dos cosas que obtendrá para la accesibilidad: la información sobre el elemento se pasa al DOM (modelo de objetos de documento) y a un árbol de accesibilidad . Las tecnologías de asistencia pueden acceder a los nodos del árbol de accesibilidad para comprender:

• qué tipo de elemento es marcando su función, por ejemplo, casilla de verificación;
• en qué estado se encuentra el elemento, por ejemplo, marcado/no marcado;
• el nombre del elemento, por ejemplo, "Suscríbete a nuestro boletín informativo".

La otra cosa que obtienes al usar elementos HTML es la interactividad del teclado. Por ejemplo, una casilla de verificación se puede enfocar usando la tecla de tabulación y seleccionarse usando la barra espaciadora (las interacciones específicas pueden variar según el navegador y el sistema operativo, pero el punto es que están disponibles y estandarizadas en todos los sitios web cuando se usan elementos HTML).

Cuando no usa HTML, por ejemplo, si crea su propia selección personalizada usando divsys spano usa una biblioteca de componentes, necesita hacer un trabajo adicional para proporcionar información sobre el elemento y crear interactividad de teclado para los usuarios de tecnología de asistencia. Aquí es donde entra en juego ARIA.

ARIA

Las Aplicaciones de Internet enriquecidas accesibles (ARIA) incluyen un conjunto de roles y atributos que definen formas de hacer que el contenido y las aplicaciones web sean más accesibles para las personas con discapacidades.

Puede utilizar ARIA para pasar información al árbol de accesibilidad. Los roles y atributos de ARIA no incluyen ninguna interactividad con el teclado. Agregar role="button”a a divno hace que responda cuando presionas la Entertecla, que debes crear usando JavaScript u otro lenguaje. Sin embargo, la Guía de prácticas de creación de ARIA incluye una lista de qué interactividad de teclado se debe agregar a varios componentes, como acordeones, botones, carruseles, etc.

Roles

Empecemos por los roles. ¿Qué diablos es esto en el siguiente código?

div className="dd-wrapper" div className="dd-header" div className="dd-header-title"/div /div div className="dd-list" button className="dd-list-item"/button button className="dd-list-item"/button button className="dd-list-item"/button /div/div

En realidad, este es un fragmento de código que encontré en línea de un elemento seleccionado para React. El hecho de que el elemento sea completamente irreconocible en el código es exactamente el problema que tendría cualquier tecnología de asistencia: no puede decirle al usuario qué es o cómo interactuar con él porque no existe una función ARIA.

Mira lo que podemos hacer aquí:

div className="dd-wrapper" role="listbox"

Puede que no estés familiarizado con un listbox, pero es un tipo selectque un usuario de lector de pantalla podría reconocer y saber cómo interactuar. Ahora podrías simplemente usar select, y no tendrías que asignarle una función porque ya tiene una que el DOM y el árbol de accesibilidad reconocerán, pero sé que no siempre es una opción factible.

Un rol le dice al usuario de tecnología de asistencia qué es, así que asegúrese de utilizar el rol correcto. Un botón es muy diferente a un banner. Elija una función que coincida con la función del componente que está creando.

Otra cosa que debes saber sobre los roles ARIA es que anulan el rol inherente de un elemento HTML.

img role="button"

Esto ya no es una imagen sino un botón. Hay muy pocas razones para hacer esto y, a menos que sepa exactamente lo que está haciendo y por qué, no anularía las funciones HTML existentes. Hay muchas otras formas de lograr esto que tienen más sentido desde la perspectiva de la accesibilidad y la solidez del código:

buttonimg src="image.png" alt="Print" //button input type="image" src="image.png" alt="Print" /button /Print/button

Si está creando un componente, puede buscar el patrón de ese componente en la Guía de prácticas de creación de ARIA , que incluye información sobre qué funciones utilizar. También puede buscar todos los roles disponibles en los documentos web de mdn .

En resumen, si está creando algo que no tiene una etiqueta HTML semántica que lo describa (es decir, cualquier cosa interactiva creada usando divo span), debe tener una función ARIA para que la tecnología de asistencia pueda reconocer lo que es.

Estados y propiedades (también conocidos como atributos ARIA)

Además de saber qué es un elemento, si tiene un estado (p. ej., hidden, disabled, invalid, readonly, selectedetc.) o cambia de estado (p. ej., checked/ not checked, open/ closed, etc.), es necesario informar a los usuarios de tecnología de asistencia cuál es su estado. es el estado actual y su nuevo estado cada vez que cambia. También puedes compartir ciertas propiedades de un elemento. La diferencia entre estados y propiedades no es realmente clara ni importante , así que llamémoslos simplemente atributos.

Estos son algunos de los atributos ARIA más comunes que podría necesitar utilizar:

• aria-checked
  Se usa con ="true"o ="false"para indicar si las casillas de verificación y los botones de opción están actualmente marcados o no.
• aria-current
  Se usa con ="true"o ="false"para indicar la página actual dentro de las rutas de navegación o paginación.
• aria-describedby
  Se usa con la identificación de un elemento para agregar más información a un campo de formulario además de su etiqueta. aria-describedbyse puede utilizar para dar ejemplos del formato requerido para un campo, por ejemplo, una fecha, o para agregar un mensaje de error a un campo de formulario.

label for="birthday"Birthday/labelinput type="text" aria-describedby="date-format"spanMM-DD-YYYY/span

• aria-expanded
  Se usa con ="true"o ="false"para indicar si al presionar un botón se mostrará más contenido. Los ejemplos incluyen acordeones y elementos de navegación con submenús.

button aria-expanded="false"Products/button

Esto indica que el menú Productos abrirá un submenú (por ejemplo, de diferentes categorías de productos). Si tuvieras que codificarlo así:

a href="/products/"Products/a

Estás estableciendo la expectativa de que sea un enlace y, al hacer clic en él, se accederá a una nueva página. Si no va a ir a una página nueva, pero en realidad permanece en la misma página pero abre un submenú, eso es lo que el botón plus le aria-expandeddice a un usuario de tecnología de asistencia. Esa simple diferencia entre buttony ay la adición de aria-expandedcomunica mucho sobre cómo interactuar con los elementos y qué sucederá cuando lo hagas.

• aria-hidden
  Se usa con algo que es visible ="true"o ="false"para ocultarlo, pero no desea que los usuarios de tecnología de asistencia lo sepan. Úselo con extrema precaución ya que hay muy pocos casos en los que no desee que se presente información equivalente.

Un caso de uso interesante que he visto es una tarjeta con una imagen y el título de texto de la tarjeta que enlazan a la misma página pero estructurados como dos enlaces separados. Imagine muchas de estas tarjetas en una página. Para un usuario de lector de pantalla, escucharía cada enlace leído dos veces. Entonces los enlaces de imágenes utilizados aria-hidden="true". La forma ideal de resolver esto es combinar los enlaces en uno que tenga tanto una imagen como un título de texto, pero la codificación de la vida real no siempre es ideal y no siempre se tiene ese nivel de control.

Tenga en cuenta que esto infringe la cuarta regla de ARIA (a la que llegaremos más adelante), pero lo hace de una manera que no infringe la accesibilidad. Úselo con extrema precaución cuando no haya mejores soluciones y lo haya probado con usuarios de tecnología de asistencia. Viajes y turismo

• aria-required
  Se utiliza con ="true"o ="false"para indicar si se debe completar un elemento del formulario antes de poder enviarlo.

Si está creando un componente, puede buscar los atributos de ese componente en la Guía de prácticas de creación de ARIA . Los documentos web de mdn cubren estados y propiedades, así como roles ARIA.

Tenga en cuenta que todos estos atributos ARIA le dicen algo al usuario, pero aún debe codificar lo que le está diciendo. aria-checked="true"en realidad no marca una casilla de verificación; simplemente le dice al usuario que la casilla de verificación está marcada, por lo que es mejor que sea cierto o empeorará las cosas y no mejorará la accesibilidad. La excepción sería aria-hidden="true"la que elimina un elemento del árbol de accesibilidad, ocultándolo efectivamente de cualquier persona que utilice tecnología de asistencia y no pueda ver.

Ahora sabemos cómo usar ARIA para explicar qué es algo, en qué estado se encuentra y qué propiedades tiene. Lo último que cubriré es la gestión del enfoque.

Gestión de enfoque

Cualquier cosa interactiva en un sitio web o aplicación web debe poder recibir atención. No todo el mundo utilizará un mouse, trackpad o pantalla táctil para interactuar con los sitios. Mucha gente usa su teclado o un dispositivo de tecnología de asistencia que emula un teclado. Esto significa que para todo lo que pueda hacer clic, también debería poder usar la tecla de tabulación o las teclas de flecha para alcanzarlo y la Entertecla, y a veces la barra espaciadora, para seleccionarlo.

Hay tres conceptos que deberá considerar si utiliza divy spancrea elementos interactivos:

1. Debes agregarlos tabindex="0"para que un teclado o emulador pueda enfocarse en ellos.
2. Para cualquier cosa que acepte entrada de teclado, debe agregar un detector de eventos para escuchar las pulsaciones de teclas.
3. Debe agregar el rol adecuado para que un usuario de lector de pantalla pueda identificar qué elemento ha creado.

Recuerde que los controles HTML nativos ya aceptan el enfoque y la entrada del teclado y tienen funciones inherentes. Esto es justo lo que debe hacer al crear elementos personalizados a partir de HTML no semántico.

Ben Myers profundiza en cómo convertir un divbotón en un botón y compartiré partes de su ejemplo aquí. Observe el tabindex y el rol:

div tabindex="0" role="button" Click me!/div

Y necesitarás JavaScript para escuchar las pulsaciones de teclas:

const ENTER = 13;const SPACE = 32;// Select your button and store it in ‘myButton’myButton.addEventListener('keydown', function(event) { if (event.keyCode === ENTER || event.keyCode === SPACE) { event.preventDefault(); // Prevents unintentional form submissions, page scrollings, the like doSomething(event); }});

Cuando se trata de determinar qué teclas escuchar, sugiero buscar el componente que está creando en la Guía de prácticas de creación de ARIA y seguir las recomendaciones de interacción del teclado.

Errores comunes

Después de haber examinado una gran cantidad de código a lo largo de mi vida, veo que se cometen repetidamente algunos errores de accesibilidad. Aquí hay una lista de los errores más comunes que encuentro y cómo evitarlos:

Usar un aria-labelledbyatributo que haga referencia a una identificación que no existe

Por ejemplo, un modal que tiene un título en el modal pero aria-labelledbyhace referencia a otra cosa que ya no existe. Probablemente sea algo eliminado por otro desarrollador que no se dio cuenta de que la aria-labelledbyconexión estaba ahí. En cambio, el título modal podría haber sido h1y aria-labelledbypodría hacer referencia a h1o podría establecer el enfoque en h1cuando se abre el modal y un usuario de lector de pantalla sabría lo que está sucediendo siempre que role="dialog”también se use. Intente evitar estructuras frágiles que, si alguien más apareciera y editara el código, se romperían fácilmente.

No mover el foco al modal cuando se abre

Innumerables veces he visto a un usuario de lector de pantalla navegando por la página detrás del modal sin saber que se ha abierto un modal o confundido porque no puede encontrar el contenido del modal. Hay varias formas de atrapar el foco dentro de un modal, pero uno de los métodos más nuevos es agregarlo inertal mainpunto de referencia (y, por supuesto, asegurarse de que el modal no esté dentro main). últimamente Inertestá recibiendo mejor soporte en todos los navegadores . Para obtener más información, consulte los cuadros de diálogo modales accesibles de Lars Magnus Klavenes usandoinert .

Agregar roles que duplican HTML

En general, hacer algo como esto button role="button”no tiene sentido. Hay un caso en el que podría tener sentido hacer esto. VoiceOver y Safari eliminan listla semántica de los elementos cuando list-style: nonese utilizan. Esto se hizo a propósito porque si no hay ninguna indicación para un usuario vidente de que el contenido es una lista, ¿por qué decirle a un usuario de lector de pantalla que es una lista? Si desea anular esto, puede agregar un ARIA explícito role="list"al archivo ul.

Adrian Roselli dice que una lista sin estilo que no se anuncia como una lista "... puede no ser un gran problema a menos que las pruebas de usuario indiquen que realmente necesitas una lista". Estoy de acuerdo con él en ese punto, pero compartiré la solución en caso de que sus pruebas de usuario demuestren que es beneficiosa.

Agregar tabindex="0"a cada elemento

A veces, los desarrolladores empiezan a utilizar un lector de pantalla y asumen que la tabulación es la única forma de navegar; por lo tanto, no se puede acceder a nada sin tabindex. Esto no es verdad. Recuerde, si no sabe cómo utilizar un lector de pantalla, no podrá solucionar problemas de usabilidad. Reúnase con un usuario habitual de lectores de pantalla para descubrirlos.

Uso de roles secundarios sin roles principales

Por ejemplo, role="option"debe tener un padre directo con role="listbox".

div role="listbox" ul li role="option"

El código anterior no es válido porque hay una diferencia ulentre los elementos padre e hijo. Esto se puede solucionar agregando una función de presentación para ocultar esencialmente el ulárbol de accesibilidad, como ul role="presentation”.

Uso role="menu"para navegación

La navegación del sitio web es realmente una tabla de contenidos y no un menú. Los menús ARIA no están destinados a usarse para la navegación, sino para el comportamiento de la aplicación, como los menús de una aplicación de escritorio. En su lugar, utilice nav, y si tiene enlaces de navegación secundarios, deben estar ocultos hasta que se presione un botón para mostrarlos:

nav aria-label="Main menu" button aria-expanded="false"Products/button ul hidden liCat pyjamas/li...

Si desea obtener más información, Heydon Pickering profundiza en la creación de sistemas de menús accesibles en su artículo de Smashing Magazine.

En cuanto a la navegación, usar navmás de una vez en una página sin darle a cada instancia una etiqueta única significa que los usuarios del lector de pantalla tendrán que explorar cada región de navegación para encontrar la que están buscando. Un simple aria-labelen cada uno navlo hará mucho más fácil.

nav aria-label="Customer service" ul lia href="#"Help/a/li lia href="#"Order tracking/a/li lia href="#"Shipping Delivery/a/li lia href="#"Returns/a/li lia href="#"Contact us/a/li lia href="#"Find a store/a/li /ul/nav

Cómo validar ARIA

Utilice verificadores de accesibilidad automatizados como las extensiones Ax o WAVE cuando ejecute su código en un navegador. Los linters de accesibilidad como Ax para Visual Studio Code o ESLint para elementos JSX comprobarán su código a medida que lo escribe.

Escuche su código con un lector de pantalla. Nunca enviarías código sin ejecutarlo en un navegador para asegurarte de que funciona, y usar un lector de pantalla puede ser el mismo tipo de verificación. NVDA es gratuito para Windows y VoiceOver viene integrado en Mac y iPhone. TalkBack está integrado en los teléfonos Android.

Pruebe con usuarios de tecnología de asistencia. Considero que esto es obligatorio para cualquier organización grande que tenga un presupuesto para accesibilidad (y todas deberían hacerlo). Hay empresas que pueden reclutar usuarios de tecnología de asistencia para realizar pruebas o realizar pruebas de usuario para usted, y la empresa para la que trabajo puede proporcionar plazos de entrega de 2 días en las pruebas de usuario facilitadas por usted o no moderadas para respaldar las pruebas de accesibilidad a escala.

Marcos y bibliotecas de componentes

Si está utilizando un marco web, una forma de hacer que la accesibilidad del edificio sea un poco más ligera es usar una biblioteca de componentes con accesibilidad incorporada. Agregaré la advertencia de que la accesibilidad puede ser compleja y no todo lo que dice ser. ser accesible es realmente utilizable por los usuarios de tecnología de asistencia. La mejor manera de garantizar la accesibilidad es probar siempre con los usuarios para los que está creando.

Aquí hay algunos puntos de partida para su búsqueda:

• Reaccionar Aria
• Vista A11y
• Diseño de materiales 3
• León
• Abrir interfaz de usuario

Conclusión

Con suerte, esto ha desmitificado a ARIA para usted. Como un lenguaje secreto que sólo conocen los expertos en accesibilidad más selectos, tiene sus propias reglas al estilo Fight Club.

1. La primera regla de ARIA es "No usar ARIA". A buttonsiempre será mejor que div role="button".
2. En segundo lugar, no anule la semántica nativa. En lugar de button role="heading", utilice h3button.
3. Además, recuerda siempre que todos los elementos interactivos de ARIA deben funcionar con el teclado.
4. No utilice role="presentation"o aria-hidden="true"en un elemento enfocable. button role="presentation”significa que estás ocultando ese botón sólo a los usuarios de tecnología de asistencia. Eso no sólo es inaccesible; excluye por completo a ciertos usuarios.
5. Por último, pero no menos importante, todos los elementos interactivos deben tener un nombre accesible. Hay muchas maneras de hacerlo, y estas son algunas de ellas:

buttonPrint/button (the name is the button text)div aria-label="Settings"svg/div (the aria-label assigns a name)div aria-labelledby="myName" h1Heading/h1/divlabel for="name"Name/labelinput type="text" /

Me gusta pensar en ARIA como una herramienta utilizada por el equipo de operaciones especiales más elitista al que recurres para tus desafíos de accesibilidad más difíciles. Bueno, tal vez siempre quise hacer flexiones con un solo brazo como Emily Blunt en Al filo del mañana, y esto es lo más cerca que puedo estar. De todos modos, espero que esto haya sido útil y que ya no estés confundido acerca de ARIA. ¡Adelante y construye cosas accesibles!

(vf, yk, il)Explora más en

• Accesibilidad
• Codificación
• javascript

Tal vez te puede interesar:

1. ¿Deberían abrirse los enlaces en ventanas nuevas?
2. 24 excelentes tutoriales de AJAX
3. 70 técnicas nuevas y útiles de AJAX y JavaScript
4. Más de 45 excelentes recursos y repositorios de fragmentos de código

Dar sentido a WAI-ARIA: una guía completa

Índice HTML ARIA

programar

es

https://aprendeprogramando.es/static/images/programar-dar-sentido-a-wai-aria-una-guia-completa-1155-0.jpg

2024-04-04

Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente