Sitio web accesible y BFSG: qué deberían revisar las pymes y qué no consigue un overlay

La consulta no llega y nadie lo advierte. Un visitante recorre con el tabulador el formulario de contacto, llega al campo “Asunto” y de repente el foco salta al vacío: el desplegable es un elemento hecho a medida que solo responde a clics de ratón. Se rinde. En las estadísticas este momento no aparece en ninguna parte; parece un abandono más.

Supongamos que esta fuera la situación de partida de un pequeño proveedor de servicios con un sitio web cuidado y visualmente atractivo. El diseño procede de una buena plantilla, los textos son esmerados, el tiempo de carga es correcto. Que el sitio apenas sea utilizable para personas con discapacidad visual, con temblor, con una sola mano o simplemente sin ratón no figura en ningún informe. Quien lo probara probablemente lo habría arreglado hace tiempo.

Por eso la accesibilidad es menos una cuestión moral que de percepción: no se ven las barreras mientras uno no las vive. Además, el grupo es mayor de lo que se piensa. Incluye las limitaciones permanentes, pero también un brazo roto, la luz solar intensa sobre el teléfono, la vista que disminuye con la edad o un monitor de portátil deficiente en la oficina.

Para las pequeñas empresas se suma una consideración sobria: cada consulta cuenta. Cuando una empresa recibe pocos contactos por semana, un formulario que excluye a una parte de los visitantes no es un asunto técnico marginal, sino un encargo perdido. No se puede cuantificar de forma general cuán grande es esa parte. Solo es seguro que no se revela por sí sola y que únicamente se hace visible mediante pruebas dirigidas.

Los patrones de error se repiten tanto que se dejan clasificar con facilidad. Texto gris sobre fondo gris claro que parece elegante y en la práctica apenas se lee. Un menú que se despliega al pasar el ratón y no es accesible con el teclado. Un contorno de foco que un diseñador eliminó con CSS “para una imagen limpia”. Imágenes sin descripción o con el nombre del archivo como descripción. Campos de formulario explicados solo por un texto de marcador de posición que desaparece al escribir.

A ello se suman errores de estructura que no se ven visualmente. Los encabezados se eligen por el tamaño de letra y no por su significado; los botones son en realidad bloques de texto en los que se puede hacer clic, sin rol y sin función de teclado. Un lector de pantalla lee entonces “grupo, grupo, grupo” o se salta lo más importante. Para los visitantes que ven esto permanece invisible, porque el ojo deduce del diseño y del color un significado que el código no proporciona.

¿Por qué pasa tanto tiempo sin descubrirse? Porque los controles de calidad habituales no lo detectan. Una revisión de diseño evalúa la impresión, una prueba comprueba si el botón desencadena un clic y las analíticas muestran abandonos sin causa. La accesibilidad exige una mirada que nadie adopta en el día a día: usar la página sin ratón, sin distinguir colores o sin imágenes. Quien ha entrenado una vez esta mirada encuentra hallazgos sorprendentemente rápido.

Las Web Content Accessibility Guidelines, WCAG para abreviar, se articulan en cuatro principios. Los contenidos deben ser perceptibles, el manejo debe ser posible, los contenidos y el manejo deben seguir siendo comprensibles y el código debe ser lo bastante robusto para que distintas tecnologías puedan interpretarlo. De los principios se derivan pautas y criterios de conformidad verificables, divididos en tres niveles: A, AA y AAA. En la práctica, el nivel AA es el que más importa.

La utilidad de los principios reside en que estructuran las preguntas. “Perceptible” pregunta si alguien puede captar el contenido a través de al menos un canal sensorial. “Operable” pregunta si cada función puede utilizarse sin un control fino del ratón, sin presión de tiempo y sin gestos. “Comprensible” se refiere al lenguaje, la previsibilidad y la ayuda ante errores de entrada. “Robusto” significa un marcado limpio, para que los lectores de pantalla y otras ayudas técnicas no tengan que adivinar.

Un ejemplo lo hace tangible. Un menú de pestañas para servicios es claro visualmente, pero sin roles ni estados un lector de pantalla no sabe qué pestaña está activa (robusto), las teclas de flecha no hacen nada (operable), la pestaña activa se distingue solo por un tono de color (perceptible) y las etiquetas son abreviaturas que nadie explica (comprensible). Un solo componente infringe los cuatro principios a la vez.

Empleamos este esquema como ayuda para pensar y no como lista de verificación. Una lista de comprobación tienta a despachar cada criterio por separado y perder de vista el conjunto. Es mejor plantear la pregunta por tipo de página: ¿quién podría fallar aquí y cómo se notaría? De ahí surge una revisión orientada al uso real que emplea los criterios como medida.

El camino más tentador es un overlay: un script que muestra un símbolo al margen de la página y promete hacer accesible el sitio web con una línea de código. Para las pequeñas empresas resulta atractivo porque es barato, rápido y suena a solución. El problema está en el mecanismo. Un script que modifica propiedades en el navegador en tiempo de ejecución solo puede adivinar etiquetas ausentes y estructura incorrecta, no completarlas de forma fiable.

Se añade un conflicto práctico. Las personas que usan lectores de pantalla y teclado ya tienen configuradas sus ayudas técnicas, y un overlay adicional puede estorbar en lugar de ayudar. Que los overlays no corrigen código defectuoso es ampliamente conocido entre los especialistas, y varias asociaciones de personas afectadas los rechazan. Además, un distintivo de “accesible” en el sitio web no sustituye a una revisión ni demuestra conformidad.

Eso no significa que toda barra de ajustes sea inútil. Una función para ampliar la letra o cambiar el contraste puede aportar comodidad. Pero es un complemento, no un cimiento. Lo decisivo es que la página esté bien construida sin ninguna herramienta adicional. Por eso recomendamos corregir la causa en el código fuente y en el diseño, lo que, por regla general, también es más rentable que una solución de suscripción permanente que no cambia nada en el cimiento.

Antes de usar un producto así, merecen la pena tres preguntas al proveedor: ¿qué se modifica exactamente y dónde queda intacto el código fuente? ¿Quién responde si la página contiene barreras a pesar del distintivo? ¿Y qué pasa con su página si usted rescinde el contrato? Si las respuestas son evasivas, eso ya es en sí una información útil.

La Barrierefreiheitsstärkungsgesetz, BFSG para abreviar, transpone una directiva europea y se aplica en Alemania desde el verano de 2025. No se dirige a todos los sitios web, sino a determinados productos y servicios que se ofrecen a consumidores. El foco está, por ejemplo, en las tiendas en línea y otras ofertas en las que los consumidores pueden celebrar un contrato por internet. Para las microempresas se prevén excepciones que dependen del tipo de servicio y del tamaño de la empresa.

Si su empresa está afectada depende, por tanto, de la oferta y no de la mera existencia de un sitio web. Una empresa de oficios cuyo sitio presenta servicios y recibe consultas se encuentra en una situación distinta a la de un proveedor que celebra contratos con consumidores en línea. Esta valoración no es asesoramiento jurídico. Para afirmaciones vinculantes sobre si le afecta, sobre plazos, obligaciones y consecuencias, debe consultar a un asesor jurídico que conozca su oferta.

Con independencia de la afectación jurídica, el criterio técnico es útil. La norma europea en la que se apoya la ley se basa, para los contenidos web, en las WCAG. Quien orienta su sitio web al nivel AA de WCAG 2.x trabaja con un criterio ampliamente reconocido y, al mismo tiempo, hace algo por todos los visitantes. Separamos deliberadamente ambas cuestiones: la valoración jurídica corresponde a otras manos, la calidad técnica puede mejorarse con independencia de ella.

Las herramientas de revisión automática como Lighthouse o axe detectan de forma fiable una parte de los errores: textos alternativos ausentes, contrastes insuficientes, campos de formulario sin etiqueta, ID duplicados, falta de indicación de idioma. Pero solo cubren una parte de todos los problemas posibles. Si un texto alternativo es útil, si el orden del foco es lógico o si un mensaje de error es comprensible es algo que un script no puede valorar. Por eso, un valor en verde no significa “accesible”, sino “sin errores detectables automáticamente”.

La segunda capa es la revisión manual, que es menos laboriosa de lo que parece. Deje el ratón a un lado y recorra la página con Tab, Mayús+Tab, Intro, la barra espaciadora y Escape. ¿Salta el foco de forma lógica? ¿Es visible en todo momento? ¿Se puede manejar cada menú y cada ventana de diálogo y salir de ellos de nuevo? Después amplíe la vista al 200 por ciento y compruebe si se cortan o se solapan contenidos.

La tercera capa es una muestra con un lector de pantalla, por ejemplo NVDA en Windows o VoiceOver en Mac y iPhone. El esfuerzo compensa en unos pocos recorridos clave: la página de inicio, una página de servicios, el formulario de contacto. Quien ha escuchado una vez su propia empresa entiende de otra manera la estructura de encabezados y los textos de los enlaces. La muestra no sustituye a una prueba con personas afectadas, pero muestra con fiabilidad errores graves que ninguna herramienta señala.

Un ejemplo de la interacción entre las capas: una herramienta indica “la imagen tiene texto alternativo” y la revisión manual comprueba que ahí figura el nombre de archivo “IMG_2043”. Cumplido en lo formal, inútil en la práctica. Y a la inversa: la herramienta detecta un valor de contraste de 3,2 a 1 en un texto corrido gris que el ojo aún lee bien en la oficina. En un smartphone al aire libre se convierte en un obstáculo.

En cuanto al contraste, las WCAG fijan como valores orientativos una relación de al menos 4,5 a 1 para el texto normal y de 3 a 1 para el texto grande, así como para los elementos de control importantes y los gráficos. Puede comprobarse con herramientas de color y con las herramientas de desarrollo del navegador. La corrección suele estar en las variables de diseño, no en la página individual: si se oscurece un gris en el sistema de color, mejoran todos los puntos a la vez. Esto aboga por mantener los colores de forma centralizada.

Para el teclado y el foco rige una regla sencilla: use elementos nativos siempre que sea posible. Un elemento de botón auténtico, un enlace auténtico y un campo de selección auténtico traen consigo el manejo con teclado, el rol y el estado. Las construcciones caseras a base de elementos div tienen que añadirlo todo después y a menudo fallan. El contorno de foco nunca debería eliminarse sin un sustituto. Un contorno claro y de alto contraste cuesta poco y hace la página más fácil de manejar para todos, también para quienes simplemente prefieren teclear.

En los textos para imágenes importa la función. Las imágenes informativas reciben una descripción breve de lo que transmiten; las decorativas, un atributo alt vacío para que se omitan. Un logotipo que funciona como enlace a la página de inicio necesita el nombre del destino, no la descripción de la imagen. Los textos de los enlaces deben entenderse por sí solos: “Servicios de un vistazo” en lugar de “más”. En los formularios, cada campo lleva una etiqueta visible y asociada al campo, y los errores se nombran en el texto, no solo se marcan en rojo.

Entre los puntos más delicados están los elementos que aportan terceros. Un banner de cookies que se superpone a la página pero no gestiona el foco puede dejar atrapadas a las personas que usan teclado o hacer que sigan navegando por detrás. Debe poder manejarse con el teclado, colocar el foco con sentido y devolverlo al cerrarse. Lo mismo vale para los mapas incrustados: un mapa interactivo suele ser casi inutilizable con el teclado, por lo que la dirección debe figurar además como texto a su lado.

Los vídeos y los contenidos de audio necesitan subtítulos o una transcripción para que las personas sordas y con dificultades auditivas puedan usarlos, y una descripción cuando la información es solo visual. Los medios que se inician automáticamente deberían poder detenerse. Los documentos PDF, como listas de precios, formularios o folletos, son un ámbito subestimado: un escaneo sin capa de texto está vacío para un lector de pantalla. Cuando es posible, una página con texto real es la mejor forma, y el PDF queda como complemento.

Otro caso especial son las animaciones y el movimiento. Quien es sensible al movimiento necesita una forma de reducir los efectos. Los navegadores modernos comunican el ajuste del sistema “reducir movimiento” y el diseño puede reaccionar eliminando los efectos de paralaje y los sliders automáticos. Lo mismo vale para los contenidos que cambian por sí solos: un carrusel que sigue sin pausa quita a las personas el tiempo para leer.

Por último, los widgets de terceros, como la reserva de citas, el chat o la visualización de valoraciones. Forman parte de su oferta, pero no son su código. Aquí conviene comprobar antes de integrarlos si el proveedor documenta la accesibilidad y, en caso de duda, ofrecer una alternativa, por ejemplo un número de teléfono o un formulario sencillo. Es incómodo, pero más honesto que esconder un obstáculo tras un distintivo.

Mejorar la accesibilidad consigue en primer lugar una cosa: más personas pueden usar su sitio. Si eso se traduce en más consultas no puede decirse de forma general y depende de cuántos visitantes han fracasado hasta ahora. Está claro que una estructura robusta, contrastes legibles y formularios bien etiquetados también ayudan a los visitantes sin limitaciones, porque las páginas resultan más claras y más rápidas de manejar. Es un beneficio secundario, pero no una promesa cuantificable.

El avance puede medirse con indicadores próximos a la deficiencia. Entre ellos están el número de infracciones señaladas por las herramientas de revisión por tipo de página, el número de recorridos clave que pueden completarse por entero con el teclado y los resultados de la muestra con lector de pantalla, en cada caso antes y después de la revisión. También es significativa la proporción de abandonos en el formulario de contacto, siempre que haya suficientes visitantes para soportar las fluctuaciones.

Lo importante es el límite: una auditoría demuestra lo que se encontró en una fecha concreta, no una conformidad permanente. Contenidos nuevos, una actualización o un plugin pueden hacer reaparecer barreras. Tampoco se puede deducir de una auditoría técnica que no exista ningún riesgo legal. Es una afirmación que no podemos hacer y por eso no la hacemos. Lo realista es un estado documentado, con puntos abiertos claramente identificados y una rutina para mantenerlo.

Un criterio práctico para medir el efecto: tras la revisión, una persona que no conozca el sitio debería poder enviar el formulario de contacto solo con el teclado y ver en todo momento dónde se encuentra. Si lo consigue, se ha alcanzado el objetivo más importante de esta fase, aunque queden otros puntos abiertos.

La accesibilidad resulta más económica cuando se tiene en cuenta desde el principio. Una paleta de colores con contrastes comprobados, elementos de control nativos y una estructura de encabezados con sentido casi no cuestan nada durante la construcción, pero sí tiempo y quebraderos de cabeza al añadirlos después. Por eso, quien crea o renueva un sitio web debería incorporar los criterios al diseño en lugar de revisarlos al final. Para los sitios existentes vale esto: primero las plantillas, después las páginas individuales.

Un segundo punto afecta a la redacción de contenidos. La tecnología crea las condiciones, pero los textos alternativos, los textos de enlace y el lenguaje comprensible nacen en el día a día. Una breve guía para quienes mantienen los contenidos suele aportar más que otra ronda de auditoría. Para empezar bastan tres reglas: describir las imágenes, explicar los enlaces, definir los encabezados según su significado.

En tercer lugar, ayuda abordar con honestidad los conflictos de objetivos. Un diseño muy discreto en gris claro y los contrastes altos se llevan mal, y un carrusel en la página de inicio rara vez es lo que buscan los visitantes. Estas decisiones deben tomarse de forma visible: donde el diseño cede, gana la legibilidad, y donde queda un compromiso, se documenta para que la siguiente revisión no lo repita sin darse cuenta.

El siguiente paso es pequeño y no requiere conocimientos previos. Abra su formulario de contacto, deje el ratón a un lado e intente enviar una consulta solo con el teclado. Si no lo consigue, ya tiene un hallazgo concreto. Si lo consigue, compruebe el contraste de su texto corrido y ejecute después Lighthouse. Si desea una valoración a continuación, revisamos su sitio y le decimos abiertamente dónde está la mayor palanca y qué no se puede responder de forma general.