Explorando o compromisso da Rocket Software com a acessibilidade.

Na Rocket Software, nossa missão vai além de simplesmente oferecer soluções inovadoras. Cada aspecto do nosso trabalho é guiado por nossos valores fundamentais: Empatia, Humanidade, Confiança e Amor. E, dentro desses valores, a Rocket Software dá grande ênfase à acessibilidade. Independentemente da tecnologia, do sistema ou do ambiente de TI, estamos comprometidos em fornecer soluções que funcionem para todos.

Para saber um pouco mais sobre como abordamos nossas soluções do ponto de vista da acessibilidade, conversamos com Brian Kunz, arquiteto de software principal da Rocket Software.

Brian possui mais de 20 anos de experiência na criação e no design de aplicações front-end. Ele se envolveu completamente com acessibilidade em 2024, liderando o esforço para construir os componentes fundamentais de acessibilidade necessários para a nova interface de usuário do Rocket Content Services, o Rocket Content Explorer.

Como você definiria acessibilidade do ponto de vista de software e desenvolvimento?

Do ponto de vista do software, tudo se resume a fazer o teclado funcionar com o aplicativo. A interface do teclado é o motor de qualquer tecnologia assistiva, como leitores de tela. Se algo precisa ser manipulado na tela, precisa ser possível manipulá-lo por meio de uma série de comandos de teclado; esses comandos de teclado são comuns e conhecidos pelos usuários finais. Como usuário final, eu deveria ser capaz de fazer tudo em um aplicativo sem nunca tocar no mouse.

Nos concentramos demais em criar aplicativos que dependem do mouse — essa é a mentalidade que precisa mudar.

Do ponto de vista do desenvolvimento, acessibilidade é uma habilidade, e é uma habilidade que a maioria dos desenvolvedores não possui. Isso era verdade para mim, e era verdade para todos os desenvolvedores que trabalharam em nosso novo projeto de interface do usuário.

As práticas ágeis provavelmente são um fator chave para explicar por que a acessibilidade não recebe mais atenção. Historicamente, os desenvolvedores se concentram na aparência do aplicativo e se o mouse funciona ao clicar; esse tem sido o limite para considerar uma funcionalidade concluída. E, uma vez que essa funcionalidade é finalizada, passa-se para a próxima, porque o objetivo é adicionar o máximo de funcionalidades possível.

Assim, a acessibilidade acaba sendo prejudicada pela falta de tempo em prol da "implementação imediata de uma funcionalidade". Não é que os desenvolvedores não queiram criar aplicativos acessíveis, mas negligenciamos a importância de programar pensando na acessibilidade, pois isso exige tempo adicional. O foco da gestão também é um fator, já que programar para acessibilidade requer um pouco mais de tempo e esforço de todos os envolvidos.

A acessibilidade pode ser vista como uma habilidade secundária, pouco discutida ou promovida, mas é isso que gostaríamos de mudar. Queremos que a acessibilidade seja uma parte natural de qualquer projeto.

Em termos simples, você pode explicar os quatro princípios das Diretrizes de Acessibilidade para Conteúdo Web (WCAG) e compartilhar por que eles são importantes?

Existe um acrônimo para isso: POUR. Ele significa Perceptível, Operável, Compreensível e Robusto.

Vamos começar com o perceptível. Trata-se de criar um aplicativo complexo que seja visualmente atraente e com um design primoroso, de forma que as relações entre os elementos visuais na tela possam ser comunicadas a quem não enxerga. Por exemplo, como um usuário sabe que existe um botão que, ao ser pressionado, exibe um novo painel de informações ao qual ele pode acessar? Ou, quando uma operação ocorre e a tela muda, mesmo que sutilmente, como essa mudança é comunicada ao usuário de uma forma que não seja visual? O perceptível consiste em pintar uma imagem na mente do usuário sobre onde ele está dentro do aplicativo e como ele está estruturado.

Quando falamos em "operável", isso significa que qualquer elemento que possa ser manipulado deve ser acessível pelo teclado. Reconhecemos que as tecnologias assistivas também incluem opções como reconhecimento de voz para usuários com deficiências motoras, já que o teclado pode não ser uma opção viável. "Operável" significa que tudo que pode ser manipulado, como um botão, uma caixa de listagem, uma entrada de texto e assim por diante, deve ser operável pelo teclado ou por comando de voz. Isso cria desafios únicos para ações tradicionalmente realizadas com o mouse, como arrastar e redimensionar. Ao programar para acessibilidade, devemos avaliar o mouse não como o principal meio de alteração, mas apenas como mais uma ferramenta. Não queremos excluir funcionalidades como clicar e arrastar simplesmente porque um usuário não consegue usar um mouse.

O próximo passo é a compreensão. Garantir que algo seja compreensível significa assegurar que qualquer widget funcione como o usuário espera. Tecnologias assistivas identificam itens na tela e exibem mensagens como "botão" ou "tabela" quando o usuário navega. Esse tipo de descrição básica transmite ao usuário como ele pode manipular o elemento, bem como utilizar os atalhos de teclado comuns fornecidos pela tecnologia assistiva. Por exemplo, se um usuário sabe que o elemento em foco é uma caixa de combinação, ele sabe que pode ativá-la pressionando a tecla Enter ou a seta para baixo, etc. Como desenvolvedores, precisamos garantir que as atividades e a ordem das atividades para um determinado item correspondam à experiência esperada de um usuário que utiliza tecnologias assistivas — caso contrário, criamos um cenário confuso para o usuário e uma tecnologia que não pode ser usada de forma eficaz.

Finalmente, chegamos à robustez. Existem convenções e atributos de codificação que os desenvolvedores devem utilizar para garantir que nosso software funcione com quaisquer tecnologias assistivas. Os padrões WCAG são o contrato que nós, como desenvolvedores, seguimos em nossa programação e que também é utilizado pelos desenvolvedores das tecnologias assistivas. Contanto que ambos os grupos de desenvolvimento façam suas partes, teremos uma experiência funcional e acessível para nossos usuários finais. Programamos de acordo com um padrão, não para uma tecnologia assistiva específica.

Robustez refere-se ao desenvolvimento de software que funcione com diversos outros agentes de usuário e tecnologias assistivas. Outro aspecto da robustez é a capacidade do usuário de navegar rapidamente pelo aplicativo com apenas algumas teclas. Se os desenvolvedores projetaram um aplicativo corretamente, ele permite que o usuário navegue rapidamente entre os locais da tela usando o teclado, sem precisar usar a tecla Tab para percorrer todos os controles ou itens da tela.

Para pessoas daltônicas, como garantir que as diretrizes de contraste de cores sejam atendidas no design de um site ou aplicativo e que tipos de ferramentas podem ser utilizadas?

Existe uma proporção recomendada pelas WCAG para cores de primeiro plano e de fundo; essa proporção é de 4,5 para 1. É um pouco difícil descrever exatamente o que isso significa, mas refere-se às tonalidades de cor entre o primeiro plano e o fundo na aplicação.

Então, como determinamos isso? Tudo começa nos primórdios do design. Usamos uma ferramenta chamada Figma para criar wireframes detalhados para o aplicativo. Essa ferramenta nos ajuda a garantir que o design em si não viole a taxa de contraste de cores. Queremos evitar criar algo que consideramos bonito e investir tempo e recursos nisso, apenas para perceber que não passará nos testes de contraste de cores.

Existe também uma ferramenta que usamos no navegador chamada Accessibility Insights; trata-se de um plugin que você pode ativar em qualquer página e que informa se há violações da proporção que mencionei anteriormente. A ferramenta também pode renderizar o aplicativo em tons de cinza, o que é uma ótima maneira de analisar o que foi desenvolvido, permitindo eliminar completamente a influência das cores e observar como o aplicativo se apresenta com contraste em tons de cinza, além de avaliar a facilidade de distinguir os itens.

Quais estratégias você utilizou para educar e promover as melhores práticas de acessibilidade entre as equipes de desenvolvimento e design?

Então, pode ser que você se assuste ao olhar para a especificação WCAG. É extensa. É muito técnica e parece difícil de assimilar. Mas, uma vez superado o impacto inicial, tudo fica muito simples quando você entende. Foi algo que aconteceu comigo durante minha jornada. Eu sabia que precisava fazer isso e que era a coisa certa a fazer.

Descobri que, uma vez que essa compreensão se tornou clara, passei a ter um novo entusiasmo pela acessibilidade. Programar dessa forma torna nossos aplicativos muito mais robustos e, no fim das contas, não é tão complexo assim... e você começa a se perguntar por que evitou essas estratégias de programação até agora.

Meu objetivo é fazer com que a programação com acessibilidade se torne algo natural para os desenvolvedores front-end, para que não seja vista como algo extra, difícil ou que não valha o esforço. Ajudei nossa equipe de desenvolvimento fornecendo esquemas básicos de design visual sobre como considerar a acessibilidade. Como especialista na equipe, pude dizer: "Ao criar esta tela, considerem estes aspectos e outros itens de acessibilidade". Eles aplicaram essas práticas ao desenvolver a programação e, em seguida, avaliamos o código durante nosso processo padrão de revisão. Sempre havia algum ajuste necessário, pois era algo novo para todos; estávamos desenvolvendo novas habilidades e todos estavam aprendendo. Então, testamos e aprimoramos o código até obtermos a experiência desejada.

Com base nessa experiência, criei uma série de vídeos de treinamento progressivo disponíveis para qualquer membro da equipe Rocketeer que esteja trabalhando na incorporação de acessibilidade. Gere quase 5 horas de conteúdo — não será algo que tomará muito do seu tempo. Esses vídeos fornecem uma introdução para a compreensão dos conceitos básicos e ensinam como colocá-los em prática com um pequeno exemplo de aplicação.

Meu objetivo é eliminar o medo da adoção dos padrões WCAG, mostrando que é bastante simples. Além disso, nossas equipes desenvolveram uma biblioteca de widgets de interface do usuário que já gerenciam a maioria dos aspectos de acessibilidade. Isso ajudará outras equipes a criar produtos melhores no futuro, utilizando esses widgets. Dessa forma, as outras equipes não precisarão se preocupar com a acessibilidade dentro do widget, pois ela já estará gerenciada.

Você tem alguma dica ou truque para compartilhar com desenvolvedores ou equipes que estão começando sua jornada rumo à acessibilidade?

Minha dica é usar o HTML5 da maneira como ele foi concebido. Você já ganha muita acessibilidade gratuitamente só por fazer isso. Depois, observe os elementos básicos ao programar para um design visual.

Se algo representa uma lista de conteúdo, use os elementos de lista do HTML5. Se algo se comporta como um botão, use um botão. Se você estiver apresentando dados tabulares, use os elementos de tabela, pois as tecnologias assistivas fornecerão informações semânticas aos seus usuários se você usar esses elementos básicos. Como desenvolvedores, tendemos a usar contêineres genéricos estilizados para se parecerem com algo específico e, em seguida, aplicar manualmente manipuladores de cliques a eles. Esse é o caminho de menor resistência e cria algo visualmente agradável e clicável com o mouse, mas sem significado para pessoas que usam tecnologias assistivas. Utilizar os elementos básicos do HTML5 lhe dará metade do que você precisa (no mínimo).

Em termos de recursos técnicos, existe uma página de padrões. Foi esse recurso que realmente fez tudo fazer sentido para mim. Essa página tem uma especificação para cada tipo de widget que você possa imaginar; ela contém exemplos, amostras de código, especificações de teclado para vários elementos, etc. Você pode até usar uma tecnologia assistiva como o JAWS para testar os widgets de exemplo e ver como o JAWS lida com as situações. Foi uma maneira maravilhosa de eu entender, quando comecei a aprender, que programar para acessibilidade não é tão difícil; eu só precisei mudar algumas coisas durante a programação.

Qual a coisa mais interessante que você aprendeu enquanto trabalhava em um projeto focado em acessibilidade?

A resposta mais simples é que consigo ver o valor fundamental da Rocket Software, a empatia, em tudo o que fazemos. Queremos que nosso software seja acessível a todos. Como mencionei anteriormente, em nosso ambiente de desenvolvimento ágil, focamos no caminho mais rápido para concluir uma funcionalidade, o que resulta em aplicativos que podem excluir certos usuários. Isso não é intencional e não há má intenção, mas podemos facilmente ignorar pessoas com deficiência e não considerar suas experiências e as dificuldades que podem enfrentar ao usar nosso software.

Precisamos mudar nossa mentalidade em relação a tudo que leva o nome da Rocket Software. Trata-se de estarmos atentos às diversas necessidades de nossos usuários e não criarmos ferramentas excludentes, mesmo que isso signifique um pouco mais de tempo para codificar e testar. É por isso que quero que as estratégias de codificação acessível sejam algo natural para nossos desenvolvedores, para que eles nem pensem "Estou fazendo isso por acessibilidade" – em vez disso, que seja uma parte fundamental da codificação de qualquer projeto.

O futuro me empolga. Há um grande potencial com as novas funcionalidades que introduzimos. Agora estou explorando como podemos usar algo como o Rocket^® Content Smart Chat para preencher lacunas na interação com o conteúdo em um aplicativo — e não apenas com o próprio aplicativo. Por exemplo, se apresentarmos um documento de imagem a um usuário, o Rocket^® Content Smart Chat poderia fornecer um resumo da imagem e informar o usuário, dizendo "Esta é uma imagem de XYZ", ou fornecer um resumo de um documento, como "Este documento é um comprovante de pagamento de materiais comprados"? Recursos como esses poderiam economizar tempo. Os usuários não precisariam ler o documento inteiro para perceber que não era o que estavam procurando.

Em vez disso, eles recebem esse resumo rapidamente e podem prosseguir para a próxima tarefa. Acredito que podemos fazer ainda mais utilizando tecnologias de ponta para tornar nossa experiência de acessibilidade ainda melhor.

É empolgante para mim e sinto muito orgulho de estarmos na vanguarda desse tipo de iniciativa internamente. Proporcionar essa experiência WCAG aos usuários é revolucionário.

Saiba mais sobre os novos recursos do Rocket Content Services .