Políticas, estándares internos y gestión de proveedores

Las buenas intenciones no sobreviven a un cambio de equipo. Lo que sí sobrevive es una política aprobada, un estándar técnico que cualquiera pueda consultar y un contrato que diga con claridad qué se exige a un proveedor y qué pasa si no lo cumple. En esta lección aprenderás a redactar esos tres documentos y a gestionar a los proveedores, que en la práctica son el origen de buena parte de las barreras que encontramos en auditoría.

La política de accesibilidad

La política es el documento breve (dos a cuatro páginas) que aprueba la dirección y que fija el compromiso, el alcance y las responsabilidades. No es un manual técnico. Una estructura que funciona:

1. Compromiso y propósito: por qué la organización se compromete con la accesibilidad digital (derechos, normativa, misión).
2. Ámbito: a qué se aplica: sitios web, aplicaciones, intranets, documentos, contenidos en redes, servicios contratados a terceros, comunicaciones electrónicas. Es importante incluir expresamente lo que se compra, no solo lo que se desarrolla.
3. Estándar de referencia: WCAG 2.2 nivel AA y EN 301 549 (PDF, se abre en una ventana nueva) (hoy la versión armonizada es la v3.2.1; la v4.1.1, publicada en septiembre de 2026 y alineada con WCAG 2.2, está pendiente de cita en el Diario Oficial de la UE) para web, documentos, software y apps. Indica cómo se gestionarán actualizaciones de las normas.
4. Roles y responsabilidades: dirección patrocinadora, responsable o unidad de accesibilidad, responsables de producto, equipos de diseño, desarrollo, contenidos y compras. En la administración pública, la unidad responsable de accesibilidad que exige el RD 1112/2018 (PDF, se abre en una ventana nueva).
5. Procesos clave: accesibilidad en requisitos, diseño, desarrollo, pruebas, publicación de contenidos y contratación.
6. Excepciones: cómo se solicita, quién la aprueba, cuánto dura y qué alternativa se ofrece a las personas usuarias. La carga desproporcionada del RD 1112/2018 exige justificación documentada; conviene exigir lo mismo internamente.
7. Mecanismo de comunicación y reclamación: cómo puede una persona informar de una barrera y en qué plazo se responde.
8. Revisión: periodicidad (anual) y responsable de la revisión.

El estándar técnico interno

El estándar interno traduce la política a reglas operativas para cada perfil. Debe ser más concreto que las WCAG, porque las WCAG dicen qué conseguir y el estándar dice cómo lo hacemos aquí. Ejemplos de contenido:

• Para diseño: paleta de colores con contrastes verificados (1.4.3 Contraste (mínimo), 1.4.11 Contraste no textual), tamaño mínimo de objetivo de 24 × 24 píxeles CSS (2.5.8 Tamaño del objetivo (mínimo)) y preferiblemente 44 × 44, estilo de foco obligatorio (2.4.7 Foco visible, 2.4.11 Foco no oculto (mínimo)), anotaciones de accesibilidad obligatorias en los diseños entregados.
• Para desarrollo: uso del design system corporativo; prohibición de componentes personalizados sin revisión; reglas de ARIA (patrones APG (se abre en una ventana nueva)); pruebas automáticas con axe-core en cada integración; revisión manual con teclado y lector de pantalla antes de cerrar una historia.
• Para contenidos: texto alternativo obligatorio; encabezados jerárquicos; PDF solo cuando sea imprescindible y siempre etiquetado; subtítulos en todo vídeo publicado (1.2.2 Subtítulos (grabados)).
• Para compras: cláusula tipo, pruebas de aceptación y penalizaciones (lo vemos a continuación).

Publica el estándar donde la gente trabaja (intranet, repositorio, herramienta de diseño) y mantenlo con control de versiones. Un estándar en un PDF olvidado no existe.

Gestión de proveedores

En auditoría es muy habitual que los bloqueos más graves estén en componentes de terceros: pasarelas de pago, gestores de citas, plataformas de formación, visores de documentos, chatbots, sedes electrónicas. La organización responde igualmente ante la ley por ellos, pero su capacidad de corrección depende del contrato. Por eso la gestión de proveedores es una pieza estratégica.

Antes de contratar

• Incluye la accesibilidad en las prescripciones técnicas. En el sector público, la Ley 9/2017 (PDF, se abre en una ventana nueva) de Contratos del Sector Público exige que las prescripciones técnicas tengan en cuenta criterios de accesibilidad universal y diseño para todas las personas; cita la EN 301 549 y las WCAG 2.2 AA de forma explícita.
• Pide evidencias, no promesas: un informe de conformidad por criterio (en el ecosistema anglosajón, el ACR basado en la plantilla VPAT es el formato habitual), una demostración con lector de pantalla y teclado, y referencias de clientes que hayan verificado la accesibilidad.
• Valora la accesibilidad como criterio de adjudicación, no solo como requisito mínimo, para premiar a quien va más allá.

En el contrato

• Nivel exigido: conformidad con WCAG 2.2 AA y con los requisitos aplicables de la EN 301 549.
• Verificación: pruebas de aceptación antes de la recepción, realizadas por la organización o por un tercero, con metodología WCAG-EM (se abre en una ventana nueva).
• Corrección: plazos por severidad (por ejemplo, bloqueos en 10 días hábiles, problemas graves en 30, moderados en la siguiente versión) y sin coste adicional.
• Penalizaciones: retención de pagos o penalidades por incumplimiento, y resolución del contrato en casos reiterados.
• Mantenimiento: obligación de mantener la conformidad en actualizaciones y de informar de regresiones.
• Documentación: entrega de documentación de accesibilidad (cómo se usan las funciones con teclado y tecnologías de apoyo), como pide el capítulo 12 de la EN 301 549.

Durante la relación

Mantén un registro por proveedor: nivel declarado, resultado de la última verificación, incidencias abiertas y plazos. Revisa la accesibilidad en cada versión mayor. Cuando un proveedor no responda, documenta cada comunicación: será la base de una penalización o, llegado el caso, de la justificación de carga desproporcionada mientras se busca alternativa.

Lista de comprobación de la gobernanza documental

1. Política de accesibilidad aprobada por la dirección, con ámbito que incluye lo contratado.
2. Estándar técnico interno publicado y versionado, por perfil.
3. Procedimiento de excepción con aprobación, plazo y alternativa.
4. Cláusula tipo de accesibilidad en todos los pliegos y contratos tecnológicos.
5. Pruebas de aceptación de accesibilidad antes de recepcionar.
6. Registro de proveedores con estado de accesibilidad e incidencias.
7. Revisión anual de la política y del estándar.

Resumen

• La política fija compromiso, ámbito, estándar (WCAG 2.2 AA y EN 301 549), roles, excepciones y revisión; el estándar interno traduce la política a reglas concretas por perfil.
• Un procedimiento de excepción documentado es mejor que incumplimientos invisibles.
• Los proveedores concentran muchos bloqueos: exige evidencias antes de contratar, pruebas de aceptación antes de recepcionar y plazos de corrección con penalizaciones en el contrato.
• La Ley 9/2017 obliga al sector público a incluir la accesibilidad en las prescripciones técnicas; conviene citar en ellas la EN 301 549 y las WCAG 2.2 de forma expresa.