Por que a accesibilidade e o consentimento se solapan agora

O GDPR esixe que o consentimento se poida obter de cada usuario, non só dos que poden ver e facer clic nun banner. O Comité Europeo de Protección de Datos aclarou que se un interesado non pode interactuar de xeito significativo coa interface de consentimento — debido a unha discapacidade que o sitio non accommodou — o consentimento non foi obtido validamente. Iso significa que as cookies nunca deberían terse cargado.

No ámbito da accesibilidade, a Lei europea de accesibilidade (EAA), transposta á lexislación nacional en todos os Estados membros da UE, fai do WCAG 2.1 AA o mínimo para os sitios web e aplicacións do sector privado que ofrecen servizos ao consumidor. O réxime sancionador varía segundo o país, pero normalmente oscila entre 50.000 e 500.000 euros por infracción, ademais de ordes de retirada do mercado para o incumprimento persistente.

Os requisitos básicos do WCAG para os banners de cookies

Operabilidade co teclado

Cada control do banner — Aceptar, Rexeitar, Xestionar preferencias, pechar — debe ser accesible e operativo só co teclado. Os usuarios deben poder moverse entre os botóns en orde lóxica con Tab e activalos con Enter ou Space. O foco debe ser visible cunha relación de contraste mínima de 3:1 contra o fondo.

Captura do foco en banners modais

Se o banner bloquea a interacción co resto da páxina, o foco do teclado debe quedar atrapado dentro do banner ata que o usuario faga unha elección. Os usuarios non deben poder saír do banner con Tab para desprazarse pola páxina subxacente. Cando o foco estaba atrapado e o banner péchase, o foco debe volver ao elemento que activou o banner ou a un valor predeterminado razoable.

Anuncios do lector de pantalla

O banner debe ser anunciado como un diálogo cun nome e un papel accesibles. Usa `role="dialog"` ou `role="alertdialog"` con `aria-labelledby` que apunte ao encabezado do banner e `aria-describedby` que apunte ao texto explicativo.

Contraste de cor

O texto principal debe cumprir un contraste de 4,5:1 contra o fondo; o texto grande (18pt+ ou 14pt negrita) precisa 3:1. O texto dos botóns, as iconas e os indicadores de foco teñen todos os seus propios mínimos de contraste. Un botón "Rexeitar" gris claro sobre fondo branco é un fallo frecuente do WCAG que vemos nas auditorías.

Sen indicios só de cor

Non te apoies só na cor para diferenciar Aceptar de Rexeitar. Usa etiquetas, iconas ou formas distintas para que os usuarios con daltonismo poidan distinguir os botóns.

Patróns escuros e accesibilidade

O WCAG 2.2 introduce novos criterios que apuntan directamente aos patróns escuros — especialmente relevantes para o consentimento:

• 3.3.8 Autenticación accesible — prohibe os quebracabezas cognitivos como fricción do consentimento.
• 3.3.7 Entrada redundante — os usuarios non deberían ter que volver a introducir información só para retirar o consentimento.
• 2.4.11 Foco non oculto — o propio banner non debe ocultar o indicador de foco dos elementos que están detrás del.
• 2.5.7 Movementos de arrastre — se o teu banner usa unha interacción de arrastre para aceptar, debe existir unha alternativa de punteiro único.

RTL e internacionalización

A accesibilidade esténdese ás linguas de dereita a esquerda (árabe, hebreo, persa, urdú) e á pronunciación do lector de pantalla:

• Establece `dir="rtl"` no banner cando o idioma do documento é RTL para que a orde dos botóns e o fluxo do foco coincidan coa dirección de lectura.
• Usa os atributos `lang` correctos no contido do banner traducido para que os lectores de pantalla pronuncien as palabras coa fonética correcta.
• Espella a iconografía — os chevrons, frechas e indicadores de progreso deben inverterse para as localidades RTL.

Probar o teu banner para o cumprimento do WCAG

Non confíes nunha única ferramenta. Combina o escaneo automatizado con probas reais de tecnoloxía de asistencia:

• axe DevTools ou Lighthouse — detecta automaticamente aproximadamente o 30-40% dos fallos do WCAG.
• NVDA ou JAWS en Windows, VoiceOver en Mac/iOS, TalkBack en Android — proba con lectores de pantalla reais. Pódese anunciar, navegar e pechar o banner usando só o lector de pantalla?
• Navegación só co teclado — desconecta o rato. Se non podes Aceptar, Rexeitar e xestionar as preferencias, os usuarios de teclado tampouco.
• Simulación de daltonismo — Chrome DevTools ten simuladores integrados de deficiencia visual. Comproba que Aceptar e Rexeitar se distinguen en protanopia, deuteranopia e tritanopia.
• Zoom ao 400% — o WCAG esixe que o contido siga sendo usable ao 400% de zoom sen desprazamento horizontal. Os banners de posición fixa adoitan fallar nesta proba.

Fallos comúns de accesibilidade que vemos

• Rexeitar oculto detrás dunha icona de engrenaxe — patrón escuro máis fallo de accesibilidade (non hai nome accesible no botón de icona).
• O foco nunca chega ao banner — banners que roban a atención visual pero son ignorados na orde Tab.
• Banner modal sen trampa de foco — os usuarios poden moverse con Tab á páxina de fondo mentres o banner afirma bloquear a interacción.
• Non hai `aria-live` nos cambios de preferencias — os usuarios de lector de pantalla non escoitan a confirmación de que a súa elección foi gardada.
• Banners traducidos sen atributo `lang` — os lectores de pantalla pronuncian o contido en español con fonética inglesa.

Como FlexyConsent ofrece accesibilidade