Lectores de pantalla y la primera regla de ARIA

La primera regla de ARIA es evitarla: si un elemento nativo de HTML ya hace el trabajo, como button, úsalo en lugar de agregarle un rol a un div.

De qué parte un lector de pantalla

Un lector de pantalla no lee píxeles. El navegador construye a partir del HTML un árbol de accesibilidad, una copia simplificada de la página en la que cada elemento de interés tiene un rol (botón, enlace, encabezado, casilla), un nombre (el texto que lo identifica) y a veces un estado (marcado, expandido, desactivado). El lector de pantalla lee ese árbol en voz alta o lo envía a una línea braille. El criterio de conformidad 4.1.2 Nombre, función, valor de WCAG 2.2, de nivel A, pide que cada control de la página exponga esas tres cosas.

Rara vez alguien escucha una página de arriba abajo. Los lectores de pantalla integrados en los principales sistemas operativos, y los gratuitos que se pueden instalar, permiten abrir una lista de encabezados, enlaces o regiones, saltar al siguiente campo de formulario o leer línea por línea. Por eso importan tanto las unidades anteriores: los encabezados reales, los campos etiquetados, los botones que son botones y el texto alt alimentan directamente ese árbol. El atributo lang del elemento html también importa. El criterio 3.1.1 Idioma de la página lo pide, y los lectores de pantalla lo usan para elegir la voz y la pronunciación correctas.

Lo que agrega ARIA

WAI-ARIA (Accessible Rich Internet Applications) es un conjunto de atributos que cambian lo que entra en el árbol de accesibilidad: role fija el rol, atributos como aria-label fijan el nombre, y otros como aria-checked o aria-expanded fijan el estado. ARIA solo cambia lo que se anuncia. No hace que un elemento pueda recibir el foco, no le agrega comportamiento con el teclado y no cambia su aspecto. La Guía de prácticas de autoría de ARIA del W3C lo pone en un encabezado: "No ARIA is better than bad ARIA" (mejor nada de ARIA que un ARIA malo). Un ARIA equivocado le dice algo falso sobre la página a quien usa un lector de pantalla.

Las reglas de uso de ARIA

El documento del W3C Using ARIA establece unas reglas breves que se citan en todas partes (en febrero de 2026 se marcó como borrador discontinuado, pero las reglas no han cambiado). Regla 1: si puedes usar un elemento o atributo nativo de HTML que ya traiga incorporados el significado y el comportamiento que necesitas, hazlo, en lugar de reconvertir otro elemento con ARIA. Regla 2: no cambies la semántica nativa a menos que de verdad sea necesario. Regla 3: todo control interactivo de ARIA debe poder usarse con el teclado. Regla 4: no pongas role="presentation" ni aria-hidden="true" en un elemento que pueda recibir el foco, o algunos usuarios llegarán a "nada".

Donde ARIA sí ayuda es en cubrir huecos que HTML no puede cubrir. Un botón que solo contiene un ícono no tiene texto, así que no tiene nombre; aria-label="Close" le da uno. Un ícono SVG junto a un texto visible es decoración, y aria-hidden="true" en el svg lo deja fuera del árbol. Esos son los dos atributos que más necesitan quienes empiezan. Para widgets completos, como pestañas o menús, sigue el patrón correspondiente de la Guía de prácticas de autoría en lugar de inventar uno.