Traduzindo wireframes de design em HTML/CSS acessível

Este artigo foi gentilmente apoiado por nossos queridos amigos do Deque, que nos ajudam a tornar sites e aplicativos móveis acessíveis. Obrigado!

Com muita frequência, a acessibilidade não passa pela cabeça de um designer ao criar interfaces de usuário. Negligenciar as considerações de acessibilidade na fase de design pode chegar ao seu site ou aplicativo e ter um grande impacto em seus usuários. Seja no teste de usabilidade, na criação de protótipos, na adoção de uma biblioteca de padrões acessível ou apenas na anotação de wireframes, os designers devem incorporar a acessibilidade em seu fluxo de trabalho. Em vez de sobrecarregar os engenheiros de controle de qualidade para encontrar defeitos de acessibilidade, pensar na acessibilidade desde o início ou “mudar para a esquerda” pode ter um impacto extremamente positivo no conteúdo que você cria.

Deslocamento à esquerda

Existem muitos estudos que mostram as mudanças no custo de correção de defeitos em diferentes etapas do processo de desenvolvimento. Com base no custo de correção de um defeito na fase de projeto como tendo um fator de 1x, esses estudos mostram diferenças de custo que aumentam para 6x durante a implementação, 15x durante o teste após a confirmação do código e até 100x se detectado após o defeito. em produção. A pesquisa do NIST estima que os custos de correção de defeitos sejam de 10x durante o teste de integração e 15x durante o teste do sistema, mas apenas 30x na produção.[^2] Independentemente dos custos reais da sua organização, uma coisa é certa: detectar defeitos no design e fase de desenvolvimento é muito mais barato do que mais tarde no processo.

Deque reuniu dados de 20 anos de testes de acessibilidade. Com base em nossos dados, uma tendência que vimos nos últimos cinco anos, à medida que os aplicativos da Web aumentaram em complexidade, é que o número de defeitos por página tem aumentado constantemente para entre 30 e 50 defeitos por página. Esses números de defeitos geralmente superam quaisquer taxas de defeitos funcionais e amplificam o valor em mudar o teste de acessibilidade e corrigir o mais à esquerda possível no processo.

Cerca de 70% dos defeitos de acessibilidade podem ser evitados por meio da combinação apropriada de testes automatizados e guiados durante o processo de design e desenvolvimento.

“

Este artigo tem como objetivo fornecer uma visão geral de como isso pode ser alcançado.

A fase de projeto

Anotações

As anotações são explicações textuais ou gráficas adicionadas a um design para informar a intenção do implementador. Semelhante a um designer anotando coisas como cor e tamanho da fonte, as informações de acessibilidade também devem ser transmitidas nos designs. Vamos mergulhar em um widget simples de reprodutor de áudio e avaliar quais tipos de anotações precisaremos.

Nosso reprodutor de áudio consistirá em três controles:

1. Um controle para ir para a faixa anterior (quando aplicável)
2. Um controle para reproduzir e pausar a faixa de áudio atualmente em reprodução
3. Um controle para ir para a próxima faixa (quando aplicável)

Nome, Função e Estado

O nome acessível de um componente ditará o que um usuário de tecnologia assistiva será informado ao interagir com ele. É muito importante anotar cada um de nossos controles de reprodutor de áudio porque, visualmente, eles são representados apenas com iconografia e sem conteúdo textual. Isso significa que anotaremos os 3 controles com nomes acessíveis de “Faixa anterior”, “Pausa” e “Próxima faixa”.

Em seguida, queremos pensar no propósito de cada um desses 3 controles. Como são elementos clicáveis ​​que executam ações do player de áudio, a escolha óbvia de função aqui é “botão”. Isso não é algo que deve ser assumido por meio do design, mas sim algo que os designers devem anotar para garantir que os implementadores adicionem essas informações semânticas aos controles. Ter as funções mapeadas desde o início evitará que você precise voltar e adicioná-las aos controles após a implementação já ter ocorrido.

Por fim, assim como os designers mapeiam como um controle aparece ao passar o mouse, eles devem estar pensando nos vários estados de seu widget em termos de acessibilidade. No caso do nosso reprodutor de áudio, temos alguns estados para anotar para o implementador. Começando pelo botão “Faixa anterior”, sabemos que ele deve ser desabilitado quando não houver nenhuma faixa anterior para tocar. O botão reproduzir/pausar deve alternar o player de áudio entre os estados de reprodução e pausa. Isso significa que precisamos anotar que o nome acessível precisa corresponder a esse estado. O nome acessível do botão deve ser “Pausar” quando o áudio estiver sendo reproduzido e “Reproduzir” quando o áudio estiver pausado. Para o botão “Próxima faixa”, devemos anotar o fato de que ele deve ser desabilitado quando não houver próxima faixa. Por fim, os estados de foco e foco para cada um dos botões devem ser anotados para que os usuários do teclado tenham alguma indicação visual do controle atualmente em foco no reprodutor de áudio.

Interação para todo o componente

Quando na primeira faixa: desative o botão “faixa anterior”

Quando na última faixa: desative o botão “próxima faixa”

Ao jogar, exiba o botão “pause” e oculte o botão “play”

Quando não estiver jogando: exiba o botão “play” e oculte o botão “pause”

Após clicar em “play”, coloque o foco no botão “pause”

Depois de clicar em "pausar", coloque o foco no botão "reproduzir"

Testando usabilidade

O teste de usabilidade, uma metodologia de pesquisa de UX em que um pesquisador faz um usuário realizar uma série de tarefas e analisa seu comportamento, é uma etapa muito importante na fase de design. As informações coletadas dos testes de usabilidade são vitais para moldar as experiências digitais do usuário. Realizar esse teste com usuários com deficiência é extremamente importante, pois permite que sua equipe tenha uma ideia da facilidade com que esses usuários poderão interagir com o conteúdo que estão criando. Se você estiver fazendo testes de usabilidade em um sistema existente, poderá obter um cenário muito realista configurado para o participante, o que é ótimo quando se trata de usuários que dependem de várias tecnologias assistivas.

Se você estiver fazendo testes de usabilidade em um sistema inexistente, esteja preparado para lidar com os desafios de acessibilidade em torno da saída do software de design. Os protótipos interativos gerados por essas ferramentas geralmente são extremamente diferentes do que o produto final será em um navegador ou em uma plataforma de sistema operacional. Além disso, esses “protótipos funcionais” geralmente são extremamente inacessíveis. Se possível, encontre uma alternativa próxima na natureza que você possa usar no lugar do seu protótipo, o que pode lhe dar uma boa ideia de como seus participantes irão interagir com seu sistema. Por exemplo, se você estiver criando um novo componente de navegação móvel, encontre um existente na Internet e faça testes de usabilidade com ele. Determine o que funcionou nesta alternativa e saiba o que precisa ser melhorado. De qualquer forma, esteja sempre preparado para fazer adaptações para os participantes do teste de usabilidade com base em suas deficiências. Garantir que os testes ocorram sem problemas, não apenas deixará seus participantes felizes, mas também permitirá que você realize mais testes em menos tempo.

Bibliotecas de padrões

As bibliotecas de padrões são coleções de componentes da interface do usuário e são extremamente benéficas nas fases de design e desenvolvimento. Ter um conjunto suficiente de componentes de interface do usuário ao seu alcance facilita muito a criação de aplicativos totalmente funcionais. Para o designer, esses componentes ajudam a manter uma boa consistência em seu aplicativo, o que melhora a experiência geral dos usuários. Para o desenvolvedor, ter componentes totalmente testados, acessíveis e reutilizáveis ​​ajuda a produzir conteúdo de alta qualidade rapidamente. Esses componentes devem ser tratados com cuidado especial em termos de acessibilidade, pois presumivelmente serão usados ​​várias vezes por meio de seu(s) aplicativo(s).

Trabalhe com os desenvolvedores

Falando com colegas desenvolvedores e designers em conferências e encontros, frequentemente ouço falar de equipes divididas em que designers e desenvolvedores trabalham em completo isolamento um do outro. Não apenas os desenvolvedores devem ser incluídos na fase de design em reuniões de revisão de design, mas os designers também devem ser incluídos na fase de desenvolvimento.

A colaboração é fundamental quando se trata de criar conteúdo acessível incrível.

“

Muitas vezes, os desenvolvedores estão a par de detalhes de implementação que podem ajudar a moldar composições de design ou até mesmo dinamizar uma abordagem para resolver um problema de design. Da mesma forma, os designers podem ajudar a manter os desenvolvedores sob controle quando se trata de implementar seus projetos de forma acessível, porque aspectos orientados a detalhes, como espaçamento e uso de cores específicas, podem ter um enorme impacto na acessibilidade. Enquanto os desenvolvedores implementam um design, os designers devem prestar muita atenção a coisas como indicação de foco, ordem de tabulação, ordem de leitura, fontes, cores e até nomes acessíveis e textos alternativos de imagens. Afinal, de que servem todas essas incríveis anotações específicas de acessibilidade se o desenvolvedor as ignorar?

A Fase de Desenvolvimento

Automatize o teste de acessibilidade

Nós, desenvolvedores, adoramos a ideia de que certas coisas em nossos fluxos de trabalho podem ser completamente automatizadas. Felizmente, existem muitas bibliotecas incríveis de automação de acessibilidade disponíveis, que sua equipe deve aproveitar para ajudar na criação de interfaces acessíveis sustentáveis. Ferramentas de análise estática, como eslint-plugin-jsx-a11y, podem fornecer feedback imediato aos desenvolvedores, alertando-os sobre possíveis problemas de acessibilidade enquanto estão codificando. Os desenvolvedores podem até configurar seu editor de texto para exibir esses avisos à medida que digitam o código, capturando esses defeitos ao vivo à medida que aparecem.

Os mecanismos de regras de acessibilidade, como o axe-core, podem ser integrados a praticamente qualquer estrutura ou ambiente e podem ajudar a detectar muitos problemas de acessibilidade extremamente comuns. Uma ótima maneira de garantir que toda a sua equipe esteja criando conteúdo acessível é integrar esses tipos de ferramentas em seus pipelines de CI (integração contínua) e CD (entrega contínua). Escrever casos de teste específicos de acessibilidade (unidade ou ponta a ponta) é outra ótima forma de automação. Na minha equipe, temos todos os itens acima configurados para que nenhuma solicitação pull possa ser mesclada até que todos os nossos testes de automação de acessibilidade sejam aprovados. Isso significa que podemos garantir defeitos mínimos de acessibilidade até mesmo para nossos servidores de desenvolvimento e definitivamente não entraremos em produção.

Gerenciar defeitos de acessibilidade sistematicamente

Os problemas de acessibilidade não devem ser tratados de forma diferente dos defeitos de segurança ou funcionalidade. Eles devem ser triados e priorizados regularmente com o restante da carga de trabalho “normal”. Medir o progresso e coletar métricas específicas para defeitos de acessibilidade também podem ser úteis, especialmente se sua equipe está apenas começando a aumentar a acessibilidade. Isso também pode ajudar a identificar os pontos fracos ou gargalos do seu sistema. Se sua equipe participa de retrospectivas de sprint (ou algo semelhante), a acessibilidade deve ser um ponto de discussão. Refletir sobre o que funciona e o que não funciona é um exercício saudável e pode levar a melhorias na abordagem geral de sua equipe em relação à acessibilidade sustentável.

Esta ferramenta Beta legal do machado

Já falamos sobre automação de acessibilidade, que é um ótimo ponto de partida para testes. No entanto, inevitavelmente, um humano deve continuar de onde os robôs param para obter cobertura total de testes de acessibilidade. O teste manual requer uma compreensão profunda de acessibilidade, bem como as Diretrizes de acessibilidade de conteúdo da Web do W3C, ou “WCAG”. O aplicativo axe Beta ajuda você a passar por este teste manual sem precisar ser um especialista em acessibilidade. Ele tem um grande conjunto de testes guiados inteligentes, que fazem perguntas extremamente simples e fazem todo o trabalho pesado para você!

Dado que sempre nos esforçamos para automatizar tudo, pode-se reagir com ceticismo à afirmação de que o teste de acessibilidade não pode ser totalmente automatizado e requer um cérebro humano para cobrir todas as bases. No entanto, vamos usar imagens como exemplo e quais informações, se houver, elas fornecem no contexto de uma página da web. Uma biblioteca de automação de acessibilidade não pode derivar intenção informativa digitalizando ou processando uma imagem. Mesmo se alimentarmos um algoritmo de aprendizado de máquina com uma imagem e ele puder fornecer uma descrição perfeita do que está nessa imagem, ele não saberá o que essa imagem transmite no contexto da página. A informação que uma determinada imagem transmite, ou se essa imagem é usada apenas como decoração, é de total responsabilidade do autor do conteúdo.

Amarrando tudo junto

Ter a acessibilidade em mente desde o início do desenvolvimento torna a criação de conteúdo acessível muito mais fácil do que fazer essas considerações no final do ciclo de vida do desenvolvimento de software. Incorporar a acessibilidade na idealização, design e implementação do seu software cria um produto mais sustentável.

Prepare sua equipe para o sucesso utilizando recursos como WCAG, ARIA, ARIA Authoring Practices e Stack Overflow. Evite que os defeitos de acessibilidade cheguem ao seu software aproveitando as bibliotecas de automação de acessibilidade e integrando-as em seus servidores de integração contínua. Nossa equipe trabalhou duro para preencher a lacuna entre testes automatizados e manuais, adoraríamos que você experimentasse o axe Beta! Se os defeitos de acessibilidade forem tratados sistematicamente, você não apenas poderá livrar seus aplicativos desses problemas, mas também impedir que eles encontrem seu caminho de volta no futuro.

Você quer se juntar a mim em um workshop gratuito sobre esse tópico exato? Inscreva-se para o nosso próximo Workshop Virtual Traduzindo Design de Wireframes, que será dividido em duas sessões de 3 horas.