Guía de accesibilidad web: fundamentos de WCAG
Explica con código de ejemplo los fundamentos de WCAG, como el contraste, la navegación con teclado, el texto alternativo y las etiquetas de formulario, y le muestra cómo probar usted mismo su sitio.
Aurora YazılımEquipo editorial
6 min de lectura
La accesibilidad web es que todas las personas, incluidas las que tienen diferencias visuales, auditivas, motrices o cognitivas, puedan percibir, recorrer y utilizar un sitio. El estándar internacional son las pautas WCAG del W3C; un contraste de color suficiente, el uso completo con teclado, el texto alternativo en las imágenes y los formularios con etiquetas son los requisitos básicos. Estos principios refuerzan tanto la experiencia de usuario como la visibilidad en buscadores.
¿Para quién es la accesibilidad?
La accesibilidad suele asociarse solo a los usuarios con discapacidad visual. Sin embargo, su alcance es mucho más amplio: personas con daltonismo, quienes no pueden usar el ratón porque tienen la mano rota, usuarios mayores, quienes ven un vídeo sin sonido en un entorno ruidoso y todo el que mira la pantalla del móvil bajo el sol.
Por eso el diseño web accesible no es un trabajo extra para un público reducido, sino una mejor experiencia para todos. Los títulos claros, el texto legible y la navegación predecible facilitan la vida también a los usuarios sin discapacidad.
La accesibilidad también favorece la visibilidad en buscadores. La jerarquía correcta de títulos, los textos de enlace descriptivos y las descripciones de imagen coinciden en gran medida con los elementos que ayudan a los buscadores a entender la página.
¿Qué es WCAG?
WCAG (Web Content Accessibility Guidelines) son las pautas de accesibilidad del contenido web elaboradas en el seno del W3C. Las pautas constan de criterios de conformidad verificables y se dividen en tres niveles: A, AA y AAA. Para la mayoría de las organizaciones y normativas, el objetivo es el nivel AA.
WCAG se basa en cuatro principios fundamentales. Cada criterio depende de uno de ellos; entender los principios es más útil que memorizar los criterios uno por uno. Puede consultar el texto oficial en la página del W3C WAI.
| Principio | Significado | Ejemplo |
|---|---|---|
| Perceptible | La información debe poder recibirse al menos por un sentido | Texto alternativo en las imágenes, subtítulos en los vídeos |
| Operable | La interfaz debe poder usarse de distintas maneras | Navegación completa con teclado, tiempo suficiente |
| Comprensible | El contenido y el comportamiento deben ser predecibles | Mensajes de error claros, menú coherente |
| Robusto | Debe ser compatible con las tecnologías de apoyo | HTML correcto, marcado válido |
Contraste de color y legibilidad
En el nivel AA se exige un contraste de al menos 4,5:1 entre el texto normal y el fondo. En los textos grandes, es decir, de unos 24 píxeles o más, o de 18,5 píxeles o más en negrita, la proporción baja a 3:1. Para los componentes de la interfaz, como los bordes de formulario y los iconos, también se espera una proporción de 3:1.
Además del contraste hay otra regla: no transmita la información solo con el color. Distinguir los campos obligatorios solo con un asterisco rojo o los enlaces solo con el color deja fuera a los usuarios con daltonismo. Use subrayado en los enlaces y texto explicativo en los errores.
El tamaño del texto también forma parte de la legibilidad. Cuando el usuario amplía la letra hasta el 200 por ciento en el navegador, el contenido no debe perderse ni la página descomponerse.
Navegación con teclado
Los usuarios que no pueden usar el ratón o que navegan con un lector de pantalla avanzan por el sitio con Tab, Shift+Tab, Enter y las flechas. Por eso los menús, botones, formularios y ventanas emergentes deben poder usarse por completo solo con el teclado.
- Foco visible: el elemento enfocado debe mostrarse con un marco claro; no elimine por completo el contorno de foco con CSS.
- Orden lógico: el orden del tabulador debe seguir el orden visual.
- Enlace para saltar al contenido: un enlace oculto al principio de la página que salta el menú y lleva al contenido principal.
- Sin trampas: debe poder salirse de una ventana emergente con Esc o con el teclado.
- Botones reales: las etiquetas button y a para los elementos en los que se hace clic, en lugar de div.
<a class="atla" href="#icerik">Saltar al contenido</a>
<header>...</header>
<main id="icerik">...</main>Texto alternativo e imágenes
Los lectores de pantalla no pueden ver las imágenes; en su lugar leen el texto del atributo alt. El texto alternativo debe describir brevemente la función de la imagen en la página. Para una foto de producto basta el nombre del producto y su rasgo distintivo; si la imagen contiene texto, ese texto también debe incluirse en el texto alternativo.
Para las imágenes meramente decorativas se usa un valor alt vacío; así el lector de pantalla las omite. Si un enlace o un botón está formado solo por un icono, lo que hace el icono debe indicarse con texto.
<img src="zeytinyagi.webp" alt="Aceite de oliva de primera presión en frío en botella de cristal de 500 ml">
<img src="dalga-deseni.svg" alt="">
<button aria-label="Abrir menú">
<svg aria-hidden="true">...</svg>
</button>Formularios y compatibilidad con lectores de pantalla
Los formularios son donde más se ven los problemas de accesibilidad. Cada campo debe tener una etiqueta de formulario visible y vinculada en el código. El texto de ejemplo (placeholder) escrito solo dentro del cuadro no sustituye a la etiqueta, porque desaparece al empezar a escribir. Si el formulario de presupuesto de un sitio web corporativo o el paso de pago de una tienda no pueden completarse con el teclado y un lector de pantalla, ese usuario no puede convertirse en cliente.
Para la compatibilidad con lectores de pantalla, los mensajes de error deben asociarse con el campo correspondiente y decir claramente qué hay que hacer: por ejemplo, «El número de teléfono debe tener 10 dígitos» en lugar de «Entrada no válida». El idioma de la página debe indicarse con el atributo lang de la etiqueta html (es para español); de lo contrario, el lector de pantalla leerá el texto con las reglas de un idioma equivocado.
<html lang="tr">
...
<label for="tel">Telefon</label>
<input id="tel" type="tel" autocomplete="tel"
aria-describedby="tel-hata" aria-invalid="true">
<p id="tel-hata">El número de teléfono debe tener 10 dígitos.</p>¿Cuándo usar ARIA?
Los atributos ARIA son para los casos que el HTML no cubre. La primera regla es esta: si un elemento HTML nativo hace el trabajo, utilícelo. Un ARIA mal usado puede causar más problemas que no usarlo en absoluto.
Accesibilidad móvil y táctil
En el teléfono, la accesibilidad plantea cuestiones adicionales. WCAG 2.2 prevé, en el nivel AA, un tamaño mínimo de 24×24 píxeles CSS para las áreas táctiles; para un uso cómodo se prefieren áreas mayores. Los enlaces pequeños apretados unos contra otros provocan toques equivocados.
La orientación de la pantalla no debe bloquearse y el contenido debe funcionar tanto en vertical como en horizontal. No deben usarse ajustes que impidan el zoom. Encontrará otros puntos que cuidar en el móvil en nuestro artículo sobre el sitio web adaptado a móviles y en nuestra página de diseño responsive.
Los errores más frecuentes
En los sitios que hemos revisado en la práctica, los problemas de accesibilidad se concentran casi siempre en los mismos puntos. La buena noticia es que la mayor parte puede corregirse con pequeños arreglos de código y supone una mejora que los usuarios notan de inmediato.
- Texto gris claro sobre fondo gris claro, es decir, contraste insuficiente.
- Imágenes de producto con el texto alternativo vacío o rellenado con el nombre del archivo.
- Textos de enlace que no explican el contexto, como «haga clic» o «leer más».
- Elegir los niveles de título por su aspecto; saltar directamente de H1 a H4.
- Menús desplegables que no se abren con el teclado y ventanas emergentes que no se pueden cerrar.
- Carruseles que arrancan solos y no se pueden detener, y vídeos con sonido automático.
- Ocultar por completo el contorno de foco por motivos de diseño.
¿Cómo probar su sitio?
Las herramientas automáticas detectan una parte de los problemas, pero no todos. El mejor resultado se logra combinando las herramientas con breves pruebas manuales. Esta revisión es una parte natural de un buen proceso de diseño UI/UX; explicamos la diferencia entre ambos conceptos en nuestro artículo sobre la diferencia entre UI y UX.
- Suelte el ratón y use la página solo con Tab y Enter.
- Obtenga un informe de accesibilidad con Lighthouse, en las herramientas para desarrolladores de Chrome.
- Escuche varias páginas con el NVDA gratuito (Windows) o con el VoiceOver integrado (macOS, iOS).
- Amplíe la letra al 200 por ciento en el navegador y compruebe si la página se descompone.
- Desactive las imágenes y compruebe si la página sigue siendo comprensible.
Preguntas frecuentes
01¿La accesibilidad contribuye al SEO?
Aunque no se considere directamente una señal de posicionamiento, una estructura de títulos correcta, el texto alternativo y los textos de enlace con sentido ayudan a los buscadores a entender la página. Por eso la accesibilidad y el diseño web SEO se apoyan en gran medida en la misma base.
02¿Basta con un plugin o una barra de herramientas de accesibilidad?
Las barras de herramientas añadidas encima de la página no resuelven los problemas básicos del código. Un formulario sin etiquetas o un menú que no se abre con el teclado debe corregirse en su origen.
03¿Se puede hacer accesible un sitio ya existente?
Sí. Correcciones como el contraste, el texto alternativo y las etiquetas de formulario suelen poder hacerse sobre la estructura existente. Los problemas de fondo, como la navegación con teclado y la estructura del menú, a veces exigen replantear el diseño.
04¿Existe una obligación legal?
En algunos países y en determinados sectores, la accesibilidad es un requisito legal; el tema cobra cada vez más importancia, sobre todo para las empresas que atienden al mercado europeo. Para su situación concreta, consulte la normativa vigente y a su asesor jurídico.
La accesibilidad no es algo que se hace una vez y se olvida, sino un criterio de calidad que se cuida en cada fase del diseño y del contenido. Para evaluar su sitio según los fundamentos de WCAG, conozca nuestro servicio de diseño UI/UX; para los demás componentes de un sitio corporativo, lea nuestro artículo qué es un sitio web corporativo. Aurora Yazılım, con sede en Edremit (Türkiye), desarrolla desde 2006 proyectos de diseño web que todo el mundo puede utilizar.
