Por Qué La Accesibilidad Debe Ser Una Prioridad Máxima en 2025

Lee la transcripción:

Estamos probando la transcripción de nuestros podcasts utilizando un programa de software. Por favor, disculpa cualquier error tipográfico ya que el bot no es correcto el 100% del tiempo.

Hannah Clark: Creo que es hora de admitir que hablar sobre accesibilidad tiende a incomodarnos. En el contexto de producto, solemos priorizar funciones con el mayor impacto y el mayor porcentaje de usuarios. Por eso, cuando hablamos de crear pensando en la accesibilidad, parece un tema complejo. ¿Dónde encajamos en el roadmap aquellas funciones que generan un gran impacto para un porcentaje relativamente pequeño de usuarios? ¿Cómo sabemos qué aspecto debe tener la accesibilidad para nuestro producto, cuando lo accesible significa cosas diferentes para distintas personas? ¿Y cómo hacemos todo esto sin asumir nada ni ofender involuntariamente a los usuarios a quienes intentamos apoyar?

Mi invitada de hoy es Prerna Ramachandra, Gerente Principal de Producto en Yahoo. Antes de unirse a Yahoo, Prerna fue Gerente Senior de Producto en Slack, donde jugó un papel clave auditando y desarrollando funciones accesibles para la diversa base de usuarios del producto. Lo que vas a escuchar es parte caso de estudio, parte guía práctica sobre el caso de negocio para la accesibilidad y las formas más eficientes y éticas de hacer que tu producto sea más acogedor para todos. Vamos a comenzar.

Bienvenidos de nuevo a El Podcast del Club CPO. Hoy estamos aquí con Prerna Ramachandra.

Prerna, muchísimas gracias por hacer tiempo en tu apretada agenda para acompañarnos hoy.

Prerna Ramachandra: Muchas gracias por invitarme. Es un placer estar aquí.

Hannah Clark: ¿Puedes contarnos un poco sobre tu trayectoria y cómo llegaste a donde estás hoy?

Prerna Ramachandra: Actualmente soy Gerente Principal de Producto en Yahoo. Llevo aquí aproximadamente un año y medio. Y antes de Yahoo, trabajé en Slack, estaba ahí justo antes de que fueran adquiridos por Salesforce y luego durante la adquisición de Salesforce. En Slack, lideraba principalmente el equipo de accesibilidad y sistemas de diseño antes de pasar a trabajar en las experiencias principales de la aplicación de escritorio.

Mi trabajo de un equipo a otro, en cierta forma, se entrelazó, y me gustaría profundizar en eso más adelante. Y antes de Slack, trabajé en The Washington Post, donde lideré el rediseño de su página principal y el replanteamiento de la experiencia de página de artículo. Así que tengo experiencia tanto en medios como en grandes tecnológicas.

Me gusta decir que mi interés por el producto se alinea con la intersección entre producto, tecnología y narrativa. Y en cómo las personas utilizan las historias para comunicarse unas con otras y cómo la tecnología puede ser una herramienta eficaz para lograrlo.

Hannah Clark: Lo cual es perfecto ya que hoy estás aquí contando tu propia historia.

Obviamente es algo que nos apasiona a ambas, la narrativa, y hoy vamos a enfocarnos en algo que quizá sea un poco más nicho, pero definitivamente es un tema que creo que no hablamos lo suficiente: la accesibilidad, y específicamente la intersección entre accesibilidad y onboarding de usuarios.

Para dar comienzo, según tu experiencia trabajando en este campo y área, ¿por qué crees que la accesibilidad a menudo se trata como algo secundario? ¿Y cuál es el caso de negocio para integrarla desde el principio?

Prerna Ramachandra: Definitivamente. Me gusta comenzar hablando desde una declaración que sinceramente creo de corazón, y es que vivimos en una época donde ya no considero que la tecnología sea un lujo.

Crecí en los años noventa—me delato un poco aquí—cuando la tecnología todavía era una novedad. Internet era una novedad. No todos tenían acceso, ni todos lo necesitaban, pero hoy vivimos en una época en la que cada uno de nuestros servicios esenciales está de alguna manera digitalizado. Y eso significa que toda persona en el mundo debería poder usarlo fácilmente.

Y las personas con discapacidad generalmente son tratadas como una ocurrencia tardía en nuestra sociedad. Creo que muchos de nuestros servicios no son realmente accesibles, pero la tecnología está posicionada, de una forma única, para integrar fácilmente la accesibilidad en lo que hace. Y la tecnología también puede facilitar enormemente la vida de todos, incluidas las personas con discapacidad.

Por eso, desde el punto de vista moral y ético, considero realmente importante priorizarla. Ahora, ¿por qué se trata como algo secundario? Francamente, es porque la mayoría de las organizaciones no comprenden realmente el caso de negocio. Primero, eso. Segundo, porque sienten que la accesibilidad requiere experiencia técnica muy específica.

Y, por tanto, no siempre sienten que cuentan con esa experiencia o simplemente no la consideran. No está integrada en los procesos y, como resultado, la ignoramos hasta que alguien se preocupa de que puedan demandarnos o perder un cliente importante con requisitos de accesibilidad.

Entonces, de repente, los equipos se apresuran para entender el problema y cómo abordarlo. Para responder la segunda parte de tu pregunta, ¿cuál es el caso de negocio para la accesibilidad? Y ya lo mencioné antes: para que la tecnología tenga éxito, necesitas más usuarios, y para la mayoría de nosotros, se nos paga más cuanto más se usa nuestro producto.

Y la única forma de que más personas lo usen es si pueden acceder a él. Así que, a nivel fundamental, la accesibilidad es importante porque más personas pueden utilizar tu producto, y cuando eso ocurre, simplemente ganas más dinero. La otra cara es que no quieres ser demandado, y si lo eres, podrías tener que pagar grandes sumas.

Así que desde ambos puntos de vista, hay un caso de negocio claro para la accesibilidad. Además, algo que me apasiona personalmente dentro del campo es que solemos limitar la accesibilidad a que funcione con lectores de pantalla o navegación por teclado, pero creo que debemos ir más allá y pensar en cómo aseguramos que todos, en cualquier circunstancia, puedan usar el producto. Muchas veces no pensamos en la accesibilidad como algo situacional o condicional.

Por ejemplo, los comandos de voz: solemos pensar que son útiles para personas con baja visión, como mi padre, que es mayor y no puede leer letras pequeñas, así que usa la voz para controlar su teléfono. Pero si vas conduciendo y no puedes usar las manos ni los ojos de la misma manera, igualmente puedes usar comandos de voz.

Por tanto, cuando piensas en accesibilidad, puedes concebirlo como una situación más que como un problema individual, y eso amplía tu definición y te hace ver que estás dejando sobre la mesa un gran caso de uso y una gran base de usuarios.

Lo cual, probablemente, no sea bueno para tu negocio. Así que existe una razón práctica para priorizar esto desde el principio.

Hannah Clark: Es resonante lo que dices. Aplica tanto para productos digitales como físicos y espacios físicos. Me gusta el planteamiento de ser accesible a una situación más que a un caso de uso concreto. Lo viví empujando un cochecito y notando cuántos espacios están diseñados para un solo peatón.

Hay muchas circunstancias distintas en las que una persona puede requerir una función o tener una necesidad de accesibilidad, y esto es transversal a muchas etapas y contextos de vida. Me gusta mucho esa forma de verlo y me gustaría profundizar en ello en un momento.

Mencionaste que querías hablar más de tu experiencia en Slack, y me interesa analizar algunos de los proyectos en los que trabajaste allí, especialmente los flujos de onboarding desde el prisma de la accesibilidad.

Cuéntame un poco, ¿cómo abordaste un análisis del estado actual para evaluar la accesibilidad del producto y cómo avanzaste desde allí?

Prerna Ramachandra: Claro. Cuando comencé en Slack, uno de mis primeros proyectos fue precisamente averiguar cuán accesible era el producto y qué podíamos hacer al respecto.

¿Qué marco teníamos para analizar el estado del producto? No teníamos ninguno cuando llegué. Slack estaba en una etapa en la que apuntaba a grandes clientes empresariales que tienen estándares muy estrictos de accesibilidad, habiendo funcionado ya muy bien en empresas pequeñas y medianas.

Lo primero que hice fue desarrollar un conjunto interno de normas, lo que llamamos los “Estándares de Accesibilidad de Slack”, que utilizaba estándares preexistentes como WCAG, pero también consideraban los productos únicos de Slack y lo que la accesibilidad significaría para ellos. Creamos un marco para recorrer el producto y analizar si cumplía con ciertos criterios.

Como resultado del análisis, asignamos una calificación, como A, B o C, a cada función del producto para analizar cuán accesible era. Era un análisis cuantitativo y cualitativo: una lista de criterios, algunos basados en tareas simples (¿todo es accesible por teclado?, ¿es todo usable por lectores de pantalla?) y otros más intangibles.

Por ejemplo, Slack es un producto de comunicación, y durante la pandemia escuchamos que la sobrecarga de notificaciones afectaba especialmente a personas neurodivergentes, que se sentían abrumadas y no podían realizar bien sus tareas. Eso no suele verse en las guías de accesibilidad, así que lo incluimos en nuestro marco.

Este marco servía para calificar áreas del producto y los criterios eran si podían realizar la tarea y con qué rapidez. Ayudaba a marcar la urgencia de los problemas y a priorizar. Usamos este marco para el análisis del producto y luego fuimos a liderazgo: este es el producto completo, así cae en el rango, y estos son los problemas graves que deben arreglarse urgente porque el producto está roto para un grupo de clientes.

La ventaja es que este marco no solo aplicaba a productos existentes, sino también para el desarrollo de nuevos productos: ayuda a saber qué revisar antes de lanzar algo.

Luego trabajé con equipos individuales ayudándolos a saber qué priorizar según este marco. Cada equipo tiene su roadmap, nadie quiere romperlo para adaptarse a algo nuevo. Trabajé con ellos para priorizar los ítems críticos. Así, al acudir en grupo a los líderes, teníamos un plan claro y podíamos explicar los esfuerzos, los plazos, los intercambios y el impacto —que es lo que ellos necesitaban conocer.

Así que fue mucho trabajo de gestión de personas y, también, mucho trabajo técnico con los ingenieros para darles el análisis que necesitaban.

Hannah Clark: Esto es fundamental. Conseguir ese apoyo decisivo es lo más importante para que estas funciones se entreguen y se hagan bien.

Me gustaría que entraras más en detalle sobre esos intercambios o trade offs. ¿Cómo se presentan? ¿Puedes dar un ejemplo de cómo se comunicaría todo esto para explicar el alcance del proyecto y su importancia?

Prerna Ramachandra: El equipo que más sintió el impacto fue el que trabajaba en el núcleo de mensajería: tenían la mayor superficie porque abarcaban desde enviar hasta recibir mensajes, canales, todo el corazón de Slack. Por ende, tenían más tareas críticas de accesibilidad.

Por ejemplo, cuando les presentamos una lista (digamos, de 100 problemas para que sea fácil calcular), me senté con la gerente de producto y analizamos: “Estos son los ítems críticos según nuestro marco, pero con los datos de uso podemos depurar: en realidad, quizás el 80% es crítico porque hay flujos alternativos, soluciones distintas, etc.” Ese filtrado junto con el PM es crucial.

Luego miramos qué parte se descontinuaba o rediseñaba pronto, y sólo nos concentramos en lo que realmente necesitaba arreglo inmediato. De los recaudos iniciales, tal vez 10 se desechaban por ser obsoletos, y de los 70 restantes, el ingeniero especialista en accesibilidad ayudaba a los ingenieros del equipo a analizar el esfuerzo para cada uno.

Luego, ¿cuántos pueden acomodar en su próximo sprint sin afectar otras entregas? Con el buffer típico de equipos que ya han lanzado producto, quizás se pueden abordar 20 sin comprometer nada, y entonces los restantes requieren intervención del liderazgo para negociar si se posponen o desplazan otras funciones importantes. Si el mismo cliente exige accesibilidad y el desarrollo de una función crítica, se negocia con el liderazgo y con el cliente para ver qué priorizan.

Lo más importante aquí es resolver lo máximo que puedas a nivel de equipo, y sólo involucrar al liderazgo en los grandes compromisos. Luego, en Slack, pasamos a planificar sprints dedicados a accesibilidad —toda la empresa podía participar durante la semana de accesibilidad mundial, con talleres y charlas. Fue mucho trabajo inicial pero, una vez resueltos los mayores intercambios, se facilitó priorizar la accesibilidad en los planes futuros.

Hannah Clark: Esto me encanta: toda la organización unida para priorizar e incentivar la accesibilidad, y encima convierte el trabajo en algo positivo. Genial.

Ahora, en cuanto a colaboración transversal, ¿cómo se aborda la accesibilidad si hay varios productos y equipos trabajando a la vez en diferentes áreas?

Prerna Ramachandra: Gran pregunta. Creo que hay dos pilares fundamentales para abordar esto.

El primero es estructural: si tienes un equipo central de accesibilidad, ¿dónde se ubica en la organización? Si sólo está en un área vertical, será difícil evitar los silos y trabajar con todos. Debe estar en la ubicación adecuada o, si no es así, como gerente de producto debes conocer a todos los equipos e involucrarte. El segundo es la comunicación constante de los roadmaps, tanto desde el equipo central como desde cada PM individual de producto.

El mayor reto y oportunidad es asegurar que, en la planificación de roadmap, incluyas a los expertos en accesibilidad desde el principio, desde el diseño y no solo en ingeniería. Herramientas como Figma permiten crear workflows accesibles desde el diseño. Así, el diseñador está involucrado desde la fase de diseño y planificación, asegurando la accesibilidad desde el arranque.

Para problemas ya existentes, el marco central sirve para evaluar prioridades ante bugs y cambios, evitando que solo una persona deba coordinar todo. No se trata de ser un “director de escuela”, sino de empoderar a cada quien informado por un marco común. Si eres PM y quieres avanzar en accesibilidad, desarrolla o adopta un marco claro para que no tengas que esperar aprobaciones cada vez.

Y si construyes algo nuevo, asegúrate de incluir a expertos e integrar la accesibilidad desde el inicio del diseño: así se evitan apuros y prioridades corregidas de última hora.

Hannah Clark: Ahora me gustaría hablar de implementación e iteración: es una cosa mejorar la versión actual, pero ¿cómo garantizas que las nuevas funciones que vengan en el roadmap sean accesibles desde el día uno?

Prerna Ramachandra: Gran pregunta. Un ejemplo concreto: el onboarding de usuarios. Al crear el roadmap, considera la accesibilidad en cada funcionalidad. Segundo, identifica dentro de tu base de usuarios quién puede dar feedback crucial sobre accesibilidad: investigaciones de usuario suelen olvidar a personas con discapacidad, así que integra sus necesidades en la investigación y testeo desde el inicio.

En Slack, detectamos que el onboarding tenía carencias de accesibilidad pero el equipo de onboarding estaba rediseñando el flujo, así que colaboramos desde el principio para asegurar accesibilidad. Nuestro diseñador participó en todo el proceso, asegurando que en Figma las especificaciones incluirían accesibilidad armónica a la funcionalidad.

Además, se creó un onboarding específico para usuarios que lo solicitaran, guiando paso a paso sobre funciones, comandos y herramientas de accesibilidad, similar a como lo hace Apple con Mac. También, gracias a ese flujo, pudimos mostrar “tooltips” dentro del producto según la respuesta del usuario, ampliando su capacitación accesible.

Fue posible porque identificamos el hueco hablando directamente con clientes que enviaban tickets de bugs de accesibilidad. Muchos dijeron: “No había nada que me ayudara a navegar Slack, me las arreglé solo”. Están acostumbrados a hacerlo así por costumbre, pero no debería ser así.

Para avances futuros, apóyate mucho en la investigación de usuario real —habla con las personas, nada sustituye eso, ni el mejor IA. Existen empresas como Fable que agrupan usuarios con discapacidad para testing, trabájalos y suma esos feedbacks.

En cuanto al diseño e iteración, incluye a alguien formado en accesibilidad desde el principio: que los diseños tengan especificaciones explícitas, porque es lo que los ingenieros implementarán. Y que participen en las pruebas antes de lanzar. Así, todo lo que construyas irá alineado desde el principio, evitando tener que rehacer o improvisar luego.

Hannah Clark: Me encantan los consejos prescriptivos. Para finalizar, quiero abordar el tema de la analítica: ¿cómo medimos el éxito real de las funciones de accesibilidad? Sabemos que analizar el product market fit general es distinto del éxito de las funciones accesibles. ¿Cómo segmentar, qué herramientas usar y cómo integrar esos aprendizajes en iteraciones futuras?

Prerna Ramachandra: Daré una respuesta incómoda para muchos PM: no puedes depender totalmente de datos cuantitativos para saber si tus funciones de accesibilidad funcionan.

Moralmente, no puedes segmentar usuarios según accesibilidad, porque estarías asumiendo su discapacidad. Aunque midas cuántos usan el teclado o activan comandos de lector de pantalla, eso igual puede excluir a muchos, por ejemplo, neurodivergentes, o personas que necesitan desactivar animaciones para evitar crisis epilépticas —no siempre es detectable o atribuible a discapacidad de forma simple.

La única forma eficaz es la investigación cualitativa directa. Preguntar a los propios usuarios si pueden cumplir sus tareas tal cual quieren. Por ejemplo, en Slack creamos una API para facilitar a otros equipos la integración de navegación por teclado, y el éxito lo medimos por el uso interno de esa API (dato cuantitativo intraempresa), pero para usuarios es clave hablar y comprobar con ellos, sobre todo con quienes ya habían pedido u observado problemas antes.

Cuando lanzamos el onboarding accesible, sí medimos cuántos optaban por él, pero la evaluación verdadera viene de la experiencia y feedback de los usuarios.

Nunca lograrás la perfección: cada usuario y circunstancia es distinta, por eso hay que mantener el canal de comunicación abierto y fomentar la retroalimentación permanente, especialmente de quienes suelen tener que exigir estas facilidades para poder trabajar.

Como PM, aceptarás un grado de incertidumbre y deberás valorar la importancia de escuchar activamente a quienes usan tus productos; nadie mejor que ellos te dirá lo que está funcionando y lo que no en materia de accesibilidad.

Hannah Clark: Totalmente de acuerdo. En este show siempre defendemos la investigación de usuarios. Hace tiempo hicimos un episodio con Steve Portigal sobre cómo entrevistar usuarios —uno de nuestros favoritos— porque la clave es dejar que las personas cuenten su experiencia real, sin guiar ni sesgar. Es clave para cualquier proceso de desarrollo.

Gracias por esta conversación tan interesante. Me ha encantado tu perspectiva y los ejemplos concretos alrededor de un producto tan conocido, porque es algo con lo que todos podemos conectar.

¿Dónde puede la gente seguir tu trabajo o contactarte?

Prerna Ramachandra: Estoy en LinkedIn como Prerna Ramachandra. También pueden contactarme a través de mi sitio web: PrernaRamachandra.me.

Hannah Clark: Genial. Muchas gracias por estar aquí.

Prerna Ramachandra: Muchas gracias, Hannah. Ha sido un placer.

Hannah Clark: Gracias por escuchar. Para más ideas, guías prácticas y reseñas de herramientas, suscríbete a nuestro boletín en theproductmanager.com/subscribe. Puedes escuchar más conversaciones como esta suscribiéndote a The CPO Club, donde sea que escuches tus podcasts.