Buenas prácticas

Banner de cookies accesible: el consentimiento RGPD debe poder rechazarse

Una banda de cookies no accesible no es solo un fallo de accesibilidad: incumple el RGPD al hacer imposible el consentimiento para todos. Entre el European Accessibility Act y las obligaciones de consentimiento explícito, su banda debe funcionar con el teclado, el zoom y los contrastes mínimos. Descubra cómo evaluarla en unos minutos y los siete puntos clave.

La respuesta breve

Una barra de cookies inaccesible genera una doble incumplimiento: el RGPD invalida cualquier consentimiento que el usuario no pueda expresar (imposibilidad de rechazar con el teclado, contraste insuficiente, botón sin etiqueta), y el EAA exige la accesibilidad de todos los elementos de la interfaz. Las siete comprobaciones mínimas: foco visible al abrirse, navegación completa con teclado, contrastes 4,5:1, nombres accesibles en los botones, rechazo tan fácil como la aceptación, ausencia de trampas de foco, legibilidad al zoom del 200 por ciento.

Por qué una barra de cookies no accesible incumple el RGPD

El RGPD exige un consentimiento explícito y libre. Sin embargo, el consentimiento solo es libre si el rechazo es tan fácil como la aceptación, y solo es accesible si todos pueden expresarlo: teclado, lector de pantalla, discapacidad visual, temblores motores. Si el botón «Rechazar» está ausente del flujo del teclado, oculto bajo 50 píxeles de contenido clickeable, etiquetado en vacío (aria-label vacío o ausente) o con un contraste de 2:1 sobre fondo blanco, el usuario con discapacidad no puede técnicamente rechazarlo: el consentimiento que recoge su sitio no es, por tanto, jurídicamente válido.

La CNIL, desde sus directrices de 2021 y confirmadas en 2023, considera que cualquier obstáculo para expresar la elección (consentimiento o rechazo) hace que esta elección no sea conforme. La accesibilidad ya no es opcional: es un requisito técnico del propio RGPD.

La capa adicional de conformidad: el European Accessibility Act

El EAA, que entrará en vigor el 28 de junio de 2025, obliga a que todos los sitios web y aplicaciones en Europa cumplan con la accesibilidad según la norma WCAG 2.1 nivel AA. Esto incluye también las barras de cookies, que son los primeros elementos que se renderizan en la página: por lo tanto, es la primera conformidad con el EAA que su sitio muestra al visitante. Si esta primera capa falla, la CNIL y las autoridades de accesibilidad recibirán una señal inmediata de negligencia.

La combinación es implacable: una barra de cookies inaccesible genera una carga de incumplimiento simultánea en dos frentes (RGPD y EAA). Los defectos identificados primero (contraste, navegación por teclado, etiquetado) se notificarán tanto como violaciones del consentimiento como violaciones del EAA.

Los siete puntos que verificar en su barra de cookies

1. Enfoque visible al abrirse

Cuando se muestra la barra, el foco del teclado debe estar presente y visible en un elemento de la barra (con mayor frecuencia el primer botón o un botón de cierre). Demasiados sitios muestran la barra pero dejan el foco en el fondo: el usuario que navega con el teclado no sabe dónde actuar.

2. Navegación completa con el teclado

La tecla Tab debe recorrer todos los botones de la barra en un orden lógico (de izquierda a derecha o de arriba a abajo), y la tecla Intro debe activar el botón con foco. Los campos de entrada y los enlaces internos de la barra también deben ser accesibles. Intro (o Espacio en los botones) debe funcionar.

3. Contraste de color suficiente

Texto sobre fondo: mínimo 4,5:1 para el tamaño normal, 3:1 para caracteres grandes (18 pt o más y en negrita). Bordes y elementos gráficos: 3:1. Una barra blanca con texto gris claro suele fallar esta prueba. Los botones semitransparentes sobre fondo blanco también fallan.

4. Botones con nombres claros

Cada botón debe tener una etiqueta visible Y un nombre accesible (atributo aria-label si la etiqueta es un icono, o el texto visible del botón). Un botón con solo un icono «X» para cerrar debe tener aria-label="Cerrar" o una alternativa equivalente. Los lectores de pantalla deben leer «Aceptar todas las cookies», no «Botón».

5. Rechazo tan accesible como la aceptación

El RGPD lo exige. El botón «Rechazar» no debe tener una fuente más pequeña, estar bajo un enlace indirecto o oculto tras un clic de precisión. Si «Aceptar» es accesible con el teclado, «Rechazar» también debe serlo y estar claramente visible. Ningún peso o color diferente debe crear una jerarquía falsa.

6. Sin trampas de foco

Focus trap: al presionar Tab al final de la barra, el foco no debe devolverlo al inicio indefinidamente ni bloquearlo fuera de la barra si esta sigue siendo visible. El foco debe poder salir después de realizar una acción (aceptar, rechazar, cerrar).

7. Legibilidad al zoom del 200 por ciento

Con un zoom del 200 por ciento en el navegador, el texto de la barra debe seguir siendo legible y los botones accesibles con el puntero. No debe haber desbordamientos invisibles ni solapamiento de texto. Un usuario con discapacidad visual que amplíe la página no debe perder la posibilidad de rechazar.

Cómo probar su banner en un minuto

Con el teclado: abra su sitio, cierre el ratón. Presione Tab: el foco debe aparecer en el banner. Continúe con Tab, recorra los botones, presione Entrar. Intente rechazar y luego aceptar. Si no puede seleccionar «Rechazar» con el teclado, su banner no cumple.

En el contraste: capture una foto del banner, péguela en una herramienta de contraste en línea (WebAIM Contrast Checker, Accessible Colors), verifique que el texto y los botones alcancen al menos 4,5:1. Si el resultado es rojo, corríjalo.

Con zoom: presione Ctrl++ tres veces (zoom al 200 por ciento). El banner debe permanecer completo, legible, y todos los botones deben ser clicables sin desplazamiento horizontal.

Con lector de pantalla: si usa un navegador con NVDA (Windows, gratuito) o VoiceOver (Mac), actívelo y escuche lo que lee. Los botones deben tener nombres explícitos («Aceptar todas las cookies» y no «Botón»). Las secciones deben tener una estructura lógica.

Conformidad más allá: pruebas manuales y gobernanza

Estos siete puntos cubren los defectos automatizables (contraste, etiquetado, navegación por teclado, foco). Pero la accesibilidad completa de la barra requiere también pruebas manuales: un desarrollador o un auditor debe verificar que la lógica del foco cumple con las expectativas (sin trampas ocultas), que los campos de personalización (si están presentes) sean navegables con el teclado y que la barra no oculte otros elementos críticos al aparecerse en pantalla.

Piense también en la gobernanza: la mayoría de los CMP (gestores de consentimiento en el mercado) presentan por defecto fallos de accesibilidad. Antes de elegir uno, revise su documentación sobre el EAA y el RGPD, pruebe su barra en preproducción con los siete puntos mencionados y, si es posible, exija correcciones antes de la puesta en línea. Inclaria permite escanear su sitio en unos segundos; la barra de cookies suele ser el primer elemento de la auditoría de accesibilidad, clasificado como bloqueante porque condiciona el acceso al resto.

Actualización: probar la barra cada tres a seis meses. Cada cambio de CMP, cada actualización del navegador o cada modificación del diseño puede generar una nueva no conformidad.

Puntos clave que recordar

• Una barra de cookies inaccesible invalida el consentimiento RGPD y viola el EAA.
• Las siete verificaciones mínimas cubren foco, teclado, contraste, nombres, igualdad aceptación/rechazo, trampas, zoom.
• La prueba manual complementa la prueba automatizada: navegabilidad real con teclado, lógica del foco, coherencia de la gobernanza del CMP.
• Una barra conforme es la primera señal de conformidad global de su sitio.