Um website pode ter uma apresentação cuidada e continuar a ser difícil de utilizar por quem navega com o teclado, amplia o texto ou utiliza um leitor de ecrã. Um menu que só abre com o rato, um formulário sem identificação clara dos campos ou um botão reconhecível apenas pela cor podem impedir tarefas tão simples como pedir informações ou concluir uma compra.
A acessibilidade web procura eliminar estas barreiras. Num projeto WordPress, deve ser considerada desde a definição da estrutura e do design até ao desenvolvimento, aos conteúdos e aos testes. Não é uma funcionalidade que se acrescenta no fim através de um plugin.
O que significa tornar um website acessível
Um website acessível permite que pessoas com diferentes capacidades visuais, auditivas, motoras ou cognitivas compreendam a informação e utilizem as funcionalidades disponíveis. Isto inclui pessoas com limitações permanentes ou temporárias e quem recorre a tecnologias de apoio, como leitores de ecrã ou comandos por voz.
As Web Content Accessibility Guidelines (WCAG) 2.2, publicadas pelo W3C, são uma referência técnica internacional. Organizam a acessibilidade em quatro princípios: conteúdo percetível, operável, compreensível e robusto. Os critérios de sucesso distribuem-se pelos níveis A, AA e AAA; para atingir o nível AA, é necessário cumprir os critérios aplicáveis dos níveis A e AA.
O nível AA é frequentemente adotado como objetivo técnico de um projeto, mas WCAG e obrigação legal não são sinónimos. O regime aplicável e a versão da norma de referência devem ser confirmados separadamente.
Estrutura e conteúdos que todos conseguem compreender
A organização visual da página deve corresponder à sua estrutura no HTML. Os títulos H1, H2 e H3 estabelecem uma hierarquia; não devem ser escolhidos apenas para aumentar ou reduzir o tamanho da letra. Listas, tabelas, regiões de navegação e outros elementos também precisam de marcação adequada, para que as tecnologias de apoio consigam interpretar o conteúdo.
Títulos, ligações e botões
Uma pessoa que utiliza um leitor de ecrã pode navegar diretamente pelos títulos ou pelas ligações. Por isso, é preferível escrever «Consultar as condições de garantia» em vez de usar repetidamente «Clique aqui», sem contexto suficiente.
Também convém distinguir a função dos elementos: uma ligação conduz a outro destino; um botão executa uma ação, como abrir uma janela, enviar um formulário ou adicionar um produto ao carrinho. Um elemento visualmente semelhante a um botão não deve depender de código improvisado que prejudique a utilização por teclado.
Imagens, vídeo e documentos
O texto alternativo de uma imagem deve transmitir a informação ou a função que se perderia sem ela. Uma fotografia informativa precisa de uma descrição adequada; um gráfico com dados essenciais pode exigir uma explicação mais completa no próprio conteúdo. Já uma imagem puramente decorativa deve, quando inserida com a etiqueta HTML de imagem, ter um atributo vazio (alt="") para não acrescentar informação inútil ao leitor de ecrã.
Em vídeo e áudio, importa prever legendas, transcrições e audiodescrição conforme o conteúdo e os requisitos aplicáveis. Os controlos de reprodução também devem ser acessíveis. O mesmo cuidado estende-se aos PDFs disponibilizados no website: catálogos, fichas técnicas ou formulários podem precisar de títulos estruturados, ordem de leitura correta, etiquetas e campos acessíveis.
Navegação por teclado, foco e componentes interativos
Nem todas as pessoas utilizam rato. É necessário conseguir percorrer e ativar ligações, menus, botões e formulários através do teclado. Um teste inicial consiste em usar Tab, Shift+Tab, Enter, Espaço e, quando apropriado, as setas ou Escape. Deve ser possível identificar o elemento selecionado, utilizá-lo e continuar a navegação sem ficar bloqueado.
O indicador de foco mostra onde está o utilizador. Remover o contorno nativo com CSS sem oferecer uma alternativa visível cria uma barreira. Na WCAG 2.2, o critério AA relativo ao foco não obscurecido também exige que um elemento com foco não fique totalmente escondido por conteúdo criado pelo website, como cabeçalhos ou barras fixas.
Menus que dependem apenas da passagem do rato, sobretudo os que incluem submenus, devem ser revistos para teclado e toque. Nas janelas modais, o foco tem de ser gerido de forma coerente: entrar na janela quando esta abre, permanecer no contexto modal enquanto está ativa e regressar a um ponto lógico após o fecho. O utilizador tem de dispor de uma forma acessível de a fechar.
Carrosséis e outros conteúdos com movimento automático exigem cuidados com a leitura, o controlo de reprodução e o foco. Antes de acrescentar uma animação ou um carrossel, vale a pena perguntar se esse componente é realmente necessário.
Contraste, leitura e utilização em dispositivos móveis
O contraste não deve ser avaliado apenas a olho. Para o nível AA, a WCAG estabelece, em geral, uma relação mínima de 4,5:1 para texto normal e 3:1 para texto grande, com exceções previstas na norma. Existem também requisitos de contraste para determinados componentes e indicadores visuais.
A cor não pode ser o único meio de comunicar informação. Num formulário, um campo incorreto não deve ficar apenas com o contorno vermelho: precisa de uma mensagem que explique o problema. O mesmo princípio aplica-se a gráficos, estados e avisos.
É igualmente importante verificar a ampliação do texto, o zoom, a reorganização do conteúdo em ecrãs estreitos e a utilização em diferentes orientações. A WCAG 2.2 inclui um critério AA para o tamanho mínimo dos alvos de interação, em regra 24 × 24 píxeis CSS ou espaçamento suficiente, sujeito às exceções definidas na norma. Um botão pequeno e demasiado próximo de outro pode ser difícil de utilizar mesmo quando o contraste é adequado.
Formulários: identificar, explicar e permitir corrigir
Cada campo deve ter um nome claro e associado ao respetivo controlo. O texto de exemplo dentro do campo (placeholder) pode ajudar, mas não deve substituir a identificação do campo. As instruções devem esclarecer o formato esperado e quais os dados obrigatórios.
Quando existe um erro, a mensagem deve ser específica e acessível às tecnologias de apoio. «Introduza um endereço de email válido» é mais útil do que «Erro no formulário». A associação entre o erro e o campo, bem como a gestão do foco quando necessária, ajudam o utilizador a corrigir a informação sem recomeçar o processo.
Esta atenção é especialmente importante nos formulários de contacto, registo, autenticação, pedido de orçamento e pagamento, onde uma barreira pode impedir a conclusão da tarefa.
WordPress, Elementor e plugins: a acessibilidade depende do resultado
O projeto WordPress estabelece WCAG 2.2 AA como referência para código novo ou atualizado integrado no próprio WordPress. Isso não significa que qualquer instalação produza automaticamente um website acessível. O resultado depende do tema, dos plugins, dos conteúdos, das configurações e das alterações feitas durante o projeto.
Mesmo a identificação de um tema como accessibility-ready não constitui uma certificação de conformidade WCAG AA do website final. No Elementor e noutros construtores visuais, é possível criar boas estruturas, mas também títulos fora de hierarquia, elementos clicáveis sem semântica adequada ou uma ordem de leitura diferente da apresentação visual.
As integrações externas merecem a mesma atenção: plataformas de pagamento, formulários, ferramentas de consentimento de cookies, chats, mapas e sistemas de reservas podem introduzir problemas de teclado, contraste ou identificação dos controlos. Devem ser avaliadas no contexto real em que serão utilizadas.
Os plugins e as barras de acessibilidade que permitem ampliar texto ou alterar cores podem oferecer funções úteis, mas não corrigem automaticamente formulários mal estruturados, janelas sem gestão de foco, documentos inacessíveis ou componentes que não funcionam por teclado. A conformidade não pode ser garantida por uma camada adicional de interface.
WooCommerce: testar o percurso de compra completo
Numa loja online, não chega verificar a página inicial ou a ficha de produto. A avaliação deve acompanhar o percurso que o cliente realmente faz:
- Encontrar um produto, interpretar as informações e selecionar eventuais variações.
- Adicionar ao carrinho, alterar quantidades e aplicar um cupão, quando disponível.
- Preencher os dados de compra, identificar erros e corrigi-los.
- Escolher entrega e pagamento, incluindo eventuais interfaces externas.
- Confirmar que a encomenda foi registada e compreender o resultado apresentado.
Estes passos devem funcionar com teclado e tecnologias de apoio, tanto em computador como em telemóvel. Uma loja pode ter páginas visualmente acessíveis e falhar precisamente na finalização da compra (checkout).
Como integrar a acessibilidade no projeto e nos testes
Os verificadores automáticos ajudam a detetar problemas de contraste, alternativas textuais em falta, campos sem identificação e determinados erros de HTML ou ARIA. Contudo, um resultado positivo numa ferramenta não comprova, por si só, a acessibilidade do website. O W3C recomenda combinar a análise automática com avaliação humana.
Os testes manuais devem incluir navegação por teclado, foco visível, ampliação e zoom, telemóvel e leitores de ecrã. Nos percursos mais relevantes, é útil envolver pessoas que utilizam tecnologias de apoio. É necessário testar não só páginas isoladas, mas também tarefas completas, mensagens de erro e alterações dinâmicas.
A distribuição do trabalho pode seguir este plano:
| Fase | O que prever ou verificar |
|---|---|
| Planeamento | Identificar páginas, funcionalidades críticas, requisitos e responsabilidades. |
| Design | Definir contrastes, estados de foco, tamanhos, disposição responsiva e interações. |
| Desenvolvimento | Rever HTML semântico, teclado, formulários, menus, janelas e integrações. |
| Conteúdos | Verificar títulos, ligações, textos alternativos, multimédia e PDFs. |
| Validação | Combinar testes automáticos e manuais; corrigir barreiras por impacto. |
| Manutenção | Aplicar orientações editoriais e rever novas páginas, plugins e funcionalidades. |
Corrigir um componente antes de o reutilizar em várias páginas tende a ser mais simples do que reparar o mesmo problema depois do lançamento. A acessibilidade deve, por isso, fazer parte da definição do projeto e da manutenção editorial.
Acessibilidade e legislação em Portugal: o que é obrigatório?
Não existe uma regra universal segundo a qual todos os websites portugueses têm de cumprir WCAG 2.2 AA. O enquadramento varia consoante a entidade, o serviço prestado e os requisitos legais aplicáveis.
| Contexto | Referência principal |
|---|---|
| Organismos públicos e outras entidades abrangidas | Decreto-Lei n.º 83/2018, relativo à acessibilidade dos websites e aplicações móveis dessas entidades. |
| Serviços abrangidos, incluindo comércio eletrónico dirigido a consumidores | Decreto-Lei n.º 82/2022, que transpôs a Diretiva (UE) 2019/882. |
| Website empresarial meramente informativo | A sua existência, por si só, não determina a aplicação do regime de comércio eletrónico; é necessário confirmar se existem outras obrigações. |
O Decreto-Lei n.º 82/2022 produz efeitos, em geral, desde 28 de junho de 2025 para os produtos e serviços a que se aplica. Abrange serviços de comércio eletrónico, na aceção legal de serviços destinados à celebração de contratos de consumo à distância. Contém exclusões específicas, incluindo a das microempresas prestadoras dos serviços abrangidos, bem como disposições transitórias e mecanismos relativos a alterações fundamentais ou encargos desproporcionados. Estas situações exigem uma análise concreta; uma empresa pequena não deve assumir automaticamente que está dispensada de todas as obrigações de acessibilidade.
Há ainda uma distinção técnica relevante: a norma europeia EN 301 549 v4.1.1, publicada em setembro de 2026, passou a incorporar a WCAG 2.2. No entanto, a publicação de uma versão técnica não a transforma, por si só, na referência harmonizada para demonstrar conformidade legal. Essa condição depende da respetiva citação no Jornal Oficial da União Europeia e do regime aplicável.
Para um projeto abrangido por obrigações legais, o procedimento adequado é identificar o enquadramento, definir os requisitos técnicos, testar e documentar as decisões. Quando existam dúvidas sobre o alcance da obrigação ou das exceções, é necessária validação jurídica. Este artigo apresenta orientação técnica e não substitui essa análise.
Conclusão
A acessibilidade de um website WordPress mede-se pela possibilidade real de compreender a informação e concluir tarefas, utilizando diferentes formas de navegação e interação. Estrutura, contraste, formulários, conteúdos e componentes externos precisam de funcionar em conjunto.
Prever estes cuidados desde o início, testar os percursos relevantes e manter critérios editoriais após a publicação é mais consistente do que tentar corrigir tudo com um plugin no final.
