Pode fazer auditorias, pode corrigir problemas, pode até cumprir os requisitos de acessibilidade. Mas será que isso significa que a sua empresa está preparada para gerir a acessibilidade?
Vamos imaginar uma situação.
A sua empresa está prestes a lançar uma nova versão de uma aplicação. O desenvolvimento terminou, o QA terminou e o lançamento está marcado. E alguém pergunta: “Então, qual é o estado da acessibilidade desta aplicação?”
Quem responde? É uma pergunta simples, mas será que temos uma resposta igualmente simples?
Talvez saiba que foi feita uma auditoria, talvez exista uma lista de problemas por resolver, talvez até exista alguém responsável por acompanhar estas questões. Mas consegue responder também:
- Quem é responsável pela acessibilidade?
- Em que momento é avaliada?
- Que critérios são usados?
- O que acontece depois de uma auditoria?
- E, sobretudo, o que estamos a fazer para evitar que os mesmos problemas apareçam outra vez?
Se começou a pensar “depende”, “acho que...” ou simplesmente “não sei”, vale a pena continuar a ler. Porque pode estar a corrigir problemas de acessibilidade sem estar, de facto, a gerir a acessibilidade.
Uma auditoria diz-nos onde estamos. E depois?
Quando falamos de acessibilidade, é muito fácil pensar em problemas.
Um botão sem nome acessível, um contraste insuficiente, uma ordem de foco errada ou um formulário que não comunica corretamente os erros. Encontramos os problemas, corrigimo-los e fechamos as tarefas. E sim, é preciso fazer isto. Mas, e depois?
Os produtos digitais não ficam parados depois de uma auditoria. Novas funcionalidades aparecem, componentes são alterados, o design muda, as equipas mudam e o produto cresce.
Por isso, uma auditoria pode dizer-nos bastante sobre o estado de um produto naquele momento. Mas há outra pergunta que precisamos de fazer “O que acontece à acessibilidade quando o produto continua a mudar?”.
É aqui que a conversa começa a ficar interessante.
Esta não é apenas uma questão nossa. O próprio W3C aborda a acessibilidade também a partir de uma perspetiva organizacional, através do seu Accessibility Maturity Model. O modelo procura ajudar as organizações a perceber as suas capacidades atuais, identificar lacunas e definir áreas de melhoria para integrar a acessibilidade de forma mais consistente.
Ou seja, podemos perguntar “Temos problemas de acessibilidade?”, mas a grande questão é perceber se temos capacidade para identificar, prevenir e gerir estes problemas de acessibilidade de forma consistente. E isto são duas coisas bastante diferentes.
Então, onde está a sua empresa?
O modelo do W3C é bastante mais completo do que aquilo que vamos ver aqui. Por isso, não vou tentar transformá-lo numa versão simplificada.
Vamos usar quatro níveis para nos ajudar a pensar sobre onde uma organização pode estar neste momento.
Nível 1: Reativa
“Corrigimos quando aparece.”
Alguém encontra um problema. Uma auditoria, uma reclamação, um cliente ou um problema descoberto antes do lançamento.
A equipa corrige e segue para o próximo assunto. Funciona? Sim. É suficiente? Provavelmente não, porque fica uma pergunta: O que mudou exatamente para que o problema não volte a acontecer?
Nível 2: Pontual
“Fazemos auditorias.”
Nesta fase já existe uma preocupação maior. A organização avalia os seus produtos, identifica problemas e cria planos de correção. Mas, muitas vezes, a acessibilidade continua a aparecer em momentos específicos: quando auditamos, corrigimos ou entregamos.
E depois? O W3C recomenda que a acessibilidade seja integrada nos processos existentes e avaliada cedo e regularmente durante o desenvolvimento.
A diferença parece pequena, mas, na prática, pode ser enorme.
Nível 3: Integrada
“Faz parte do nosso processo.”
Por sua vez, neste nível começamos a mudar a forma como trabalhamos. A acessibilidade não fica à espera da auditoria.
O designer considera-a, o developer sabe o que precisa de garantir, o QA inclui-a nos seus testes e os componentes reutilizáveis também são avaliados.
E, principalmente, começa a acontecer uma coisa importante: tentamos evitar que o problema seja criado em primeiro lugar. Não significa que deixámos de ter problemas, significa que começámos a lidar com eles mais cedo.
Nível 4: Estratégica
“Sabemos onde estamos e para onde vamos.”
Por fim, nesta etapa já não estamos apenas a falar de desenvolvimento, estamos a falar de gestão.
Conseguimos responder:
- Que produtos estão a ser avaliados?
- Onde estão os principais riscos?
- O que é prioritário?
- Quem é responsável?
- Que objetivos temos?
- Como estamos a evoluir?
- Como sabemos que uma nova funcionalidade não está a introduzir novos problemas?
O W3C recomenda, entre outras práticas, definir responsabilidades, estabelecer objetivos e acompanhar o progresso. E é aqui que, para mim, está a grande diferença: a acessibilidade deixa de ser apenas uma preocupação técnica e passa a fazer parte da gestão do produto.
E o que custa ficar parado?
Há uma coisa que às vezes esquecemos: o custo da acessibilidade nem sempre aparece numa fatura.
Pode aparecer em retrabalho, em atrasos, num componente que precisa de ser reconstruído, num design que tem de ser alterado ou numa equipa que corrige o mesmo tipo de problema várias vezes.
Vamos imaginar duas equipas. A primeira encontra um problema de acessibilidade quando o produto já está desenvolvido. A segunda encontra o mesmo problema quando o componente ainda está a ser desenhado. O problema é o mesmo, mas o custo de lidar com ele pode não ser.
É por isso que o W3C recomenda integrar a avaliação da acessibilidade ao longo do design e desenvolvimento e destaca a importância de identificar problemas cedo, reduzindo risco e custo. Quanto mais tarde descobrimos um problema, mais coisas podem já ter sido construídas à volta dele.
Por isso, maturidade não significa que temos menos problemas, significa que conseguimos lidar com os problemas antes que eles se tornem maiores.
O teste dos 60 segundos
Sugiro fazer uma coisa diferente.
Não consulte a sua equipa, não procure documentação, não abra uma ferramenta. Responda simplesmente com o que sabe agora.
Tem 60 segundos. Para cada pergunta, responda: Sim / Não / Não sei
- Existe uma pessoa ou equipa claramente responsável pela acessibilidade?
- A acessibilidade é considerada durante o design e não apenas depois do desenvolvimento?
- Existem critérios de acessibilidade incorporados no desenvolvimento?
- O QA testa acessibilidade como parte do processo normal de qualidade?
- Os componentes reutilizáveis e design systems são avaliados quanto à acessibilidade?
- Existe acompanhamento dos problemas depois de uma auditoria ou lançamento?
- A organização tem objetivos claros para melhorar a acessibilidade?
E então?
Conte os seus “sim”.
0–2: A acessibilidade tende a ser gerida de forma reativa.
3–4: Existem algumas práticas, mas podem ainda depender de iniciativas pontuais.
5–6: A acessibilidade está provavelmente integrada em várias partes do processo.
7: Existem sinais de uma abordagem mais estratégica e estruturada.
Nota: Este resultado não é uma certificação nem substitui uma avaliação de acessibilidade. É apenas um exercício rápido para perceber onde a sua organização pode estar hoje.
Mas há uma coisa que quero que repare. Quantas vezes respondeu “não sei”?
Porque um “não” mostra uma lacuna. Mas um “não sei” pode mostrar que não existe informação, responsabilidade ou comunicação suficientemente clara. E isso também é um problema.
Agora faça o teste com a sua equipa
É aqui que o teste fica realmente interessante.
Pegue nas mesmas sete perguntas e envie-as a pessoas de: Produto · Design · Desenvolvimento · QA
Mas não lhes dê as respostas, nem explique demasiado o objetivo. Peça-lhes apenas que respondam e, depois, comparem as respostas.
Imagine isto:
Produto diz que existe uma pessoa responsável.
Desenvolvimento não sabe quem é.
QA diz que acessibilidade não faz parte dos testes.
Design diz que segue requisitos, mas não sabe exatamente quais.
A pontuação pode até parecer razoável. Mas as respostas contam uma história completamente diferente.
O W3C recomenda que as responsabilidades pela acessibilidade sejam claramente definidas e distribuídas pelas diferentes funções envolvidas.
Por isso, não procurem apenas uma pontuação alta. Procurem respostas diferentes.
É aí que podem estar algumas das maiores lacunas da vossa abordagem.
E agora?
Encontrou alguns “não”? Encontrou muitos “não sei”? Não tente resolver tudo amanhã. Escolha um.
Talvez seja uma responsabilidade que ninguém assumiu, talvez seja um momento do processo onde a acessibilidade simplesmente não existe, talvez seja um critério que devia fazer parte do QA, talvez seja um problema que continua a aparecer em diferentes projetos.
Pergunte: “O que precisamos de mudar para que isto deixe de depender de esforço individual?”
Pode ser uma responsabilidade, um critério de aceitação, um passo no processo de QA, uma regra para componentes, uma forma de acompanhar problemas ou simplesmente um objetivo.
Não precisa de transformar tudo de uma vez, mas sim de saber qual é o próximo passo.
A acessibilidade não fica “resolvida”
E aqui está outra armadilha fácil de cair: achar que a acessibilidade fica “resolvida”. Não fica.
O produto muda, as funcionalidades mudam, os componentes mudam, as equipas mudam e, com eles, podem aparecer novos problemas. Por isso, o objetivo passa por criar uma organização capaz de acompanhar a acessibilidade de forma contínua. A ideia de chegar a um momento em que podemos dizer “Pronto. A acessibilidade está tratada.” dá lugar a uma abordagem contínua, que seja capaz de detetar, corrigir, prevenir, acompanhar e melhorar.
O W3C recomenda integrar as atividades de acessibilidade nos processos da organização e acompanhá-las ao longo do tempo, tendo em conta a evolução dos produtos e das próprias práticas.
Estar preparado significa saber o que fazer quando eles aparecem.
Então, está preparado?
Voltemos à pergunta do início: “Qual é o estado de acessibilidade dos seus produtos digitais?”
Talvez agora a resposta já não seja apenas “Fizemos uma auditoria.”, ou “Temos alguns problemas para corrigir.”
Uma organização preparada consegue responder a algo mais: “Sabemos onde estamos, quais são os nossos riscos, quem é responsável e qual é o próximo passo.”
E essa diferença importa.
Porque uma organização preparada para a acessibilidade não é aquela que nunca encontra problemas, mas a que sabe como os encontrar, quem os deve resolver e como evitar que voltem a acontecer.
Por isso, faça o teste. Depois faça-o com a sua equipa. E quando compararem as respostas, não procurem a pontuação mais alta. Procurem as respostas diferentes. É aí que pode estar a próxima melhoria da vossa organização.