Interpretar falsos positivos y falsos negativos

Un falso positivo es un problema que la herramienta señala y que no existe o no es un incumplimiento WCAG. Un falso negativo es un problema real que la herramienta no detecta. Los primeros destruyen la credibilidad del informe ante el equipo de desarrollo; los segundos destruyen su validez ante las personas usuarias. El trabajo del auditor consiste en filtrar ambos. Esta lección cataloga los casos más habituales y da un procedimiento de verificación.

Falsos positivos habituales

Contraste

• Texto sobre imagen, degradado o vídeo. La herramienta no puede calcular el color de fondo y lo marca como «necesita revisión» o, en motores menos cuidadosos, como error. Mide con un cuentagotas en el punto de peor contraste.
• Texto oculto o superpuesto. Elementos con opacity: 0, fuera de pantalla o tapados por otra capa; algunos motores miden el color del elemento equivocado.
• Componentes inactivos y texto incidental. 1.4.3 exime los controles deshabilitados, los logotipos y el texto puramente decorativo; la herramienta a veces no reconoce la desactivación si se hace con clases en lugar del atributo disabled.

Nombres y etiquetas

• Campos etiquetados por aria-labelledby apuntando a varios elementos o por un title: válido, aunque alguna herramienta lo marque como sin etiqueta.
• Enlaces con imagen con alt correcto: algunos motores antiguos los marcaban como enlaces vacíos.
• Iconos con aria-hidden="true" dentro de botones con texto visible: es el patrón correcto.

Estructura

• Saltos de nivel de encabezado (de h2 a h4). Es una buena práctica no saltar, pero no es un fallo de 1.3.1 si la jerarquía refleja la estructura del contenido. Infórmalo como recomendación, no como incumplimiento.
• Ausencia de <h1>, de <main> o contenido fuera de landmarks. Buenas prácticas de axe (page-has-heading-one, landmark-one-main, region); sin criterio WCAG directo.
• Atributos ARIA redundantes (role="button" en un <button>): innecesarios, pero no rompen nada.

Validación HTML

• Errores de sintaxis que no afectan al árbol de accesibilidad. Desde la eliminación de 4.1.1 en WCAG 2.2, solo son hallazgo si repercuten en otro criterio (por ejemplo, un id duplicado que rompe un label for).

Falsos negativos habituales

Son más peligrosos porque no dejan rastro. Los más frecuentes en auditorías reales:

• Texto alternativo presente pero incorrecto: alt="imagen", alt="DSC_0042.jpg", alt vacío en una imagen informativa, o alt que repite el pie de foto. 1.1.1 Contenido no textual.
• Etiqueta que no describe el campo o que no coincide con la visible (2.5.3 Etiqueta en el nombre), o placeholder como única etiqueta visible que desaparece al escribir (3.3.2).
• Controles personalizados con rol correcto pero sin comportamiento de teclado: un div role="button" tabindex="0" que no responde a Enter ni a Espacio (2.1.1); pestañas sin flechas (APG (se abre en una ventana nueva)); modal que no atrapa ni devuelve el foco (2.4.3).
• Orden de foco incoherente por tabindex positivos o por CSS que reordena visualmente (2.4.3, 1.3.2).
• Contenido que aparece y desaparece sin anuncio: resultados de búsqueda, mensajes de éxito, contadores del carrito (4.1.3 Mensajes de estado).
• Foco que queda oculto bajo cabeceras fijas o banners de cookies (2.4.11), o indicador de foco eliminado con outline: none y sustituido por un cambio de color insuficiente (2.4.7).
• Objetivos táctiles pequeños (2.5.8), gestos de arrastre sin alternativa (2.5.7), carruseles que no se detienen (2.2.2).
• Idioma declarado erróneo (lang="en" en una página en castellano) o cambios de idioma sin marcar (3.1.1, 3.1.2).
• Mensajes de error que no sugieren corrección (3.3.3) o que se indican solo con color (3.3.1, 1.4.1).
• Subtítulos automáticos sin revisar o inexistentes (1.2.2), vídeo sin audiodescripción (1.2.5).

<!-- Pasa: tiene rol, nombre y tabindex -->
<div role="button" tabindex="0" aria-label="Añadir al carrito"
     onclick="anadir(123)">Añadir al carrito</div>

<button type="button" onclick="anadir(123)">Añadir al carrito</button>

Procedimiento de verificación

1. Reproduce el problema en el navegador: localiza el elemento con el selector que da la herramienta e inspecciona el árbol de accesibilidad (panel Accessibility de Chrome o Firefox).
2. Comprueba el contexto: ¿está visible? ¿está activo? ¿es decorativo? ¿tiene una alternativa en la misma página?
3. Confirma con tecnología de apoyo cuando el criterio lo requiera: lee el elemento con NVDA o VoiceOver y anota qué se anuncia.
4. Mapea al criterio con número y nombre, y decide el nivel de severidad en función del impacto en la tarea, no del «impact» que asigna la herramienta. La lección siguiente reúne las correspondencias de las reglas más frecuentes con sus criterios.
5. Documenta la decisión también cuando descartes: una lista de falsos positivos descartados con su motivo evita que el cliente los vuelva a sacar al ejecutar la herramienta por su cuenta.

Comparar dos herramientas como control

Ejecutar axe e IBM Equal Access sobre la misma página y cruzar resultados reduce ambos tipos de error: una violación que marcan ambas rara vez es falso positivo; una que marca solo una es candidata a revisión; y el conjunto de «necesita revisión» de ambas es un buen punto de partida para la lista manual. Las discrepancias suelen deberse a reglas de buenas prácticas, a umbrales distintos o a distinta interpretación de las reglas ACT, y conviene anotarlas en el informe para evitar discusiones.

Resumen

• Falsos positivos típicos: contraste sobre imagen, etiquetado válido no reconocido, saltos de encabezado, buenas prácticas de landmarks, errores HTML sin efecto en la accesibilidad.
• Falsos negativos típicos: alt incorrectos, controles sin teclado, orden de foco, mensajes de estado no anunciados, foco oculto, objetivos pequeños, idioma erróneo, errores sin sugerencia.
• Verifica cada violación: reproducir, contextualizar, confirmar con tecnología de apoyo, mapear al criterio y documentar también los descartes.
• Usar dos motores distintos y cruzar resultados reduce ambos tipos de error.
• La severidad la fija el auditor por impacto en la tarea, no la etiqueta de la herramienta.