Accesibilidad, que también se prueba
Una webview hereda la accesibilidad de la web, y eso es una ventaja que se pierde con facilidad. Qué comprobar, cómo se automatiza parte, y lo que no.
Lo que se hereda
Y el patrón: todo lo de la columna derecha son cosas que alguien hace a propósito. La accesibilidad de una webview no hay que construirla: hay que no romperla.
Lo que se puede automatizar
La primera es la que más cubre por menos esfuerzo, y se añade a las pruebas que ya tienes.
Lo que hay que probar a mano
Y lo que ninguna herramienta detecta:
- Recorrer la aplicación entera solo con el teclado. Nivel 53.4: si te quedas atascado en algún sitio, ahí hay una barrera.
- Usarla con un lector de pantalla al menos una vez. Los tres sistemas traen uno, y media hora con él revela cosas que ninguna prueba encuentra: nombres que no dicen nada, cambios que no se anuncian, orden que no tiene sentido al escucharlo.
- Y probar con el tamaño de texto del sistema aumentado, que es lo que hace mucha gente y lo que rompe las disposiciones ajustadas.
La segunda es incómoda la primera vez y es la que más enseña: escuchar tu propia interfaz cambia cómo la escribes.
Las cuatro roturas frecuentes
Y sus arreglos, que son de una línea:
- Elemento genérico con manejador → usar un botón.
- Foco quitado → estilizarlo en vez de quitarlo.
- Imagen o icono sin nombre → un texto alternativo o una etiqueta accesible.
- Y cambios que no se anuncian → una región que avise al lector cuando algo importante cambia sin que el usuario lo haya provocado.
Las cuatro juntas son la mayor parte de los problemas reales, y las cuatro se detectan con el analizador del apartado anterior salvo la última.