O que é alvo de queixas: um guia prático sobre os padrões de interface do utilizador subjacentes a 6 666 queixas de acessibilidade

O cabeçalho é a primeira área interativa em todas as páginas, e o botão de menu horizontal é frequentemente a primeira coisa a que um utilizador que navega apenas pelo teclado acede. Quando esse botão é apresentado como um <div> se tiver uma imagem de fundo em CSS, não tiver um nome acessível ou expandir um menu que retém o foco ou não indica o seu estado de aberto/fechado, todo o site torna-se estruturalmente inoperável a partir do teclado antes mesmo de o utilizador ter acedido a qualquer conteúdo efetivo.

O link de salto é a falha associada. Um link que funciona "Skip to main content" O link de salto é uma correção de apenas cinco linhas, mas é também o indicador mais eficaz para determinar se uma equipa de desenvolvimento tem, de todo, a acessibilidade na sua lista de verificação. As reclamações referem frequentemente ambos os aspetos no mesmo parágrafo, porque a ausência ou o mau funcionamento de um link de salto é o sinal de alerta — se a equipa não implementou um link de salto, é quase certo que também não implementou os estados «aria-expanded».

Renderizar o gatilho do menu como um elemento real <button> com uma etiqueta de texto visível ou apenas para leitores de ecrã e um elemento gerido aria-expanded atributo. Indique um "Skip to main content" link que fica visível quando recebe o foco e fica dentro do <main> ponto de referência. Certifique-se de que o foco passa para o menu quando este se abre, volta para o elemento de ativação quando se fecha e que Esc fecha o menu.

A pesquisa é implementada como um componente personalizado na maioria dos sites de grande dimensão — um campo de introdução de texto com supressão de repetições que envia um pedido a cada tecla pressionada e apresenta uma lista flutuante de sugestões dentro de um elemento posicionado de forma absoluta <div>. O campo de introdução de texto em si costuma funcionar bem. A lista de sugestões, por outro lado, quase nunca funciona. É apresentada fora do contexto DOM do campo de introdução, não tem role="listbox", não aria-activedescendant, e não há qualquer aviso da «live-region» quando os resultados aparecem. Um utilizador de um leitor de ecrã escreve, não ouve nada, carrega em Enter e obtém uma página de resultados que não sabia que estava à sua espera.

O mesmo padrão arquitetónico repete-se nos painéis de filtragem da pesquisa facetada e na própria lista de resultados: elementos que podem receber o foco do teclado, que estão visualmente presentes, mas nunca são anunciados. As reclamações sobre a pesquisa raramente dizem respeito à caixa de pesquisa; dizem respeito a tudo o que aparece depois de o utilizador escrever.

Utilize o padrão WAI-ARIA para caixas de seleção: role="combobox" na entrada com aria-expanded, aria-controls, e aria-activedescendant ligado a um role="listbox" de sugestões. Adicione uma área dinâmica que anuncie o número de resultados. Certifique-se de que a lista de sugestões é acessível com a tecla de seta para baixo, e não apenas com o rato.

A grelha PLP concentra vários anti-padrões num único ecrã. Cada mosaico é, normalmente, um cartão clicável com três ou quatro elementos interativos secundários — link de imagem, link de título, amostras de cor, botão de adição rápida —, todos integrados num outro link para a página do produto. O resultado são elementos interativos aninhados (um erro de HTML), texto de link redundante («Hero Dash Three Graphic Image Link» repetido quatro vezes) e amostras de cor criadas a partir de <div> elementos com manipuladores de clique, mas sem função nem nome.

A barra lateral de filtragem acrescenta uma segunda categoria de falha. As facetas de filtragem são normalmente listas de caixas de seleção, mas são criadas com elementos div e span personalizados, com um estilo que as faz parecer caixas de seleção, sendo que o verdadeiro <input> oculto fora do ecrã. Quando esse campo de entrada oculto perde a sua associação — através de uma regra CSS, de um manipulador de eventos JavaScript que ignora as pressões da tecla de espaço ou de um for atributo na etiqueta visível — o filtro passa a ser operável apenas com o rato.

Utilize uma âncora por mosaico com texto descritivo, em vez de três links por produto. Apresente as amostras de forma realista <button> elementos dentro de um role="radiogroup". Criar facetas de filtro com base em dados reais <input type="checkbox"> elementos associados <label> tags; aplicar estilo aos campos de entrada de forma visível, em vez de os ocultar. Avisar das alterações no filtro através de uma área interativa.

A página de detalhes do produto é onde um utilizador de leitor de ecrã tem de efetuar várias escolhas específicas na ordem correta: escolher uma cor, escolher um tamanho, definir a quantidade e, por fim, adicionar ao carrinho. Cada uma dessas opções é implementada no comércio eletrónico moderno como um widget personalizado — geralmente uma linha horizontal de <button>em forma de <div>Quanto aos tamanhos, blocos de cor criados a partir de divs com estilos CSS e um controlador numérico composto por dois botões com ícones que ladeiam um campo de entrada. Os botões de aumento e diminuição são normalmente fornecidos sem um nome acessível; as reclamações descrevem-nos como anunciado como «botão, botão» sem qualquer indicação do que fazem.

Os guias e tabelas de tamanhos constituem uma falha à parte: encontram-se quase sempre atrás de um link «Tabela de tamanhos» que abre uma janela modal, sendo que o próprio link muitas vezes não tem qualquer título, a janela modal frequentemente não apresenta um título e a tabela no seu interior muitas vezes não tem cabeçalhos nas linhas nem nas colunas.

Utilize controlos de formulário reais. As amostras de cor e os seletores de tamanho devem ser um role="radiogroup" de role="radio" botões (ou campos de opção com estilo invisível), cada um com um nome acessível como «Tamanho: Médio». O controlador de quantidade deve ser um campo numérico rotulado, acompanhado de botões de aumento/diminuição cujos nomes acessíveis incluam a ação e a quantidade atual. Envolva todo o bloco de seleção num fieldset com uma legenda.

O botão «Adicionar ao carrinho» é o momento mais testado em qualquer funil de comércio eletrónico e um dos que apresenta falhas mais frequentes para os utilizadores de tecnologias de assistência. O padrão é mecânico: um visitante clica no botão, surge uma pequena janela de confirmação ou uma gaveta do mini-carrinho durante dois ou três segundos, e o ícone do carrinho atualiza um indicador de quantidade no cabeçalho. Os utilizadores com visão veem os três sinais. Os utilizadores de leitores de ecrã normalmente não recebem nenhum. A janela de confirmação é apresentada fora de qualquer área ativa, a gaveta aparece sem gestão de foco e a alteração na contagem do carrinho é apresentada como uma simples mutação do DOM que nenhum leitor de ecrã anunciará.

O resultado é um botão que, do ponto de vista do utilizador, não faz nada. O utilizador carrega nele, não ouve nada, presume que não funcionou e volta a carregar. Algumas reclamações referem que o utilizador carregou no botão cinco ou seis vezes antes de perceber que o carrinho tinha acumulado silenciosamente cinco ou seis artigos.

Envolva a região cart-status em aria-live="polite" e atualize o seu texto sempre que a adição for bem-sucedida. Se o design utilizar uma janela de confirmação, desloque o foco para a janela quando esta se abrir e volte a colocá-lo no botão original quando ela se fechar. Atualize o indicador da quantidade no carrinho com uma mensagem destinada exclusivamente a leitores de ecrã, como «1 artigo adicionado. Total do carrinho: 3 artigos.»

Os controlos compostos apenas por ícones apresentam falhas de forma previsível: o conteúdo visível é um SVG ou um glifo de fonte de ícones, o conteúdo acessível está vazio e a leitura do leitor de ecrã resume-se à função estrutural do elemento, sem nome. O ícone do carrinho acaba por ser anunciado como «link» ou «colapsado»; a bolha de chat como «botão»; a linha de ícones sociais no rodapé como «link, link, link, link, link». O utilizador não tem como saber o que cada um deles faz.

Os ícones de carrinho apresentam falhas com mais frequência do que outros ícones por uma razão de natureza arquitetónica: muitas implementações apresentam a quantidade do carrinho no nome acessível do ícone (por exemplo, o ícone mostra «0» no interior do SVG), e o leitor de ecrã capta apenas o algarismo. As reclamações referem que o ícone do carrinho é anunciado como «3, link» ou «0, link», sem qualquer indicação de que «3» se refere a uma quantidade no carrinho de compras.

Todos os controlos que consistem apenas em ícones precisam de um nome acessível. Adicione um aria-label no botão ou inserir uma etiqueta de texto invisível no seu interior: "Shopping cart, 3 items". Evite incluir números no nome acessível do ícone sem contexto. No caso de ícones decorativos que aparecem ao lado de texto visível, utilize aria-hidden="true" clique no ícone e deixe que o texto funcione como etiqueta.

A página de finalização da compra concentra mais riscos de conformidade por pixel quadrado do que qualquer outra página de um site de comércio eletrónico, e o padrão de falhas é frequente. Listas suspensas de endereços apresentadas como personalizadas <div> componentes que ignoram a tecla de espaço. Os indicadores de campos obrigatórios são apresentados apenas como um asterisco vermelho, sem aria-required e sem qualquer associação programática. Mensagens de erro exibidas em texto vermelho abaixo do campo, sem aria-describedby ao associar o campo ao erro e não haver qualquer indicação na área ativa quando a validação falha. O utilizador preenche o formulário, clica em «Continuar», é redirecionado silenciosamente e não tem como saber quais os campos que falharam nem porquê.

A mesma descrição das reclamações repete-se em centenas de casos: a mensagem de erro não é anunciada, as mensagens de erro são vagas, não é possível introduzir os dados de faturação. Não se trata de erros isolados. Trata-se do comportamento padrão da maioria dos componentes de finalização de compra em lojas online, lançados sem um trabalho explícito de acessibilidade.

Use o verdadeiro <label> elementos associados às entradas por for/id. Indique os campos obrigatórios com aria-required="true" e indique o requisito através de texto visível, não apenas da cor. Em caso de falha na validação, apresente a mensagem de erro dentro do campo de entrada aria-describedby destino, indicar o campo com erro aria-invalid="true"e desloque o foco do teclado para o primeiro campo inválido. Inclua uma área de resumo de erros na parte superior do formulário com links de âncora para cada campo com erros.

O bloco de pagamento é invulgar porque é frequentemente apresentado através de um iframe incorporado de terceiros — Stripe Elements, Braintree Hosted Fields ou um componente integrado da Adyen. Dentro do iframe, o formulário do próprio fornecedor de serviços de pagamento costuma estar bem identificado. Mas no momento em que um site cria o seu próprio formulário de captura de cartão, ou envolve os campos incorporados num layout personalizado que substitui as etiquetas por marcadores de posição visuais, os quatro campos — número, data de validade, CVV, código postal — tornam-se uma linha de campos em branco para um leitor de ecrã.

O campo CVV é aquele que mais frequentemente é mal identificado, pois os designers costumam substituir o seu rótulo por um ícone de ponto de interrogação que abre uma dica explicando o que é o CVV. A dica não é o rótulo; o campo continua a precisar de um nome programático. Quando não o tem, o leitor de ecrã anuncia todo o bloco de pagamento como «editar, editar, editar, editar» e a transação é interrompida.

Se estiver a utilizar uma integração de campos hospedados por terceiros, siga as orientações de acessibilidade do fornecedor — a maioria disponibiliza um método documentado para rotular os campos a partir do exterior do iframe. Se estiver a criar um formulário de captura de cartão personalizado, cada campo de entrada precisa de um <label> elemento com uma etiqueta de texto visível, além de autocomplete="cc-number" / cc-exp" / cc-csc" atributos para que os gestores de palavras-passe e as tecnologias de assistência possam identificar os campos de acordo com a sua finalidade.

A página do carrinho repete a falha do controlador de quantidade da página de detalhes do produto (PDP), mas com consequências mais graves: um utilizador de leitor de ecrã que não consiga utilizar o controlador não consegue concluir a encomenda. O botão «Remover» é, por si só, um anti-padrão — trata-se normalmente de um pequeno ícone em forma de × ao lado de cada item da lista, muitas vezes sem texto visível, sem aria-label, e não há qualquer aviso quando a linha é removida. O utilizador clica no que pensa ser o botão de remoção, a linha desaparece e o leitor de ecrã permanece em silêncio. Não há forma de confirmar se a ação foi bem-sucedida.

Várias reclamações referem um problema semelhante: o total acumulado do carrinho atualiza-se dinamicamente quando as quantidades mudam ou os artigos são removidos, mas o novo total é apresentado como texto DOM normal fora de qualquer área dinâmica, pelo que o utilizador não faz ideia do valor que lhe será cobrado.

Cada item deve apresentar um botão de remoção identificado (por exemplo, "Remove Blue T-Shirt, size M, from cart"). Os controlos de seleção de quantidade devem indicar o seu valor atual como parte do nome acessível ou através de atualizações em tempo real associadas. O subtotal do carrinho deve estar dentro de um aria-live="polite" região, pelo que as alterações são anunciadas. Confirme as remoções através de uma funcionalidade de anulação.

Esta é a categoria mais numerosa do conjunto de dados, pois é o problema cuja deteção implica o menor custo e cuja ignorância acarreta o maior custo. Um leitor de ecrã percorre o DOM, encontra um <input>, e lê o seu nome acessível — que calcula a partir de, por ordem: aria-labelledby, aria-label, uma empresa associada <label for>, o title atributo ou o marcador de posição. Se nenhum deles existir, o leitor de ecrã anuncia apenas a função: «caixa de edição» ou «edição, em branco». Essa frase, quase literalmente, repete-se em centenas de registos de reclamações.

A razão pela qual isto é tão comum é de natureza estrutural. Os sistemas de design modernos costumam apresentar texto de preenchimento dentro do campo de entrada como substituto do rótulo visível, e os programadores partem do princípio de que esse texto de preenchimento desempenha a função de rotulagem. Mas não é assim. O texto de preenchimento desaparece quando o utilizador começa a escrever, não deixa qualquer nome programático e torna o campo inutilizável para quem chegar a ele mais tarde no fluxo ou regressar a ele após um erro.

Cada controlo interativo recebe um rótulo visível, associado programaticamente. <label for="email">Email</label><input id="email" type="email"> é o padrão canónico. Os marcadores de lugar são indicações complementares, não substitutos. Para controlos em que um rótulo visível seja realmente indesejável (caixas de pesquisa, botões com ícones), utilize aria-label com texto descritivo — nunca com o marcador de posição duplicado.

A frase «não anunciado nem com foco» aparece literalmente em mais de 400 registos de reclamação e é uma das frases mais repetidas em todo o conjunto de dados. Descreve um modo de falha específico: surge um modal ou uma caixa de diálogo na página (muitas vezes automaticamente — inscrição na newsletter, verificação de idade, confirmação de localização), o conteúdo visível muda, mas o leitor de ecrã não recebe qualquer sinal de que algo tenha mudado. O foco permanece na página subjacente. O utilizador continua a navegar com a tecla Tab pelo que quer que estivesse por baixo do modal, sem se aperceber de todo que surgiu uma caixa de diálogo que bloqueia a visualização.

Este é o exemplo clássico de um modal que falha em todos os aspetos ao mesmo tempo: não role="dialog", não aria-modal="true", sem mudança programática de foco quando a janela está aberta, sem «foco preso» enquanto a janela está aberta, sem comportamento de fechar ao premir Esc, sem título anunciado. Como todas estas falhas ocorrem em conjunto, corrigir qualquer uma delas isoladamente não resolve o problema.

Utilize um padrão de caixa de diálogo estabelecido (a especificação WAI-ARIA Authoring Practices serve de referência). Ao abrir: desloque o foco para o primeiro elemento com foco dentro da caixa de diálogo, defina aria-modal="true" e role="dialog", atribua um título à caixa de diálogo com aria-labelledby apontando para o seu título. Enquanto estiver aberta: manter o foco dentro da caixa de diálogo. Ao fechar: devolver o foco ao elemento que a ativou. Respeitar a tecla Esc. Se a janela modal interromper um fluxo (por exemplo, reprodução automática ao carregar a página), ofereça ao utilizador um único mecanismo para a fechar definitivamente.

Os indicadores de foco são normalmente desativados deliberadamente por um programador ou designer que considerou o contorno padrão do navegador como ruído visual e escreveu *:focus { outline: none; } numa folha de estilo global. A página apresenta agora um aspeto mais limpo para um utilizador com visão normal que utilize o rato. Para um utilizador com visão normal que utilize o teclado — incluindo a maioria dos utilizadores com baixa visão, utilizadores com deficiências motoras e utilizadores que navegam sem rato — a página torna-se inutilizável. O utilizador pode premir a tecla Tab, mas não consegue ver onde se encontra.

Este é um dos poucos tipos de falha que é visível sem qualquer tecnologia de apoio. Um revisor de controlo de qualidade que percorra a página inicial uma vez, sem recorrer a outras ferramentas, irá detetá-la em menos de um minuto. O facto de as equipas de acessibilidade a encontrarem sistematicamente em sites alvo de litígio, enquanto a revisão interna a ignorou, é um dos sinais mais fiáveis no conjunto de dados de que o site não passou, de todo, nos testes de acessibilidade com teclado.

Nunca desative de forma generalizada :focus contornos sem substituição. Defina um estilo de foco visível — normalmente um contorno de 2 a 3 px com contraste suficiente em relação ao elemento e ao seu fundo — utilizando :focus-visible Assim, o indicador aparece durante a navegação pelo teclado, mas não quando se clica com o rato. Verifique isto em todos os componentes interativos, incluindo widgets personalizados, links dentro de cartões e elementos com tabindex.

O logótipo é a imagem mais visitada num site e uma das que mais frequentemente apresenta erros. Normalmente, está inserido num link que redireciona para a página inicial, mas a imagem é apresentada sem alt, não aria-label no link, sem texto circundante. O leitor de ecrã anuncia apenas “link”, sem qualquer informação sobre para onde leva. Multiplique isso por todas as páginas do site.

A categoria mais ampla — imagens sem texto alternativo — abrange banners, fotografias de produtos, ilustrações de destaque, ícones de redes sociais e o vasto catálogo de imagens de marketing que um site de comércio eletrónico típico disponibiliza. As reclamações nesta categoria citam frequentemente nomes de ficheiros de imagem específicos, indicando que o perito do queixoso realizou uma verificação automática que listou todas as imagens cujo alt O atributo estava em falta ou vazio, quando deveria ter sido descritivo.

Os logótipos devem incluir um texto alternativo que descreva o nome da empresa e, caso o logótipo tenha um link para algum site, o destino — alt="Acme Co. — homepage". As imagens decorativas recebem um atributo alt vazio (alt=""), o que as oculta deliberadamente das tecnologias de assistência. As imagens informativas devem ter um texto alternativo descritivo. Evite a geração automática de texto alternativo a partir de nomes de ficheiros ou de legendas geradas por IA sem revisão humana; os registos de reclamações citam repetidamente casos em que ferramentas de sobreposição descreveram o logótipo de uma empresa como «um sinal azul e amarelo».

Os leitores de ecrã apresentam uma visualização em «lista de links», amplamente utilizada por utilizadores experientes para analisar uma página em segundos. Essa visualização mostra apenas o texto do link, separado do parágrafo em que se insere. Uma página em que cada resumo de blogue termina em «Ler mais» é apresentada nessa vista como quinze entradas idênticas. Uma página com cinco links vazios — <a href="..."></a>, o que é comum quando os ícones estão dentro de elementos de ligação sem qualquer texto alternativo — resulta em cinco espaços em branco.

A solução é bem conhecida, tal como a falha, e é por isso que este padrão continua a surgir nas reclamações — a sua persistência indica um processo de desenvolvimento sem um linter automatizado para o texto dos links e sem uma verificação manual com um leitor de ecrã.

Cada link deve ter um nome acessível que descreva o seu destino ou ação. Substitua frases genéricas por frases descritivas — «Ler mais» torna-se «Saiba mais sobre os resultados do terceiro trimestre». No caso de links que incluem apenas ícones, adicione texto oculto visualmente ou um aria-label. Execute uma verificação automática (Axe, Lighthouse, etc.) para detetar elementos vazios <a> elementos durante a IC.

O vídeo surge em reclamações de duas formas. A primeira é a mais óbvia: um vídeo de marketing, uma demonstração de produto ou um vídeo explicativo é publicado sem legendas, transcrição ou qualquer alternativa textual — e um visitante surdo ou com deficiência auditiva não consegue aceder ao conteúdo. O segundo é mais subtil: um vídeo de destaque que é reproduzido automaticamente ao carregar a página, o que interfere com a saída do leitor de ecrã e viola os controlos de pausa/parar exigidos pelo nível AA das WCAG 2.2 (conforme SC 2.2.2 Pausar, Parar, Ocultar para conteúdo em movimento e SC 1.4.2 para qualquer áudio).

Algumas reclamações incluídas neste conjunto de dados afirmam que «a ausência de legendas nos vídeos do site constitui uma violação da ADA», apresentando esta afirmação como uma conclusão jurídica. A validade dessa interpretação varia consoante a jurisdição e as circunstâncias; o que é mais consistente é o facto de estes vídeos não cumprirem sistematicamente as diretrizes WCAG 2.2 AA, a norma que a maioria dos tribunais e acordos de resolução de litígios considera como o padrão de conformidade aplicável.

Forneça legendas sincronizadas para todos os vídeos pré-gravados com áudio. Forneça também uma transcrição em texto; as transcrições são úteis para utilizadores com dispositivos em silêncio, em ambientes com baixa largura de banda e para fins de indexação. Evite a reprodução automática; se a reprodução automática for necessária por motivos de design, forneça um comando de pausa/parar acessível imediatamente através do teclado. Para conteúdos apenas em vídeo (sem áudio), forneça uma descrição áudio ou uma alternativa em texto.

O registo é o ponto de controlo de toda a experiência de autenticação. Quando o formulário falha, todas as páginas a seguir ficam inacessíveis, e as reclamações frequentemente tratam essa cadeia de falhas como um único obstáculo. O padrão é a mesma falha na identificação do formulário que a E·01, frequentemente combinada com três subfalhas específicas: um botão de alternância «Mostrar palavra-passe» implementado apenas como um ícone, sem nome e sem aviso de alteração de estado; um CAPTCHA que impede totalmente a utilização de leitores de ecrã; e erros embutidos («credenciais inválidas») que são apresentados no ecrã, mas não anunciados.

A caixa de seleção «lembrar-me» é uma falha secundária recorrente adicional: apresentada como um elemento com estilo <div>, com o real <input> oculta fora do ecrã, a caixa de seleção pode ser selecionada com o rato, mas não através do teclado ou de um leitor de ecrã. O utilizador não tem como ativar uma sessão persistente.

Use o verdadeiro <input>, <label>, e <button> elementos. Transforme o botão para mostrar/ocultar a palavra-passe num botão verdadeiro com um nome acessível que se atualize de acordo com o estado ("Show password" / "Hide password") e anunciar a alteração com aria-pressed. Disponibilizar uma alternativa acessível aos CAPTCHAs baseados em imagens (CAPTCHA de áudio ou — de preferência — substituir o CAPTCHA por uma autenticação baseada no risco ou pelas variantes acessíveis do hCaptcha).

Os leitores de ecrã apresentam a página através de três modos de navegação: por título, por ponto de referência e por link. Uma página que seja publicada sem um <h1>, sem <main>, <nav>, e <footer> pontos de referência, e sem um lang="en" atributo no <html> elemento, eliminou simultaneamente esses três modos de navegação. Os utilizadores não têm como percorrer o conteúdo, não têm como saltar para o conteúdo e o leitor de ecrã não consegue carregar o motor de pronúncia adequado.

Trata-se de uma falha invulgarmente propagadora: a ausência de um único ponto de referência provoca uma cascata de falhas a jusante, uma vez que todas as estratégias de navegação dos leitores de ecrã que dependem desse ponto de referência deixam agora de funcionar. As falhas desta categoria costumam enumerar quatro ou cinco problemas estruturais específicos em conjunto, apresentados como prova de que o site carece de uma base semântica.

Cada página recebe uma e apenas uma <h1>, com subtítulos (<h2>, <h3>) aninhadas de forma lógica. Envolva as regiões em elementos de referência HTML5: <header>, <nav>, <main>, <aside>, <footer>. Definir lang na raiz <html> elemento. Valide com um verificador de esboço ou execute document.querySelectorAll('h1').length === 1 como um teste de verificação na integração contínua.

A maior parte do controlo de qualidade em matéria de acessibilidade é realizada em navegadores de computador com o NVDA ou o JAWS. As tecnologias de assistência móveis — o VoiceOver no iOS e o TalkBack no Android — apresentam uma renderização diferente do mesmo DOM, frequentemente com erros distintos. As reclamações utilizam repetidamente a abreviatura «SRU móvel» (utilizador de leitor de ecrã móvel) para assinalar falhas exclusivas da visualização móvel: um menu hambúrguer que funciona com o NVDA no computador, mas não reage no VoiceOver; um botão Apple Pay acessível num portátil, mas não na versão da página para iPhone; mensagens de erro que são anunciadas no computador, mas não no telemóvel.

Os dados sugerem que os réus cuja acessibilidade em computadores de secretária é, de resto, sólida continuam a ser alvo de processos judiciais devido a problemas específicos dos dispositivos móveis. A paridade móvel constitui, por si só, um critério de aprovação na auditoria.

Teste, no mínimo, com o VoiceOver no Safari para iOS e com o TalkBack no Chrome para Android, seguindo os mesmos fluxos que o controlo de qualidade para computador abrange. Preste especial atenção às interações baseadas em gestos, aos botões de pagamento nativos e à leitura dos campos de formulário quando estes recebem o foco. Se existir uma aplicação nativa, submeta-a à mesma verificação — as reclamações abrangem frequentemente tanto a versão web como a aplicação no âmbito do mesmo caso.

A sobreposição de acessibilidade é o único caso neste catálogo em que a falha não reside de todo no site subjacente — reside sim na suposta camada de correção que foi adicionada para a resolver. As reclamações nesta categoria descrevem dois problemas distintos. O primeiro é que as sobreposições não resolvem efetivamente as barreiras subjacentes, pelo que o utilizador se depara com os mesmos modais defeituosos, formulários mal rotulados e erros inesperados, independentemente da presença ou não do widget. O segundo é mais específico: as sobreposições por vezes introduzem novas falhas ao inserir rótulos incorretos, aplicar incorretamente funções ARIA ou interferir com a própria configuração de tecnologia de assistência do utilizador.

Um pormenor digno de nota: as queixas apresentadas em 2024 e 2025 referem cada vez mais o nome do fornecedor da sobreposição. Duas passagens específicas das queixas identificam a UserWay e a AccessiBe em termos inequívocos, e as recentes medidas da FTC criaram um risco explícito de que a adição de uma sobreposição constitua, por si só, prova de uma falha na implementação de medidas corretivas efetivas — em vez de uma defesa contra um processo judicial.

Considere as sobreposições como um indicador, e não como uma solução. Se já tiver uma implementada, planeie um plano de ação para uma correção efetiva que aborde o código subjacente, em vez de o mascarar. O caminho comprovado consiste numa combinação de: um scanner automatizado integrado na integração contínua (CI), uma auditoria manual em conformidade com as WCAG 2.2 AA, testes manuais com, pelo menos, um leitor de ecrã e navegação apenas por teclado, e controlo de qualidade contínuo da acessibilidade no processo de design e engenharia.