Vale a pena usar um plug-in de acessibilidade?
- Patrícia
- há 4 dias
- 12 min de leitura
Atualizado: há 3 dias
Introdução
Plugins de acessibilidade, também conhecidos como “accessibility overlays”: vale a pena implementá-los num website? Se já o fez ou pensa fazê-lo, este artigo pretende esclarecer porque deverá reconsiderar essa opção. Serão esclarecidos alguns mitos sobre a sua eficácia e partilhadas opiniões de utilizadores com deficiência e de especialistas em acessibilidade, bem como alternativas ao seu uso.
O que é um plug-in de acessibilidade?
Nos mais variados websites, é cada vez mais comum encontrar uma overlay de acessibilidade. Muitas vezes, o botão pop-up assemelha-se a um ícone na pose de “homem de vitrúvio” ou o símbolo da deficiência; e, ao quando é clicado, apresenta opções de estilização da página. E o que pensamos, muitas vezes? Que esse website é acessível.
É essa a mensagem induzida pelo produto e o seu marketing. Se visitarmos o website de alguns plugins populares, encontramos citações como:
"O Userway potencia conformidade com acessibilidade digital em websites por todo o mundo. Identifique e corrija erros de código automaticamente". (Userway)
"Conformidade: Correcção baseada nas Directrizes de Acessibilidade para Conteúdo Web (WCAG) 2.1. nível AA, para conformidade com o Americans with Disabilities Act (ADA)". (AccessiBe)
"Entrega verdadeira acessibilidade através de automatismos baseados em Inteligência Artificial (...) As melhores soluções de conformidade com o Americans with Disabilities Act à medida". (EqualWeb)
Em suma, estes plugins prometem:
Conformidade com as Directrizes de Acessibilidade para Conteúdo Web (WCAG);
Conformidade com leis que exigem o cumprimento dessas normas;
Correcção automática de erros de código;
“Verdadeira acessibilidade”.
Ainda assim, lendo entre as linhas, vemos palavras que nos indicam:
“Através de automatismos”: A correcção feita pelos plugins é apenas automática.
“Potencia conformidade”: Não a providencia directamente, apenas potencia - fica à interpretação do leitor o que significa “potenciar”.
“Correcção baseada nas WCAG”: As alterações efectuadas podem ser apenas “inspiradas”/baseadas nas WCAG, e não realmente segui-las verdadeiramente.
Na verdade, os plugins induzem o leitor em erro, achando que é mais eficaz do que realmente é. Falemos então das limitações destas identificações e correcções automáticas.
Qual é o problema das verificações automáticas?
As Directrizes de Acessibilidade para Conteúdo Web (WCAG) 2.1 nível A e AA têm 37 critérios a seguir, base para as leis Europeias. Para cada um, existem vários pontos a analisar. No entanto, os validadores automáticos apenas identificam um máximo de cerca de 30% dos problemas, porque os restantes exigem uma compreensão subjectiva de contexto e propósito dos elementos, avaliadas manualmente (fonte: “How do accessibility automated checkers compare?”).
Como ferramenta complementar à avaliação manual, as verificações automáticas podem ser úteis para um auditor que conheça bem as suas limitações. O WAVE é uma destas ferramentas amplamente utilizadas, bem como o AccessMonitor, em Portugal. No entanto, são substancialmente insuficientes em si mesmas.
O mesmo se irá aplicar a estes plugins. Se fossem validadores automáticos especializados, o máximo que conseguiriam identificar seria por volta dos 30% dos problemas. No entanto, não são nem pretendem sê-lo - e não sabemos quantos erros identificam realmente. Mas o seu propósito vai para além disso: prometem até a correcção automática de todos os problemas.
Qual é o problema das correcções automáticas destes plugins?
Há vários problemas associados a correcções automáticas. Primeiro, não são feitas a nível nativo, pelo que não garantem compatibilidade para quem já utiliza as suas próprias tecnologias de apoio; em segundo lugar, não é possível fazer um website ficar em conformidade com as WCAG apenas através de automatismos; por último, por vezes, os códigos destes plugins aplicam práticas questionáveis que interferem com ferramentas de avaliação de acessibilidade como o WAVE e, quando activados, interferem até com as tecnologias de apoio dos utilizadores.
A experiência de base não é conforme com as WCAG
Os princípios das Directrizes de Acessibilidade são que o conteúdo deve ser, para todos os utilizadores: Percepcionável, Compreensível, Operável e Robusto. O que isto significa é que todo o conteúdo deve ser utilizável por todos os utilizadores de raiz ou, se necessário, com uma alternativa. Alguns exemplos concretos:
Conteúdo percepcionável: um utilizador surdo deve ter acesso a legendas para um vídeo com áudio; etc.
Conteúdo compreensível: relaciona-se com o uso de linguagem compreensível, por exemplo, mensagens de erro claras em formulários;
Conteúdo operável: funcionalidades interactivas devem ser activáveis por todos os utilizadores: quer por pessoas que usam o rato, como para quem navega através do teclado ou tecnologia equivalente - devido a problemas de mobilidade ou de visão.
Conteúdo robusto: o código do website deve cumprir com todas as normas necessárias que o tornam plenamente compatível com qualquer tecnologia de apoio que exista (como leitores de ecrã).
Todos os exemplos aqui mencionados são referentes a conteúdos que fazem parte do website, de base. As legendas são adicionadas ao vídeo pelo criador de conteúdos, e só ele consegue garantir a sua completa precisão e sincronia com o som, bem com aplicar guidelines de leiturabilidade; as instruções de um formulário e a sua clareza não são alteradas por plugins, nem é possível, por automatismo, garantir que foram redigidas adequadamente; e só um código de base correcto consegue garantir que as preferências do utilizador sejam respeitadas, seguindo o princípio da robustez. E poderíamos continuar.
Porém, o plugin e as suas soluções automatizadas não corrigem este tipo de erros se eles existirem de raiz no website e no seu código original. É uma cortina de código aplicada por cima deste; o que se chama uma solução de “penso rápido”: pode acrescentar algumas coisas e tentar compensá-las, mas não cura a ferida de base - e não é construído para respeitar as preferências que os utilizadores já usam no seu dia-a-dia.
Os plugins não conseguem corrigir (a maioria dos) problemas
Como mencionado, um validador automático só descobre até 30% dos problemas de um site. Já isso é uma limitação; mas, depois de identificados, há pouco que é possível corrigir automaticamente sem o envolvimento de alguém especializado. Muitas correcções exigem compreensão subjectiva sobre o contexto para diagnosticar problema e saber como o corrigir. Vejamos dois exemplos:
Imagens: texto alternativo
Um validador automático consegue descobrir que uma imagem não tem texto alternativo, não sendo lida por um leitor de ecrã, e assinalar isso como um erro. E LLMs podem tentar criar uma descrição automática da imagem. No entanto, só um ser humano consegue perceber, pelo contexto, se a imagem é ou não decorativa, e qual o seu propósito, e a partir daí decidir como deve ser o texto alternativo. Só ele consegue garantir que o texto alternativo é fiável, conciso e adequado à circunstância.
Neste sentido, uma ferramenta automática não consegue corrigir texto alternativo.
Exemplo concreto: pôr animações em pausa
Agora, um exemplo concreto: um especialista em acessibilidade testou o overlay UserWay para perceber a sua eficácia com as funções disponíveis no mesmo. Um dos vários problemas que encontrou foi com o botão “Pôr animações em pausa”. Demonstrou-o no vídeo “How UserWay (accessibility overlay) does not work” - ATENÇÃO: este vídeo pode causar convulsões para pessoas com epilepsia foto-sensível. Por favor, não clique no link se tiver esta condição: em vez disso, leia a descrição que se segue.
Eis o que acontece: O website tem uma animação em loop que vai mudando, circulando por vários gifs animados. Quando se selecciona a opção “Pôr animações em pausa”, a partir do overlay, cada um destes gifs é posto em pausa, um de cada vez, transitando para o seguinte, que também é posto em pausa, e assim sucessivamente. Isto ocorre tão rapidamente que causa um efeito de flash perigoso para pessoas com epilepsia foto-sensível - ironicamente, as que precisariam mais da opção - e coloca-as ainda mais em risco de sofrer convulsões do que se não tivessem clicado.
Ao tentar corrigir um problema através de automatismos, sem saber a sua origem, o UserWay cria um novo problema - neste caso, uma grave ameaça à saúde do utilizador.
Em suma: plugins têm um alcance muito limitado e, mesmo quando uma ferramenta automática identifica um problema, só um ser humano consegue corrigi-lo adequadamente.
Bloquear e interferir com ferramentas de validação automática
Apesar das suas limitações, há ferramentas de análise automáticas especializadas, como o WAVE, que são usadas por especialistas de acessibilidade como uma das suas ferramentas de trabalho, não exclusiva, mas complementar, permitindo descobrir determinados tipos de erros mais rapidamente.
No entanto, alguns plugins de acessibilidade, como o UserWay, bloqueiam ou interferem com estas ferramentas:
“Quando a ferramenta WAVE é activada, o UserWay altera a página de uma forma que interfere com a capacidade do WAVE de testar a página com precisão. O UserWay injecta código na página (...) interferindo com a eficácia e precisão de outro produto (...) convencendo o cliente do UserWay de que não é necessário empreender mais esforços em relação a acessibilidade.” (overlayfalseclaims.com)
A perspectiva dos especialistas e utilizadores
Segundo um inquérito de 2021, 72% dos utilizadores com deficiência considerava que este tipo de plugin era “nada eficaz” ou “não muito eficaz”; apenas 3,3% o considerava muito eficaz (Webaim, Overlay).
Mas, na Alemanha, já se considera que o impacto vai para lá da ineficácia. Desde 2025 que, neste país, não é possível certificar websites que utilizem overlays de acessibilidade como sendo acessíveis ou conformes com com as leis nacionais e Europeias de Acessibilidade, de acordo com a regulamentação Barrierefreie-Informationstechnik-Verordnung - BITV, respectiva a requisitos de acessibilidade web aplicáveis à administração pública. Segundo a documentação oficial sobre o procedimento BITV, estas ferramentas podem até deteriorar a acessibilidade do website.
Vão de encontro às mesmas preocupações o European Disability Forum (EDF), que trabalha com o Parlamento Europeu, a Comissão Europeia e outras instituições da União Europeia, e a Associação Internacional de Profissionais de Acessibilidade (IAAP), afirmando publicamente que Overlays de Acessibilidade não garantem conformidade com a legislação europeia. Num statement oficial. Justificam a posição com problematizações relativas às mencionadas neste artigo, como:
A sobreposição forçada do plug-in sobre as definições do utilizador: "Utilizadores de tecnologias de apoio têm os seus dispositivos e browsers configurados para as suas definições preferenciais. A tecnologia de overlay pode interferir com a tecnologia de apoio do utilizador e sobrepôr-se às suas definições, forçando-o a usar, em vez disso, o overlay. Isto torna o website menos acessível (...)";
Recolha de dados sensíveis contra a privacidade do utilizador: "Algumas overlays detectam quando há uma tecnologia de apoio activa no dispositivo de um utilizador (...) e informação sobre deficiência é um dado pessoal sensível";
Informação enganosa: "Criadores de websites que não sejam especialistas de acessibilidade podem ser levados a crer que overlays 'corrigem' a acessibilidade de um site, que não é o caso. Overlays não fazem um website acessível nem conforme com legislação Europeia relativa a acessibilidade (...)"
Com vista à consciencialização sobre o assunto, também vários especialistas criaram a “Overlay Fact Sheet”, assinada até à data por 1031 especialistas em acessibilidade e utilizadores com deficiência de todo o mundo. À semelhança das instituições já mencionadas, a “fact sheet”:
desmistifica desconhecimentos e mitos sobre plugins de acessibilidade,
alerta para potenciais problemas de privacidade associados a recolha de dados sensíveis dos utilizadores,
e apresenta testemunhos de utilizadores sobre as suas experiências com estes plugins.
Em suma, procura esclarecer ao público em geral que a verdadeira acessibilidade se alcança corrigindo o código do próprio site e através de esforços empreendidos continuamente sobre a acessibilidade do site, e não através de plugins “penso-rápido”. Nela encontram-se testemunhos como os apresentados em seguida.
Alguns testemunhos sobre overlays/plugins de acessibilidade:
“O #AccessiBe faz os sites mais difíceis de usar (...). Eu e um aluno descobrimos um site “melhorado” [pelo AccessiBe] e com pena minha, saímos dele porque navegar nessa confusão ia para além das minhas capacidades nesse dia.”
“Cada vez que vou a um website e oiço a notificação do #AccessiBe de que o site está adaptado para o meu leitor de ecrã, eu sei que o meu blocker não está a funcionar correctamente e que me vou deparar com um pesadelo de experiência naquele website em particular.”
Mas existem diferentes plugins. São todos iguais?
Não são todos exactamente iguais, mas o consenso entre especialistas identifica que, no geral, todos são pouco ou nada eficazes a corrigir os problemas que propõem remediar.
Então quer dizer que os utilizadores não usam estes plugins, nunca?
Não podemos afirmar isso, porque “nunca” é uma generalização demasiado assertiva. Pode haver pessoas que o façam. Por outro lado, outros utilizadores com deficiência chegam a usar adblockers especializados para bloquear os efeitos destes plugins, para evitar a sua interferência com as suas acções e definições.
Em suma, podemos dizer que, tendencialmente, os utilizadores que dependem se soluções de acessibilidade já as usam transversalmente para todos os sites que visita, e não apenas naqueles que têm o plugin de acessibilidade. Por isso, cada website deve ser compatível com as tecnologias e estratégias usadas por eles, e isso alcança-se seguindo as recomendações das WCAG.
Assim, deve-se providenciar as medidas de acessibilidade essenciais das WCAG e depois, se achar necessário, desenvolver e disponibilizar opções extra numa secção de “settings” criada e testada especialmente para o website.
Quais são as alternativas ao plugin?
Como afirmado, mais do que corrigir problemas do website, muitas funcionalidades destes plugins são opções de preferências (às vezes apenas estéticas) que pretendem emular softwares e tecnologias de apoio ou estratégias adaptativas já existentes, que os utilizadores que precisam provavelmente já utilizarão no seu dia-a-dia.
Neste sentido, há alternativas para as funcionalidades destes plugins, tanto a nível do website como a nível pessoal para os utilizadores. Aqui estão alguns exemplos de funcionalidades mais úteis baseadas nas opções do UserWay.
Opções de overlay | Solução nativa no website | Soluções para o utilizador |
|---|---|---|
Alto contraste | Para todos os elementos do site aplicáveis, usar um template de cores com contraste em conformidade com as WCAG 2.1. AA (mínimo) ou, para ir mais além, AAA (avançado). Para ir mais além, providenciar, através de “media queries”, opções de alto contraste que se adaptem às preferências dos utilizadores cujas definições pessoais já o peçam, por exemplo light/dark mode. | Usar opções do sistema operativo ou uma extensão de browser que force alto contraste segundo a necessidade do utilizador, por exemplo: |
Alterar o tipo de letra, alinhar o texto, mudar o espaçamento entre linhas | Respeitar as preferências do browser e sistema operativo do utilizador. Para ir mais além, providenciar uma secção de definições com opções específicas através de javascript, de acordo com as preferências que se pretenda incluir. | Personalizar o tipo de letra pelas definições do browser. Usar uma extensão de browser que permita personalizar a página (espaçamento, tipo de letra, etc), por exemplo: |
Aumentar o tamanho do texto | Garantir que a página é responsiva para que o utilizador não seja afectado ao usar zoom ou outras opções pessoais. Para ir mais além, providenciar opções numa secção de definições. | Personalizar o tamanho do texto pelas definições do browser e/ou sistema operativo; e/ou usar extensões de browser como o Zoom Text Only (Chrome) ou Text Zoom to increase font size (Chrome) e/ou fazer zoom com Ctrl + scroll up |
Leitor de ecrã ou Text to speech (vocalizar o texto no ecrã) | Permitir o uso e compatibilidade com leitores de ecrã através de um código completo e adequado | Usar um leitor de ecrã Ou usar uma extensão de browser como Read Aloud: A text to speech voice reader (Chrome) Ou usar outros softwares e definições de sistema operativo que leiam o texto em voz alta. |
Pôr animações em pausa | Providenciar um botão de pausa ou opções para parar ou ocultar para as animações necessárias (requerido pelas WCAG nível AA para certas animações). Respeitar as preferências do utilizador para movimento reduzido com a media feature do CSS prefers-reduced-motion. | Usar definições do browser para desactivar as animações: Desactivar animações no Firefox Ou usar extensões como Animation Policy (Chrome) |
Aumentar o tamanho do cursor | Normalmente, deixa-se ao critério do utilizador; porém seria possível, com javascript, oferecer opções no website. | Mudar a cor e/ou tamanho do cursor: No Windows, em Definições > Acessibilidade > Tamanho do cursor. No iMac em Preferências do Sistema. Ou usar extensões como: Custom Cursor for Chrome. |
Ocultar imagens | Normalmente, deixa-se ao critério do utilizador; porém seria possível, com javascript, oferecer esta opção no website. |
Conclusão
O uso de plugins de acessibilidade como o UserWay não é suficiente para providenciar os requisitos mínimos de acessibilidade dispostos nas WCAG, porque não conseguem corrigir problemas de fundo e podem até causar interferência negativa na experiência do utilizador.
Em vez disso, o website deve cumprir as WCAG nativamente e garantir compatibilidade com diversas tecnologias de apoio e necessidades básicas de acessibilidade, para que o utilizador possa usar as suas próprias soluções a nível pessoal. Além disso, o website pode optar por ir mais além e providenciar soluções extra criando e disponibilizando uma secção de definições do website, com recurso a javascript, construída de raiz no website.
Em suma, não só é possível ter um website acessível e conforme com as WCAG e leis Europeias sem plugins de acessibilidade, como é até mais seguro, fiável, e respeitador das suas preferências e privacidade do utilizador - sendo um plugin automático em nada contribui para essa conformidade pois não consegue fazê-lo, nem se aproxima disso.
Assim, apesar de estes plugins poderem melhorar um pouco a experiência, especialmente a nível estético, de alguns utilizadores, deve-se ter a consciência de que, regra geral, nada acrescentam a quem usa as suas próprias tecnologias de apoio no dia-a-dia e em todos os websites e, como afirmado pelo European Disability Forum, "não constituem uma alternativa aceitável ou um substituto para a correcção do próprio website"; sendo assim, deve-se pensar na acessibilidade como algo inerente ao website, e empreender esforços no sentido de a garantir e manter, em continuidade, a nível nativo.
Artigo editado a 9 de Agosto de 2026: Foram corrigidas pequenas gafes e acrescentado um parágrafo sobre o statement do European Disability Forum, bem uma citação do mesmo na conclusão.
Comentários