Un desarrollador de Infinity Interactive relata la experiencia de construir un flujo de aprobación de compras en Power Automate para un cliente con empleados ciegos y sordos. Lo que empezó como un cálculo optimista de dos horas terminó en 18 horas de trabajo y una revisión de accesibilidad dirigida por una especialista invidente, usuaria final del sistema.
El artículo expone los obstáculos concretos que aparecieron al intentar usar las herramientas de Microsoft con lectores de pantalla. SharePoint, al compartir una página en modo de solo lectura, añade la etiqueta "(read only)" a cada campo: para un usuario vidente es un detalle menor, pero para quien escucha el contenido con un lector de pantalla se convierte en una cadena repetitiva que oculta la información útil. Además, los lectores de pantalla no reconocen la aplicación nativa de aprobaciones de Power Automate en Teams, JAWS presenta incompatibilidades con los correos de aprobación en Outlook y SharePoint genera varios encabezados H1 en una misma página, rompiendo la navegación.
Donde fue posible, el desarrollador corrigió etiquetas, añadió texto alternativo descriptivo y limpió la estructura de encabezados. Para la página de seguimiento de SharePoint, optó por reemplazar la consulta visual por notificaciones por correo en cada etapa del proceso. Donde la plataforma lo impedía, elaboró documentación específica con indicaciones para sortear los problemas.
El texto subraya que gran parte del software se construye y prueba por personas que ven y oyen, lo que mantiene las brechas de accesibilidad ocultas hasta que un usuario real las recorre. Propone integrar los estándares de accesibilidad desde el inicio, revisar las herramientas internas y reportar los errores a los proveedores para que这些问题 salgan del backlog.