Tarjetas de aprobación de VoiceOver para acciones de agentes

Una tarjeta de aprobación es una decisión de seguridad, no una interrupción decorativa. Si un usuario de VoiceOver no puede identificar el proceso que solicita, el destino real, la acción y el alcance antes de llegar a los botones, la tarjeta pide consentimiento sin ofrecer los datos necesarios para concederlo.

He visto equipos llamar «accesible» a una solicitud porque VoiceOver llegaba a un botón Aprobar. Es un listón muy bajo y peligroso. Una persona puede activar un control que no entiende. En el caso de las acciones de los agentes, las consecuencias son serias: una aprobación puede enviar una solicitud con una credencial almacenada o abrir una sesión SSH en una máquina que el propio agente no es capaz de describir de forma fiable.

La tarjeta debe explicar la decisión antes de ofrecer controles

La primera locución útil debe identificar la decisión, y todos los datos necesarios para tomarla deben aparecer antes de Aprobar y Denegar. Una buena tarjeta ofrece primero un resumen breve a VoiceOver y después muestra los detalles en un orden estable. No obliga a la persona a explorar una disposición visual que solo tiene sentido cuando puede ver sus espacios, distintivos o colores.

Usa este orden:

1. Por qué apareció la tarjeta: un proceso nuevo del agente solicita autorización o una credencial protegida requiere confirmación para esta llamada.
2. Quién la solicita: el nombre del proceso, la ruta del ejecutable cuando resulte útil y su autoridad de firma de código.
3. Dónde quiere actuar: el protocolo y el destino concreto.
4. Qué quiere hacer: el método HTTP y la estructura de la solicitud, o el comando SSH y su destino.
5. Qué concede la decisión: esta llamada, este proceso en ejecución hasta que termina o un único uso de una credencial protegida.

Esa secuencia coincide con la decisión que toma un operador cuidadoso. La procedencia responde a quién solicita el acceso. El destino indica dónde recaerá la consecuencia. La acción explica qué cambiará. El alcance aclara cuánto tiempo durará el permiso. Colocar los botones antes de esa cadena convierte la tarjeta en una prueba de reflejos.

Mantén el resumen inicial lo bastante corto como para escucharlo de una vez. Por ejemplo:

Authorization requested. Signed process: Acme Development, agent-helper.
HTTPS request to api.example.net. POST /v1/releases.
This approval allows this process until it exits.

Los detalles ampliados deben aparecer inmediatamente después del resumen, antes de los controles. No los ocultes tras un triángulo de expansión sin etiqueta ni obligues al usuario a entrar en otra vista para conocer el host. Una tarjeta compacta puede ocultar campos de poca importancia, pero nunca debe ocultar el destino ni la operación.

Las WAI-ARIA Authoring Practices del W3C describen un diálogo modal como una interacción contenida, con una etiqueta, una gestión adecuada del foco y una forma explícita de cerrarlo. Ese consejo también se aplica cuando la aplicación usa controles nativos de macOS en lugar de ARIA web. Una solicitud modal que anuncia únicamente su título cumple la parte más superficial del patrón, pero falla en la decisión real.

La identidad del proceso es una prueba, no un permiso

La firma de un proceso indica al usuario quién creó o firmó el código que solicita acceso. No indica si la solicitud es adecuada. Trátala como una prueba que debe aparecer al principio de la tarjeta y haz que el resto de la solicitud no pueda confundirse con esa identidad.

El campo de identidad necesita una forma estable y fácil de pronunciar. Empieza por la autoridad de firma, porque ofrece un punto de referencia útil cuando varios procesos auxiliares tienen nombres de archivo parecidos. Después incluye el nombre del proceso. Añade una ruta solo cuando resuelva una ambigüedad, por ejemplo, si una compilación local de desarrollo y una compilación instalada comparten nombre. Una ruta larga debe quedar en la región de detalles, donde VoiceOver pueda leerla línea por línea.

Evita expresiones vagas como «agente de confianza» o un distintivo verde de «verificado». Esas frases reducen varias afirmaciones distintas a una señal visual tranquilizadora. Un proceso puede tener una firma válida y aun así contener una solicitud mal formada, una fuente de instrucciones comprometida o una petición dirigida a la cuenta equivocada. Los usuarios necesitan conocer la procedencia, no un veredicto decidido por la interfaz.

El resumen de una solicitud puede decir:

Requesting process
Signing authority: Example Software LLC
Process: deploy-helper
Details: /Applications/Deploy Helper.app/Contents/MacOS/deploy-helper

Expón ese contenido como un único grupo etiquetado cuyos elementos sigan el mismo orden. No repitas la autoridad de firma en un subtítulo, un distintivo y una indicación de accesibilidad. La repetición hace que la salida de VoiceOver resulte agotadora y el usuario empieza a saltarse precisamente la frase que querías que notara.

Aquí aparece otra trampa: el nombre de un proceso puede cambiar. Un atacante puede llamar «release-agent» a un ejecutable y confiar en que la persona no lea más. La autoridad de firma es más difícil de imitar, pero tampoco puede autorizar el destino. La tarjeta nunca debe expresar la identidad como si garantizara la solicitud. Di «solicitado por» o «firmado por» y describe la acción en frases separadas.

En el caso de procesos locales de desarrollo sin firma, indica esa condición claramente. No la sustituyas por un eufemismo como «compilación personal». Si el producto permite la solicitud, el usuario puede decidir si un proceso sin firma merece un permiso para la sesión. Ocultar la condición no elimina la fricción; solo la retrasa hasta después del error.

El destino necesita un nombre que el usuario pueda inspeccionar

Una tarjeta debe pronunciar el destino como un endpoint o host específico, porque las categorías y los iconos no pueden indicar a un usuario adónde viajarán las credenciales. HTTP y SSH necesitan resúmenes distintos, pero ambos requieren un extremo remoto concreto antes de cualquier control de aprobación.

Para HTTP, lee el protocolo, el host, el método y una ruta que conserve la consecuencia. POST api.example.net/v1/releases dice mucho más que «Servicio de lanzamientos». Si el puerto es distinto del habitual, inclúyelo. Si la solicitud sigue una redirección, no describas solo el host original y dejes el host final para una sorpresa posterior. Resuelve el destino antes de pedir consentimiento o vuelve a pedirlo cuando la resolución cambie el host remoto.

Para SSH, lee el host o alias, el usuario cuando afecte a los privilegios y el comando. [email protected]: systemctl restart worker ofrece una decisión que una persona puede tomar. «Comando SSH» no. Si un alias se expande mediante un archivo de configuración, proporciona el host resuelto en el resumen principal y conserva el alias en los detalles. La gente suele reconocer primero el apodo y después la máquina real; necesita ambos.

DNS merece la misma prudencia. Un nombre de host es la identidad adecuada para las personas. Una dirección IP puede complementarlo, especialmente en una solicitud sospechosa o inusual, pero no debe sustituir al nombre de host y convertir cada aprobación en una prueba de memoria. Si un sistema no puede resolver un destino, la solicitud debe decirlo. No debe inventar confianza con una etiqueta antigua almacenada en caché.

No dependas de una etiqueta roja de producción, un triángulo de advertencia o una columna situada a la izquierda para distinguir los destinos. Esos recursos ayudan a revisar la pantalla visualmente, pero no pueden transmitir el significado. Incluye el nombre del entorno en texto si tienes una fuente fiable y pronuncia también el host. Las etiquetas de entorno cambian. Los hosts indican al usuario adónde va la conexión.

Una representación accesible y concisa tiene este aspecto:

Destination
Protocol: HTTPS
Host: billing.example.net
Request: PATCH /v2/subscriptions/4821
Credential: billing-service token

La etiqueta de la credencial debe ir después del destino y de la acción, no antes. El usuario debe saber qué hará la credencial antes de decidir si merece utilizarla. No pronuncies nunca el valor del token, ni siquiera en una etiqueta destinada únicamente a la accesibilidad. La tecnología de asistencia forma parte de la interfaz de usuario, no es un canal privado para secretos.

La ocultación debe conservar el motivo para aprobar o denegar

La ocultación debe eliminar el material secreto y conservar las partes de la solicitud que cambian la decisión. Los equipos suelen hacerlo al revés. Ocultan todos los parámetros y dicen que han protegido la privacidad, mientras la tarjeta de aprobación se vuelve demasiado vaga para evitar una acción incorrecta.

Oculta siempre los tokens bearer, las contraseñas, el material de claves privadas, las cookies, las cabeceras de autorización, las URL firmadas y los valores completos de los campos que puedan contener datos personales o financieros. Enmascarar solo la parte central de un token suele ser teatro. Un secreto parcial todavía puede ayudar a un atacante a relacionar o reconstruir una credencial, y también induce a los diseñadores a exponer demasiado en los registros.

Conserva la estructura. En una solicitud HTTP, muestra el método, el host, la ruta, el tipo de contenido, el tamaño del cuerpo cuando aporte una escala útil y los nombres de los campos sensibles. En un comando, muestra el ejecutable, los argumentos, los archivos o servicios de destino y una marca explícita para los argumentos ocultos. Una persona que decide si debe enviar una factura debería oír que la solicitud contiene recipient, amount y currency; no necesita la dirección del destinatario ni el importe si la política los trata como datos sensibles.

Compara estos dos resúmenes hablados:

POST request with protected details.

POST api.example.net/v1/payouts.
JSON fields: destination account redacted, amount redacted, currency visible.
This call uses the finance credential.

La segunda versión no revela los valores secretos, pero informa al usuario de que el agente intenta realizar un pago y no una comprobación de estado inofensiva. Esa diferencia es el objetivo de una pantalla de consentimiento.

No crees un botón de «mostrar secreto» dentro de una solicitud de aprobación. Un usuario puede necesitar más contexto, pero la respuesta es una representación más segura, no una salida fácil de los límites de la bóveda. Si un operador realmente necesita inspeccionar un valor protegido, dirígelo a un flujo de trabajo separado y autenticado de forma deliberada, con reglas de acceso claras. La tarjeta de aprobación debe seguir siendo una superficie de decisión, no un navegador de secretos.

La ocultación también debe mantenerse al copiar, en la salida de accesibilidad y en la proyección de auditoría. Si la etiqueta visible dice «token oculto», pero el valor de accesibilidad del elemento contiene la cabecera original, VoiceOver se ha convertido en una vía de exfiltración. Prueba todas las representaciones del campo: texto visible, etiqueta de accesibilidad, valor de accesibilidad, texto de ayuda, comportamiento al copiar al portapapeles y entrada del registro.

El árbol de accesibilidad del diálogo debe reflejar la decisión

VoiceOver sigue la semántica de accesibilidad, no el recorrido visual del diseñador. Construye el árbol de accesibilidad en el mismo orden que la decisión y compruébalo con el lector de pantalla, sin asumir que la pila visual determina el recorrido.

Usa un contenedor real de diálogo o alerta, con un título accesible y conciso como «Se requiere aprobación». Mueve el foco al diálogo cuando se abra. El foco inicial debe situarse en el resumen de la decisión o en el primer campo de identidad, no en Aprobar. Si el sistema mueve el foco directamente al botón predeterminado, crea un camino rápido hacia un clic sin información suficiente y obliga al usuario a recorrer el diálogo en sentido inverso para entenderlo.

Los controles nativos de macOS ya proporcionan buena parte del comportamiento que las vistas personalizadas deben recrear. Mantén la superficie nativa siempre que sea posible: texto estático para los datos, un control de expansión estándar para los detalles opcionales, una casilla solo cuando el usuario pueda cambiar una opción explicada con claridad y botones normales con etiquetas distintas. Así, un inspector de accesibilidad puede mostrar un árbol que tenga posibilidades de coincidir con la interfaz.

El orden previsto debería poder leerse como un esquema sencillo:

Dialog: Approval required
  Summary: New agent process requests authorization
  Group: Requesting process
    Static text: Signing authority, Example Software LLC
    Static text: Process, deploy-helper
  Group: Destination
    Static text: HTTPS, api.example.net
  Group: Requested action
    Static text: POST /v1/releases
  Group: Scope
    Static text: Approval lasts until this process exits
  Disclosure button: More redacted details, collapsed
  Button: Deny request
  Button: Approve this process

Esto es un artefacto de aceptación, no una sugerencia para meter todas las frases en una sola etiqueta de accesibilidad. Los grupos ofrecen puntos de referencia. El texto estático de cada grupo da al usuario un lugar al que volver. El orden debe mantenerse estable tanto si el control de detalles está contraído como si está expandido.

Da nombres completos a los botones. «Aprobar» resulta impreciso cuando más de una solicitud de aprobación puede interrumpir el trabajo. «Aprobar este proceso» y «Denegar solicitud» siguen siendo claros cuando VoiceOver los lee de forma aislada. Si la tarjeta ofrece una aprobación para una sola llamada y otra para una sesión, expresa esa diferencia en el texto del botón o en la descripción accesible inmediatamente anterior. Dos botones con la etiqueta «Permitir» y distintos textos visuales son un error de diseño.

Las directrices de accesibilidad de Apple para macOS piden a las aplicaciones etiquetas, roles, valores y descripciones que comuniquen la finalidad de un control. La palabra «finalidad» importa aquí. Un campo llamado «Destino» puede tener etiqueta, rol y valor, y aun así obligar al usuario a deducir si nombra un host, una cuenta, un archivo o un comando. Prefiere etiquetas que incluyan el sustantivo que falta: «Host SSH», «Solicitud HTTP», «Credencial utilizada» y «Duración de la aprobación».

No anuncies un muro de texto cuando se abra el diálogo. Los usuarios de VoiceOver necesitan un punto de partida claro, no un párrafo que les impida interrumpir y examinar un elemento. Coloca el resumen breve en la región del título o justo después y deja que los comandos de lectura normales recorran los datos. Anuncia una vez y con lenguaje sencillo los cambios importantes, como una solicitud denegada o una aprobación que caduca al terminar el proceso.

El color y la disposición no pueden transmitir la advertencia

Una tarjeta de aprobación solo supera la prueba básica de accesibilidad cuando una persona puede tomar la misma decisión mediante el orden hablado y los controles de teclado que al mirarla. La prueba detecta algo más que fallos de contraste de color. También descubre supuestos ocultos sobre columnas, colocación de iconos, foco predeterminado y agrupación visual.

Haz este ejercicio con un evaluador que use VoiceOver habitualmente, no solo con un desarrollador que sepa dónde está cada elemento. Inicia un proceso nuevo del agente. Activa VoiceOver. Mantén el puntero alejado de los controles. Pide al evaluador que responda cuatro preguntas antes de aprobar o denegar: quién lo solicitó, dónde actuará, qué hará y cuánto durará la aprobación.

Después pídele que complete esta secuencia:

1. Encuentra la aprobación entrante sin ayuda de una persona vidente.
2. Lee la identidad del proceso, el destino, la acción y el alcance en orden.
3. Expande los detalles e identifica qué valores ha ocultado la interfaz.
4. Deniega la solicitud, activa otra nueva y apruébala.
5. Confirma qué ocurrió después de cada elección y dónde encontrar la acción registrada.

Registra la secuencia hablada real, incluidas las etiquetas repetidas, los campos omitidos y los saltos de foco. Una revisión visual puede pasar por alto un orden de accesibilidad defectuoso porque el revisor ve la disposición prevista y completa las lagunas de forma inconsciente. Las grabaciones de voz y las transcripciones escritas hacen que resulte difícil negar el defecto.

Prueba estos casos por separado:

• Un proceso de agente firmado solicita la aprobación de una primera sesión.
• Un proceso local sin firma realiza la misma solicitud.
• Una credencial protegida requiere confirmación para una llamada después de que ya exista una aprobación de sesión.
• Una solicitud contiene cabeceras o campos del cuerpo ocultos.
• Llegan dos solicitudes con poca diferencia y la primera tarjeta desaparece después de denegarla.

El último caso revela un fallo habitual. Los desarrolladores usan una vista reutilizable y actualizan sus etiquetas sobre la marcha. Una persona vidente nota el cambio de la tarjeta. VoiceOver puede conservar el foco en un botón mientras cambian el proceso, el host y la acción que hay detrás. Trata una solicitud materialmente distinta como un diálogo nuevo, con un resumen y un evento de foco nuevos. No permitas nunca que un botón Aprobar existente adquiera silenciosamente un significado diferente.

Prueba también los ajustes de movimiento reducido y texto grande. Estos ajustes no cambian directamente la semántica de VoiceOver, pero suelen activar código de disposición alternativo. Si una disposición compacta mueve el texto del alcance debajo de los botones o elimina una etiqueta para ahorrar espacio, los usuarios pierden información precisamente cuando su configuración necesita una interfaz más tolerante.

La aprobación de sesión necesita un límite visible

Un permiso de sesión solo es seguro cuando la persona puede saber exactamente qué proceso en ejecución lo recibió y cuándo termina. «Recordar mi elección» es un lenguaje incorrecto para un agente, porque suena a preferencia permanente cuando la decisión real debería estar vinculada a la vida de un único proceso.

Indica el límite en la tarjeta: «Esta aprobación permite llamadas de este proceso hasta que termine». Colócalo después de la descripción de la acción, donde responde a la pregunta natural que surge a continuación. Si el proceso termina y se inicia un reemplazo, vuelve a mostrar la tarjeta. Un proceso nuevo puede tener el mismo nombre visible, pero no ha obtenido la decisión anterior.

La autorización por sesión de Sallyport lo hace de forma predeterminada y su tarjeta de aprobación comienza con la autoridad de firma de código del proceso. Es un buen punto de partida, pero la tarjeta aún debe hacer que el destino, la acción y la duración sean igual de claros para una persona que use VoiceOver.

La aprobación por llamada tiene otra función. Úsala para credenciales individuales cuando cada uso tenga consecuencias independientes, como una operación de pago, un borrado en producción o un comando SSH que cambie el estado de un servicio. La confirmación debe indicar claramente ese hecho: «Esta credencial requiere aprobación para cada uso». No ocultes la condición en una pantalla de ajustes para sorprender después al usuario con una solicitud adicional.

Evita la recomendación habitual de poner todas las decisiones detrás de un único interruptor amplio de «permitir este agente». Resulta atractiva porque mantiene el trabajo autónomo en marcha. También mezcla identidad, objetivo y duración en una promesa de que el agente se comportará bien. Esa promesa no tiene un significado de seguridad útil cuando el agente sigue otra instrucción o llega a otro servicio. Un permiso de sesión limitado, combinado con confirmaciones selectivas por llamada, pide a la persona que valore una solicitud real.

El control de la bóveda debe quedar fuera de esta elección. Cuando la bóveda está bloqueada, el sistema debe denegar las acciones directamente en lugar de mostrar una tarjeta de aprobación que sugiera que un clic puede saltarse el bloqueo. Una acción de Touch ID puede desbloquear o confirmar cuando el producto lo permita, pero la interfaz hablada debe indicar qué evento ocurrió. «Aprobado» y «bóveda desbloqueada» son cambios de estado distintos y nunca deben compartir un anuncio ambiguo.

Los registros de auditoría deben permitir reconstruir después una decisión

Un flujo de aprobación está incompleto si el operador no puede saber más tarde qué solicitud aprobó, qué acción siguió y si el registro cambió. La tarjeta inmediata gestiona el consentimiento. El registro de auditoría gestiona la discusión posterior, que suele llegar cuando nadie recuerda qué apareció fugazmente en pantalla.

Mantén separados el evento de sesión y el evento de acción individual. Un registro de sesión debe identificar la ejecución del agente, su decisión de autorización y la revocación o salida. Un registro de actividad debe identificar cada llamada HTTP o SSH, su destino, su operación, su resultado y las mismas reglas de ocultación usadas en la vista de aprobación. Mezclarlo todo en una entrada vaga de «agente permitido» elimina la conexión entre consentimiento y consecuencia.

En un registro cifrado encadenado mediante hashes, la verificación debe ser un acto separado e inspeccionable. La forma esperada es sencilla:

$ sp audit verify
Verifying encrypted audit log...
Chain verified: 184 records
Result: valid

El número exacto de registros variará, pero el comando debe indicar al operador si la verificación tuvo éxito o falló y debe fallar de forma visible si encuentra una cadena rota. Verificar el texto cifrado importa porque un revisor puede comprobar la integridad del registro sin desbloquear primero la bóveda solo para leer las pruebas de auditoría. Eso no demuestra que una acción aprobada fuera sensata. Demuestra que la secuencia conservada no ha cambiado silenciosamente.

Construye la tarjeta de aprobación y los registros a partir del mismo vocabulario de eventos. Si la tarjeta dice «Solicitud HTTPS a billing.example.net» mientras el registro la llama «operación remota 12», el usuario no puede relacionar la decisión con su registro. Reutiliza el destino, la acción, la identidad del proceso, el alcance y las categorías de ocultación, aunque cada superficie los presente con un nivel de detalle diferente.

Ofrece a los usuarios de VoiceOver un camino igual de directo hasta el registro. Después de aprobar o denegar, anuncia el resultado y proporciona una ruta etiquetada hacia la entrada de sesión o actividad correspondiente. No hagas que un punto de estado de color aporte la prueba de que ocurrió una acción. Un usuario que oye «Solicitud denegada. Registro de actividad disponible» puede comprobar el resultado más tarde sin reconstruir la interfaz de memoria.

Las regresiones de accesibilidad forman parte del conjunto de pruebas de seguridad

Trata la secuencia hablada de aprobación como un contrato de seguridad y pruébala cada vez que cambien la tarjeta, el canal de acción o el modelo de identidad. Una instantánea que confirme la existencia de un título y dos botones no detectará un destino que haya quedado debajo de los controles ni un campo oculto que se filtre mediante un valor de accesibilidad.

Mantén un conjunto pequeño de casos de prueba con solicitudes deliberadamente incómodas: una autoridad de firma larga, un proceso sin firma, un nombre de host internacionalizado, un puerto no estándar, una redirección a otro host, un alias SSH y un cuerpo con nombres de campos sensibles. Cada caso debe producir un esquema de accesibilidad esperado y una representación esperada en el registro. Cuando un diseñador cambie la disposición visual, compara esas salidas antes de dar el trabajo por terminado.

Una revisión práctica plantea cuatro preguntas directas. ¿Puede un usuario de VoiceOver identificar el ejecutable y el firmante? ¿Puede identificar el destino remoto final? ¿Puede distinguir entre esta llamada y la duración de este proceso? ¿Puede aprobar o denegar y oír después un resultado claro? Si alguna respuesta depende de ver un color, un espacio o un icono, la solicitud aún tiene un defecto de seguridad.

Haz la primera prueba con la credencial de mayores consecuencias y la solicitud menos cooperativa que permita tu producto. Un GET amistoso a un host conocido hace que cualquier tarjeta de aprobación parezca correcta. La solicitud que revela el diseño es la de un proceso firmado desconocido que pide modificar un servicio real con partes de su cuerpo ocultas. Ahí es donde el texto, el orden y el comportamiento del foco permiten a una persona ejercer el control o la reducen a hacer clic para atravesar una barrera.