Melhor UX para ferramentas web adaptativas

As ferramentas da interação

Para as pessoas que dependem de ferramentas web adaptativas para navegar na Internet, a forma como o conteúdo é construído e apresentado é tudo. A tecnologia de apoio mais sofisticada do mundo não consegue ler, anunciar nem operar conteúdo que não exista numa forma acessível. Um botão que na verdade é uma <div> estilizada, uma imagem sem alternativa textual ou uma lista pendente personalizada sem suporte de teclado é simplesmente invisível — ou pior, um beco sem saída — para as pessoas que dependem destas ferramentas todos os dias.

A QualiBooth ajuda-o a compreender duas coisas em simultâneo: como as ferramentas de um utilizador interpretam de facto o seu conteúdo, e que conteúdo ou estrutura está em falta, avariado ou ambíguo. É essa combinação que distingue um site que tecnicamente carrega de um que funciona genuinamente para todos.

Este guia percorre as principais categorias de tecnologia de apoio e adaptativa, como cada uma espera que um site se comporte, e os passos práticos que pode dar para construir com estas ferramentas em vez de contra elas. Estabelece também uma linha clara entre a verdadeira tecnologia de apoio e os overlays de acessibilidade — porque as duas são frequentemente confundidas, e essa confusão tem consequências reais para utilizadores reais.

O que significam realmente as «ferramentas web adaptativas»

As ferramentas web adaptativas — mais comummente chamadas tecnologia de apoio (TA) — são software e hardware que alteram a forma como uma pessoa perceciona ou opera uma interface digital. Não são complementos ao seu site; são o ambiente próprio do utilizador, configurado de acordo com as suas necessidades e frequentemente usado durante horas por dia em milhares de sites.

As principais categorias incluem:

Leitores de ecrã que convertem o conteúdo no ecrã em fala sintetizada ou braille atualizável.
Ampliação de ecrã que amplia e reorganiza parte ou a totalidade do ecrã.
Dispositivos de acesso por manípulo (switch) para pessoas que não conseguem usar um teclado ou rato padrão.
Controlo por voz que conduz a interface inteiramente por comando falado.
Funcionalidades integradas no navegador e no sistema operativo tais como modos de alto contraste, movimento reduzido e ferramentas de leitura.
Auxiliares de leitura e de compreensão que simplificam, narram ou reestruturam o texto.

Cada uma destas assenta na mesma base: uma página bem estruturada, semântica e operável por teclado, que cumpre normas estabelecidas. Quando constrói segundo as WCAG 2.2, está a estabelecer o contrato do qual cada uma destas ferramentas depende.

Leitores de ecrã: a estrutura é a interface

Os leitores de ecrã são a tecnologia de apoio mais conhecida e, para muitas equipas, a mais difícil de conceber — precisamente porque a disposição visual que vê não lhe diz quase nada sobre o que um leitor de ecrã anuncia.

Os leitores de ecrã mais utilizados são o NVDA e o JAWS no Windows, o VoiceOver no macOS e iOS, e o TalkBack no Android. Não «veem» a sua página; constroem um modelo a partir da árvore de acessibilidade, que deriva da semântica do seu HTML e de qualquer ARIA que acrescente por cima.

O que os leitores de ecrã precisam de si

Elementos semânticos reais. Use <button>, <a>, <nav>, <main>, <h1>–<h6> e <table> para aquilo que são. Um cabeçalho tem de ser um cabeçalho para que os utilizadores possam saltar entre secções; uma ligação tem de ser uma ligação para que apareça na lista de ligações.
Alternativas textuais significativas. Cada imagem informativa precisa de um atributo alt que descreva o seu propósito. As imagens decorativas devem ter um alt="" vazio para serem ignoradas em vez de anunciadas como ruído.
Etiquetas programáticas para os controlos. Os campos de formulário precisam de elementos <label> associados; os botões só com ícone precisam de um nome acessível através de aria-label ou de texto visualmente oculto.
Uma hierarquia de cabeçalhos lógica. Os cabeçalhos são a principal forma de os utilizadores de leitores de ecrã percorrerem uma página. Saltar níveis ou usar cabeçalhos apenas pelo tamanho visual quebra essa navegação.
ARIA correto — e apenas quando necessário. O ARIA pode comunicar estados (expandido, selecionado, desativado) e papéis para widgets personalizados, mas um ARIA mau é pior do que nenhum. A primeira regra do ARIA é usar HTML nativo sempre que possível.

Um ponto de confusão frequente é a diferença entre um leitor de ecrã e a leitura de texto comum. Uma ferramenta de leitura narra texto; um leitor de ecrã expõe e opera a interface inteira, incluindo controlos, estados e navegação. Abordamos esta distinção em profundidade em leitura de texto versus leitores de ecrã.

Como as ferramentas automatizadas só conseguem detetar uma fração dos problemas dos leitores de ecrã, a única forma fiável de saber como o seu site soa é testá-lo como os utilizadores o fazem. O nosso guia de testes com leitor de ecrã descreve o fluxo de trabalho prático, e uma avaliação por leitor de ecrã dedicada submete os seus percursos mais importantes a esse processo com testadores experientes.

Ampliação de ecrã: conceber para a vista ampliada

As pessoas com baixa visão ampliam frequentemente o ecrã entre 200% e 800% ou mais, vendo apenas uma pequena fatia da página de cada vez. Algumas usam a lupa do sistema operativo; outras recorrem ao zoom do navegador ou a software especializado.

Com ampliação elevada, decisões de disposição em que nunca pensa tornam-se críticas:

Reorganização (reflow). O conteúdo deve reorganizar-se numa única coluna a 400% de zoom (critério de sucesso WCAG 2.2 1.4.10) para que os utilizadores não tenham de deslocar em duas direções para ler uma frase.
Proximidade dos elementos relacionados. Se uma mensagem de erro surgir longe do campo que descreve, um utilizador com ampliação pode nunca os ver na mesma janela de visualização. Mantenha as etiquetas, os campos e o feedback juntos.
Foco visível. Um indicador de foco claro e de alto contraste permite a um utilizador com ampliação encontrar onde está depois de a vista saltar.
Sem perda de conteúdo ou de função. Nada deve ser cortado, sobreposto ou tornado inoperável quando o texto é ampliado até 200% (critério de sucesso 1.4.4).

A ampliação premeia disposições limpas e adaptáveis e penaliza os designs em pixels fixos e o conteúdo que depende do passar do rato.

Acesso por manípulo e operabilidade por teclado

Os dispositivos de manípulo permitem às pessoas operar um computador com uma ou duas entradas simples — um botão, um dispositivo de sopro ou um movimento da cabeça — geralmente percorrendo os elementos interativos um de cada vez. O acesso por manípulo assenta no suporte de teclado: se o seu site funcionar totalmente a partir do teclado, quase de certeza funciona também com manípulos.

Isto faz da plena operabilidade por teclado uma das coisas com maior alavancagem para acertar:

Tudo alcançável. Cada elemento interativo deve poder receber foco e ser operável sem rato — ligações, botões, controlos de formulário, menus, janelas modais, carrosséis e widgets personalizados.
Uma ordem de foco visível e lógica. O foco deve mover-se pela página numa ordem que corresponda ao fluxo visual e de leitura, e o elemento com foco deve estar sempre claramente indicado.
Sem armadilhas de teclado. Os utilizadores devem conseguir mover o foco para fora de qualquer componente, incluindo média incorporado e caixas de diálogo.
Ligações de salto. Uma ligação «saltar para o conteúdo principal» permite às pessoas contornar a navegação repetida em vez de a percorrerem em cada página.

Se um cliente estiver a preencher um formulário, consegue tabular por todos os campos, abrir uma lista pendente, escolher um produto e submeter — tudo sem tocar num rato? O preenchimento automático do navegador irá cooperar com a sua marcação? Estas são as perguntas que os utilizadores de manípulo e de teclado respondem sobre o seu site, quer as coloque ou não.

Controlo por voz: os nomes e as etiquetas visíveis importam

As ferramentas de controlo por voz como o Dragon, o Voice Control e o Voice Access permitem aos utilizadores dizer comandos como «clicar em Submeter» ou «deslocar para baixo». Para que estes comandos funcionem, a etiqueta visível de um controlo deve corresponder ao seu nome acessível. Esta é a base do critério de sucesso WCAG 2.2 2.5.3, Etiqueta no Nome.

Orientações práticas:

O nome acessível deve conter o texto visível. Se um botão diz «Enviar mensagem», não lhe dê um aria-label de «Submeter formulário» — o utilizador que diz «clicar em Enviar mensagem» será ignorado.
Evite controlos só com ícone sem texto, ou dê-lhes um nome acessível que corresponda a um comando falado provável.
Mantenha os alvos clicáveis suficientemente grandes para serem selecionados de forma fiável, o que também cumpre o critério de tamanho do alvo das WCAG 2.2.

Funcionalidades de acessibilidade do navegador e do sistema operativo

Nem todas as ferramentas adaptativas são produtos separados. Os navegadores e sistemas operativos modernos incluem poderosas funcionalidades integradas que os utilizadores ativam a nível de todo o sistema, e o seu site deve respeitá-las automaticamente:

Movimento reduzido. Respeite a media query prefers-reduced-motion para desativar ou suavizar animações para utilizadores que sentem náuseas ou distração com o movimento.
Modo escuro e alto contraste. Suporte prefers-color-scheme e o Alto Contraste / Cores Forçadas do Windows para que a sua interface se mantenha legível sem lutar contra as definições do utilizador.
Redimensionamento de texto e zoom. Use unidades relativas para que o escalonamento de texto do navegador funcione, em vez de fixar os tamanhos em pixels.
Modos de leitura e ferramentas de leitura. As vistas de leitura dos navegadores e ferramentas como o Immersive Reader reduzem uma página ao seu conteúdo essencial — o que funciona muito melhor quando o seu HTML é semântico e isento de desordem.

Estas funcionalidades não custam nada extra ao utilizador e muito pouco a si, mas melhoram drasticamente o conforto para um público vasto, incluindo pessoas sem deficiência diagnosticada.

Ferramentas de leitura e de compreensão

As ferramentas de leitura servem pessoas com dislexia, PHDA, deficiências cognitivas ou literacia limitada na língua da página. Incluem narradores de leitura de texto, réguas de leitura, realce de palavras, resumidores e ferramentas de tradução.

Para funcionarem bem com elas:

Escreva numa linguagem simples e bem organizada, com cabeçalhos descritivos e parágrafos curtos.
Marque a página de modo a que o conteúdo principal seja claramente identificável e a ordem de leitura esteja correta.
Evite transmitir significado apenas através da cor, da disposição ou das imagens — forneça um equivalente textual.
Garanta que a sua língua está declarada (atributo lang) para que a narração e a tradução usem a pronúncia e as regras corretas.

Uma boa estrutura de conteúdo ajuda todas as ferramentas deste artigo ao mesmo tempo, porque todas se baseiam na mesma marcação subjacente.

Verdadeira tecnologia de apoio vs overlays de acessibilidade

Esta é a distinção que mais importa, e é onde muitas organizações erram.

A verdadeira tecnologia de apoio — leitores de ecrã, lupas, acesso por manípulo, controlo por voz — funciona no dispositivo do utilizador, sob o controlo do utilizador, e opera o seu site através da sua semântica e do suporte de teclado. O utilizador passou anos a configurá-la. A sua função é simplesmente construir uma página que estas ferramentas consigam compreender.

Os overlays de acessibilidade são scripts de terceiros que acrescenta ao seu próprio site e que prometem «torná-lo acessível» automaticamente, geralmente através de um widget flutuante. Não substituem a tecnologia de apoio, e não corrigem um site inacessível. Eis porquê:

Não conseguem reparar o código subjacente. Os overlays assentam por cima da página; não conseguem inventar de forma fiável texto alternativo em falta, corrigir estruturas de cabeçalhos avariadas ou fazer com que uma <div> se comporte como um botão real em todos os leitores de ecrã.
Entram frequentemente em conflito com a TA real. Muitos utilizadores de leitores de ecrã relatam que os overlays interferem com as ferramentas em que já confiam, tornando por vezes os sites mais difíceis de usar, e não mais fáceis.
Criam uma falsa sensação de conformidade. Instalar um widget não cumpre as WCAG 2.2, a EAA nem a ADA. Foram intentadas ações judiciais contra sites que usam overlays precisamente porque as barreiras subjacentes se mantiveram.
Não refletem a experiência vivida. A acessibilidade é, em última análise, julgada pelas pessoas que usam TA todos os dias — razão pela qual realizamos auditorias por pessoas com deficiência em vez de confiar nas alegações de um script.

O caminho de confiança é corrigir a acessibilidade no código e validá-la com testes automatizados e humanos. Explicamos esta filosofia de forma mais completa em o que significa a verdadeira acessibilidade digital.

Um fluxo de trabalho prático para construir com ferramentas adaptativas

Conceber para tecnologia de apoio não é um projeto pontual; é um processo que se encaixa na forma como já lança software. Uma abordagem sustentável combina normalmente quatro elementos:

Análise automatizada, cedo e com frequência. Ferramentas como um software de análise de acessibilidade detetam um grande volume de problemas ao nível do código — etiquetas em falta, falhas de contraste, ARIA avariado — antes de chegarem à produção. As verificações automatizadas são rápidas e repetíveis, mas só cobrem parte do quadro.
Testes manuais e com tecnologia de apoio. Os problemas que mais afetam os utilizadores reais — ordem de foco confusa, anúncios pouco claros, widgets personalizados inutilizáveis — exigem um humano. O nosso guia de auditorias manuais de acessibilidade descreve como isto complementa a automatização.
Integrar a acessibilidade na sua equipa. Tratar a acessibilidade como uma disciplina contínua, apoiada pela melhoria do processo de acessibilidade, evita a lenta regressão que ocorre quando as correções são pontuais.
As ferramentas certas para a sua stack. O conjunto de ferramentas de acessibilidade da QualiBooth reúne análise, monitorização e relatórios, enquanto o Agora e a nossa edição comunitária oferecem pontos de entrada para equipas em diferentes estádios de maturidade.

Se a terminologia deste artigo lhe é nova, o glossário de acessibilidade é um companheiro útil à medida que coloca estas práticas em prática.

Onde se enquadra a QualiBooth

A QualiBooth identifica problemas no seu site existente e pode também analisar páginas antes de entrarem em linha, para que os clientes que usam qualquer ferramenta adaptativa tenham uma experiência fluida que aumenta a usabilidade e a lealdade à marca. Combinamos a deteção automatizada com a avaliação por testadores experientes e pessoas com deficiência, e depois ajudamos a sua equipa a transformar os achados em correções duradouras — nunca um overlay que mascara o problema.

O objetivo é simples: um site que funciona com as ferramentas em que os seus utilizadores já confiam, nos termos deles, sempre que visitam.

Pronto para ver como o seu site se comporta perante tecnologia de apoio real? Execute uma análise de acessibilidade gratuita para detetar ganhos rápidos, solicite uma demonstração para ver a QualiBooth em ação, ou fale com a nossa equipa sobre um trabalho de consultoria de acessibilidade à medida.