Guía práctica · accesibilidad
Accesibilidad web básica: qué puede comprobar una herramienta
La automatización encuentra ausencias concretas en el marcado, pero no determina por sí sola si una página es accesible. Esta guía separa las cinco señales que AuditLume observa de las pruebas manuales que siguen siendo imprescindibles.
Las cinco comprobaciones implementadas
1. Idioma declarado
AuditLume comprueba que el elemento <html> tenga un atributo lang no vacío. No juzga si el código elegido coincide con el idioma real. Revisa manualmente que sea correcto y marca los cambios de idioma relevantes dentro del contenido cuando corresponda.
2. Imágenes con atributo alt
Cuenta imágenes que no incluyen el atributo alt. No puede decidir si el texto alternativo existente comunica el propósito de la imagen. Una imagen informativa suele necesitar una alternativa útil; una decorativa puede necesitar alt=""; una imagen funcional debe explicar la acción. El contexto decide.
3. Campos y etiquetas
Cuenta controles visibles input, select y textarea, y los compara con el número de elementos label. Es una aproximación: no comprueba que cada label esté asociado al control correcto, ni reconoce todos los patrones accesibles posibles. Inspecciona cada relación for/id y no uses el placeholder como única instrucción.
4. Un encabezado H1
Señala cuando el HTML contiene cero o más de un H1. Esta regla ayuda a detectar una estructura inicial confusa, pero no evalúa la secuencia completa de encabezados ni la calidad de sus textos. Recorre H1, H2 y H3 como un índice y comprueba que cada sección tenga un nombre descriptivo.
5. Viewport móvil
Comprueba la presencia de una meta viewport. Su presencia no demuestra que la interfaz funcione con ampliación, reflujo o distintos tamaños. Prueba el contenido a varios anchos y con zoom sin perder información ni controles.
Pruebas que el chequeo no realiza
- Teclado: recorrer controles, abrir menús, cerrar diálogos y confirmar que el foco sea visible y siga un orden comprensible.
- Tecnología de asistencia: comprobar nombres, estados, avisos y relaciones con herramientas reales.
- Contraste: medir colores en sus estados normales, hover, foco, error y desactivado.
- Contenido: valorar si instrucciones, errores, enlaces y alternativas transmiten la información necesaria.
- Interacción: probar validación, cambios dinámicos, multimedia, tiempos y gestos.
W3C WAI presenta sus comprobaciones fáciles como una primera revisión y advierte que una evaluación completa exige más trabajo. Sus tutoriales sobre imágenes y etiquetas de formulario muestran por qué el contexto importa.
Plan de corrección sin falsos atajos
| Paso | Acción | Cómo verificar |
|---|---|---|
| 1 | Corregir ausencias inequívocas: lang, alt, etiquetas y viewport. | Volver a analizar y revisar el HTML resultante. |
| 2 | Ordenar títulos y encabezados según el propósito del contenido. | Leer el índice de encabezados fuera de contexto. |
| 3 | Probar el recorrido principal solo con teclado. | Completarlo sin ratón y con foco siempre perceptible. |
| 4 | Incluir personas y tecnologías de asistencia en una evaluación adecuada al alcance. | Registrar escenarios, resultados y cambios pendientes. |
No arregles una alerta añadiendo texto genérico. Por ejemplo, alt="imagen" satisface la presencia técnica pero puede no ayudar a nadie. La corrección debe conservar el propósito de la interfaz.
Interpretación prudente
Que AuditLume no muestre hallazgos de accesibilidad solo significa que no detectó esas cinco condiciones en el documento recuperado. No acredita conformidad con WCAG, EAA ni otra norma, y tampoco sustituye una evaluación manual del sitio completo.
Un resultado se refiere a la página analizada y al HTML recibido en ese momento. Otras rutas, estados autenticados, contenido que aparece después o componentes interactivos pueden comportarse de otra manera.