Como fazer o handoff de designs acessíveis para as pessoas desenvolvedoras…

Escrito por: Lisha Dai
Traduzido, adaptado e melhorado por: Marília Gabriele Suzart

Assim, as pessoas com deficiência visual poderão ter uma experiência similar a das pessoas usuárias que são videntes.

Ao entregar o protótipo de uma nova funcionalidade para equipe de desenvolvimento, você pensou como será a experiência das pessoas com deficiência visual na aplicação? Se você não pensou sobre isso, você está deixando a responsabilidade para as pessoas que desenvolvem, que muitas vezes, não entendem sobre UX e tem dificuldade de realizar a tradução da jornada visual em uma experiência auditiva.

Se você deseja garantir experiências agradáveis para todas as pessoas usuárias — incluindo pessoas usuárias com deficiência visual, este artigo mostrará o passo a passo para fazer isso.

Um pouco do passado: nos últimos 1 ano e meio, eu trabalhei para um cliente no qual os produtos precisavam atingir o nível AA de conformidade com as diretrizes internacionais de acessibilidade (WCAG). Nesse projeto, um dos desafios que tive foi de como comunicar todos os detalhes de acessibilidade de um projeto para as pessoas que desenvolvem.

Meu colega, que participou de vários projetos de acessibilidade, sugeriu que eu entregasse notas de acessibilidade junto com o design.

Vamos começar a analisar item a item?

Como fazer notas de acessibilidade

Marque os pontos de referência, por exemplo, cabeçalho, conteúdo principal e rodapé.

Os pontos de referência são regiões na página para as quais os leitores de tela e outras tecnologias assistivas podem pular, assim as pessoas que usam essas tecnologias podem acessar as informações desejadas com menos esforço, ou seja, menos cliques. Por exemplo, se a pessoa usuária deseja entrar em contato com suporte para solicitar ajuda, é provável que esteja no rodapé, sem a marcação correta, caso haja uma barreira no meio da tela, a pessoa nunca vai conseguir conversar com o suporte.

Nota para dev: O cabeçalho, conteúdo principal e rodapé, são respectivamente as tags do HTML, <header>, <main> e <footer>.

Coloque uma função de pular para o conteúdo principal quando o cabeçalho tiver muitas opções (CTA — Call-to-Actions)

Normalmente, o cabeçalho permanece o mesmo durante toda a jornada da pessoa usuária. Para quem usa apenas o teclado — como pessoas cegas ou com dificuldades motoras — ao apertar a tecla tab precisar passar por todos os componentes do cabeçalho várias vezes é uma tortura. Fornecer uma função de pular para conteúdo principal economizará muito tempo.

Nota para dev: Um exemplo para referência é a página de pesquisa do Google, que ao navegar pelo teclado, exibe o botão “Ir para o conteúdo principal” que estava invisível. Ao clicar nele o foco é movido para o primeiro item da lista de resultados.

Cabeçalho da lista de acordo com a lógica do conteúdo

Os títulos definem a hierarquia da informação na sua página, o que permite que pessoas usando leitores de tela façam uma leitura dinâmica da página e identifiquem algo de interesse mais rápido. Um erro muito comum é confundir o tamanho da fonte com o nível de hierarquia do cabeçalho, os títulos devem ser definidos pensando na lógica e não no tamanho da fonte. Além disso, toda página deve possuir um título principal H1, em alguns casos, como landing page, esse título pode ser colocado de forma invisível, mas que será lido pelo leitor de telas.

Nota para dev: Uma referência para implementação é o site da Apple, no qual o título principal está invisível e o texto é o nome da própria empresa. Alguns atributos do CSS ocultam o conteúdo do leitor de telas como é o caso do display: none, para colocar conteúdos invisíveis, mas que sejam lidos pelo leitor de telas, use o mesmo CSS da classe visuallyhidden que está na captura de tela acima.

Marque a ordem da tabulação

A ordem da tabulação deverá ser aplicada apenas nos elementos que recebem o foco, ou seja são clicáveis, por exemplo, botões, links, campos de texto, etc. A ordem deve ser lógica. Por exemplo, ao fazer a reserva de um hotel, o componente de seleção de data deve estar antes do botão ‘reservar agora’, mesmo que visualmente o botão de reserva venha primeiro, é possível mudar a ordem através do código.

Adicione texto alternativo a imagens e ícones

O texto alternativo é uma palavra ou frase para explicar o conteúdo da imagem. É essencial para pessoas usuárias cegas e também ajuda qualquer pessoa que navega pelo conteúdo e tenha tido problemas para carregar a imagem.

Se a imagem for meramente ilustrativa, não é necessário colocar um texto alternativo, você pode colocar aria-hidden, assim o leitor de telas vai pular essa imagem. Porém, se essa imagem for importante para a compreensão do conteúdo ou para a navegação, você precisa colocar o texto alternativo. Por exemplo, os botões que possuem apenas ícone não são compreensíveis para pessoas com deficiência visual, como o menu de hambúrguer que precisamos declarar que o texto alternativo é ‘Menu’.

Além disso, se uma imagem desperta sentimentos emocionais, coloque um texto alternativo para oferecer uma experiência agradável para todas as pessoas. A melancia acenando triste mostra a emoção que desejamos que as pessoas usuárias sintam. Assim, podemos colocar um texto alternativo mesmo que seja possível sobreviver sem um.

Nota para dev: Dentro dos botões de ícone, coloque um span com texto alternativo e aplique o mesmo CSS da classe visuallyhidden, assim, mesmo que haja problemas para carregar imagens e CSS, qualquer pessoa, até mesmo o robô da Google, vai entender o que é esse botão. Além disso, use os ícones como svg para garantir que não serão serão lidos em duplicidade pelo leitor de telas e também que não será encontrado na pesquisa do Google Imagens.

Coloque dicas relacionadas a elementos interativos

E esta é a nota que fiz para as pessoas desenvolvedoras:

Sem informações adicionais, a pessoa cega não consegue preencher corretamente o campo de texto. Portanto, precisamos anexar informações de suporte a ele pelo atributo aria-describedby.

Aqui mostra como fazer a nota:

Nesse exemplo, se não fornecermos uma dica, as pessoas usuárias com deficiência visual ouvirão a mesma função duas vezes e podem ficar confusas, ‘Editar o que?’. Após colocar as dicas no botão, as pessoas usuárias podem entender qual é o botão para editar o e-mail e qual é para editar a senha.

Mostrar estado de foco de elementos interativos

O estado de foco é uma comunicação visual para informar qual elemento está selecionado, ele é essencial para pessoas com deficiências motoras. Ao navegar uma aplicação pelo teclado, tecla tab, voz ou até mesmo um controle remoto, se o foco não estiver visível, a pessoa usuária não terá ideia de onde está na página.

Nota para dev: ao iniciar um projeto muitas vezes colocamos outline: none para todas as tags do HTML, por favor remova essa linha de código! Ao invés disso, use o CSS da imagem ao lado, apenas onde for necessário, assim você removerá o outline do clique e o manterá para a navegação via teclado.

Anote as funções e estados para os elementos personalizados.

As funções WAI-ARIA são para comunicar como um componente personalizado se comporta. No exemplo, uma pessoa usuária pode marcar e desmarcar os cards. Esses recursos tornam os cards semelhantes ao radio button. Como não é um componente de radio button nativo, precisamos especificar seu nome ao entregá-lo.

Forneça designs para diferentes breakpoints

Você pode pensar: “Eu sei que os breakpoints são importantes. Mas como isso está relacionado à acessibilidade?” Na verdade, os breakpoints melhoram não apenas a usabilidade, mas também a acessibilidade. Por exemplo, quando você deseja aumentar o zoom em 200% para ler melhor o texto em um site.

Sem breakpoints definidos, o site não será fácil de navegar. Com os breakpoints definidos, o navegador pode personalizar a visualização e facilitar a operação em diferentes cenários.

Juntando tudo

Parece cansativo listar tantas notas. Não se preocupe, podemos combinar muitas anotações em uma visualização. Aqui está um exemplo:

Foi cansativo para mim no começo. Felizmente, percebi mais tarde que não preciso saber tudo, em vez disso, posso trabalhar em conjunto com as pessoas especialistas em acessibilidade e obter feedbacks.

Como revisar suas notas de acessibilidade?

Para começar, você precisa de uma pessoa especialista em acessibilidade para consultar por algumas horas. Quando seu design estiver pronto, revise-o e discuta-o com a pessoa que é especialista em acessibilidade. Ela vai corrigir erros, responder perguntas e fornecer exemplos. Depois de concluir as anotações de acessibilidade, compartilhe e analise-as com as pessoas desenvolvedoras.

Como revisar as implementações?

Quando a implementação estiver pronta, você poderá usar a tecla tab e o leitor de tela para navegar pela aplicação. Plugins como o Accessibility Insights for Web podem te ajudar a verificar se o site está acessível. Então você sabe que tudo é implementado de acordo com o plano — eles podem não cobrir tudo, mas já é um começo.

Assista ao vídeo do nosso canal falando sobre o Handoff de Acessibilidade

Teremos vídeos toda semana, nas versões inglês e português!

A versão original desse artigo foi escrito em inglês por Lisha Dai, com a autorização da mesma, foi traduzido e adaptado por Marília Gabriele Suzart, acesse o artigo original através do link: https://uxdesign.cc/how-to-hand-off-accessible-designs-to-developers-e10a0eeacaa6

Obrigada por ler. Esperamos que isso seja útil para você ☺