Porque é que a acessibilidade deve ser uma prioridade máxima em 2025

Leia a transcrição:

Estamos a experimentar transcrever os nossos podcasts utilizando um programa de software. Perdoe quaisquer erros tipográficos, uma vez que o sistema nem sempre está 100% correto.

Hannah Clark: Acho que está na altura de admitirmos que falar sobre acessibilidade tende a deixar-nos desconfortáveis. Num contexto de produto, tendemos a dar prioridade às funcionalidades com maior impacto e à maior percentagem de utilizadores. Por isso, quando falamos em criar produtos acessíveis, parece um tema delicado. Onde é que, no roteiro, incluímos funcionalidades que têm um grande impacto para uma percentagem relativamente pequena de utilizadores? Como sabemos qual deve ser o aspeto da acessibilidade no nosso produto, quando acessível significa coisas diferentes para pessoas diferentes? E como fazemos tudo isto sem fazer suposições ou ofender inadvertidamente os utilizadores que estamos a tentar apoiar?

A minha convidada de hoje é Prerna Ramachandra, Diretora Principal de Produto na Yahoo. Antes de se juntar à Yahoo, Prerna foi Diretora Sénior de Produto na Slack, onde teve um papel fundamental na auditoria e no desenvolvimento de funcionalidades acessíveis para a diversificada base de utilizadores do produto. O que vai ouvir é, em parte, um estudo de caso e, em parte, um guia prático sobre os argumentos empresariais a favor da acessibilidade e as formas mais eficientes e éticas de tornar o seu produto mais acolhedor para todos. Vamos começar.

Bem-vindos de volta ao podcast The CPO Club. Estamos hoje aqui com Prerna Ramachandra.

Prerna, muito obrigada por ter encontrado tempo na sua agenda preenchida para se juntar a nós hoje.

Prerna Ramachandra: Muito obrigada pelo convite. É ótimo estar aqui.

Hannah Clark: Pode contar-nos um pouco sobre o seu percurso e sobre como chegou onde está hoje?

Prerna Ramachandra: Atualmente sou Diretora Principal de Produto na Yahoo. Estou aqui há cerca de um ano e meio. Antes da Yahoo, trabalhava na Slack e estava na Slack quando a empresa foi adquirida pela Salesforce, tendo acompanhado também o processo de aquisição. Na Slack, liderava principalmente a equipa de acessibilidade e sistemas de design, antes de passar a trabalhar na aplicação de experiências principais para computadores.

O meu trabalho numa equipa e noutra acabou por se cruzar bastante, e gostaria de explorar isso mais tarde. Antes da Slack, trabalhava no Washington Post, onde liderei a reformulação da página inicial e a migração da experiência da página de artigos para uma nova plataforma. Por isso, tive alguma experiência nos meios de comunicação social e também em grandes empresas tecnológicas.

Gosto de dizer que o meu interesse por produto se encontra na interseção entre produto, tecnologia e narrativa: as formas como as pessoas utilizam histórias para comunicar umas com as outras e como a tecnologia pode ser uma ferramenta eficaz para o fazer.

Hannah Clark: O que é perfeito, já que está aqui hoje a contar a sua história.

É evidente que contar histórias é algo que nos apaixona a ambas e, hoje, vamos concentrar-nos em algo talvez um pouco mais específico, mas que é definitivamente um tema sobre o qual não falamos o suficiente: a acessibilidade, e concretamente a interseção entre acessibilidade e integração de utilizadores.

Para começarmos, com base na sua experiência de trabalho neste campo, porque diria que a acessibilidade é frequentemente tratada como algo secundário? E qual é o argumento empresarial para a integrar desde o início?

Prerna Ramachandra: Sem dúvida. Gosto de começar por falar de uma afirmação em que acredito profundamente: vivemos numa época em que já não considero a tecnologia um luxo.

Cresci nos anos 90 — estou a revelar a minha idade —, numa altura em que a tecnologia ainda era uma novidade. A internet também era uma novidade. Nem toda a gente tinha acesso a ela, nem toda a gente precisava de ter, mas vivemos numa época em que todos os nossos serviços essenciais estão, de uma forma ou de outra, digitalizados. Isso significa que todas as pessoas no mundo devem conseguir utilizá-los facilmente.

As pessoas com deficiência são geralmente tratadas como uma preocupação secundária na nossa sociedade. Muitos dos nossos serviços não são suficientemente acessíveis, mas a tecnologia está numa posição única para integrar facilmente a acessibilidade no que faz. Está também numa posição única para tornar a vida de todas as pessoas, incluindo as pessoas com deficiência, muito mais fácil.

Por isso, penso que esta é uma das principais razões — de natureza moral e ética — pelas quais é realmente importante dar prioridade à acessibilidade. O motivo pelo qual é tratada como uma preocupação secundária é, francamente, o facto de não achar que a maioria das organizações compreenda totalmente o argumento empresarial a favor da acessibilidade. Essa é a primeira razão. A segunda é que penso que as pessoas consideram que a acessibilidade exige conhecimentos técnicos muito profundos.

Por isso, nem sempre sentem que têm esses conhecimentos ou nem sempre pensam no assunto. A acessibilidade não está integrada nos nossos processos. Como resultado, ignoramo-la até alguém começar a recear que a organização seja processada ou perca um cliente com necessidades de acessibilidade.

De repente, as equipas entram em modo de urgência para tentar perceber o que está errado e como integrar a acessibilidade. Para responder à segunda parte da sua pergunta — qual é o argumento empresarial a favor da acessibilidade? — já toquei nisso no meu primeiro ponto. A realidade é que, para a tecnologia ter sucesso, queremos ter mais utilizadores e, para a maioria de nós, quanto mais o nosso produto for utilizado, mais somos recompensados.

A forma de conseguir que mais pessoas utilizem o produto é garantir que conseguem aceder-lhe. A um nível fundamental, a acessibilidade é realmente importante porque permite que mais pessoas utilizem os seus produtos; quando mais pessoas utilizam os seus produtos, ganha mais dinheiro. O outro lado da questão é que não quer ser processado. Se for processado, poderá ter de pagar uma quantia significativa.

Por isso, há um argumento empresarial a favor da acessibilidade sob ambos os pontos de vista. Também quero acrescentar algo que explorarei mais detalhadamente: no domínio da acessibilidade, limitamos muitas vezes a ideia de acessibilidade a garantir que o produto pode ser utilizado por leitores de ecrã ou que é possível navegar através do teclado.

Penso que precisamos de ultrapassar essa definição de acessibilidade e refletir realmente sobre como garantir que todas as pessoas, em todas as circunstâncias, conseguem utilizar o produto. Muitas vezes não pensamos na acessibilidade como algo que pode ser situacional e condicional.

Um exemplo que gosto sempre de dar são os comandos de voz ou a utilização da voz para utilizar o produto. Pensamos sempre que isso é mais fácil para quem tem uma visão reduzida. O meu pai, por exemplo, é bastante mais velho e pode não conseguir ver texto pequeno no ecrã, por isso gosta de utilizar a voz para controlar várias coisas no telemóvel.

Mas se estiver a conduzir, também não pode utilizar as mãos e não utiliza a visão da mesma forma, pelo que continua a poder usar comandos de voz. Quando pensamos em acessibilidade, podemos considerá-la algo que abrange uma situação, e não apenas um indivíduo ou um problema individual. Isso amplia a definição e permite perceber que estamos a deixar escapar um caso de utilização e uma base de utilizadores enormes.

O que provavelmente não é bom para o negócio. Existe, portanto, um argumento empresarial prático para dar prioridade à acessibilidade desde o início.

Hannah Clark: Acho que isso é muito pertinente. Aplica-se tanto à acessibilidade em produtos digitais como a produtos físicos e espaços físicos. Gosto muito da ideia de ser acessível a uma situação, em vez de se tratar de um caso de utilização específico. Eu própria passei por isso quando empurrava um carrinho de bebé e reparei em quantos espaços eram concebidos para um único peão, em fila única.

Percebemos que existem tantos contextos diferentes em que alguém pode precisar de uma funcionalidade ou adaptação de acessibilidade, ou de algo concebido a pensar na acessibilidade, porque isso se aplica transversalmente a muitas idades, fases e momentos da vida. Gosto muito dessa forma de pensar e gostaria de aprofundá-la dentro de momentos.

Referiu que queria falar mais sobre a sua experiência na Slack. Gostaria de explorar alguns dos projetos em que trabalhou nessa altura, em particular os fluxos de integração de utilizadores através de uma perspetiva de acessibilidade.

Explique-me como abordou uma análise do estado atual para avaliar qual era o nível de acessibilidade do produto e como avançou a partir daí.

Prerna Ramachandra: Quando comecei na Slack, um dos primeiros projetos em que trabalhei foi perceber exatamente até que ponto o produto era acessível e o que podíamos fazer para responder à sua pergunta.

Que tipo de estruturas tínhamos para realizar uma análise do estado do produto? Quando entrei na Slack, não tínhamos nada. A empresa estava numa fase em que procurava grandes clientes empresariais, depois de ter tido bastante sucesso no mercado das pequenas e médias empresas. Ao procurar esses grandes clientes empresariais, percebeu que existia um conjunto muito rigoroso de regulamentações de acessibilidade aplicáveis aos seus fornecedores.

A primeira coisa que fiz foi desenvolver um conjunto interno de normas, a que chamámos normas de acessibilidade da Slack. Utilizámos normas preexistentes, como as WCAG, mas também tivemos em conta os produtos específicos da Slack e o que a acessibilidade significaria para esses produtos. Criámos uma estrutura que permitia analisar o produto e verificar se cumpria determinados critérios.

Com base nessa análise, atribuímos uma classificação — A, B ou C — a diferentes funcionalidades do produto, para avaliar o seu nível de acessibilidade. Tratava-se de uma análise quantitativa e qualitativa. Tínhamos uma lista de critérios. Alguns baseavam-se em tarefas muito simples: é tudo acessível através do teclado? É tudo acessível através de um leitor de ecrã?

Outros aspetos eram um pouco mais intangíveis. Por exemplo, a Slack é um produto de comunicação e uma das coisas que faz muito bem são as notificações. É necessário receber notificações, mas isto aconteceu durante a pandemia, quando muitas pessoas trabalhavam a partir de casa e remotamente.

Ouvimos clientes dizerem que existia uma sobrecarga de notificações, que afetava especificamente as pessoas que se identificavam como neurodivergentes. Sentiam-se muito sobrecarregadas e não conseguiam realizar corretamente as suas tarefas. Esse era um aspeto mais intangível.

Não é algo que se encontre normalmente em muitas das diretrizes de acessibilidade existentes. Por isso, incorporámos tudo isso para criar esta estrutura. Utilizámo-la para atribuir classificações a cada área funcional, baseadas exclusivamente na possibilidade de realizar a tarefa e na rapidez com que era possível fazê-lo.

Isso ajudou-nos a estabelecer um sentido de urgência relativamente aos problemas, distinguindo o que era mais importante do que não era. Essa foi a primeira coisa que fizemos. Utilizámos a estrutura para realizar uma análise do estado do produto e depois fomos falar com a liderança: este é o produto completo, é assim que se distribui pelas diferentes classificações e estes são os problemas que acreditamos ter de ser resolvidos imediatamente, porque afetam fundamentalmente o produto.

O produto estava, na prática, inutilizável para um grupo de clientes devido a esses problemas. O aspeto interessante desta estrutura era que não se aplicava apenas aos produtos existentes. Se estivesse a desenvolver novos produtos, também podia aplicá-la para perceber o que precisava de verificar antes do lançamento.

Era igualmente útil para pensar no futuro e para produtos futuros. Depois, trabalhei bastante com as equipas individuais para as ajudar a perceber o que deviam priorizar com base nesta estrutura.

Todas as pessoas têm um roteiro. Ninguém quer desmantelar o seu roteiro para responder a algo novo. Todas as equipas têm um conjunto de compromissos assumidos. Trabalhei com as equipas individuais para que soubessem exatamente quais eram os itens críticos para elas. Assim, quando nos apresentávamos coletivamente à liderança e dizíamos que determinado trabalho precisava de ser priorizado, tínhamos um plano muito claro.

Também conseguíamos explicar quais seriam as contrapartidas: qual seria o esforço necessário para corrigir cada item, o que teria de ser adiado no roteiro para acomodar esse trabalho e qual seria o impacto.

Acredito sempre que, quando se trata de acessibilidade — e isto é verdade para muitas áreas de produto —, é necessário compreender o equilíbrio entre trabalhar com a equipa individual responsável pela área funcional e saber como trabalhar com a liderança para obter apoio e dar prioridade a esse trabalho.

Tive muita sorte porque a liderança da Slack estava muito empenhada em dar prioridade a este trabalho e fazê-lo corretamente. O que precisavam de nós era informação clara: qual era o esforço necessário, qual era o calendário, quais eram as contrapartidas e qual seria o impacto. Foi isso que conseguimos apresentar.

Por isso, foi muito trabalho de gestão de pessoas e também muito trabalho técnico com os engenheiros, para fornecer a análise de que precisavam.

Hannah Clark: Isto é extremamente importante. Penso que obter apoio é essencial para garantir que estas funcionalidades são efetivamente lançadas e, como disse, que são lançadas corretamente.

Gostaria de aprofundar um pouco a questão das contrapartidas. Como seria uma contrapartida? Se pudesse dar uma história ou um exemplo de como isso seria apresentado, como formularia a questão para contextualizar tudo e explicar o âmbito do projeto e a sua posição na lista de itens críticos?

Prerna Ramachandra: A equipa que, diria, foi mais afetada pelo trabalho que fizemos era responsável pela área principal de mensagens do projeto. Isto porque detinha a maior superfície funcional: desde a experiência de alguém escrever e enviar uma mensagem até à receção de uma mensagem em todo o portal de mensagens.

Também tinha membros responsáveis pelos canais. Se utiliza a Slack, sabe que esta é a essência da experiência Slack. Por isso, fazia sentido que tivesse o maior número de itens a resolver. Não só detinha a maior superfície funcional, como era também a mais crítica.

A Slack existe porque as pessoas enviam e recebem mensagens. Era, portanto, a superfície mais crítica e tinha os problemas de maior impacto em matéria de acessibilidade.

Para dar um exemplo muito específico, quando apresentámos a lista de problemas, não vou utilizar números reais, mas sim uma hipótese. Vou usar 100 porque facilita o cálculo de percentagens. Apresentei uma lista de 100 problemas e disse que era necessário resolver todos para garantir que o produto era, no mínimo, utilizável por todas as pessoas que utilizavam um leitor de ecrã, navegavam através do teclado ou se identificavam como pessoas com deficiência.

A primeira coisa que fiz foi sentar-me com a gestora de produto e dizer: identificámos estes problemas com base na estrutura que criámos. Foi uma etapa muito importante, porque a gestora conseguiu trabalhar comigo e dizer: compreendo porque considera estes 100 itens críticos, mas penso que apenas 80% são realmente críticos.

Temos estes dados e estas informações sobre a forma como as pessoas utilizam o produto. Se considera este fluxo essencial, na realidade os utilizadores estão a fazê-lo de outra forma. Existem soluções alternativas. Essa primeira análise foi fundamental, porque conseguimos reduzir os 100 problemas para 80.

Para qualquer organização central de acessibilidade, é muito importante ter esta conversa com a pessoa responsável pelo produto. Essas pessoas conhecem melhor os seus utilizadores. Conseguimos, assim, reduzir bastante a lista.

Depois analisámos quais dos problemas se encontravam em áreas ou funcionalidades que seriam brevemente reformuladas ou descontinuadas. Se uma área estivesse a ser reformulada, bastava garantir que seria acessível na nova versão; não era necessário corrigir o problema imediatamente. Se uma área fosse descontinuada, também não precisávamos de a corrigir naquele momento. Eliminámos assim mais 10 problemas, por exemplo.

Ficámos com cerca de 70 problemas para resolver com a equipa. Sentámo-nos com os engenheiros. É aqui que é muito importante ter pelo menos um especialista interno em acessibilidade. Tivemos a sorte de contar com um engenheiro muito competente nessa área, que ajudou a equipa de engenharia a compreender os problemas e a analisar o esforço necessário para resolver cada um dos 70 itens.

Depois perguntámos à gestora de produto quantos desses 70 problemas poderiam ser priorizados no ciclo atual ou no ciclo seguinte, dentro do trimestre, sem provocar atrasos no roteiro. A maioria das equipas tem alguma margem, sobretudo quando trabalha num produto já lançado e precisa de gerir erros e problemas recebidos.

A equipa disse que conseguiria resolver cerca de 20 sem um impacto significativo no roteiro. Não foi necessário envolver a liderança nesse ponto. Ficámos então com cerca de 50 problemas.

Foi nesse momento que tivemos de perguntar quais eram as grandes áreas do produto que poderiam ser adiadas se todos esses problemas fossem priorizados. A liderança teve de intervir para nos ajudar a decidir e negociar o que fazer.

Havia uma funcionalidade que a equipa planeava lançar nesse trimestre e que era muito importante para um grande cliente. Esse mesmo cliente era também quem nos pedia que corrigíssemos os problemas de acessibilidade dentro de determinado prazo.

Conseguimos apresentar a situação à liderança: esta é a contrapartida. Depois trabalhámos com os gestores da conta desse cliente e perguntámos ao próprio cliente o que preferia ver primeiro.

O mais importante é fazer o máximo de trabalho possível ao seu nível — como colaborador individual, gestor sénior, gestor principal ou gestor de grupo — para priorizar criativamente todo o trabalho que a equipa consegue realizar. A liderança deve ser envolvida apenas quando estão em causa áreas de grande impacto.

Neste caso, foi útil o facto de o mesmo cliente ser afetado pelos dois conjuntos de problemas. Conseguimos negociar com ele o que deveria ser feito primeiro e o que poderia ficar para mais tarde. Assim, resolvemos 10 problemas nesse trimestre, sem atrasar demasiado a outra funcionalidade, e outros 10 no trimestre seguinte.

Nos trimestres seguintes, incorporámos no próprio ciclo de planeamento trimestral períodos dedicados exclusivamente à acessibilidade. Também organizámos semanas de trabalho de acessibilidade, que coincidiam com o Dia Mundial da Consciencialização para a Acessibilidade sempre que o calendário do trimestre o permitia. Todas as equipas de engenharia trabalhavam em conjunto nos problemas de acessibilidade durante essa semana, criando também um bom ambiente de comunidade.

Organizámos ainda sessões de formação sobre acessibilidade. Funcionou muito bem, embora tenha exigido bastante trabalho no início. Quando existem grandes contrapartidas entre funcionalidades, é nesse momento que é necessário envolver a liderança para ajudar a negociar e decidir o que priorizar e quando.

Hannah Clark: Isto é muito interessante. Gosto particularmente de ouvir como toda a organização se juntou para dar prioridade à acessibilidade e reservar tempo para esse trabalho. E acabou por ser também uma experiência de trabalho muito positiva.

Agora que estamos a falar de colaboração e de trabalho conjunto entre diferentes equipas, gostaria de saber como funciona quando se trabalha numa organização com vários produtos e várias equipas a tentar resolver problemas de acessibilidade em diferentes produtos e funcionalidades.

Como colaboram as equipas de produto para trabalharem em sintonia e minimizarem o esforço e a comunicação necessários para lançar esses produtos?

Prerna Ramachandra: Existem duas formas diferentes, ou dois pilares, para abordar este problema.

O primeiro pilar é estrutural. Se a organização tiver uma equipa central de acessibilidade — e penso que atualmente a maioria das organizações tem uma, de alguma forma —, é importante perceber onde essa equipa se encontra na estrutura da organização. Se estiver inserida numa única área vertical, será muito difícil ultrapassar os silos organizacionais e trabalhar com outras equipas.

É necessário garantir que a equipa está posicionada no local certo. Se não estiver, a pessoa responsável pelo produto tem de contactar as outras equipas, compreender os seus roteiros e conhecê-las para poder trabalhar bem em conjunto.

O segundo aspeto é garantir uma comunicação constante sobre os roteiros, tanto por parte da pessoa que gere e lidera a equipa central de acessibilidade como por parte das pessoas responsáveis pelas equipas funcionais.

Se souber o que está a ser preparado, consegue antecipar o trabalho. Esse foi um dos maiores desafios e também uma das maiores oportunidades quando trabalhei em acessibilidade na Slack. Mais tarde, quando passei a trabalhar no produto para computadores, deixei de estar na equipa central de acessibilidade e passei a fazer parte de uma dessas equipas funcionais.

O mais importante é garantir que, durante o planeamento do roteiro, envolve desde o início os especialistas em acessibilidade necessários. O processo começa no planeamento e continua durante o design. Gosto de dizer que a acessibilidade não começa nos engenheiros, embora exija conhecimentos de engenharia.

Por vezes, começa no designer. Se utilizar ferramentas como o Figma, existem excelentes funcionalidades para criar designs acessíveis e fluxos específicos de acessibilidade. O nosso designer participava desde o início no desenvolvimento e no design do produto para perguntar como garantir que os designs eram acessíveis e identificar o que funcionava e o que não funcionava.

É aqui que a estrutura se tornava muito útil. Quando eu estava na equipa central, não conseguia acompanhar todas as alterações, todos os roteiros e tudo o que cada equipa fazia. Mas, como tínhamos um conjunto centralizado de normas que todas as equipas conheciam, qualquer gestor de produto podia consultá-lo, partilhá-lo com o designer e com o engenheiro e verificar se um erro de acessibilidade era crítico, médio ou de baixa prioridade.

Assim, podia decidir se o problema precisava de ser priorizado imediatamente ou mais tarde. Ter normas centrais foi muito útil porque permitia que uma pessoa sem conhecimentos especializados tivesse algo a que recorrer quando surgiam problemas e ajudava a definir prioridades.

Também evitava que uma única pessoa tivesse de tentar controlar tudo e perguntar constantemente se cada equipa estava a tratar do assunto.

Quando trabalhei em acessibilidade, não queria ser como uma diretora de escola a dizer às pessoas o que tinham de fazer. Ninguém quer isso. Somos todos adultos. Também acredito que todas as pessoas envolvidas se preocupam genuinamente com o tema.

Ninguém me disse que não queria trabalhar nisso. Todas as pessoas diziam que queriam que o produto fosse acessível, mas que não sabiam como fazê-lo, não sabiam se teriam autoridade para lhe dar prioridade ou se teriam tempo para o trabalho. Era isso que tentávamos resolver.

Se é gestor de produto de uma funcionalidade e está a tentar tornar o produto acessível, veja se consegue desenvolver uma estrutura ou trabalhar com alguém da organização para a criar. Assim, não terá de esperar constantemente que alguém lhe diga se determinada questão é importante.

Quando estiver a criar algo novo, desenvolvendo um novo produto, garanta que consegue contactar as pessoas com os conhecimentos certos e integre a acessibilidade no processo de design desde o início. Isso evita que surjam problemas mais tarde e que a equipa tenha de correr para os priorizar. Saberá que o produto será acessível desde o lançamento.

Hannah Clark: Isto é muito interessante. Gostaria de falar um pouco mais sobre implementação e iteração, porque uma coisa é analisar as funcionalidades existentes, definir prioridades e implementar melhorias; outra é acompanhar a introdução de novas funcionalidades, a substituição de funcionalidades antigas e as atualizações.

Como integra esse processo de análise? Qual é a abordagem proativa para garantir que as funcionalidades futuras introduzidas no roteiro são acessíveis desde o primeiro dia?

Prerna Ramachandra: Quando está a criar o roteiro, deve analisar todas as funcionalidades, tudo o que está a acontecer e tudo o que está a construir, sabendo que tem de pensar na acessibilidade. Como gestor de produto, deve manter isso presente em todas as decisões.

Também é importante saber quando e quem, na sua base de clientes, pode ajudá-lo a garantir que algo é acessível. Os gestores de produto recorrem muito à investigação com utilizadores para decidir o que construir, mas esquecem frequentemente que existem clientes e pessoas que utilizam o produto de formas que exigem funcionalidades de acessibilidade.

É importante integrá-los desde o início no processo de investigação com utilizadores.

Um exemplo é a integração de utilizadores. Durante a nossa análise inicial na Slack, descobrimos que a experiência de integração tinha falhas de acessibilidade. Queríamos resolvê-las, mas sabíamos também que a equipa de integração estava a preparar uma grande reformulação, porque o produto tinha evoluído desde a primeira versão.

Trabalhámos com essa equipa desde o início para garantir que o fluxo principal de integração que estavam a reformular era acessível. Participámos no planeamento do roteiro desde o princípio. O projeto era grande, por isso era especialmente importante envolver os especialistas certos.

O nosso designer participou em todo o processo de design: na investigação com utilizadores, nos testes com utilizadores e na criação dos designs no Figma. Criou, em paralelo, as especificações de acessibilidade para garantir que tudo era acessível desde o início.

Também percebemos que existia uma oportunidade para criar uma experiência de integração especificamente centrada na acessibilidade para os utilizadores que dela necessitavam.

Um excelente exemplo é a Apple. Os produtos da Apple são muito sólidos em matéria de acessibilidade. Quando compra um novo Mac, pode escolher um fluxo de integração que mostra especificamente onde estão as diferentes funcionalidades de acessibilidade e como utilizá-las.

A nossa equipa de acessibilidade criou uma experiência semelhante. Quando o utilizador entrava no fluxo normal de integração, perguntávamos se a acessibilidade era importante para ele. Se respondesse afirmativamente, era conduzido por um processo passo a passo que mostrava onde estavam as ferramentas, como utilizar a navegação pelo teclado e quais eram os diferentes comandos.

Também utilizámos os dados. Quando uma pessoa indicava interesse na acessibilidade, era encaminhada para o fluxo de integração. Depois, mostrávamos-lhe estrategicamente diferentes dicas dentro do produto, permitindo-lhe continuar essa aprendizagem.

Tudo isto foi possível porque, quando identificámos os problemas do fluxo existente, percebemos que havia uma lacuna enorme: não existia uma experiência de integração dedicada à acessibilidade.

Além disso, falámos com muitos clientes, incluindo clientes que nos enviavam pedidos relacionados com erros de acessibilidade e nos ajudavam a perceber o nível de acessibilidade do produto. Muitos diziam que não havia nada que os ajudasse a perceber como navegar na Slack e que tinham de descobrir tudo sozinhos.

Infelizmente, a maioria das pessoas com necessidades de acessibilidade está habituada a isso, porque muitos produtos não lhes oferecem orientação. Mas, na minha opinião, não é o fluxo ideal.

Quando pensar no futuro e nos produtos que quer criar, recorra bastante à investigação com utilizadores. É necessário falar com os clientes. Nada substitui essa conversa. A inteligência artificial não lhe vai dizer o que deve construir; são as pessoas que utilizam o produto que lhe vão dizer.

Existem hoje empresas e ferramentas que ajudam nesse processo. Se for uma grande empresa e os seus clientes forem outras empresas, é muito provável que tenham um grupo de recursos para colaboradores com deficiência. Esse grupo pode ajudá-lo a avaliar os fornecedores.

Também existem empresas especializadas em testes de acessibilidade com utilizadores com deficiência. Trabalhámos com uma empresa chamada Fable, que recrutava especificamente utilizadores com deficiência para realizar testes. É semelhante ao usertesting.com, mas dedicado à acessibilidade.

Trabalhe com essas entidades e organizações para compreender o que está a construir e como o está a construir. Durante o processo de design e iteração, inclua alguém com conhecimentos de acessibilidade. O designer pode frequentar uma formação sobre design acessível ou pode envolver diretamente uma pessoa especializada.

Garanta que os designs têm especificações de acessibilidade, porque é a elas que os engenheiros vão recorrer para decidir como construir algo. Certifique-se de que os designers e especialistas em acessibilidade participam nos testes. É assim que garante que tudo o que está a construir continuará a ser acessível.

Hannah Clark: Quem ouve o programa há muito tempo sabe que gosto de recomendações prescritivas e muito específicas. Obrigada por partilhar estas sugestões tão concretas. Para concluir, gostaria de falar sobre análise de dados.

Falámos de dados há pouco e quero perceber como medimos o sucesso das funcionalidades de acessibilidade e de todo o trabalho realizado em conjunto. Quando medimos a taxa de ativação ou outras métricas de adoção, podemos estar a analisar um processo diferente para segmentar a eficácia das funcionalidades de acessibilidade.

Como segmenta o que mede para garantir que está a medir o sucesso das funcionalidades de acessibilidade que criou, em vez de medir apenas o produto em geral? Existem ferramentas que utilizaria? Tem outras sugestões para integrar esses dados em iterações futuras?

Prerna Ramachandra: Vou dar uma resposta que provavelmente deixará muitos gestores de produto desconfortáveis. Também é algo que me deixa desconfortável: não pode depender de dados quantitativos para compreender se as funcionalidades de acessibilidade estão a funcionar ou se o produto é acessível.

Moral e eticamente, não pode segmentar verdadeiramente os utilizadores com base na acessibilidade, porque estaria a fazer suposições sobre se alguém tem uma deficiência. Mesmo que utilize dados como o número de pessoas que navegam pelo teclado ou ativaram comandos de leitor de ecrã, isso pode excluir uma grande parte da população.

Por exemplo, no caso da neurodivergência, as pessoas neurodivergentes conseguem utilizar o produto ou sentem-se demasiado sobrecarregadas? Existem funcionalidades específicas relacionadas com isso. Em produtos como a Slack, e em qualquer produto que tenha animações, deve ser possível desativá-las, porque em algumas pessoas podem provocar convulsões. Também é difícil medir esse tipo de situação.

Os dados quantitativos fornecem apenas uma parte da informação. É muito difícil segmentar os utilizadores da forma habitual, porque isso implicaria fazer suposições que normalmente não queremos fazer. Além disso, provavelmente não seria eficaz, porque existem deficiências invisíveis e porque essa abordagem não tem em conta o aspeto situacional de que falei no início.

O que considero mais eficaz para avaliar a acessibilidade é voltar aos utilizadores e perguntar-lhes. Na minha opinião, a investigação qualitativa é a melhor forma de medir o sucesso da acessibilidade.

Dou outro exemplo específico. Na Slack, criámos uma API que várias equipas podiam utilizar para integrar facilmente a navegação pelo teclado nos seus produtos. Muitas equipas não tinham os conhecimentos especializados necessários, pelo que a API facilitava o trabalho.

Nesse caso, medimos o sucesso verificando quantas equipas utilizavam a API. Como a sua utilização não era obrigatória, as equipas poderiam tentar desenvolver a funcionalidade por conta própria. Se utilizavam a nossa API, isso significava que a equipa de acessibilidade tinha criado algo útil e que podia ser integrado pelas outras equipas.

Era menos uma métrica de utilizadores e mais uma métrica interna de equipas. Para medir o sucesso junto dos utilizadores, falávamos com eles. Quando lançámos o fluxo de integração, obtivemos alguns dados quantitativos sobre quantas pessoas optavam pela experiência de integração de acessibilidade. No entanto, trabalhámos sobretudo para reunir grupos de utilizadores com quem pudéssemos conversar sobre acessibilidade.

Incluímos utilizadores que tinham colocado questões sobre acessibilidade ou que utilizavam funcionalidades de acessibilidade. Foi sobretudo uma questão de conversas, medição qualitativa e investigação qualitativa.

Não basta saber se alguém utiliza o produto; é necessário saber se consegue utilizá-lo corretamente para realizar as tarefas que pretende realizar. Se o produto estiver a ter bons resultados com a maioria dos utilizadores, isso fornece uma indicação geral, mas, para falar especificamente com utilizadores sobre acessibilidade, terá de encontrar essas pessoas e realizar investigação qualitativa.

Sei que não é uma resposta ideal, porque os gestores de produto procuram números e dados. Mas parte do trabalho consiste em aceitar esse nível de incerteza. Também é importante reconhecer que nunca se será perfeito.

Nenhum produto conseguirá cumprir perfeitamente todos os critérios de acessibilidade, porque muitos aspetos são situacionais. Por isso, é essencial continuar a conversar com os utilizadores.

As pessoas que se preocupam com a acessibilidade tendem a ser muito vocais, porque não estão habituadas a receber as ferramentas de que precisam para realizar o seu trabalho. Precisam de falar para conseguirem sobreviver e trabalhar corretamente. Existe aí um recurso muito valioso.

Ao longo da minha carreira como gestora de produto, foi quando trabalhei em acessibilidade que compreendi verdadeiramente a importância de falar com os utilizadores e ouvi-los. Eles podem fornecer a melhor informação sobre o desempenho do produto.

Não se fala o suficiente sobre a importância da investigação qualitativa e da ligação humana. Mas acredito que é isso que lhe dirá se o produto funciona. Quando se trata de acessibilidade, é muito importante falar com as pessoas.

Hannah Clark: Concordo completamente. Este é um programa muito defensor da investigação com utilizadores. Há algum tempo, fizemos um episódio com Steve Portigal sobre como entrevistar utilizadores. É um dos nossos episódios favoritos, porque se trata de falar com as pessoas, permitir que descrevam a sua experiência autêntica, não tentar orientar a conversa e eliminar os nossos próprios preconceitos. Isso é muito importante para o processo de desenvolvimento de produtos.

Muito obrigada. Foi uma conversa muito interessante e agradeço imenso a sua perspetiva sobre este tema. Também gostei muito das histórias específicas sobre um produto tão conhecido, porque todos conseguimos compreender como estas funcionalidades ganham vida.

Onde é que as pessoas podem acompanhar o seu trabalho online ou entrar em contacto consigo?

Prerna Ramachandra: Estou no LinkedIn. Basta procurar o meu nome: Prerna Ramachandra. Também pode contactar-me através do meu site: PrernaRamachandra.me.

Hannah Clark: Excelente. Muito obrigada por ter estado connosco.

Prerna Ramachandra: Muito obrigada, Hannah. Foi ótimo.

Hannah Clark: Obrigada por nos ouvir. Para mais informações úteis, guias práticos e análises de ferramentas, subscreva a nossa newsletter em theproductmanager.com/subscribe. Pode ouvir mais conversas como esta subscrevendo o The CPO Club, onde quer que ouça os seus podcasts.