Cómo crear y operar una Declaración de Accesibilidad: una plantilla práctica que convierte la responsabilidad social en mejora continua

Resumen ejecutivo (puntos clave primero)

• Una declaración de accesibilidad no es una proclamación de “cumplimos”. Es una promesa sincera por escrito que comunica con claridad el estado actual, el alcance, las limitaciones, los planes de mejora y los métodos de contacto.
• Si tu objetivo es WCAG 2.1 AA, como mínimo tu declaración debería incluir: alcance / normas aplicadas / estado de conformidad / problemas conocidos / alternativas / contacto / fecha de última actualización.
• Lo más importante es lo que ocurre después de publicarla. Con evaluaciones periódicas, priorización de correcciones y gestión de consultas, la responsabilidad social se convierte en confianza sostenida.
• Este artículo incluye plantillas de declaración de accesibilidad listas para copiar, ejemplos para redactar problemas conocidos, un flujo de respuesta a consultas y reglas operativas fáciles de conseguir que se aprueben internamente.

Público objetivo (específico): PR, Legal, Asuntos Generales, RR. HH.; equipos web de organismos/municipios; responsables de sitios corporativos; product managers; líderes de accesibilidad; directores de agencia
Nivel de accesibilidad: Orientado a WCAG 2.1 AA (y asumiendo que la propia declaración es legible y cumple con acceso por teclado, contraste y estructura)

1. Introducción: una declaración es infraestructura social que aporta tranquilidad

El trabajo de accesibilidad es a la vez un reto técnico/de diseño y una declaración de responsabilidad social. Pero, en la práctica, a menudo es difícil hacer que todo sea perfecto de una sola vez. Tamaño del sitio, limitaciones del CMS, activos heredados, vídeos y PDF, integraciones con servicios externos… siempre quedarán asuntos pendientes.

Por eso es importante publicar una declaración de accesibilidad (política/estado). No es un documento que diga “no hay problemas”. Es una guía práctica que comparte honestamente qué funciona, qué es difícil y cómo y cuándo se mejorará, y garantiza que quien necesite ayuda pueda contactarte sin perderse.

En este artículo cubriremos no solo cómo redactar una declaración, sino también el sistema operativo necesario para que no sea “solo de cara a la galería”, convirtiéndola en algo utilizable en la práctica real.

2. Los 7 elementos esenciales de una Declaración de Accesibilidad

Una declaración de accesibilidad debería estructurarse para que quien la lea pueda decidir rápidamente: “¿Puedo usar este sitio?”. Especialmente si apuntas a WCAG 2.1 AA, estos siete puntos son el mínimo.

2.1 (1) Propósito (¿por qué publicarla?)

• Ejemplo: “Mejoramos continuamente para que todas las personas puedan acceder a la información.”

2.2 (2) Alcance (¿qué está cubierto?)

• Dominio, directorios principales, apps, subsitios
• Indica claramente excepciones (servicios de terceros, incrustaciones, PDF heredados, etc.)

2.3 (3) Normas aplicadas (¿qué usas como referencia?)

• Ejemplo: “Nuestro objetivo es WCAG 2.1 Nivel AA.”

2.4 (4) Estado de conformidad (¿qué tan avanzado está?)

• Si declaras “conforme”, “parcialmente conforme”, “no conforme”, etc. puede depender de la política de tu organización, pero añade evidencia como el método de evaluación y la fecha de evaluación.

2.5 (5) Problemas conocidos (¿qué no funciona?)

• Es la parte más importante. La gente quiere saber: “¿en qué podría tener dificultades?”
• Escribe los problemas conocidos no como excusas, sino como impacto + alternativa.

2.6 (6) Alternativas (¿qué deben hacer las personas si encuentran una barrera?)

• Ejemplos: teléfono, email, formulario, chat
• Importante: que sea utilizable vía texto, e incluye horarios de atención / expectativas de respuesta si es posible.

2.7 (7) Fecha de última actualización y plan de mejora (¿cuándo se revisará?)

• Fecha de última actualización, próxima fecha de revisión, prioridades/hoja de ruta (aunque sea ligera)
• Una declaración que deja de actualizarse suele reducir la confianza—por eso las operaciones deben proteger esto.

3. Redacción que genera confianza: diseñar para la sinceridad

Una declaración no solo la leen especialistas; también personas afectadas, sus familias, apoyos y el personal de atención. Por eso no solo debe ser “correcta”, sino también “amable”.

3.1 Minimiza la jerga; si la usas, incluye una explicación en lenguaje sencillo

• “Lector de pantalla” → “software de lectura en voz alta (texto a voz)”
• “Contraste” → “la diferencia de luminosidad entre el texto y el fondo”
• “Operación por teclado” → “usar el sitio sin ratón”

3.2 Habla menos de por qué no puedes—y más de cómo ayudarás

• Mal: “No podemos dar soporte por limitaciones del sistema.”
• Bien: “Algunos PDF pueden no permitir lectura en voz alta. Si necesitas la información, podemos proporcionarla en texto—contacta por el canal indicado abajo.”

3.3 Usa este formato para problemas conocidos (no se desmorona)

Ubicación (p. ej., Empleo > Formulario de solicitud)
Problema (p. ej., los mensajes de error son difíciles de entender con lectura en voz alta)
Impacto (p. ej., cuesta corregir errores de entrada)
Alternativa (p. ej., aceptamos solicitudes por email)
Mejora prevista (p. ej., corrección en la próxima versión; objetivo para marzo de 2026)

4. Plantilla de Declaración de Accesibilidad lista para copiar

Esta “forma básica” funciona para sitios corporativos, del sector público y sitios de servicios. Añade encabezados según sea necesario.

4.1 Plantilla de declaración (ejemplo)

## Política de Accesibilidad (Declaración de Accesibilidad)

### 1. Propósito
Nos comprometemos a mejorar continuamente para que todas las personas—independientemente de su edad, discapacidad o entorno—puedan acceder a la información y utilizar nuestras funcionalidades.

### 2. Alcance
- Cubierto: este sitio web (páginas clave y funciones clave)
- No cubierto (ejemplos): páginas proporcionadas por proveedores externos, contenido incrustado de terceros, algunos materiales heredados (p. ej., PDF)

### 3. Objetivo y normas aplicadas
Nuestro objetivo es cumplir WCAG 2.1 Nivel AA.

### 4. Estado de conformidad
En este momento, estamos mejorando la accesibilidad principalmente en páginas clave y funciones clave.
Método de evaluación: combinación de pruebas automatizadas, pruebas manuales (p. ej., navegación por teclado) y comprobaciones con tecnologías de asistencia.
Fecha de evaluación: AAAA-MM-DD

### 5. Problemas conocidos (ejemplos)
- Algunos documentos PDF pueden ser difíciles de leer en voz alta o de reutilizar.
  Alternativa: si necesitas el contenido, podemos proporcionarlo en texto—contacta por el canal indicado abajo.
  Mejora prevista: a partir de nuevas publicaciones, priorizaremos formatos accesibles y ampliaremos las mejoras con el tiempo.

- Algunos formularios pueden tener indicaciones de error difíciles de comprender.
  Alternativa: podemos aceptar solicitudes por email o teléfono.
  Mejora prevista: lo abordaremos en la próxima actualización del formulario (objetivo: AAAA-MM).

### 6. Contacto (soporte de accesibilidad)
Si tienes dificultades al usar este sitio o quieres enviar comentarios, contáctanos.
- Métodos de contacto: Email / Teléfono / Formulario de contacto (elige lo aplicable)
- Horario: días laborables 9:00–17:00 (ejemplo)
- Si es posible, incluye:
  - URL o nombre de la página
  - Tu entorno (dispositivo, SO, navegador, software de lectura en voz alta, etc.)
  - Qué intentabas hacer y qué ocurrió

### 7. Actualizaciones
Última actualización: AAAA-MM-DD

El punto clave de esta plantilla es: enumerar lo “fuera de alcance” no debe convertirse en un escudo. Incluso si algo está fuera de alcance, ofrecer una alternativa es lo que hace la declaración amable y práctica.

5. Ejemplos de “problemas conocidos” por situación común

La parte más difícil suele ser decidir “cuánto divulgar”. Un buen enfoque es listar un pequeño número de problemas representativos en orden de impacto—demasiados pueden agotar a quien lee.

5.1 Organizaciones con muchos PDF

• Problema: algunos PDF carecen de etiquetado, lo que dificulta la lectura en voz alta y la navegación por encabezados.
• Impacto: las personas usuarias de lectura en voz alta pueden tener dificultades para comprender el contenido; la reutilización (copiar, etc.) puede ser difícil.
• Alternativa: proporcionar el mismo contenido como HTML o texto plano.
• Mejora: priorizar formatos accesibles para materiales nuevos; remediar PDF heredados empezando por los más usados.

5.2 Organizaciones con muchos vídeos

• Problema: algunos vídeos pueden no tener subtítulos suficientes (incluyendo señales sonoras e identificación de quién habla).
• Impacto: la información sonora puede ser difícil de acceder.
• Alternativa: proporcionar una versión en texto (puntos clave o transcripción completa).
• Mejora: estandarizar para nuevas producciones y remediar vídeos existentes por prioridad.

5.3 Servicios centrados en formularios

• Problema: algunos formularios pueden no mover el foco correctamente al resumen de errores.
• Impacto: las personas que usan teclado pueden tener dificultades para encontrar qué corregir.
• Alternativa: ofrecer ayuda de entrada mediante canales de soporte.
• Mejora: estandarizar un enfoque de dos capas: resumen de errores + errores en línea.

5.4 Sitios con incrustaciones de terceros

• Problema: algunos widgets de reserva de terceros pueden no admitir totalmente la navegación por teclado.
• Impacto: las personas usuarias pueden no poder completar la reserva.
• Alternativa: aceptar reservas por teléfono o email.
• Mejora: mantener permanentemente rutas alternativas y compartir solicitudes de mejora con el proveedor (informar del progreso mediante actualizaciones de la declaración).

6. Convertir la declaración en mejora continua: publicar es el comienzo

Publicar no es la meta—es la línea de salida. Si las operaciones se detienen, parecerá “solo lo escribimos”. Construye al menos el siguiente sistema mínimo.

6.1 Ciclo de evaluación (se recomienda trimestral)

• Cada trimestre, revisa páginas representativas (inicio, lista, detalle, formularios, cuenta, etc.)
• Realiza comprobaciones focalizadas antes de lanzamientos que cambien funcionalidades importantes
• Corrige fallos “críticos” de inmediato; programa los demás en la hoja de ruta

6.2 Mantener un backlog de problemas conocidos

Gestiona incidencias con estos cuatro puntos:

• Dónde ocurre (página/función)
• A quién afecta (teclado, lectura en voz alta, visión del color, zoom, etc.)
• Si existe una alternativa
• Esfuerzo y prioridad (alta/media/baja)

6.3 Flujo de gestión de consultas (pequeño, pero obligatorio)

Un canal de contacto por sí solo no basta—necesitas capacidad de respuesta.

• Recibir → verificar → proporcionar alternativa → decidir corrección → compartir progreso → actualizar la declaración
  Si defines “quién hace qué”, la responsabilidad social se convierte en acción organizacional real.

7. Diseñar el canal de contacto: la accesibilidad funciona cuando la gente puede pedir ayuda

El canal de contacto es adonde la gente acude primero. Por eso hay que diseñarlo con cuidado.

7.1 Lo ideal es ofrecer múltiples canales

• Email (estable, basado en texto)
• Formulario (manejo robusto de errores y apoyo de entrada)
• Teléfono (basado en voz)
• Si es posible, chat de texto (consideración para diferencias auditivas)

7.2 Lista en viñetas “lo que nos gustaría que compartieras”

Esto mejora la reproducibilidad sin aumentar la carga:

• Nombre de la página (o qué pantalla)
• La acción que intentabas realizar
• Dispositivo (PC/móvil) y navegador
• Software de lectura en voz alta (si se usa)

7.3 Respuestas tipo (plantillas)

• Al recibir:
  “Gracias por contactarnos. Revisaremos los detalles y, si es necesario, proporcionaremos la información por un método alternativo.”
• Provisión de alternativa:
  “Este material se está mejorando actualmente. Te enviaremos el mismo contenido en formato de texto.”
• Plan de mejora:
  “Nuestro objetivo es completar la corrección para AAAA-MM. También registraremos el progreso en nuestra declaración de accesibilidad.”

8. Cómo presentar un plan de mejora que obtenga apoyo interno

No necesitas un plan enorme en la declaración. Pero ayuda tanto a lectores como a partes internas si se ve “qué priorizaremos” y “cuándo revisaremos”.

8.1 Ejemplo de mini hoja de ruta (texto plano es suficiente)

• Este trimestre (0–3 meses): unificar mensajes de error en formularios; mejorar la navegación por teclado en menús principales
• Siguiente (3–6 meses): convertir PDF clave a HTML; proporcionar versiones en texto para vídeos
• Más adelante: impulsar mejoras en componentes incrustados de terceros; sistematizar componentes en un sistema de diseño

8.2 No prometas perfección—promete el sistema de mejora

La accesibilidad no se mantiene con una corrección puntual.
En la declaración, promete “evaluación y mejora continuas” y respáldalo con operaciones (fechas de evaluación, fechas de actualización y un canal de contacto). Eso es lo que construye confianza.

9. La accesibilidad de la propia página de la declaración

La página de la declaración representa la postura de tu organización. Como mínimo, asegúrate de:

• Estructura correcta de encabezados (h1 → h2 → h3)
• Contraste texto/fondo (4.5:1)
• Enlaces no identificables solo por color (p. ej., subrayado)
• Acceso total mediante teclado
• Datos de contacto (teléfono/email) en texto plano y copiables
• En páginas largas, un resumen inicial y una tabla de contenidos

10. Valor claro para personas reales

• Personas ciegas/usuarias de lectura en voz alta: pueden anticipar dónde habrá problemas y llegar rápido a alternativas.
• Personas con diferencias auditivas: pueden evaluar disponibilidad de subtítulos y versiones en texto.
• Personas con diferencias cognitivas: menos ansiedad gracias a la claridad, y contacto claro cuando se atascan.
• Personas mayores: pueden pedir ayuda cuando el zoom/operación se vuelve difícil.
• Organizaciones (PR/legal/ops): pueden cumplir con rendición de cuentas, estandarizar respuestas y acordar prioridades con más facilidad.

Una declaración no es “trato especial para personas vulnerables”. Es un sistema que asegura que nadie quede atrás cuando encuentre barreras.

11. Evaluación del nivel de accesibilidad (lo que este artículo permite)

• Apoya el diseño y la operación de declaraciones orientadas a WCAG 2.1 AA
  • 1.3.1 Información y relaciones: estructura mediante encabezados, listas y secciones
  • 1.4.3 Contraste (mínimo): requisitos de legibilidad para la página de declaración
  • 2.4.1 Evitar bloques: resumen/TOC/encabezados para navegación más fácil
  • 2.4.6 Encabezados y etiquetas: intención clara por sección
  • 3.1.5 Nivel de lectura (práctico): lenguaje sencillo, frases cortas, concreción
  • 3.3.x (relacionado): identificación de errores y sugerencias (si se usan formularios)
  • 4.1.2 Nombre, función, valor (relacionado): implementación correcta de UI/formularios de contacto
• Incluye operaciones (fecha de evaluación, fecha de actualización, flujo de contacto) para que la organización pueda declarar claramente un sistema de “apuntar continuamente a AA”.

12. Conclusión: una declaración es un contrato de amabilidad sostenida

1. Una declaración de accesibilidad no es “ya terminamos”: documenta el estado actual y promesas de mejora.
2. Elementos requeridos: propósito / alcance / normas / estado de conformidad / problemas conocidos / alternativas / fecha de última actualización.
3. Los problemas conocidos deberían seguir: ubicación → problema → impacto → alternativa → mejora prevista.
4. Tras publicar, usa evaluación periódica, gestión de backlog y flujo de consultas para impulsar la mejora continua.
5. Haz accesible la propia página de la declaración para no perder credibilidad.

La accesibilidad crece no desde la perfección, sino desde el compromiso de no dejar a nadie atrás cuando tenga dificultades.
Una declaración de accesibilidad convierte ese compromiso en una promesa silenciosa pero firme—para que la amabilidad de tu organización siga llegando a las personas, de forma continua.