2026-02-11 · Redacción Baduno · 8 blog.readMin · Blog & Conocimiento
Ley de Refuerzo de la Accesibilidad: Lo que los sitios web deben cumplir ahora
Desde junio de 2025 está en vigor la BFSG – y muchos sitios web empresariales están sujetos a ella. Las obligaciones, ordenadas de forma comprensible, sin pánico.
Quién está afectado
La ley abarca servicios electrónicos orientados al consumidor – incluyendo tiendas en línea y muchos procesos de reserva y contacto. Las ofertas puramente B2B y las microempresas están en parte exentas; la clasificación debe ser verificada legalmente en caso de duda.
Qué se exige
En la práctica, los requisitos se basan en las WCAG: perceptible (contrastes, textos alternativos), operable (teclado, foco), comprensible (lenguaje claro, mensajes de error) y robusto (HTML limpio para tecnologías de asistencia).
La buena noticia
Los sitios web accesibles son casi siempre también sitios web más rápidos, mejor estructurados y más amigables para los motores de búsqueda. La obligación contribuye a una calidad que de todas formas vale la pena – y abre un gran grupo de usuarios a menudo ignorado.
Empezar de forma pragmática
Primero revisar (automatizado más manual), luego priorizar según el impacto: contrastes, textos alternativos, formularios y operación con teclado resuelven la mayoría de las barreras cotidianas. Una declaración de accesibilidad documenta honestamente el estado.
Hreflang y accesibilidad: una interacción a menudo pasada por alto
Los sitios web multilingües se enfrentan a un desafío adicional: los requisitos de accesibilidad se aplican por separado a cada versión de idioma. El atributo hreflang, que indica a los motores de búsqueda la asignación de idioma y región, debe implementarse de manera que los lectores de pantalla y otras tecnologías de asistencia reconozcan correctamente los cambios de idioma. Si hreflang está configurado incorrectamente o falta, puede dificultar significativamente la navegación para usuarios con discapacidad visual, por ejemplo, cuando una página se carga repentinamente en otro idioma sin que el usuario lo espere. En la práctica, esto significa que cada variante de idioma no solo debe ofrecer traducciones, sino también estructuras completamente accesibles. Esto incluye declaraciones de idioma correctas en HTML (atributo lang) y textos alternativos coherentes en todos los idiomas. Por lo tanto, la configuración de hreflang debe incluirse desde el principio en la revisión de accesibilidad.
Herramientas de prueba automatizadas: fortalezas y limitaciones
Herramientas como axe, Wave o Lighthouse pueden detectar automáticamente muchas barreras técnicas, por ejemplo, textos alternativos faltantes, contrastes insuficientes o atributos ARIA incorrectos. Sin embargo, no sustituyen una revisión manual, ya que aspectos como la comprensibilidad de los textos, el orden lógico de los contenidos o la usabilidad de formularios con tecnologías de asistencia solo pueden evaluarse mediante pruebas reales con usuarios. Los análisis automatizados proporcionan un primer diagnóstico rápido de errores y son adecuados para pruebas continuas en pipelines CI/CD. No obstante, los resultados siempre deben ser evaluados por una persona, ya que las herramientas producen tanto falsos positivos como falsos negativos. Un flujo de trabajo pragmático: primero pruebas automatizadas, luego una muestra manual con lector de pantalla y teclado, y finalmente una prueba de usabilidad con personas afectadas.
Consecuencias legales y plazos de transición
El BFSG prevé multas y advertencias si los sitios web no cumplen con los requisitos. Para los productos que se pusieron en funcionamiento antes del 28 de junio de 2025, existe un plazo de transición hasta el 28 de junio de 2030, pero solo para aquellos que ya fueran accesibles antes de la fecha límite o que demuestren estar trabajando en ello. Quien lance un nuevo sitio web o un rediseño después del 28 de junio de 2025 debe cumplir inmediatamente con todos los requisitos. Atención: la ley se aplica a todos los contenidos nuevos; los contenidos antiguos (por ejemplo, páginas de archivo) pueden requerir adaptaciones más complejas. En la práctica, se recomienda documentar por escrito el progreso para poder demostrar, en caso de reclamaciones, que se está implementando la accesibilidad de forma gradual. Una declaración de accesibilidad en el sitio web es obligatoria de todos modos.
Desde junio de 2025 está en vigor la BFSG – y muchos sitios web empresariales están sujetos a ella. Las obligaciones, ordenadas de forma comprensible, sin pánico.
Accesibilidad como parte de la estrategia SEO internacional
Los sitios web accesibles no solo cumplen con los requisitos legales, sino también con muchos criterios que los motores de búsqueda valoran positivamente: estructura HTML semántica, jerarquías claras de encabezados, textos alternativos significativos y tiempos de carga rápidos. Estos factores son relevantes para el SEO en todos los idiomas. Además, los motores de búsqueda pueden penalizar explícitamente barreras como botones sin etiquetar o encabezados faltantes, ya que dificultan la indexación. Quien hace que su sitio web sea accesible para todos los usuarios mejora automáticamente la experiencia de usuario y, por lo tanto, indirectamente las señales de ranking. Especialmente en sitios web multilingües, vale la pena integrar la accesibilidad desde el principio en los flujos de trabajo de localización, por ejemplo, mediante listas de verificación para traductores para crear textos alternativos accesibles.
Pruebas con usuarios reales: por qué son imprescindibles
Las herramientas automatizadas solo detectan una parte de las barreras. Solo la prueba con personas que realmente dependen de tecnologías de asistencia muestra si su sitio web funciona en el día a día. Los usuarios ciegos utilizan los lectores de pantalla de manera diferente a como simulan las pruebas automatizadas; los usuarios sordos tienen requisitos distintos para los videos en lengua de señas; las personas con discapacidades motoras navegan sin ratón. Una prueba estructurada con tres a cinco participantes de diferentes grupos de discapacidad descubre problemas que ninguna herramienta encuentra, como secuencias de enfoque ilógicas, falta de información contextual en las etiquetas ARIA o mensajes de error incomprensibles. Planifique estas pruebas idealmente durante la fase de desarrollo, no justo antes del lanzamiento. Documente los resultados en la declaración de accesibilidad como parte de su aseguramiento de calidad. Recuerde: las pruebas deben realizarse por separado para cada versión lingüística, ya que las traducciones pueden crear nuevas barreras, por ejemplo, cuando los textos alternativos no coinciden con el idioma de destino o las indicaciones de los formularios son gramaticalmente incorrectas.
Sistemas de gestión de contenidos y accesibilidad: obstáculos en los plugins
Muchos sitios web se basan en CMS como WordPress, TYPO3 o Drupal. Estos sistemas ofrecen plugins o extensiones que prometen accesibilidad – por ejemplo, herramientas superpuestas que ajustan contrastes o insertan atributos ARIA posteriormente. Dichas soluciones suelen ser insuficientes e incluso pueden crear nuevas barreras al sobrescribir estructuras semánticas existentes. En su lugar, debe implementar la accesibilidad directamente en el tema o plantilla: estructura HTML limpia, jerarquías de encabezados correctas, elementos de formulario nativos. Al seleccionar plugins, asegúrese de que cumplan con las WCAG y se actualicen periódicamente. Otro problema: muchos editores insertan contenido a través del editor visual e ignoran textos alternativos o formatos de encabezados. Capacite a sus editores o utilice flujos de trabajo que exijan entradas accesibles – como campos obligatorios para textos alternativos en imágenes. También la elección de la plantilla del CMS influye en la accesibilidad: pruebe cada plantilla antes de usarla con una herramienta automatizada y una muestra manual.
Pruebas con personas con discapacidades: el paso imprescindible
Las herramientas automatizadas y las listas de verificación manuales detectan muchas barreras técnicas, pero no sustituyen las pruebas con usuarios reales. Las personas con discapacidades utilizan diferentes tecnologías de asistencia: lectores de pantalla como JAWS, NVDA o VoiceOver, software de ampliación, control por voz o teclados especiales. Cada una de estas combinaciones se comporta de manera diferente, por lo que incluso una página formalmente conforme puede ser inutilizable para un usuario ciego. Por lo tanto, planifique pruebas periódicas con un grupo heterogéneo: personas con discapacidad visual, motora y cognitiva. Haga que realicen tareas definidas en su sitio web, como una compra de producto o rellenar un formulario de contacto. Documente con precisión los problemas que surjan: dónde se estanca la navegación, qué anuncios son incomprensibles, qué elementos no se alcanzan. Las conclusiones de estas pruebas son oro, porque muestran no solo barreras, sino también potencial de optimización para todos los usuarios. Asegúrese de realizar las pruebas por separado para cada versión de idioma, ya que las traducciones y las oraciones subordinadas afectan la comprensibilidad de manera diferente. Integre los resultados en su proceso de mejora continua: la accesibilidad no es un proyecto único, sino una tarea permanente.
Anclar la accesibilidad en el sistema de gestión de contenidos
Muchos defectos de accesibilidad surgen ya en la creación de contenido: los editores olvidan textos alternativos, no utilizan encabezados jerárquicamente o enlazan palabras sin sentido como 'haga clic aquí'. Para evitarlo, debe anclar la accesibilidad directamente en su sistema de gestión de contenidos (CMS). Capacite a sus equipos editoriales en los fundamentos de las WCAG – y hágalo por separado para cada equipo de idioma, para que los requisitos no se vean socavados por diferencias culturales en el diseño de texto. Utilice plugins o extensiones del CMS que exijan campos obligatorios de texto alternativo al insertar imágenes o que muestren visualmente una jerarquía de encabezados. Integre comprobaciones automatizadas en el flujo de trabajo de aprobación que señalen errores comunes antes de la publicación, como etiquetas faltantes o contrastes insuficientes. Asegúrese además de que las plantillas y temas del CMS que utiliza ya sean accesibles – por ejemplo, con landmarks ARIA correctos, gestión del foco del teclado y HTML semántico. Para sitios web multilingües es esencial que el CMS admita la localización de estructuras accesibles, por ejemplo, estableciendo automáticamente los atributos hreflang y las declaraciones de idioma de forma correcta. Un proceso de accesibilidad bien integrado en el CMS reduce el esfuerzo de corrección y garantiza una calidad consistente en todas las versiones de idioma.
blog.faqT
¿Qué sucede si mi sitio web infringe el BFSG?
En caso de infracciones contra el BFSG, se pueden imponer multas. Además, cabe esperar advertencias por parte de competidores o asociaciones de consumidores. El importe de las multas depende de la gravedad de la infracción y puede ascender hasta 100.000 euros. Es obligatorio presentar una declaración de accesibilidad con el alcance y el estado de las medidas, que sirve como prueba.
¿Deben ser también accesibles las traducciones de mi sitio web?
Sí, cada versión lingüística debe cumplir individualmente los requisitos de accesibilidad. Esto incluye atributos de idioma correctos (lang), textos alternativos traducidos y una navegación de baja barrera. El atributo hreflang debe configurarse de modo que los motores de búsqueda y las tecnologías de asistencia detecten correctamente los cambios de idioma. Por lo tanto, las agencias de traducción también deben prestar atención a la accesibilidad de sus entregas.
