Camera & Photo Capture UI

Solicitar acceso a la camara al cargar la página, sin que el usuario tenga contexto, hace que la mayoría deniegue el prompt y bloquee el acceso de forma permanente. El permiso aterriza mejor cuando va precedido de una breve explicación de por que hace falta la camara y lo dispara un gesto explicito del usuario, nunca un script automático. Una vez denegado, el navegador exige al usuario desbloquear el sitio manualmente en ajustes, así que cada prompt desperdiciado es caro.

Un overlay con recorte transparente y fondo atenuado le dice al usuario exactamente donde apuntar, eliminando la incertidumbre para INE, QR, cheques o códigos de barras. Sin guía, los usuarios capturan el objetivo descentrado, recortado o en un angulo que el OCR o el decodificador posterior no pueden procesar. La forma del overlay debe coincidir con la física de lo que se captura: cuadrado para QR, rectangulo vertical para identificaciones, horizontal para tarjetas o documentos.

El obturador es la acción principal de toda pantalla de camara y debe verse como tal: un botón circular grande, centrado en la franja inferior, con un tap target generoso. Comprimirlo entre otros controles o reducirlo al tamaño de un icono más obliga al usuario a apuntar con precisión mientras sostiene el telefono, una postura inestable. Los controles secundarios (flash, voltear) se colocan a los lados, más pequeños, para que la jerarquía sea inequivoca.

La mayoría de flujos tienen una camara preferida por defecto (trasera para documentos, frontal para selfies o verificación de rostro), pero el usuario debe poder cambiarla con un solo toque. El control de volteo va proximo al obturador, con un icono de rotación reconocible y un estado que indique que camara esta activa. En la API esto se logra con la constraint facingMode: "environment" o "user"; reabrir el stream con el modo opuesto evita pedir permiso de nuevo.

Un breve destello blanco da confirmación instantanea e inequivoca de que se capturo un cuadro; sin el, el usuario toca de nuevo creyendo que fallo y genera envios duplicados. La imagen capturada debe mostrarse como vista previa para que juzgue calidad (foco, luz, encuadre) antes de enviar el formulario. El par Retomar / Usar es la interfaz mínima post-captura, con "Usar" como acción primaria. Nunca envies la imagen en silencio sin darle oportunidad de revisarla.

getUserMedia() rechaza con nombres de error distintos que exigen respuestas distintas: NotAllowedError (el usuario o la Permissions Policy bloqueo el acceso y debe desbloquearlo en ajustes), NotFoundError (no hay camara), NotReadableError (otra app la esta usando). Un genérico "Camara no disponible" para todos los casos obliga a un troubleshooting innecesario. Cada estado de error debe ofrecer además una salida: un enlace a la guía de ajustes o un fallback a subir archivo, para que el usuario nunca quede atrapado.

El usuario puede haber revocado el permiso, estar en un dispositivo sin camara, en penumbra, o simplemente preferir subir una foto existente. La camara puede ser el default ofrecido en flujos móviles que se benefician de captura en vivo, pero una opción "Elegir de la galeria" o "Subir archivo" siempre debe estar visible, no escondida en un menú overflow. Lo más simple es un <input type="file" accept="image/*"> (sin el atributo capture) junto al botón de camara.

Los controles de camara como botones de solo icono (obturador, voltear, flash, retomar) son invisibles para usuarios de lector de pantalla salvo que cada botón tenga un nombre accesible. Cuando la captura tiene exito, el cambio de estado ("Foto capturada. Revisa la imagen o retoma.") debe anunciarse vía una region aria-live, y el foco debe moverse al primer control accionable. Para flujos que verifican identidad por visión (p. ej. "saluda a la camara"), WCAG 2.5.4 exige una alternativa de UI equivalente.