¿Cómo hago accesible mi página web?

Hacer accesible una web: qué significa y quién debe hacerlo

Una web es accesible cuando es perceptible, operable, comprensible y robusta; esos son los cuatro principios básicos de las Pautas de Accesibilidad para el Contenido Web (WCAG). En la práctica significa que los textos se pueden leer, incluso con poca visión, todo funciona sin ratón, los procesos son fáciles de seguir y el código está lo bastante limpio para que las ayudas técnicas, como los lectores de pantalla, lo lean correctamente. Como objetivo de implementación se ha impuesto WCAG 2.2 en el nivel AA.

Que exista una obligación depende de su oferta. La ley alemana de accesibilidad (BFSG) rige desde el 28 de junio de 2025 y afecta sobre todo a ofertas para consumidores con celebración de contrato, como tiendas online y flujos de reserva; las microempresas están exentas en los servicios. Las páginas meramente informativas y las ofertas solo para clientes empresariales, por lo general, no entran, y los organismos públicos siguen el reglamento BITV 2.0. Esta guía no sustituye el asesoramiento jurídico: haga revisar su obligación caso por caso.

Paso 1: comprobar el estado actual, de forma automática y a mano

Empiece con un inventario. Las herramientas automáticas como Lighthouse, axe o WAVE encuentran con rapidez etiquetas ausentes, contrastes insuficientes o identificadores duplicados, pero solo detectan una parte de los problemas. No ven si un texto alternativo tiene sentido ni si el manejo sigue siendo lógico. No se fíe por eso nunca de un único valor de prueba: complemente cada pasada automática con sencillas pruebas manuales.

Revise sus flujos más importantes, como la página de inicio, el formulario de contacto, la reserva o el pedido, con unos pocos gestos. Maneje la página solo con la tecla Tab, amplíela al 200 por ciento y pruebe un flujo corto con un lector de pantalla como NVDA o VoiceOver. Anote cada error con la página, la descripción y la urgencia. Así surge una lista priorizada de la que se pueden deducir el esfuerzo y el orden de implementación.

• Navegar por la página solo con el teclado
• Ampliar la vista al 200 por ciento y comprobar que no se corta nada
• Prueba por muestreo con lector de pantalla en los flujos más importantes
• Medir el contraste de textos y elementos de control
• Anotar los errores con la página, la descripción y la urgencia

Paso 2: perceptible, con contrastes, textos y medios

Según las WCAG, el texto normal necesita una relación de contraste de al menos 4,5 a 1 con el fondo, y el texto grande y los elementos de control, como los bordes de los campos de entrada, al menos 3 a 1. El texto gris claro sobre blanco y el texto sobre fotos son errores típicos. No se fíe nunca solo del color: un borde rojo alrededor de un campo erróneo necesita además un texto o un símbolo. El texto debería poder ampliarse sin pérdida y no estar incrustado en imágenes.

Las imágenes con significado reciben un texto alternativo breve y con sentido; las puramente decorativas, uno vacío para que los lectores de pantalla las omitan. Los vídeos necesitan subtítulos, y para los contenidos que solo se explican en la imagen hace falta una descripción o una transcripción. Los medios no deberían iniciarse automáticamente con sonido y deberían poder pausarse. Estas medidas ayudan no solo a las personas con limitaciones, sino a cualquiera que mire una pantalla en la calle, con ruido o con luz intensa.

Paso 3: operable, con teclado, foco y tamaños de destino

Todo lo que se pueda manejar con el ratón debe funcionar también con el teclado: menús, formularios, diálogos, carruseles. El orden al tabular debería seguir la lógica visual, y cada elemento activo necesita un foco claramente visible. Según WCAG 2.2, el foco tampoco debe quedar tapado por elementos fijos como cabeceras o avisos de cookies. Un enlace de salto al principio de la página permite omitir la navegación. Las trampas de teclado de las que ya no se puede salir son inadmisibles.

WCAG 2.2 fija además requisitos para el manejo táctil: las superficies en las que se hace clic deberían medir al menos 24 por 24 píxeles CSS o tener suficiente separación, y las acciones que exigen arrastrar necesitan una alternativa sencilla con un clic. Los límites de tiempo, por ejemplo en las sesiones, deberían poder prolongarse. Estos puntos facilitan el manejo a personas con limitaciones motoras y mejoran a la vez el uso en el teléfono móvil.

• Todas las funciones accesibles con el teclado, en orden lógico
• Foco visible que no quede tapado
• Enlace de salto al contenido principal
• Superficies de clic con tamaño suficiente o separación suficiente
• Alternativas sencillas a los movimientos de arrastre

Paso 4: comprensible, con estructura, formularios y mensajes de error

Una estructura clara ayuda a todos. Use exactamente un encabezado principal y debajo una jerarquía lógica, marque semánticamente áreas como cabecera, navegación, contenido principal y pie, dé a cada página un título significativo y fije el idioma de la página en el código para que los lectores de pantalla pronuncien bien. Los textos de los enlaces deberían entenderse por sí solos; «haga clic aquí» no dice nada en una lista de enlaces.

Los formularios son el obstáculo más frecuente. Cada campo necesita una etiqueta visible y vinculada al campo, los campos obligatorios deben reconocerse, y los mensajes de error aparecen como texto junto al campo afectado y explican cómo corregir el error. Use la función de autocompletado del navegador y no exija introducir los datos varias veces. Los inicios de sesión deberían funcionar sin acertijos ni tareas de memoria. Eso aumenta el número de solicitudes completadas.

Paso 5: robusta, con código limpio, terceros y documentos

La base más fiable es el HTML semántico: botones reales como botones, enlaces como enlaces, listas como listas. Los atributos ARIA complementan donde los elementos nativos no bastan, pero no los sustituyen; un ARIA defectuoso suele empeorar el manejo más que no tenerlo. Para componentes construidos a medida, como menús desplegables, diálogos o carruseles, existen patrones probados que tienen en cuenta el teclado y el lector de pantalla. Pruebe estos bloques uno a uno.

Tenga en cuenta también lo que no es suyo: avisos de cookies, widgets de reserva y de pago, ventanas de chat y mapas incrustados. Si no son accesibles, todo su flujo resulta inutilizable, y entonces hace falta adaptarlos o sustituirlos. Lo mismo vale para los documentos PDF, que deberían ofrecerse como archivos estructurados y accesibles. Desaconsejamos el uso de una superposición que promete accesibilidad con solo pulsar un botón: no corrige las causas en el código.

Paso 6: declaración, comentarios y manteni­miento continuo

Documente el estado de su accesibilidad. Según la obligación, esto incluye información sobre la accesibilidad de su oferta, una declaración de accesibilidad con el estado de la implementación y las limitaciones conocidas, y un contacto a través del cual los usuarios puedan comunicar deficiencias. Los organismos públicos están expresamente obligados a ello; para otros proveedores, las obligaciones de información dependen de la ley y de la oferta. Haga que se revise jurídicamente caso por caso; esto no sustituye el asesoramiento jurídico.

La accesibilidad no es un proyecto con punto final, porque cada contenido nuevo puede abrir lagunas. Fije normas para la redacción: textos alternativos, estructura de encabezados, textos de enlace con sentido, subtítulos. Revise de nuevo los flujos más importantes en cada versión y ante cambios mayores, y forme a los redactores nuevos. Quien nombra con claridad las responsabilidades mantiene la calidad a largo plazo. Le acompañamos desde la revisión y la implementación hasta la formación.