Acessibilidade para equipes

Como incorporar a acessibilidade ao processo da sua equipe.

Rob Dodson

Tornar seu site mais acessível pode ser uma tarefa assustadora. Se você está se aproximando da acessibilidade pela primeira vez, a amplitude do tópico pode fazer você se perguntar por onde começar. Afinal, trabalhar para acomodar uma variedade de habilidades significa que há uma variedade correspondente de problemas a serem considerados.

Lembre-se de que a acessibilidade é um esforço coletivo. Cada pessoa tem um papel a desempenhar. Este artigo descreve os critérios para cada uma das principais disciplinas (gerente de projeto, designer de UX e desenvolvedor) para que elas possam incorporar as práticas recomendadas de acessibilidade ao processo.

Gerente de projeto

Um objetivo primordial para qualquer gerente de projeto é tentar incluir o trabalho de acessibilidade em cada etapa, garantindo que ele seja tão prioritário quanto outros tópicos, como desempenho e experiência do usuário. Confira abaixo alguns itens da lista de verificação que você precisa considerar ao trabalhar no processo.

• Disponibilize treinamentos de acessibilidade para a equipe.
• Identifique as jornadas ideais do usuário no site ou aplicativo.
• Tente incorporar uma lista de verificação de acessibilidade ao processo da equipe.
• Sempre que possível, avalie o site ou o aplicativo com estudos de usuários.

Treinamento de acessibilidade

Há vários recursos sem custo financeiro excelentes para aprender sobre acessibilidade na Web. Reservar um tempo para que a equipe estude o assunto pode facilitar a inclusão da acessibilidade no início do processo.

Alguns recursos fornecidos pelo Google incluem:

Acessibilidade na Web do Google: um curso de treinamento interativo de várias semanas.

Noções básicas sobre acessibilidade: guias de acessibilidade e práticas recomendadas.

Diretrizes do Material: acessibilidade: um conjunto de práticas recomendadas de UX para design inclusivo.

Como identificar jornadas ideais do usuário

Cada aplicativo tem uma ação principal que o usuário precisa realizar. Por exemplo, se você estiver criando um app de e-commerce, todos os usuários vão precisar poder adicionar um item ao carrinho de compras.

Algumas ações podem ser de importância secundária e talvez sejam realizadas apenas ocasionalmente. Por exemplo, mudar a foto do avatar é um recurso legal, mas não é essencial para todas as experiências.

Identificar as ações principais e secundárias no seu app vai ajudar você a priorizar o trabalho de acessibilidade que está por vir. Mais tarde, você pode combinar essas ações com uma lista de verificação de acessibilidade para acompanhar seu progresso e evitar regressões.

Incorporar uma lista de verificação de acessibilidade

O tema da acessibilidade é bastante amplo. Por isso, ter uma lista de verificação de áreas importantes a serem consideradas pode ajudar a garantir que você esteja cobrindo todas as bases.

Há várias listas de verificação de acessibilidade disponíveis. Confira alguns exemplos do setor:

Lista de verificação do WebAIM WCAG Diretrizes de acessibilidade da Vox

Com uma lista de verificação em mãos, você pode analisar suas ações principais e secundárias para começar a triagem do que ainda precisa ser feito. Você pode ser bastante estratégico nesse processo e até criar uma matriz de ações principais e secundárias e determinar, para cada etapa desses processos, se há algum bit de acessibilidade ausente.

Como avaliar com estudos com usuários

Nada supera sentar com usuários reais e observá-los enquanto eles tentam usar o app. Se você estiver adaptando a acessibilidade a uma experiência existente, esse processo pode ajudar a identificar rapidamente as áreas que precisam de melhorias. E se você estiver iniciando um novo projeto, os primeiros estudos de usuários podem ajudar a evitar passar muito tempo desenvolvendo um recurso difícil de usar.

Tente incorporar o feedback de um grupo de usuários o mais diversificado possível. Considere os usuários que navegam principalmente com o teclado ou dependem de tecnologias auxiliares, como leitores de tela ou recursos para aumentar o zoom.

Designer de UX

Como as pessoas tendem a projetar usando os próprios vieses, se você não tem uma deficiência e não tem colegas com deficiência, pode estar projetando involuntariamente para apenas alguns dos seus usuários. Ao trabalhar, pergunte-se "Quais são todos os tipos de usuários que podem depender desse design?" Confira algumas técnicas que você pode usar para tornar seu processo mais inclusivo.

• O conteúdo tem contraste de cor suficiente.
• A ordem das guias está definida.
• Os controles têm rótulos acessíveis.
• Há várias maneiras de interagir com a interface.

O conteúdo tem bom contraste de cor

O objetivo principal da maioria dos sites é transmitir algumas informações ao usuário, seja por texto escrito ou imagens. No entanto, se o conteúdo tiver baixo contraste, pode ser difícil para alguns usuários (principalmente aqueles com deficiência visual) ler. Isso pode afetar negativamente a experiência do usuário. Para resolver esse problema, tente fazer com que todos os textos e imagens tenham contraste de cor suficiente.

O contraste é medido comparando a luminância de uma cor de primeiro e de segundo plano. Para textos menores (abaixo de 18 ou 14 pt em negrito), é recomendada uma proporção mínima de 4,5:1. Para textos maiores, essa proporção pode ser ajustada para 3:1.

Na imagem abaixo, o texto à esquerda atende a esses mínimos de contraste, enquanto o texto à direita tem baixo contraste.

Há várias ferramentas para medir o contraste de cores, como a Ferramenta de cores do Material Design do Google, o app Contrast Ratio de Lea Verou e o aXe da Deque.

A ordem das guias foi definida

A ordem de guias é a ordem em que os elementos recebem foco conforme o usuário pressiona a tecla Tab. Para usuários que navegam principalmente com um teclado, a tecla Tab é a principal forma de acessar tudo na tela. Pense nele como o cursor do mouse.

O ideal é que a ordem das guias siga a ordem de leitura e flua da parte de cima da página para a parte de baixo, com os itens mais importantes aparecendo mais acima na ordem. Isso torna mais eficiente para qualquer pessoa que use um teclado acessar rapidamente esses itens.

A interface simulada acima está numerada para mostrar a ordem das guias. Criar um modelo como este pode ajudar a identificar a ordem das guias pretendida. Isso pode ser compartilhado com os desenvolvedores e testadores de controle de qualidade para garantir que ele seja implementado e testado corretamente.

Os controles têm rótulos acessíveis

Para usuários de tecnologias adaptativas, como leitores de tela, os marcadores fornecem informações que, de outra forma, seriam apenas visuais. Por exemplo, um botão de pesquisa que é apenas um ícone de lupa pode ter um rótulo acessível de "Pesquisar" para ajudar a preencher a affordance visual ausente.

Confira algumas sugestões simples para seguir ao projetar rótulos acessíveis:

• Seja sucinto: pode ser cansativo ouvir descrições longas.
• Tente não incluir o tipo ou estado de controle. Se o controle for codificado corretamente, um leitor de tela vai anunciar isso automaticamente.
• Foco nos verbos de ação: use "pesquisar", não "lupa".

Você pode criar um modelo com todos os controles rotulados. Isso pode ser compartilhado com sua equipe de desenvolvimento e de controle de qualidade para implementação e testes.

Várias maneiras de interagir com a interface e entendê-la

É fácil presumir que todos os usuários interagem com a página principalmente usando um mouse. Ao projetar, considere como alguém vai interagir com um controle usando um teclado.

Planeje seus estados de foco. Isso significa determinar a aparência de um controle quando o usuário o foca com a tecla Tab ou pressiona as teclas de seta. É útil planejar esses estados com antecedência, em vez de tentar inseri-los no design mais tarde.

Por fim, em qualquer ponto de interação, é importante garantir que o usuário tenha várias maneiras de entender o conteúdo. Tente não usar apenas cores para transmitir informações, já que essas dicas sutis podem passar despercebidas por um usuário com deficiência de visão de cores. Um exemplo clássico é um campo de texto inválido. Em vez de apenas um sublinhado vermelho para indicar um problema, considere adicionar um texto auxiliar. Dessa forma, você está cobrindo mais bases e aumentando a probabilidade de um usuário perceber o problema.

Desenvolvedor

O papel do desenvolvedor é onde o gerenciamento de foco e a semântica se combinam para formar uma experiência de usuário robusta. Confira abaixo alguns itens que os desenvolvedores podem considerar ao trabalhar no site ou aplicativo:

• A ordem das guias é lógica.
• O foco é gerenciado e visível corretamente.
• Os elementos interativos têm suporte a teclado.
• As funções e os atributos ARIA são aplicados conforme necessário.
• Os elementos são rotulados corretamente.
• Os testes são automatizados.

Ordem lógica das guias

Elementos nativos, como input, button e select, são incluídos na ordem de guias sem custo financeiro e podem ser focados automaticamente com o teclado. Mas nem todos os elementos recebem esse mesmo comportamento. Em particular, elementos genéricos como div e span não são incluídos na ordem de guias. Isso significa que, se você usar um div para criar um controle interativo, vai precisar fazer mais trabalho para que ele seja acessível pelo teclado.

Duas opções são:

• Dê um tabindex="0" ao controle. Isso pelo menos vai torná-lo focado, mas provavelmente você vai precisar fazer mais trabalho para adicionar suporte a pressionamentos de tecla.
• Sempre que possível, use button em vez de div ou span para qualquer controle semelhante a um botão. O elemento nativo button é muito fácil de estilizar e recebe suporte de teclado sem custo financeiro.

Gerenciar o foco

Ao mudar o conteúdo da página, é importante direcionar a atenção do usuário movendo o foco. Um exemplo clássico de quando essa técnica é útil é ao abrir uma caixa de diálogo modal. Se um usuário que usa um teclado pressionar um botão para abrir uma caixa de diálogo e o foco não for movido para o elemento da caixa de diálogo, a única ação possível será percorrer todo o site até encontrar o novo controle. Ao mudar o foco para o novo conteúdo assim que ele aparece, você pode melhorar a eficiência das experiências desses usuários.

Suporte ao teclado para elementos interativos

Se você estiver criando um controle personalizado, como um carrossel ou menu suspenso, será necessário fazer mais alguns ajustes para adicionar suporte ao teclado. O guia de práticas de criação de ARIA (em inglês) é um recurso útil que identifica vários padrões de IU e os tipos de ações de teclado que eles devem oferecer suporte.

Para saber mais sobre como adicionar suporte ao teclado a um elemento, consulte a seção Tabindex itinerante nos documentos de Noções básicas de acessibilidade do Google.

As funções e os atributos ARIA são aplicados conforme necessário

Os controles personalizados não precisam apenas de suporte adequado ao teclado, mas também de semântica adequada. Afinal, um div, semanticamente, é apenas um contêiner de agrupamento genérico. Se você estiver usando um div como base para o menu suspenso, vai precisar usar a ARIA para adicionar semânticas adicionais para que o tipo de controle possa ser transmitido à tecnologia adaptativa. Novamente, o guia de práticas de criação de ARIA pode ajudar a identificar quais papéis, estados e propriedades você deve usar. Como bônus, muitas das explicações no guia ARIA também vêm com exemplos de código.

Rotulagem de elementos

Para rotular entradas nativas, use o elemento <label> integrado, conforme descrito no MDN. Isso não apenas ajuda a criar uma affordance visual na tela, mas também dá à entrada um nome acessível na árvore de acessibilidade. Esse nome é então escolhido por uma tecnologia adaptativa (como um leitor de tela) e anunciado ao usuário.

Infelizmente, <label> não oferece suporte para dar um nome acessível a controles personalizados, como aqueles criados usando Elementos personalizados ou fora de divs e spans simples. Para esses tipos de controles, você precisa usar os atributos aria-label e aria-labelledby.

Testes automatizados

Ser preguiçoso pode ser bom, especialmente quando se trata de testes. Sempre que possível, procure automatizar seus testes de acessibilidade para não precisar fazer tudo manualmente. Atualmente, há várias ferramentas de teste do setor que facilitam e aceleram a verificação de problemas comuns de acessibilidade:

O aXe, criado pela Deque Systems, está disponível como uma extensão do Chrome e um módulo Node (bom para ambientes de integração contínua). Este A11ycast curto explica algumas maneiras diferentes de incorporar o aXe ao seu processo de desenvolvimento.

O Lighthouse é o projeto de código aberto do Google para auditar a performance dos seus Progressive Web Apps. Além de verificar se a PWA tem suporte para recursos como Service Worker e um manifesto de app da Web, o Lighthouse também executa uma série de testes de práticas recomendadas, incluindo testes para problemas de acessibilidade.

Conclusão

A acessibilidade é um esforço coletivo. Todos têm um papel a desempenhar. Este guia apresenta alguns itens importantes que cada membro da equipe pode usar para se aprofundar rapidamente no assunto e, com sorte, melhorar a experiência geral do app.

Para saber mais sobre acessibilidade, confira nosso curso sem custo financeiro da Udacity e navegue pelas documentações sobre acessibilidade disponíveis aqui no web.dev.