Aprendí la primera regla de ARIA por las malas.

Hace un tiempo lancé un componente que sentí que era accesible para todas las métricas que pude probar. La navegación con el teclado funciona. Los roles ARIA se aplican correctamente. La revisión automática pasó sin quejas. Sin embargo, los usuarios de lectores de pantalla no saben cómo activarlo. Cuando lo probé yo mismo con navegación sólo con teclado y NVDA, vi lo mismo: la interacción simplemente no funcionó como esperaba.

Nada en la lista de verificación marcó un error. Técnicamente todo es “correcto”. Pero en realidad este componente es impredecible. Aquí hay una versión simplificada del componente que causa el problema:

Como puede ver en la demostración, el marcado no es nada complicado:

<button class="cta" role="link">Save changes</button>

Y la solución fue mucho más fácil de lo esperado. Tuve que borrar ARIA role Propiedades que agregué por la bondad de mi corazón.

El marcado es más simple que antes:

<button class="cta">Save changes</button>

Esa experiencia cambió mi perspectiva sobre la accesibilidad. La lección más importante es: El HTML semántico hace mucho más por la accesibilidad de lo que a menudo le damos crédito, y es fácil abusar de ARIA cuando lo usamos como acceso directo y complemento.

muchos de nosotros ya lo sabemos LA PRIMERA REGLA DE ARIA: No lo uses. Bueno, úsalo. Pero este no es el caso si los beneficios y funciones accesibles que necesitas ya están incluidos, en mi caso antes de agregar role propiedad.

Permítanme describir paso a paso exactamente lo que está pasando, porque creo que mi error es en realidad una práctica muy común. Hay muchos artículos que expresan exactamente de lo que estoy hablando, pero creo que escucharlo a través de experiencias de la vida real a menudo ayuda a interiorizarlo.

notas: Este artículo se probó utilizando la navegación por teclado y un lector de pantalla (NVDA) para observar el comportamiento de interacción en el mundo real entre elementos nativos y elementos modificados por ARIA.

1: Comience con el marcado más simple

Nuevamente, esta es solo una página mínima con un único nativo <button> No hay arias. De forma predeterminada, permite el enfoque del teclado y demuestra la funcionalidad utilizada. pestaña, Ingresary espacio Listo para usar nada más sacarlo de la caja. Jeff recientemente presentó este caso. Explicar los beneficios de accesibilidad de los elementos HTML semánticos..

Si la interacción desencadena una acción, entonces El elemento es un botón.. en este caso, <button> Diseñado para ejecutar un script que guarda los cambios en los perfiles de usuario:

<button>Save changes</button>

Esta línea nos regala una sorprendente cantidad:

• Activación del teclado Enter y Space llave
• Comportamiento de enfoque correcto
• El papel entendido de la tecnología de asistencia
• Anuncios consistentes en todos los lectores de pantalla.

En este momento, hay No ARIA – Esto es intencional. Pero ya tenía una clase en mi CSS para diseñar los botones, así que agregué:

<button class="cta">Save changes</button>

2: observe el comportamiento nativo antes de agregar algo

Usando sólo elementos nativos, probé tres cosas:

1. Solo teclado (pestaña, Ingresar, espacio)
2. lector de pantalla (Escuche cómo se anuncia el control)
3. orden de enfoque dentro de la pagina

Se espera todo. El navegador hace exactamente lo que espera el usuario. Este paso es importante porque establece una línea de base. Si surgen problemas más adelante, sabrá que no es el HTML el culpable. De hecho, inspeccionando los elementos del panel de Accesibilidad de DevTool podremos comprobar que todo está en perfecto estado de funcionamiento.

3: Agregar buena voluntad ARIA

El problema surge cuando intento que el botón se comporte como un enlace:

<button class="cta" role="link">Save changes</button>

Hago esto por motivos de estilo y enrutamiento. El botón debe tener un estilo ligeramente diferente al del botón predeterminado. .cta clase, pensé que podría usar atributos ARIA en lugar de usar clases modificadoras. Puedes empezar a ver cómo dejo que el estilo dicte e influya en la funcionalidad. uno <button> Sigue siendo el elemento adecuado para este propósito, pero debido a requisitos de diseño quiero que parezca un enlace. También podría darle al elemento un link ¿Entonces el papel?

Superficialmente no parece haber ningún daño. Las herramientas automatizadas permanecen silenciosas. Pero en el uso real, las grietas aparecen rápidamente:

• espacio Los controles ya no se activan de forma fiable.
• Los lectores de pantalla anuncian roles conflictivos.
• Los usuarios del teclado experimentan un comportamiento que no coincide exactamente con el botón o enlace.

ARIA no añade claridad aquí; introduce ambigüedad. Pero yo he “probado” el mío y nada me sorprende porque estoy confundiendo los elementos. role con otro tipo de elemento. Nuevamente, eche un vistazo rápido a DevTools.

4: Volver a la semántica

Esta solución no es inteligente. Esto es una resta. Restauré el estilo, usé clases para el estilo y volví al marcado semántico antes de cambiar los roles de accesibilidad:

<button class="cta">Save changes</button>

Sé que esto suena simple: si es una acción, usa <button>. Si te lleva a algún lugar, utiliza el enlace (<a>). Sin embargo, en la práctica tomamos decisiones con cada tecla que escribimos y es fácil confundir acciones con destinos. ¡En este caso, usé exactamente el elemento correcto! Mi error fue pensar que ARIA era el gancho de estilo adecuado para mi CSS.

Una vez que los elementos correctos están en su lugar (sin ARIA), el problema desaparece. En lugar de eso, podría definir un nuevo nombre de clase y, como habrás adivinado, usar estilos de conservación con estilos.

<button class="cta cta-alt">Save changes</button>

Así de fácil, pude diseñar los elementos como necesitaba y el usuario que informó el problema pudo confirmar que todo estaba funcionando como se esperaba. Este es un error involuntario que surge de un malentendido básico de la posición de ARIA en la pila.

¿Por qué esto sigue sucediendo?

Los atributos ARIA se utilizan para definir la esencia de las cosas, pero no redefinen el comportamiento predeterminado de los elementos nativos. Cuando vamos más allá de la semántica, asumimos silenciosamente la responsabilidad de:

• interacción del teclado,
• gestión de enfoque,
• anuncios anticipados, y
• Peculiaridades específicas de la plataforma.

Esto requiere mantener una gran superficie, razón por la cual pequeños cambios ARIA pueden tener efectos grandes e impredecibles.

Las reglas que sigo ahora

Aquí está el flujo de trabajo que me ha ahorrado más tiempo y errores:

1. Utilice HTML nativo para expresar su intención.
2. Pruebe usando un teclado y un lector de pantalla.
3. Agregue ARIA solo para comunicación Estado faltanteen lugar de redefinir roles.

Si ARIA siente que está haciendo el trabajo pesado, eso suele ser una señal de que el marcado está luchando contra el navegador.

donde esta el aria Hacer pertenecer

Un ejemplo es el uso del widget público simple de Native. <button> agregar aria-expanded Estado de comunicación: muestra ARIA para Agregar estadono reemplaza la semántica.

Esta demostración utiliza nativos. <button> y aria-expandedque se alterna mediante JavaScript:

const button = document.getElementById("toggle");
const panel = document.getElementById("panel");

button.addEventListener("click", () => {
  const expanded = button.getAttribute("aria-expanded") === "true";
  button.setAttribute("aria-expanded", !expanded);
  panel.hidden = expanded;
});

Estado accesible (true/false) se puede transmitir correctamente sin reemplazar la semántica del botón.

Ahora sé que ARIA es crucial cuando:

• Transmite estado expandido o colapsado,
• Al anunciar una actualización dinámica,
• Cree widgets verdaderamente personalizados y
• Exponer relaciones que HTML no puede expresar.

De esta manera, ARIA complementa el HTML semántico, en lugar de competir con él.

Deja que la plataforma te sirva

La mayor mejora de accesibilidad que he realizado no es conocer más atributos, sino confiar en los que el navegador ya comprende. El HTML semántico no es una línea de base que se pueda superar. Ésta es la base sobre la que descansa todo lo demás.

Eso es lo que realmente espero que aprendas de mi experiencia. Todos cometemos errores. Desafortunadamente, esto es parte del trabajo. Pero, ¿de qué sirven si no podemos aprender de ellos, incluso si eso requiere lecciones difíciles?