La accesibilidad, especialmente en contenidos Web, ha estado dominada por validadores automatizados que proliferaron en la última década y media. Si bien esto ha permitido encarar el tema desde un cierto nivel, en 2026 se percibe con creciente fuerza lo prescrito por la W3C/WAI: las pruebas con usuarios reales. Pero a su vez, estas pruebas deben poder contar con usuarios entrenados en navegación Web, que entienden la lógica de las estructuras Web y la lógica misma de la herramienta de asistencia que usan.

En este sentido, nuestro modelo integra WCAG-EM, la metodología del W3C/WAI para evaluar conformidad, con la guía complementaria del W3C/WAI sobre participación de usuarios en la evaluación de accesibilidad. Todo lo cual se aplica en cinco pasos:

1. Firmamos el alcance. Fijamos la dirección o aplicación exacta, el nivel A o AA, la versión WCAG 2.2, los lectores de pantalla y navegadores, y lo que queda fuera. No empezamos sin ese documento firmado.
2. Auditamos la muestra (Capa 1). Exploramos el sitio y elegimos una muestra de páginas estructurales, procesos críticos y componentes complejos. Verificamos cada criterio A y AA de WCAG 2.2 con herramientas automatizadas, inspección de código, teclado y lector de pantalla.
3. Evaluamos con usuarios reales (Capa 2). Convocamos de 3 a 8 personas que usan lector de pantalla, con perfiles distintos. Diseñamos tareas reales («encuentre y descargue el formulario X») y las grabamos con consentimiento informado. Como mínimo probamos con NVDA, el lector más extendido en Perú.
4. Triangulamos (Capa 3). Cruzamos cada hallazgo técnico con lo que vivieron los usuarios. Cuando coinciden, la severidad se confirma. Cuando un usuario choca con una barrera que la auditoría no marcó como crítica, aparece una falla de experiencia.
5. Entregamos informe y hoja de ruta. Priorizamos la remediación por severidad.

Qué recibe y cómo lo comprueba

El informe detallado trae portada con alcance, resumen ejecutivo, método con la muestra justificada, resultados por página y criterio, y la hoja de ruta de remediación.

El cliente puede verificar tres cosas en cada hallazgo:

• Cita el criterio exacto, por ejemplo «2.4.7 Foco visible, nivel AA». Nunca dice «problema de accesibilidad» a secas.
• Trae evidencia reproducible: captura, fragmento de código o ruta para repetir el error.
• Dice cuántos de los participantes encontraron la barrera. No generaliza el caso de una sola persona.

Emitimos una Declaración de Conformidad solo si la muestra cumple el 100 % de los criterios aplicables del nivel declarado. Lleva fecha, alcance, tecnologías de soporte y vigencia recomendada, y se revalida ante cualquier cambio sustantivo del sitio.

El costo de seguir sin evidencia

Un dato o una cifra de «porcentaje de accesibilidad» sin muestra declarada no resiste una auditoría externa. Un informe sin criterio WCAG exacto por hallazgo tampoco. Sin evidencia, su equipo no puede mostrar qué corrigió. Un eventual usuario con discapacidad atrapada en el paso tres de un proceso largo pedirá ayuda o renuncia, y el trámite sigue cerrado.

Dé el primer paso

Solicite la declaración de alcance para su portal de trámites. En ella definimos qué se evalúa, con qué lectores de pantalla y qué queda fuera.

Póngase en contacto con nosotros para una comunicación más directa.

Nuestros expertos saben detectar los verdaderos problemas y barreras de la accesibilidad Web.

Volver al Inicio