Accesibilidad web obligatoria para empresas

Índice de contenidos

• Introducción
• ¿Cuándo es obligatoria la accesibilidad web?
• El nivel de referencia: WCAG y conformidad AA
• Dónde fallan más las webs de empresa
• Cómo abordar la accesibilidad web obligatoria sin improvisar
• No confundáis el cumplimiento con un widget
• Una decisión de negocio, no solo de cumplimiento

Introducción

Una persona llega a vuestra página de contacto, pero no puede activar el botón con el teclado. Otra no puede entender un vídeo porque no tiene subtítulos. Una tercera abandona el proceso de compra porque el mensaje de error de un formulario solo aparece en rojo. No son incidencias menores de diseño: son barreras que hacen perder ventas, servicio y confianza. La accesibilidad web obligatoria sitúa estos problemas en un ámbito de cumplimiento, pero para muchas empresas el coste real también es comercial y operativo.

La pregunta útil no es si una web «se ve bien». Es si una persona puede informarse, registrarse, comprar, solicitar un presupuesto o gestionar un servicio sin depender de capacidades, dispositivos o formas de navegación concretas. Esta es la diferencia entre una presencia digital decorativa y una infraestructura que funciona.

¿Cuándo es obligatoria la accesibilidad web?

No todas las empresas tienen exactamente las mismas obligaciones. El marco aplicable depende del país en el que operáis, del tipo de servicio, de los mercados en los que vendéis y de si vuestra organización presta un servicio público o esencial. Por eso, tratar la accesibilidad como una casilla legal universal es un error.

En la Unión Europea, la normativa de accesibilidad del sector público ya exige que muchas webs y aplicaciones públicas sean accesibles. Además, el Acta Europea de Accesibilidad amplía las exigencias a determinados productos y servicios dirigidos al consumidor desde junio de 2025. Entre los ámbitos afectados se encuentran, según el caso, el comercio electrónico, los servicios bancarios, las plataformas de transporte, las comunicaciones electrónicas y determinados servicios digitales asociados.

Para las empresas de Andorra o de fuera de la UE, el factor determinante no es solo dónde está constituida la sociedad. También cuenta si comercializa servicios a consumidores europeos, si trabaja con organismos públicos o si forma parte de una cadena de proveedores que impone requisitos de accesibilidad. Las microempresas pueden tener excepciones en contextos específicos, pero no conviene asumirlas sin revisar el caso concreto con asesoramiento jurídico.

La conclusión operativa es clara: identificad vuestro mercado, vuestros canales digitales y los servicios que los usuarios pueden contratar o gestionar a través de ellos. Después, definid qué nivel de cumplimiento os corresponde. Hacerlo al revés —rediseñar sin conocer el alcance legal ni las prioridades de negocio— genera gasto y deja puntos críticos sin resolver.

El nivel de referencia: WCAG y conformidad AA

Cuando se habla de requisitos técnicos, las Pautas de Accesibilidad para el Contenido Web, conocidas como WCAG, son la referencia habitual. La conformidad AA es a menudo el nivel exigido en licitaciones, entornos regulados y proyectos con una elevada exposición pública. No es un sello estético ni una prueba que pueda superarse en una sola sesión de QA.

Las WCAG agrupan los criterios en torno a cuatro condiciones: el contenido debe ser perceptible, operable, comprensible y compatible con tecnologías de asistencia. Traducido a decisiones de producto, esto implica que una imagen relevante necesita una alternativa textual útil; que la navegación debe funcionar con teclado; que los campos de un formulario deben tener etiquetas claras; y que el código debe transmitir correctamente la estructura y el estado de los componentes.

El contraste de color es probablemente el aspecto más conocido, pero es solo una parte del trabajo. Una web con un contraste correcto puede seguir siendo inaccesible si el foco del teclado no es visible, si un menú desplegable queda atrapado, si una ventana emergente no anuncia su apertura o si un lector de pantalla recibe botones sin nombre.

Dónde fallan más las webs de empresa

Las barreras suelen aparecer en componentes repetidos, no en una única página. Esto es una buena noticia: corregir un sistema de diseño, una plantilla o un componente de desarrollo puede mejorar decenas de pantallas a la vez. También explica por qué los parches puntuales suelen fallar con el tiempo.

Los formularios son un punto especialmente sensible porque coinciden con momentos de conversión. Un placeholder no sustituye a una etiqueta de campo. Los errores deben explicar qué ha ocurrido y cómo solucionarlo, no limitarse a cambiar de color. Si se solicita un número de teléfono con un formato específico, la instrucción debe darse antes de enviar el formulario, no después de bloquear al usuario.

La navegación es el segundo foco crítico. Los menús móviles, buscadores internos, filtros de catálogo, cookies y ventanas modales deben ser navegables y previsibles. Una interfaz puede parecer moderna y, al mismo tiempo, ser imposible de utilizar sin ratón. Esto afecta a personas con discapacidad motora, pero también a usuarios con una lesión temporal, un portátil sin ratón o una conexión lenta que altera el comportamiento de la página.

Los contenidos multimedia también requieren criterio editorial. Los vídeos necesitan subtítulos cuando el sonido aporta información; las transcripciones pueden ser necesarias para piezas informativas; y las imágenes no deben tener textos alternativos genéricos. «Imagen 1» no informa a nadie. Sin embargo, una fotografía puramente decorativa no necesita una descripción extensa. La accesibilidad no consiste en añadir texto a todo, sino en conservar el significado.

Cómo abordar la accesibilidad web obligatoria sin improvisar

El primer paso es una auditoría con una doble perspectiva: automática y manual. Las herramientas automáticas detectan problemas recurrentes de marcado, contraste o atributos ausentes. Son eficientes para detectar problemas a gran escala, pero no pueden decidir si un texto alternativo es adecuado, si el orden de navegación tiene sentido o si un proceso de compra es comprensible. Confiar en ellas como única prueba ofrece una falsa sensación de seguridad.

Después hay que priorizar según el riesgo y el impacto. Empezad por los flujos que generan ingresos o dan acceso a un servicio: compra, reserva, alta, pago, contacto, área privada y soporte. Continuad con la navegación global y los componentes compartidos. Esta secuencia evita dedicar semanas a ajustes de páginas secundarias mientras un usuario no puede completar la acción principal.

La corrección debe llegar tanto al diseño como al código. El diseño define la jerarquía, el contraste, los estados de foco, los mensajes y los comportamientos responsive. El desarrollo aplica HTML semántico, estructuras correctas de encabezados, etiquetas de formulario, gestión del foco y compatibilidad con tecnologías de asistencia. Si uno de los dos equipos entra tarde, aparecen soluciones caras y frágiles.

También conviene establecer una definición de hecho para los cambios futuros. Cada nuevo componente debe pasar revisiones de teclado, foco, semántica, contraste y adaptación a móvil antes de publicarse. Cada pieza editorial debe seguir unas reglas básicas para encabezados, enlaces descriptivos, imágenes y vídeo. Sin esta disciplina, una web corregida vuelve a degradarse con cada campaña o actualización.

No confundáis el cumplimiento con un widget

Los widgets que prometen solucionar la accesibilidad mediante una capa flotante resultan atractivos porque parecen rápidos y baratos. Pero no reparan la estructura del código, las etiquetas incorrectas ni los flujos mal diseñados. En algunos casos, incluso añaden fricción a personas que ya utilizan sus propias tecnologías de asistencia.

Una solución fiable trabaja sobre el producto real. Esto puede requerir cambios en una plantilla de CMS, un rediseño de componentes, una revisión del checkout o una integración con sistemas de terceros. Si el proveedor de pagos o reservas no es accesible, la responsabilidad comercial no desaparece porque el componente sea externo. Hay que valorar alternativas, configurarlo correctamente o dejar constancia del riesgo y del plan de mitigación.

Una decisión de negocio, no solo de cumplimiento

La accesibilidad tiene un coste inicial, especialmente en webs antiguas, plataformas muy personalizadas o procesos de compra con muchas dependencias. Pero aplazarla suele multiplicarlo. Corregir un componente antes de desplegarlo es más eficiente que intervenirlo después en decenas de páginas, campañas y variantes de dispositivos.

También mejora elementos que cualquier negocio necesita: formularios más claros, navegación más consistente, contenido mejor estructurado y menos abandono por fricción. No garantiza ventas por sí sola, pero elimina obstáculos que impiden que la demanda existente llegue a convertir.

El buen momento para actuar no es cuando llega una queja o una exigencia contractual. Es cuando vuestra web todavía se puede ordenar con criterio: priorizando los servicios críticos, arreglando el sistema y haciendo que cada futura mejora mantenga el mismo nivel. Esta es la manera práctica de convertir una obligación potencial en un activo digital que aguanta el crecimiento.