En el Perú, la accesibilidad web es obligatoria para las entidades públicas. La Resolución de Secretaría de Gobierno y Transformación Digital N.º 001-2025-PCM/SGTD, publicada en El Peruano el 26 de junio de 2025, aprobó el lineamiento que obliga a ministerios, gobiernos regionales y locales, universidades públicas y empresas del Estado a diseñar sus servicios y plataformas digitales para que las personas con discapacidad puedan usarlos. La referencia técnica es WCAG, el estándar internacional del W3C. Las empresas privadas no tienen hoy una obligación equivalente con plazos, pero quien le vende una web o un sistema al Estado sí tendrá que cumplirla.
Esta guía tiene un enfoque práctico. Primero explica qué dice la norma, a quién alcanza y en qué plazos. Después muestra cómo llevar esos requisitos a un sitio hecho en WordPress, que es el gestor más usado en webs institucionales y de empresas peruanas: tema, constructor visual, formularios, menús, documentos PDF y contenido diario. Si ya tienes una web, al final encontrarás una ruta de revisión que puedes hacer con tu propio equipo.
Actualizado: octubre de 2026
Lo esencial
- El lineamiento vigente es la Resolución N.º 001-2025-PCM/SGTD. Reemplaza a los lineamientos de 2009 (RM 126-2009-PCM), derogados por la RM 100-2025-PCM.
- Alcanza a toda la Administración Pública y a las empresas públicas, con plazos de 12, 18 o 24 meses según el tipo de entidad.
- La base técnica son las pautas WCAG del W3C. En la práctica, el nivel que se pide como meta en el Estado peruano es AA.
- WordPress permite cumplir, pero no lo hace solo: el tema, el constructor, los plugins y la forma de publicar contenido deciden el resultado.
- Los «widgets» de accesibilidad que agregan un botón flotante no convierten una web en accesible. Hay que corregir el código y el contenido.
Qué exige la normativa peruana de accesibilidad web
El marco tiene tres capas. La primera es la Ley 29973, Ley General de la Persona con Discapacidad, que reconoce el derecho a la accesibilidad en el entorno físico, el transporte y las comunicaciones, incluidas las tecnologías de la información. La segunda es la política de transformación digital del Estado, que encarga a la Secretaría de Gobierno y Transformación Digital (SGTD) de la PCM fijar las reglas técnicas de los servicios digitales públicos.
La tercera capa, y la que importa para el día a día, es el lineamiento aprobado por la Resolución N.º 001-2025-PCM/SGTD, firmado el 24 de junio de 2025. Su objetivo, según sus considerandos, es que las entidades incorporen de forma obligatoria los criterios de accesibilidad en el entorno digital. Antes de esta norma regían los lineamientos de la RM 126-2009-PCM, pensados para la web de hace quince años. La RM 100-2025-PCM, del 13 de mayo de 2025, los derogó.
El lineamiento se apoya en las Pautas de Accesibilidad para el Contenido Web (WCAG 2.2), publicadas por el W3C. El proyecto que se sometió a consulta con la RM 269-2024-PCM incluía como anexo los criterios de WCAG 2.2, y la SGTD queda encargada de actualizar el lineamiento a medida que salgan nuevas versiones. Antes de un proyecto concreto, revisa el anexo oficial para confirmar el nivel de conformidad que te exigen.
Por qué WCAG nivel AA es la meta práctica
WCAG agrupa sus criterios en tres niveles: A (lo mínimo), AA (lo razonable para cualquier sitio público) y AAA (lo más exigente, que pocas webs alcanzan completo). Los sellos de accesibilidad digital que entrega la PCM toman AA como referencia, y es también el nivel que piden las normas de otros países de la región. Si diseñas o rediseñas una web en 2026, apuntar a WCAG 2.2 AA es la decisión segura.
A quién obliga y en qué plazos
El artículo 2 de la resolución fija plazos escalonados. Las fechas exactas dependen de cómo se compute cada plazo, así que conviene confirmarlas con el área legal de la entidad.
| Tipo de entidad | Plazo para implementar | Ejemplos |
|---|---|---|
| Poderes Ejecutivo, Legislativo y Judicial; organismos constitucionales autónomos; gobiernos regionales; universidades públicas; empresas públicas bajo FONAFE o de gobiernos regionales y locales | 12 meses | Ministerios, Reniec, JNE, Sunedu, universidades nacionales, empresas de agua o electricidad del Estado |
| Gobiernos locales Tipo A y Tipo C; otras entidades del artículo I del TUO de la Ley 27444 | 18 meses | Municipalidades provinciales y distritales de mayor tamaño, programas y proyectos especiales |
| Gobiernos locales Tipo B | 24 meses | Municipalidades distritales pequeñas |
| Otras entidades | Según sus capacidades y recursos | Entidades con regímenes especiales |
La resolución también encarga a la SGTD emitir guías complementarias en un plazo de 180 días hábiles. Para octubre de 2026, el primer grupo de entidades ya debería tener sus plataformas adaptadas o un plan de adecuación en marcha.
¿Y las empresas privadas?
La norma de 2025 se dirige a la Administración Pública. Una clínica, una tienda virtual o un estudio contable no tienen hoy un plazo legal para hacer accesible su web. Hay tres situaciones en que el tema sí te toca:
- Si eres proveedor del Estado. Las entidades que contratan el desarrollo de un portal, un sistema de trámites o una app incluirán WCAG en los términos de referencia. Si no lo cumples, no pasas la conformidad.
- Si prestas un servicio público o regulado. Bancos, telecomunicaciones, transporte y educación tienen reguladores que pueden pedir canales accesibles para la atención al usuario.
- Si tienes Libro de Reclamaciones virtual. Un formulario de reclamo que una persona ciega no puede completar es una barrera. Lo explicamos en qué exige Indecopi sobre la accesibilidad del Libro de Reclamaciones virtual.
Si quieres el detalle legal del marco general, lo tratamos en accesibilidad web obligatoria en Perú: ley y cómo cumplir. Esta guía se centra en el lado técnico.
A cuántas personas afecta una web inaccesible
Según el Perfil Sociodemográfico de la Población con Discapacidad del INEI, basado en los Censos Nacionales 2017, 3 millones 209 mil 261 personas declararon tener alguna discapacidad, el 10.3 % de la población. La dificultad para ver es la más frecuente. A ese grupo se suman adultos mayores con vista cansada o temblor en las manos, personas que navegan con el celular a pleno sol y usuarios con conexiones lentas.
La accesibilidad no es solo para personas ciegas. Un buen contraste ayuda a quien mira el celular en la combi. Los subtítulos sirven a quien ve un video sin audio en la oficina. Un formulario bien etiquetado reduce errores en todos los usuarios. Muchas mejoras de accesibilidad también son mejoras de usabilidad y de SEO, porque Google y las IA leen mejor un HTML ordenado.
Los criterios WCAG que más fallan en webs peruanas
WCAG 2.2 tiene decenas de criterios, pero la mayoría de errores se concentra en unos pocos. Si corriges estos, avanzas una buena parte del camino.
| Criterio WCAG | Nivel | Error típico | Cómo se corrige |
|---|---|---|---|
| 1.1.1 Contenido no textual | A | Imágenes sin texto alternativo o con «IMG_2045.jpg» | Describir la imagen en el campo «Texto alternativo» de la biblioteca de medios |
| 1.4.3 Contraste mínimo | AA | Texto gris claro sobre blanco, letras blancas sobre fotos | Relación mínima de 4.5:1 en texto normal y 3:1 en texto grande |
| 2.1.1 Teclado | A | Menús desplegables o sliders que solo funcionan con el mouse | Usar componentes que respondan a Tab, Enter y Esc |
| 2.4.7 Foco visible | AA | El tema elimina el contorno del foco con CSS | Restaurar un estilo de foco claro en enlaces, botones y campos |
| 1.3.1 Información y relaciones | A | Títulos que son solo texto en negrita, saltos de H2 a H5 | Usar encabezados reales en orden |
| 3.3.2 Etiquetas o instrucciones | A | Campos de formulario con solo un texto de ejemplo dentro | Etiqueta visible asociada a cada campo |
| 2.5.8 Tamaño del objetivo (nuevo en 2.2) | AA | Íconos de redes o botones muy pequeños y pegados | Áreas táctiles de al menos 24 × 24 píxeles |
| 1.2.2 Subtítulos | A | Videos institucionales sin subtítulos | Subtítulos revisados en YouTube o en el reproductor |
Fíjate en que casi nada de esta lista requiere programación avanzada. La mayoría se resuelve con un tema bien hecho y con disciplina al publicar contenido.
Cómo cumplir en WordPress: el tema y la estructura
WordPress produce HTML razonable por defecto, pero el tema decide gran parte del resultado. Antes de elegir uno, revisa estos puntos.
Elige un tema que respete la estructura
- Etiqueta «accessibility-ready». El directorio oficial de temas de WordPress marca con esa etiqueta los temas que pasaron una revisión de accesibilidad básica. No garantiza WCAG AA, pero es un buen punto de partida.
- Enlace «Saltar al contenido». Al pulsar Tab al cargar la página, debe aparecer un enlace que lleve directo al contenido principal sin recorrer todo el menú.
- Regiones bien marcadas. Cabecera, navegación, contenido principal y pie deben usar las etiquetas
header,nav,mainyfooter. - Un solo H1 por página. El título de la entrada o de la página, y los demás encabezados en orden.
- Idioma declarado. En Ajustes > Generales, el idioma del sitio debe ser español para que el lector de pantalla pronuncie bien.
Cuidado con el constructor visual
Elementor, Divi y otros constructores facilitan el diseño, pero también facilitan errores: títulos que se ven grandes pero son párrafos, botones hechos con un div, carruseles que no se detienen. Elementor tiene opciones para el foco, el texto alternativo, la etiqueta HTML de cada título y el texto de los enlaces. Las revisamos una por una en accesibilidad en Elementor: los ajustes en tus manos.
Una regla útil: en cada widget de título, revisa que la etiqueta HTML corresponda a la jerarquía (H2, H3) y no al tamaño visual que quieres. El tamaño se ajusta con estilos, no con la etiqueta.
Cómo cumplir en WordPress: menús, formularios y componentes
Menús que funcionen con teclado
Prueba tu menú solo con el teclado. Con Tab deberías llegar a cada opción, con Enter o la flecha abrir los submenús y con Esc cerrarlos. Si un submenú solo se abre al pasar el mouse, una persona que navega con teclado o con lector de pantalla no llega a esas páginas. Los mega menús son los que más fallan en esto.
Formularios que todos puedan completar
Los formularios de contacto, de trámite y de reclamo son el punto donde más se nota la falta de accesibilidad, porque ahí el usuario necesita hacer algo, no solo leer.
- Cada campo debe tener una etiqueta visible, no solo un texto de ejemplo que desaparece al escribir.
- Los campos obligatorios se indican con texto («obligatorio»), no solo con un asterisco rojo.
- Los mensajes de error deben decir qué falló y cómo corregirlo, junto al campo, y el lector de pantalla debe anunciarlos.
- Los captchas de imagen son una barrera. Prefiere métodos invisibles o de casilla.
- WCAG 2.2 añade que no se pida al usuario volver a escribir datos que ya dio en el mismo proceso (criterio 3.3.7).
Plugins como Gravity Forms, WPForms o Fluent Forms generan formularios con etiquetas correctas si los configuras bien. Para el lado de diseño y conversión, revisa cómo diseñar formularios que la gente sí complete.
Sliders, ventanas emergentes y videos
Un carrusel que cambia solo cada tres segundos es difícil para cualquiera y casi imposible para quien usa lector de pantalla. Si lo mantienes, agrega botón de pausa y controles con teclado. Las ventanas emergentes deben poder cerrarse con Esc y devolver el foco a donde estaba. Los videos necesitan subtítulos y, si transmiten información solo visual, una descripción.
Cómo cumplir en WordPress: el contenido de cada día
Una web puede salir accesible del desarrollo y dejar de serlo en dos meses si quien publica no sigue unas reglas. En entidades públicas, donde varias oficinas suben noticias y documentos, esto es lo que más se descuida.
- Texto alternativo en cada imagen informativa. Describe lo que aporta la imagen: «Alcalde entrega maquinaria agrícola a productores de Huaral» en vez de «foto1». Las imágenes decorativas llevan el alternativo vacío.
- Enlaces con sentido propio. «Descarga el TUPA 2026 (PDF, 2 MB)» en lugar de «clic aquí».
- Encabezados en el editor. Usa los bloques de encabezado, no negritas grandes.
- Tablas solo para datos. Con fila de encabezados definida.
- Nada de texto dentro de imágenes. Un afiche escaneado de una convocatoria es invisible para un lector de pantalla. Publica también el texto.
El problema de los PDF
Muchas webs del Estado publican resoluciones, bases y formatos como PDF escaneados, que son solo una imagen. Un PDF accesible tiene texto seleccionable, etiquetas de estructura, orden de lectura y título del documento. Si el documento es importante para un trámite, lo ideal es publicar el contenido también como página web. Exportar desde Word con la opción de etiquetas de accesibilidad activada ya resuelve buena parte.
Por qué un plugin de «accesibilidad» no basta
En el repositorio de WordPress hay plugins que agregan un botón flotante para agrandar letra, cambiar contraste o activar una lectura en voz alta. Pueden ser una ayuda menor, pero no corrigen lo que realmente falla: imágenes sin alternativo, formularios sin etiquetas, menús que no funcionan con teclado. Las personas que usan lector de pantalla ya tienen su propia tecnología y lo que necesitan es que el código esté bien hecho.
Hay plugins que sí ayudan al equipo técnico, porque señalan errores mientras editas o corrigen problemas concretos del tema, como el foco o los enlaces que abren en ventana nueva sin avisar. Úsalos como herramienta de revisión, no como certificado.
Tampoco existe una herramienta automática que asegure el cumplimiento. Los analizadores como WAVE, Lighthouse o axe detectan una parte de los errores; el resto requiere revisión humana con teclado y lector de pantalla.
Ruta de revisión de tu web en cinco pasos
- Inventario. Lista las páginas clave: inicio, servicios o trámites, formularios, Libro de Reclamaciones, transparencia, contacto. No empieces por las 800 noticias.
- Análisis automático. Pasa WAVE o Lighthouse por cada página clave y anota los errores de contraste, alternativos y etiquetas.
- Prueba con teclado. Desconecta el mouse y recorre cada página. Anota dónde se pierde el foco o dónde no puedes avanzar.
- Prueba con lector de pantalla. NVDA es gratuito en Windows; en Android viene TalkBack. Escucha cómo se anuncian los títulos, los botones y los errores.
- Plan y reglas de publicación. Prioriza lo que bloquea trámites, corrígelo en el tema y deja por escrito una guía corta para quienes publican contenido.
Si los errores son estructurales, como un tema antiguo o un constructor mal usado en todo el sitio, a veces sale más barato rehacer la web que parcharla. Lo analizamos en accesibilidad como motivo de rediseño y en rediseño web y accesibilidad.
Qué pedir si vas a contratar una web accesible
Si eres una entidad que prepara términos de referencia o una empresa que cotiza una web nueva, pide por escrito:
- Conformidad con WCAG 2.2 nivel AA en las plantillas y en las páginas entregadas.
- Un informe de pruebas con herramienta automática, teclado y lector de pantalla.
- Capacitación al equipo que publicará contenido, con una guía de buenas prácticas.
- Formularios, menús y componentes probados con teclado.
- Una declaración de accesibilidad publicada en la web, con un canal para reportar barreras.
Sobre el diseño inclusivo desde el inicio del proyecto, puedes leer diseño web inclusivo: cómo crear páginas para todos.
Una web accesible desde el diseño
Adaptar una web existente cuesta más que construirla bien desde el principio. En KOM diseñamos sitios en WordPress con estructura de encabezados, contraste, formularios y menús pensados para teclado y lector de pantalla, y te entregamos el sitio con una guía para que tu equipo mantenga el nivel al publicar. Si necesitas una web nueva o evaluar la que tienes, revisa nuestros planes de diseño web y conversemos sobre tu caso.
Este contenido es informativo y no reemplaza la asesoría legal.
Preguntas frecuentes
¿Qué es una página web con accesibilidad?
Es una web que cualquier persona puede usar, incluidas quienes tienen discapacidad visual, auditiva, motriz o cognitiva. En la práctica significa que se puede navegar con teclado, que un lector de pantalla puede leer textos, imágenes y formularios, que el contraste permite leer bien y que los videos tienen subtítulos. El estándar que se usa para medirlo son las pautas WCAG del W3C.
¿Mi pequeña empresa puede ser multada por no tener una web accesible?
Hoy el lineamiento de la PCM obliga a las entidades públicas, no a las empresas privadas en general. Aun así, si atiendes reclamos o ventas en línea, una barrera que impida a una persona con discapacidad usar tu servicio puede generar un reclamo ante Indecopi. Además, si vendes servicios digitales al Estado, te pedirán cumplir WCAG en el contrato.
¿Cuánto cuesta hacer accesible una web en WordPress?
Depende de cómo esté construida. Si el tema es moderno y el contenido está ordenado, a menudo bastan ajustes de contraste, foco, alternativos y formularios. Si el sitio usa un tema antiguo, muchos sliders y documentos escaneados, la adaptación puede acercarse al costo de una web nueva. Lo prudente es hacer primero una revisión de las páginas clave y luego cotizar.
¿Existe un sello o certificación de accesibilidad en Perú?
Sí. La PCM otorga el Sello de Accesibilidad Digital a entidades públicas que demuestran buen nivel en sus plataformas, usando WCAG como referencia. No existe un certificado oficial obligatorio para webs privadas. Lo que sí puedes hacer es publicar una declaración de accesibilidad con el nivel alcanzado, la fecha de revisión y un canal para que los usuarios reporten problemas.
¿Qué diferencia hay entre WCAG 2.1 y WCAG 2.2?
WCAG 2.2, publicada por el W3C en octubre de 2023, mantiene casi todo lo de la versión 2.1 y suma nueve criterios. Entre ellos destacan el foco que no queda oculto detrás de cabeceras fijas, el tamaño mínimo de los botones táctiles, alternativas al arrastre con el mouse y la autenticación sin pruebas de memoria. Si tu web cumple 2.1 AA, el salto a 2.2 suele ser corto.
