Jun 25, 2024
Artigo histórico da Make (a fonte indica 25 de junho de 2024). Este texto reproduz um artigo da Make publicado nessa data. O «nós» e as recomendações, ferramentas, preços e capturas de tela são do autor da Make naquela data; não são uma afirmação deste site nem garantia de que esses apps, recursos ou preços continuem iguais hoje. Para o estado atual das plataformas, consulte as fontes oficiais.
Neste guest post da Fillout, Dominic Whyte (cofundador da Fillout) explora como você pode aumentar a acessibilidade dos seus formulários web.
A conscientização e os esforços em torno da acessibilidade digital vêm ganhando força nos últimos anos. Em 2021, a Forrester Research constatou que "84% das empresas estão fazendo trabalho de [acessibilidade], embora apenas 36% das empresas tenham um compromisso vindo de cima de criar experiências digitais acessíveis". Dois anos depois, os compromissos vindo de cima tinham saltado para 60%.
Há muitas razões para ter esperança de que a web está se tornando mais perceptível, compreensível e operável para todos. Mas, como a maioria dos especialistas dirá, a acessibilidade deve ser uma jornada, não um destino. Especialmente à medida que a tecnologia que todos usamos evolui e muda.
Por muito tempo, todos estavam focados em escrever HTML acessível. Depois, esses esforços se expandiram para incluir JavaScript e CSS. Hoje, com toda a conveniência das plataformas de automação de arrastar e soltar, bancos de dados, criadores de formulários e outros apps SaaS, um dos maiores desafios de acessibilidade é trabalhar dentro dos limites do playground de outra pessoa. Tornar seu app ou interface o mais universalmente utilizável possível sem controlar o código em si não é fácil.
A maioria dos apps estabelecidos e respeitáveis tem baselines de acessibilidade. Eles não podem, no entanto, fazer tudo por você. Não existe Um Jeito Certo de otimizar apps e interfaces web para cada perfil de usuário. O ideal, porém, é que os apps ofereçam configurações e ajustes para proporcionar uma experiência positiva aos seus usuários, independentemente de como eles acessam a web.
No caso dos formulários web, eu costumo dizer às pessoas para começarem focando nestas quatro otimizações importantes de acessibilidade e irem avançando a partir daí.
Teste a navegação por teclado e os tipos de campo problemáticos
Uma das primeiras coisas que qualquer pessoa trabalhando em acessibilidade de formulários deve testar é a navegação somente por teclado. Conseguir interagir com cada parte do formulário sem usar mouse ou touchscreen melhora drasticamente a experiência de pessoas com deficiências visuais e motoras. Embora a maioria dos criadores de formulários de arrastar e soltar seja otimizada para navegação por teclado por padrão, nem todos os campos de formulário são iguais.
Seletores de data
Os seletores de data, por exemplo, são notoriamente difíceis de navegar sem um mouse e nem sempre incluem marcos para os leitores de tela narrarem. O especialista em acessibilidade Adam Silver, do Form Design Mastery, diz: "Só use um seletor de data quando os usuários precisarem encontrar uma data em relação a outra, ou se precisarem saber o dia, a semana ou o mês a que a data se refere". Para todos os outros casos de uso, Adam sugere, em vez disso: "Use três caixas de texto separadas para datas".
CAPTCHAs
CAPTCHAs são outro campo de formulário comum que causa problemas para navegação por teclado e usuários de leitores de tela. Quando convidadas a avaliar os elementos mais frustrantes e difíceis da web, as pessoas que participaram da Screen User Survey 2024 da WebAIM apontaram os CAPTCHAs como os piores, de longe.
Pior ainda, a WebAIM observou que "a ordem e a dificuldade indicada para os itens desta lista permanecem praticamente inalteradas nos últimos 14 anos". Sempre que possível, evite CAPTCHAs ou opte por outra verificação humana (por exemplo, um cenário da Make que envia um código de uso único por SMS, ou a verificação por e-mail da Fillout).
A lista de opções de campos de cada app de formulários e a implementação desses campos são diferentes. Minha recomendação número um para acessibilidade de formulários web é sempre fazer um teste rápido de navegação somente por teclado antes de publicar. De preferência com um leitor de tela ligado, narrando cada campo conforme recebe foco.
Andrew Hedges, da Assistiv Labs, diz: "Não há substituto para testar em tecnologias assistivas reais, inclusive com pessoas que usam esses modos de entrada todos os dias. Funciona só com teclado? Funciona com leitores de tela tanto no Windows quanto no macOS? Funciona com controle por voz?"
Comece experimentando os leitores de tela embutidos no Windows (Narrator) e no macOS (VoiceOver). No entanto, apenas cerca de 10% dos usuários de leitores de tela usam esses dois. Você também deve testar com o NVDA (que é gratuito) e o JAWS (que é pago, mas tem teste grátis), já que os dois juntos detêm mais de 78% da participação no mercado de leitores de tela.
Crie mensagens de erro que todos possam entender
Usar apenas formatação de cor para comunicar informação é um erro de acessibilidade comum em toda a web. Mas é especialmente problemático em formulários. Quando um usuário fornece uma entrada que não atende aos requisitos de um campo, alguns formulários simplesmente destacam os rótulos dos campos em vermelho ou mostram um ícone ao lado dos envios problemáticos. Essas são notificações que podem ser totalmente invisíveis para usuários cegos e daltônicos.
Segundo o rascunho mais recente do Tutorial de Formulários das Web Content Accessibility Guidelines (WCAG), uma mensagem de erro deve sempre ser escrita em texto, especificar qual campo contém um erro, explicar a causa do erro (por exemplo, campo obrigatório vazio, resposta mal formatada etc.) e fornecer um exemplo de envio aceitável.
Para apps de formulário sem mensagens de erro personalizáveis, uma possível solução alternativa é uma caixa de texto condicional que só aparece quando um campo anterior não atende aos requisitos de entrada.
Remova texto de placeholder e rótulos flutuantes
Com uma frequência surpreendente, melhorias de acessibilidade exigem remover algo que foi pensado para ajudar. Veja o caso do texto de placeholder, por exemplo, aquele texto que aparece dentro de um campo vazio com instruções ou um exemplo de resposta. A ideia é fornecer orientação ocupando menos espaço na página. Especialistas argumentam que o texto de placeholder faz mais mal do que bem.
O texto de placeholder quase sempre é formatado em um cinza de baixo contraste, difícil de ler para usuários com baixa visão. Ele também desaparece assim que o campo recebe foco ou qualquer valor é digitado. Quando um usuário quer comparar o que digitou com o texto de placeholder, precisa apagar a resposta para tornar o placeholder visível de novo. Se você o usa como lugar para escrever instruções do campo, o espaço é muito mais limitado que o de um rótulo de campo tradicional. Por fim, e pior de tudo do ponto de vista da acessibilidade, o texto de placeholder costuma ser invisível para leitores de tela.
Katie Sherwin escreve para o Nielsen Norman Group que "mesmo quando se usam rótulos, colocar dicas ou instruções importantes dentro de um campo de formulário ainda pode causar problemas… o texto de placeholder é geralmente ruim para a acessibilidade". Ela passa a explicar que uma das alternativas mais populares, os rótulos flutuantes, não é muito melhor.
Rótulos flutuantes são textos que aparecem dentro dos campos do formulário até que o campo receba foco ou o usuário digite um valor, momento em que o rótulo muda de tamanho e posição para "flutuar" acima do campo vazio. O rótulo nunca desaparece, não usa uma cor de fonte de baixo contraste e ocupa menos espaço na página do que um rótulo de campo estático seguido de um campo vazio.
Mas, como Sherwin aponta, "campos com texto dentro são menos perceptíveis, e os usuários podem achar que já existe um valor padrão preenchido no campo", uma escolha de UX questionável, ainda mais comprometida pelo problema de que rótulos flutuantes são marcados de formas que os usuários de leitores de tela ignoram.
O conselho do Nielsen Norman Group aqui é simples: "Em vez de arriscar que os usuários tropecem ao preencher formulários ou desperdicem um tempo valioso tentando descobrir como funcionam, a melhor solução é ter rótulos claros e visíveis posicionados fora dos campos de formulário vazios".
Divida formulários em várias páginas de coluna única
A maioria dos usuários de leitores de tela se acostumou tanto a páginas longas e com muito texto que a primeira coisa que fazem é ler todos os títulos antes de ler os parágrafos relevantes por completo. Para esses usuários (e para todos os outros, sinceramente), páginas curtas com apenas alguns campos relacionados são um alívio bem-vindo.
A WCAG tem uma seção inteira sobre formulários de várias páginas, dizendo: "Sempre que possível, divida formulários longos em vários formulários menores que constituam uma série de etapas ou estágios lógicos. Isso ajuda a tornar formulários longos menos assustadores e mais fáceis de entender, particularmente para pessoas menos experientes no uso de computadores ou que têm várias deficiências cognitivas".
Essa abordagem também facilita para os usuários encontrar e corrigir erros de preenchimento, ao mesmo tempo em que oferece uma alternativa aos layouts de várias colunas "econômicos em espaço" (que prejudicam consistentemente as taxas de conversão). Depois, há ainda as oportunidades adicionais de lógica de ramificação, que ajuda os usuários de leitores de tela a pular páginas e campos desnecessários com base em respostas anteriores.
Depois que os usuários concluírem todas as páginas, é fundamental fornecer uma confirmação do envio, idealmente junto com uma forma de atualizar qualquer uma das respostas.
O Gov.uk Design System criou o padrão "Check Answers Page" para "aumentar a confiança dos usuários, pois eles veem claramente que concluíram todas as seções e que seus dados foram capturados" e "reduzir as taxas de erro, pois os usuários têm uma segunda chance de perceber e corrigir erros antes de enviar os dados".
Se você estiver usando um app de formulários que não consegue recriar a Check Answers Page, um cenário simples da Make ajudaria você a enviar por e-mail aos usuários os recibos de confirmação e fornecer um link para outro formulário, caso vejam algo que precise ser alterado.
Pensando em acessibilidade em todo lugar onde você interage com usuários
Algumas das melhorias que você pode fazer nos seus formulários também se aplicam a experiências web não interativas. Você deve passar seu logotipo, designs de landing page e formulários por um verificador de contraste antes de colocá-los no ar. Qualquer imagem do seu site ou posts em redes sociais deve ter texto alternativo descritivo. Vídeos e áudios devem sempre ter legendas e legendas descritivas em conformidade com a WCAG. Os textos devem ser sempre fáceis de entender e consistentes. Tornar seus formulários mais acessíveis leva tempo. Comece pequeno. Acostume-se com a navegação por teclado, com o uso de um leitor de tela, com a correção de mensagens de erro, placeholders e formulários longos de página única. Se você conseguir dominar isso, estará tornando suas experiências (e a web de modo geral) mais fáceis de usar para milhões de pessoas online.