Accesibilidad

docs.scrimba.com

Las personas acceden a la web de muchas maneras. Algunos miran una pantalla y mueven un ratón. Algunos no pueden ver la pantalla y la escuchan leer en voz alta. Algunos nunca tocan un ratón y se desplazan por una página con el teclado, con la voz, o con un interruptor que presionan. La accesibilidad es la práctica de construir páginas que todos ellos puedan usar, y la mayoría se reduce a escribir HTML de la manera en que fue pensado.

Por qué importa la accesibilidad

Accesibilidad significa asegurarse de que todos puedan usar tu página, sin importar sus circunstancias o cómo naveguen. Alguien podría no poder ver la pantalla y escucharla en su lugar, a través de software que lee la página en voz alta. Alguien podría no usar un ratón y moverse por la página con el teclado. Alguien podría necesitar texto más grande o colores más fuertes para leer cómodamente.

Piensa en un edificio con una rampa junto a los escalones. La rampa ayuda a las personas que no pueden subir escaleras, y no quita nada a nadie que pueda hacerlo. HTML accesible es la misma idea: abre la página a más personas sin hacerla peor para nadie.

La parte tranquilizadora es que HTML es accesible desde el inicio. Llegas la mayor parte del camino de forma gratuita simplemente usando el elemento correcto para cada parte del contenido.

Accesibilidad, a menudo abreviada como a11y (una "a", luego once letras, luego una "y"), se trata de que tu página funcione en todo el rango de formas en que las personas acceden a la web: lectores de pantalla que hablan la página, navegación solo con teclado, control por voz, ampliación de pantalla, y modos de pantalla de color reducido o alto contraste.

El marco práctico que más ayuda: HTML te da accesibilidad como posición inicial, no como algo que agregues al final. La mayor parte del trabajo es elegir el elemento correcto y no deshacer lo que el navegador ya hace por ti. Las fallas tienden a venir de un pequeño conjunto de causas: widgets personalizados reconstruidos desde elementos genéricos, campos de formulario sin etiqueta, contraste de color débil, y comportamiento que solo responde a un ratón.

Accesibilidad es si las personas que usan tecnología de asistencia (software o hardware que ayuda a alguien a operar una computadora, como un lector de pantalla que habla la página, un dispositivo de interruptor presionado en lugar de hacer clic, o control por voz) pueden percibir, operar y entender tu página. El estándar de referencia es WCAG, las Pautas de Accesibilidad del Contenido Web, organizadas alrededor de cuatro principios: el contenido debe ser perceptible, operable, comprensible y robusto.

Hay dos consecuencias que vale la pena tener presentes. Primero, la misma estructura bien formada en la que confía la tecnología de asistencia es también lo que los motores de búsqueda y otras máquinas leen del DOM (el modelo en memoria del navegador de la página), así que la accesibilidad y el SEO tiran en la misma dirección en lugar de competir por tu tiempo. Segundo, en muchos lugares la accesibilidad es un requisito legal para sitios públicos, no un complemento agradable. La forma útil de pensar en todo esto: una página accesible es principalmente una construida correctamente. Casi todo en este capítulo es HTML estándar usado como se pretendía.

JunoPor qué importa la accesibilidad Accesibilidad significa que todos puedan usar tu página, sin importar quiénes sean y cómo lleguen. La parte agradable es que HTML te da la mayor parte de forma gratuita en el momento en que eliges el elemento correcto para el trabajo. Imagina una rampa junto a los escalones: más personas entran, y nadie está peor.

JunoPor qué importa la accesibilidad Accesibilidad es que tu página funcione para lectores de pantalla, teclados, ampliadores, y todos los demás. Comienzas desde un buen lugar porque HTML es accesible desde el inicio, así que la mayoría de las fallas vienen de deshacer eso con widgets personalizados y etiquetas faltantes. Construye con los elementos correctos y ya estás en la mayor parte del camino.

JunoPor qué importa la accesibilidad El estándar es WCAG y sus cuatro principios: perceptible, operable, comprensible, robusto. La misma estructura que ayuda a un lector de pantalla ayuda a un rastreador de búsqueda a leer el DOM, así que esto no es un impuesto separado en tu tiempo. Trata el resto del capítulo como HTML ordinario usado como se pretendía, porque eso es lo que la mayoría de él es.

HTML semántico como base

La cosa más efectiva que puedes hacer por la accesibilidad es usar el elemento que coincide con el significado del contenido, en lugar de uno genérico estilizado para verse bien.

HTML semántico significa elegir una etiqueta por lo que el contenido es, no por cómo se ve. Un encabezado usa <h1> a <h6>. Un botón usa <button>. Un enlace usa <a>. Una lista usa <ul> u <ol>. Cada uno de estos ya lleva significado que un lector de pantalla puede anunciar, así que un oyente sabe "esto es un botón" o "esto es un encabezado" sin verlo.

Es como etiquetar cajas cuando te mudas de casa. Una caja marcada "cocina" ayuda a quien la carga, no solo a la persona que la empacó. Las etiquetas semánticas etiquetan tu contenido de la misma manera, así que el navegador y la tecnología de asistencia saben qué es cada parte.

En la práctica, esto significa usar <button> cuando quieres un botón, no un <div> que has estilizado para verse como uno. El <div> puede hacerse verse idéntico, pero no dice nada sobre lo que es. El capítulo HTML semántico repasa el conjunto completo.

Los elementos semánticos llegan con comportamiento y significado ya adjuntos. Un <button> es enfocable, responde a Enter y Espacio, y se anuncia como un botón. Un <nav> marca una región de navegación. Los encabezados <h1> a <h6> forman un esquema por el que un usuario de lector de pantalla puede saltar, de la manera en que un lector con vista examina una sección.

La regla que evita la mayoría de los problemas: usa el elemento nativo antes de construir el tuyo propio. Un <div role="button" tabindex="0"> con un controlador de clic puede hacerse funcionar, pero estás reimplementando enfoque, soporte de teclado, y el rol a mano, y uno de esos elementos tiende a escaparse. Un <button> verdadero te da todo de una vez. Los elementos de referencia (<header>, <nav>, <main>, <aside>, <footer>) hacen lo mismo a escala de página: permiten que un usuario de lector de pantalla salte directamente a una región en lugar de escuchar todo lo que está encima. El capítulo HTML semántico cubre cada uno.

HTML semántico es la base porque el navegador asigna cada elemento semántico a un rol en el árbol de accesibilidad (la versión simplificada de la página que la tecnología de asistencia lee, descrita en detalle en la sección ARIA a continuación). Un <button> recibe el rol de botón, su comportamiento de enfoque, y su manejo de teclado sin trabajo por tu parte. Reconstruirlo desde un <div> y no hereda nada de eso: ahora posees enfocabilidad, manejo de teclas, y el rol anunciado a mano, y cada brecha es un defecto para alguien.

Dos hábitos cargan la mayor parte del peso. Dale a los niveles de encabezado una estructura real: un <h1> para la página, luego <h2> y <h3> anidados sin saltarse un nivel, porque los usuarios de lectores de pantalla navegan por encabezado y un salto de <h2> a <h4> se lee como una sección que faltó. Y usa los elementos de referencia (<main>, <nav>, <header>, <footer>, <aside>) para que la página exponga regiones navegables. El modo de falla que debes reconocer es "sopa de div", una página ensambla casi totalmente desde <div> y <span>: se renderiza perfectamente y expone casi nada a la tecnología de asistencia, porque esos dos elementos no llevan rol alguno.

JunoHTML semántico como base Elige etiquetas por lo que el contenido es, no cómo se ve: <button> para un botón, <h1> para un encabezado, <a> para un enlace. Cada uno ya le dice a un lector de pantalla lo que es, así que obtienes eso de forma gratuita. Un <div> estilizado puede verse igual y aun así no decir nada.

JunoHTML semántico como base Los elementos nativos vienen con enfoque, soporte de teclado, y un rol hablado ya conectado, así que un <button> supera a un <div> fingiendo ser uno. Usa el elemento real antes de reconstruirlo, y apóyate en referencias como <nav> y <main> para que las personas puedan saltar alrededor. Eso es la mayoría del trabajo ya.

JunoHTML semántico como base Cada elemento semántico se asigna a un rol en el árbol de accesibilidad, así que <button> te entrega el rol, enfoque, y teclas juntos, mientras que un <div> te entrega una factura para los tres. Mantén encabezados en orden sin niveles saltados, ya que las personas navegan por ellos. La sopa de div se renderiza bien y no le dice nada a la tecnología de asistencia, que es el problema completo con ella.

Alternativas de texto, etiquetas, enfoque y teclado

Algún contenido no puede hablar por sí solo. Una imagen es invisible para un lector de pantalla hasta que la describas. Un campo de formulario es una suposición hasta que se etiqueta. Y una página que solo responde a un ratón excluye a todos los que no usan uno. Estas cuatro áreas son donde un poco de cuidado vale mucho.

Un puñado de hábitos confiables cubren la mayoría de esto:

• Las imágenes necesitan texto alternativo. El atributo alt describe una imagen para cualquiera que no pueda verla. Si la imagen es solo decorativa, un alt="" vacío le dice al lector de pantalla que la salte.

<img src="red-fox.jpg" alt="Un zorro rojo acurrucado durmiendo en la nieve">

• Los campos de formulario necesitan etiquetas. Una <label> le dice tanto al visitante como al lector de pantalla qué escribir en un campo.

<label for="email">Correo electrónico</label>
<input id="email" type="email">

• Los botones y enlaces necesitan texto claro. "Leer más" por sí solo es poco claro cuando se lee fuera de contexto; "Leer más sobre precios de entradas" tiene sentido por sí solo.
• El orden del teclado debe coincidir con el orden de lectura. Alguien presionando Tab se mueve a través de la página en el orden en que los elementos aparecen en tu HTML, así que mantén ese orden sensato.

Los capítulos Imágenes y medios y Formularios e entradas profundizan en texto alternativo y etiquetas.

Asocia cada control de formulario con una <label>. La forma confiable es coincidir el atributo for de la etiqueta con el id de la entrada:

<label for="postcode">Código postal</label>
<input id="postcode" type="text" name="postcode">

Ahora hacer clic en la etiqueta enfoca el campo, y un lector de pantalla anuncia la etiqueta cuando el campo obtiene enfoque. El capítulo Formularios e entradas cubre las variaciones.

Para texto alternativo, describe el propósito, no los píxeles: alt="Logotipo de la empresa" supera a una lista de colores y formas, y una imagen decorativa toma un alt="" vacío para que sea saltada en lugar de ser leída como un nombre de archivo.

El orden de enfoque sigue el orden de elementos en el DOM, así que mantén el orden de tu fuente coincidiendo con el orden de lectura visual. Evita valores de tabindex positivos (tabindex="1" y más); inventan una secuencia de tabulación separada que es difícil de mantener correcta. Usa tabindex="0" para agregar un control personalizado al orden natural, y tabindex="-1" para hacer que algo sea enfocable por script pero no por Tab.

Para operabilidad de teclado, la regla es corta: todo lo que puedas hacer con un ratón debe funcionar con el teclado. Si un clic abre un menú, Enter también debería hacerlo. Y mantén un esquema de enfoque visible para que los usuarios de teclado puedan ver dónde están. El contraste de color importa aquí también: WCAG pide una relación de contraste de al menos 4.5:1 entre texto normal y su fondo, y nunca confíes solo en color para llevar significado, ya que no todos distinguen los mismos colores.

Estas cuatro áreas son todos lugares donde el DOM tiene que llevar significado que la disposición visual lleva para un usuario con ratón y vista.

Etiquetas. Una <label> vinculada a un control por for/id, o envolviendo la entrada, le da a ese control su nombre accesible (el texto que la tecnología de asistencia anuncia para un elemento). Sin una etiqueta, un lector de pantalla lee el tipo del campo y nada sobre su propósito. El texto del marcador de posición no es una etiqueta: desaparece en la entrada y se anuncia de manera inconsistente.

Alternativas de texto. alt es el nombre accesible de una <img>. Escríbelo por propósito, no por apariencia. Una imagen decorativa toma alt="" (vacío, presente pero en blanco) para que sea eliminada del árbol de accesibilidad; omitir alt completamente es diferente, y algunos lectores de pantalla vuelven a leer el nombre del archivo, lo que no ayuda a nadie.

Enfoque. El orden de enfoque es orden de DOM a menos que lo anueles, y tabindex positivo es casi siempre un error porque construye una segunda secuencia de tabulación que luego tienes que mantener contra la disposición visual. Usa tabindex="0" para plegar un control personalizado en el orden natural y tabindex="-1" para hacer que un elemento sea enfocable solo por script, lo que necesitas cuando mueves el enfoque después de una acción. Mantén un indicador de enfoque visible: nunca establezcas outline: none sin proporcionar un reemplazo, o los usuarios de teclado pierden la pista de su posición. Ten cuidado también con una trampa de teclado (enfoque que un usuario de teclado puede mover hacia dentro pero no hacia afuera), que WCAG señala específicamente.

Teclado y contraste. Cada operación debe ser alcanzable y operable por teclado, en un orden lógico. Para contraste, WCAG AA pide 4.5:1 en texto del cuerpo y 3:1 en texto grande y en el límite visual de un control, y el significado nunca debe depender solo del color. Un campo requerido marcado solo en rojo es invisible para alguien que no percibe esa diferencia; emparéjalo con texto o un icono.

JunoAlternativas de texto, etiquetas, enfoque y teclado Cuatro pequeños hábitos cargan la mayor parte de esto: dale a las imágenes un alt, dale a los campos de formulario una <label>, escribe texto de botón y enlace que tenga sentido por sí solo, y mantén el orden de tabulación coincidiendo con el orden de lectura. Ninguno de ellos toma mucho tiempo. Las imágenes decorativas obtienen un alt="" vacío para que sean saltadas.

JunoAlternativas de texto, etiquetas, enfoque y teclado Conecta cada entrada a una <label> con for e id coincidentes, y escribe alt por propósito, vacío para decorativo. Mantén el orden de enfoque como orden de DOM y salta tabindex positivo. La línea que recordar: todo lo que un ratón puede hacer, el teclado también debe hacerlo, y verifica que tu contraste alcance 4.5:1.

JunoAlternativas de texto, etiquetas, enfoque y teclado Las etiquetas y alt establecen el nombre accesible de un elemento, así que un marcador de posición no es una etiqueta y un alt faltante no es uno vacío. Deja el enfoque en orden de DOM, evita tabindex positivo, y nunca elimines el esquema de enfoque sin reemplazarlo. Alcanza 4.5:1 en texto y nunca dejes que el color sea la única señal, o un marcador requerido solo en rojo no llega a nadie que no pueda ver el rojo.

ARIA, y por qué no usarla primero

Hay un conjunto de atributos HTML hechos específicamente para la accesibilidad, llamados ARIA. Es útil en el lugar correcto, y es una de las partes más mal utilizadas de la plataforma, así que vale la pena entender tanto lo que hace como cuándo dejarla sola.

ARIA significa Aplicaciones Ricas de Internet Accesibles. Es un conjunto de atributos adicionales que puedes agregar a un elemento para decirle a la tecnología de asistencia más sobre él. El nombre lo hace sonar como la primera herramienta a la que recurrir, y generalmente es la última.

La razón es simple: la mayoría de lo que ARIA puede describir, HTML ya lo dice por su cuenta. Un <button> ya se anuncia como un botón. Agregar role="button" a él no cambia nada. Si te encuentras agregando ARIA para explicar qué es un elemento, eso generalmente es una señal para cambiar al elemento HTML simple que ya lo dice.

Imagina una nota adhesiva agregada a una caja de mudanza. Si la caja ya está impresa "cocina", una nota adhesiva leyendo "cocina" solo agrega desorden. Guarda la nota para la caja que no tiene etiqueta. ARIA es para las partes de una página que HTML no tiene elemento, lo cual es más raro de lo que suena.

ARIA agrega tres tipos de información a un elemento: roles (lo que es, como role="dialog"), estados (su condición actual, como aria-expanded="false"), y propiedades (relaciones adicionales, como aria-describedby apuntando a algún texto de ayuda). Los lectores de pantalla usan estos para anunciar widgets personalizados que no tienen equivalente HTML nativo, como un panel de pestañas o un regulador.

La guía para liderar es la primera regla de ARIA: no uses ARIA si un elemento nativo ya hace el trabajo. Un <button> nativo supera a <div role="button"> cada vez, porque el elemento nativo trae comportamiento y el atributo ARIA solo trae una etiqueta. Peor, un atributo ARIA incorrecto u obsoleto es peor que ninguno, porque anula lo que el navegador habría dicho de otra manera. Pon aria-hidden="true" en el elemento incorrecto y escondes contenido real de usuarios de lectores de pantalla mientras se sienta visible en la pantalla. Recurre a ARIA cuando estés construyendo un widget que HTML no tiene elemento, y luego sigue un patrón establecido en lugar de inventar atributos.

Comienza con la cosa que ARIA edita. El árbol de accesibilidad es una estructura paralela que el navegador construye junto al DOM. Para cada elemento, registra un rol (lo que el elemento es: botón, enlace, encabezado), sus estados y propiedades (condiciones y relaciones, como aria-expanded, aria-checked, o disabled), y su nombre accesible y descripción (el texto que se anuncia). La tecnología de asistencia lee este árbol, no tu CSS ni el HTML sin procesar.

ARIA es el vocabulario para editar ese árbol directamente: roles (role="tablist"), estados que cambian con el tiempo (aria-selected="true"), y propiedades que describen relaciones más estables (aria-labelledby, aria-controls). La primera regla de ARIA es que si un elemento HTML nativo o un atributo ya te da el rol, estado o propiedad que necesitas, úsalo y no agregues ARIA. La razón es que ARIA cambia solo el árbol de accesibilidad y no agrega comportamiento por su cuenta. role="button" en un <div> hace que un lector de pantalla lo llame botón, pero no le otorga enfocabilidad, manejo de Enter o Espacio, y soporte deshabilitado. Agregarías cada uno de esos tú mismo, y el día que olvides uno tienes un control que se anuncia como botón pero no actúa como uno, lo que es peor que un <div> honesto.

Algunas reglas mantienen ARIA de causar el daño que se supone debe prevenir. Prefiere elementos nativos. No anuales la semántica nativa (no role="heading" en un <button>). No coloques elementos interactivos dentro de un subárbol marcado aria-hidden="true", o haces controles enfocables que un lector de pantalla no puede ver. Y mantén estados en sincronización con tu JavaScript, ya que un aria-expanded obsoleto miente al usuario. Cuando necesites ARIA, construye desde las Prácticas de Autoría de WAI-ARIA, los patrones publicados para widgets comunes, en lugar de componer atributos desde cero. Para probar cualquiera de esto, el inspector de accesibilidad del navegador muestra el rol, nombre y estado computado para un elemento dado, que es exactamente lo que la tecnología de asistencia recibirá.

JunoARIA, y por qué no usarla primero ARIA es un conjunto de atributos adicionales que describen un elemento a la tecnología de asistencia. Suena como la primera cosa a la que recurrir y generalmente es la última, porque un <button> real ya dice que es un botón. Guarda ARIA para la parte rara de una página que HTML no tiene elemento, y mantén todo lo demás simple.

JunoARIA, y por qué no usarla primero ARIA agrega roles, estados, y propiedades para widgets personalizados que HTML no tiene elemento. La primera regla de ARIA es saltarla cuando un elemento nativo ya hace el trabajo, ya que un atributo incorrecto u obsoleto es peor que ninguno. Si estás etiquetando un <button> como botón, detente y usa el botón.

JunoARIA, y por qué no usarla primero ARIA edita el árbol de accesibilidad: roles, estados, y propiedades, y nada más, así que nunca agrega comportamiento. Esa es la razón completa de la primera regla de ARIA, ya que role="button" en un <div> anuncia un botón que no tiene teclas ni enfoque hasta que lo construyas. Mantén estados en sincronización con tu JavaScript, y cuando necesites un widget, copia un patrón publicado en lugar de inventar atributos.

Una auditoría rápida de auto-evaluación

No necesitas software especializado para detectar los problemas más comunes. Algunos controles con herramientas ya en tu máquina encuentran la mayoría de ellos, y solo toman un par de minutos ejecutarlos.

Aquí hay una lista de verificación corta que puedes ejecutar en cualquier página:

• Deja el ratón a un lado y presiona Tab. ¿Puedes llegar a cada enlace y botón, en un orden que tenga sentido? ¿Puedes activarlos con Enter?
• ¿Cada imagen tiene un atributo alt?
• ¿Cada campo de formulario tiene una <label>?
• ¿Tus botones y enlaces aún tienen sentido cuando se leen por su cuenta?
• ¿El texto es claro de leer contra su fondo?

Ejecutar estos en tu propia página es rápido, y detecta los problemas que la gente encuentra más a menudo. Si la tecla Tab se atora en algún lado, o una imagen no tiene alt, has encontrado algo que vale la pena arreglar.

Construye una pasada repetible en tu flujo de trabajo:

1. Teclado. Tab a través de toda la página. Cada elemento interactivo debe ser alcanzable, en un orden sensato, con un indicador de enfoque visible, y operable con Enter o Espacio. Si el enfoque desaparece o se queda atrapado, arréglalo antes que cualquier otra cosa.
2. Encabezados e referencias. Confirma que hay un <h1>, que los encabezados no salten niveles, y que las regiones principales usen <main>, <nav>, y las otras referencias.
3. Nombres. Cada imagen tiene un alt, cada control tiene una etiqueta, y cada enlace y botón se lee claramente fuera de contexto.
4. Contraste. Verifica texto contra su fondo en las herramientas de desarrollador de tu navegador, que informan la relación y marcan lo que falla.

Los verificadores automatizados como el panel Lighthouse en las herramientas de desarrollador de Chrome o la extensión del navegador axe detectan una parte útil de problemas, pero solo una parte. No pueden juzgar si un texto alternativo es significativo o si un orden de tabulación tiene sentido, así que la pasada manual de teclado sigue siendo esencial.

Una auditoría que funciona combina pasadas automatizadas y manuales, porque la automatización cubre solo parte del terreno: las herramientas encuentran confiablemente alt faltante, etiquetas faltantes, y fallos de contraste (aproximadamente un tercio de los criterios WCAG), y no pueden juzgar si un texto alternativo es preciso o si un orden de tabulación es lógico.

• Automatizado. Ejecuta axe o Lighthouse primero para limpiar los fallos mecánicos.
• Teclado. Deja el ratón a un lado y Tab a través, confirmando alcanzabilidad, un orden lógico, un anillo de enfoque visible, operabilidad completa, y ningún lugar donde el enfoque no pueda salir. Esta pasada por sí sola expone la mayoría de los defectos de widgets personalizados.
• Lector de pantalla. Enciende uno (VoiceOver viene con macOS vía Cmd+F5, NVDA es una descarga gratuita en Windows, TalkBack está incorporado en Android) y escucha a través de algunos flujos clave. Estás verificando que los nombres se anuncien, los roles sean correctos, y los cambios de estado realmente se hablen.
• El árbol de accesibilidad. Las herramientas de desarrollador del navegador muestran el rol, nombre y estado computado para cualquier elemento, que te dice qué la tecnología de asistencia realmente recibirá, independientemente de cómo se vea el elemento.

Ejecuta las pasadas de teclado y lector de pantalla incluso cuando las herramientas automatizadas reporten verde, porque las cosas que no pueden verificar son las cosas que más afectan a una persona real usando la página.

JunoUna auditoría rápida de auto-evaluación Deja el ratón a un lado y Tab a través de tu página: ¿puedes llegar y usar todo en un orden sensato? Luego verifica que cada imagen tenga un alt, cada campo tenga una <label>, y el texto se lea claramente contra su fondo. Un par de minutos de esto detecta los problemas que la gente encuentra más.

JunoUna auditoría rápida de auto-evaluación Hazlo una rutina: Tab a través para alcanzabilidad y orden, verifica un <h1> y ningún encabezado saltado, confirma nombres en imágenes y controles, y lee el contraste en herramientas de desarrollador. Las herramientas automatizadas como axe y Lighthouse ayudan, pero solo detectan parte de él, así que sigue haciendo la pasada de teclado manualmente.

JunoUna auditoría rápida de auto-evaluación La automatización encuentra alt faltante, etiquetas faltantes, y contraste, alrededor de un tercio de WCAG, y no juzga nada sobre significado u orden. Así que emparéjalo con una pasada de teclado, una escucha a través de un lector de pantalla, y una mirada al inspector de accesibilidad para el rol y nombre computado. Los controles que una herramienta no puede ejecutar son los que más importan, así que ejecútalos tú mismo incluso cuando el informe es verde.