Cómo auditar la accesibilidad web (WCAG 2.2) de tu prototipo en el TFG de Informática paso a paso (2026)

Has desarrollado una aplicación web y llegas al capítulo de evaluación con el problema clásico del TFG de Informática: funciona, pero «funciona» no es un resultado. Necesitas una evaluación con criterios externos, reproducible y que produzca números.

Una auditoría de accesibilidad resuelve exactamente eso. Te da un estándar internacional que no has inventado tú, un procedimiento repetible, una tabla de resultados con criterios superados y fallidos, y —esto es lo que casi nadie aprovecha— un anclaje en la normativa española que convierte tu capítulo en algo con relevancia real y no solo académica.

Qué es WCAG 2.2 y en qué versión estamos

Las Pautas de Accesibilidad para el Contenido Web (WCAG) 2.2 son una Recomendación del W3C publicada el 12 de diciembre de 2024. Ese es el dato que debes citar y la fecha que debe aparecer en tu bibliografía: una parte considerable de los TFG sigue referenciando la 2.1 o directamente «las WCAG», sin versión.

Dos precisiones que el propio documento hace y conviene reproducir con exactitud:

• La 2.2 no deroga ni sustituye a la 2.0 ni a la 2.1, que siguen siendo Recomendaciones. El contenido que cumple 2.2 cumple también 2.0 y 2.1, de modo que la 2.2 puede servir como vía alternativa de conformidad allí donde una política exija las versiones anteriores.
• Las pautas cubren accesibilidad en cualquier tipo de dispositivo —escritorio, portátil, quiosco, móvil— y no pretenden cubrir todas las necesidades de todas las personas con discapacidad. Decir esto en tu memoria es una limitación honesta, no una debilidad.

La arquitectura del estándar: cuatro principios y tres niveles

El estándar se organiza en cuatro principios —el contenido debe ser perceptible, operable, comprensible y robusto—, que se despliegan en pautas y estas en criterios de conformidad comprobables, cada uno etiquetado con un nivel A, AA o AAA.

Para un TFG, el objetivo razonable y el que se exige habitualmente en el sector público es el nivel AA. Anunciar que vas a auditar en AAA suele terminar en un informe lleno de incumplimientos que no significan nada, porque el AAA no está pensado para aplicarse a la totalidad de un sitio.

Lo que cambió en la 2.2 y casi nadie ha actualizado

La versión 2.2 incorpora criterios nuevos que un prototipo actual suele incumplir sin que su autor lo sospeche. Entre ellos: Focus Not Obscured en sus variantes mínima y mejorada, Dragging Movements, Target Size (Minimum), Consistent Help, Redundant Entry y Accessible Authentication en sus dos niveles.

Y hay una retirada que merece un párrafo propio, porque distingue inmediatamente un trabajo actualizado de uno copiado de un tutorial viejo: el criterio 4.1.1 «Parsing» está marcado como obsoleto y eliminado. Si tu informe dedica una fila a validar el marcado contra ese criterio, estás auditando contra una versión que ya no existe.

Por qué esto tiene relevancia legal en España

El Real Decreto 1112/2018 regula la accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público. Su artículo 5 exige que los contenidos sean perceptibles, operables, comprensibles y robustos —los mismos cuatro principios—, y su artículo 6 establece una presunción de conformidad: se presume conforme el contenido que cumpla las normas armonizadas cuyas referencias se hayan publicado en el Diario Oficial de la Unión Europea y, en su defecto para los sitios web, los requisitos pertinentes de la norma europea EN 301 549 en la versión que el propio real decreto cita.

Dos detalles muy aprovechables en una memoria:

1. La norma contempla excepciones cuando el cumplimiento suponga una carga desproporcionada, pero deja claro que la falta de prioridad, de tiempo o de conocimientos nunca son motivos legítimos para invocarla. Es una frase que vale su peso en oro en una discusión sobre por qué los prototipos se entregan inaccesibles.
2. El régimen incluye la obligación de publicar una declaración de accesibilidad y de habilitar un mecanismo por el que cualquier persona pueda comunicar incumplimientos, quejas y sugerencias.

Si tu prototipo simula un servicio público, esto no es contexto decorativo: es el criterio de aceptación de tu sistema. Y si tu trabajo entra en el terreno de qué información publica una administración, la guía sobre cómo pedir datos a la administración con la Ley de Transparencia cubre el otro lado del mismo tablero.

Un aviso de rigor: comprueba tú mismo, en el texto consolidado del real decreto y en las referencias publicadas en el Diario Oficial, qué versión de la norma armonizada aplica cuando escribas. Las referencias se actualizan y una memoria que cita una versión obsoleta pierde precisamente el punto que quería ganar. Para el formato de la cita, revisa cómo se cita legislación española en APA 7.

El procedimiento, paso a paso

Paso 1. Define el alcance y la muestra

No se audita «la aplicación»: se audita un conjunto identificado de páginas o estados. Selecciona una muestra que incluya la página de inicio, al menos un formulario, una vista de listado, una vista de detalle, el flujo de autenticación si existe y cualquier página con contenido dinámico o multimedia. Documenta la muestra con su URL o su ruta y con la fecha, porque un prototipo cambia entre la auditoría y la defensa.

Paso 2. Pasa las herramientas automáticas

Usa al menos dos validadores distintos y compara. Las opciones habituales y gratuitas son las extensiones de navegador basadas en motores de reglas de accesibilidad, la auditoría de accesibilidad integrada en las herramientas de desarrollo del navegador y los evaluadores web que analizan una URL pública.

Y aquí va la frase que tu tribunal quiere oír: ninguna herramienta automática detecta todos los incumplimientos. Una parte importante de los criterios exige juicio humano —si un texto alternativo describe realmente la imagen, si el orden de tabulación es lógico, si un mensaje de error explica cómo corregirlo—. Presentar solo la salida de un validador como «auditoría» es el error que más nota cuesta en este tipo de trabajos. Di explícitamente qué proporción de tu evaluación fue automática y qué proporción manual.

Paso 3. Haz la parte manual

Esta es la que aporta valor. Un guion mínimo, todo con teclado y sin ratón:

• Navegación por teclado completa: recorre toda la interfaz con tabulador. Comprueba que puedes llegar a todo, activar todo y salir de cualquier componente sin quedarte atrapado.
• Foco visible y no tapado: el indicador de foco debe verse siempre y no debe quedar oculto tras cabeceras fijas o banners de cookies. Este es exactamente el escenario del criterio nuevo de la 2.2.
• Zoom al 200 % y ventana estrecha: comprueba que nada se solapa ni exige desplazamiento horizontal.
• Contraste de texto y de componentes de interfaz, con una herramienta de medición, no a ojo.
• Formularios: cada campo con su etiqueta asociada, errores identificados en texto y no solo por color, e instrucciones que digan cómo corregir.
• Alternativas textuales: imágenes informativas descritas y decorativas marcadas como tales.
• Lector de pantalla: una pasada con el lector integrado en tu sistema operativo. No hace falta ser experto; con recorrer un formulario y una tabla ya detectas la mitad de los problemas.
• Estructura semántica: encabezados jerárquicos correctos, regiones y listas reales en lugar de divs con estilo.

Paso 4. Registra los resultados de forma comparable

Construye una tabla con una fila por criterio de conformidad evaluado y estas columnas: número y nombre del criterio, nivel (A o AA), resultado (cumple / no cumple / no aplicable), evidencia, método de detección (automático o manual) y severidad. Esa tabla es tu capítulo de resultados.

Con ella puedes calcular métricas defendibles: porcentaje de criterios superados sobre los aplicables, número de incumplimientos por principio y distribución por severidad. Y si tu TFG compara dos versiones —antes y después de tus correcciones—, tienes un diseño pre-post con una métrica objetiva, que es mucho más de lo que ofrece la mayoría de los trabajos de desarrollo.

Paso 5. Corrige y vuelve a medir

El ciclo auditoría → corrección → segunda auditoría es lo que convierte un informe en investigación aplicada. Documenta qué corregiste, cuánto costó cada corrección y cuáles decidiste no abordar y por qué. Ese último apartado, el de las decisiones no tomadas, es el que demuestra criterio.

Cómo encaja en la memoria

La auditoría no es un anexo: es la sección de evaluación. En la metodología describe el estándar y su versión, el nivel objetivo, la muestra, las herramientas con su versión y el reparto entre comprobación automática y manual. En resultados van la tabla y las métricas. En la discusión, los patrones —si los incumplimientos se concentran en formularios, en contraste o en semántica— y sus causas de diseño.

Si tu memoria sigue el formato de ingeniería habitual, esta sección encaja de forma natural en el bloque de verificación y validación; la estructura completa está en la guía del TFG de Ingeniería Informática con memoria en formato IEEE, y una integración muy productiva es incorporar los validadores automáticos al pipeline de integración continua, de modo que cada cambio se compruebe solo.

No olvides citar el software y las herramientas que usaste con su versión: una auditoría hecha con una versión distinta del motor de reglas puede dar resultados distintos, y sin la versión tu trabajo no es reproducible.

Si tu TFG va de personas, no solo de código

La auditoría técnica responde a «¿cumple el estándar?». No responde a «¿le sirve a alguien?». Si quieres abordar la segunda pregunta, el trabajo cambia de naturaleza: pasa a implicar participantes reales y, con ellos, consentimiento informado y aprobación ética.

Es un salto que merece la pena si tienes tiempo, y conecta con un contexto que da sentido al trabajo: los datos sobre estudiantes con discapacidad en la universidad española sirven para justificar la relevancia del tema en la introducción, y si tu ámbito es educativo, el TFG sobre necesidades educativas especiales aporta el marco de diseño para todos.

Cinco errores que se repiten

1. Presentar la puntuación de una única herramienta automática como el resultado. Es un indicio, no una auditoría.
2. Auditar contra WCAG «a secas». Sin versión ni nivel, tu evaluación no es replicable.
3. Incluir el criterio 4.1.1 «Parsing», que en la 2.2 está obsoleto y eliminado.
4. No documentar la muestra. Si no consta qué páginas y en qué fecha, nadie puede repetir la medición.
5. Confundir accesibilidad con usabilidad. Están relacionadas y no son lo mismo: un sistema puede cumplir el nivel AA y seguir siendo incómodo de usar.

Pasa de la teoría a tu documento terminado

Tienes la tabla de criterios, las capturas y las métricas. Lo que falta —y lo que se atasca a las dos de la mañana— es convertir todo eso en una sección de metodología precisa y una discusión que interprete los patrones en lugar de repetir la tabla. Tesify redacta esos apartados contigo, mantiene la coherencia terminológica y deja el documento entero en el formato que pide tu escuela.

Empieza tu TFG con Tesify

Preguntas frecuentes

¿Qué versión de WCAG debo usar en mi TFG en 2026?

La 2.2, Recomendación del W3C de 12 de diciembre de 2024. Cítala con su fecha y su versión. Ten en cuenta que cumplir 2.2 implica cumplir también 2.0 y 2.1, que siguen vigentes como Recomendaciones.

¿Qué nivel de conformidad debo auditar?

El nivel AA. Es el que exigen habitualmente las políticas del sector público y el que produce un informe interpretable. El AAA no está concebido para aplicarse en su totalidad a un sitio completo.

¿Puedo hacer la auditoría solo con herramientas automáticas?

No, y decirlo en la memoria te suma. Los validadores cubren una parte del estándar; el resto exige juicio humano. Declara qué parte de tu evaluación fue automática y qué parte manual.

¿Necesito un lector de pantalla profesional?

No. El lector integrado en tu sistema operativo basta para una evaluación de TFG. Lo que importa es que documentes cuál usaste, con qué versión y qué recorridos hiciste con él.

¿Se aplica el Real Decreto 1112/2018 a mi prototipo?

Directamente no, salvo que tu trabajo se desarrolle para un organismo del sector público. Pero es el marco que da relevancia a tu evaluación y el que justifica el nivel objetivo elegido. Cítalo como criterio de referencia, no como obligación propia.

¿Qué es la carga desproporcionada?

Una excepción prevista en la normativa para casos en que el cumplimiento resulte inasumible para el organismo. La propia norma aclara que la falta de prioridad, de tiempo o de conocimientos no son motivos legítimos para invocarla.

¿Sirve esto si mi prototipo es una app móvil y no una web?

Sí. El marco normativo cubre expresamente las aplicaciones para dispositivos móviles, y los principios son los mismos. Cambian las herramientas de comprobación y algunas técnicas concretas, así que documenta bien cuál usaste.

¿Es lo mismo accesibilidad que usabilidad?

No. La accesibilidad se evalúa contra criterios de conformidad definidos externamente; la usabilidad se mide con personas usuarias y con métricas de eficacia, eficiencia y satisfacción. Un TFG puede hacer las dos, pero debe presentarlas como evaluaciones distintas.