O que significa, na prática, a WCAG 2.1 AA
WCAG 2.1 AA é um conjunto de requisitos de acessibilidade para websites, aplicações e documentos digitais. WCAG significa Web Content Accessibility Guidelines. Estas regras foram concebidas para ajudar a tornar os serviços digitais utilizáveis por pessoas com deficiência, incluindo pessoas cegas ou com baixa visão, surdas ou com dificuldades auditivas, com mobilidade reduzida, com incapacidades cognitivas, dificuldades de aprendizagem ou incapacidades temporárias, como um braço partido ou fadiga ocular.
Para leitores não técnicos, a forma mais simples de pensar na WCAG 2.1 AA é esta: trata-se de uma norma reconhecida para fazer com que o conteúdo digital funcione para mais pessoas. Abrange aspetos como a legibilidade do texto, a utilização de um website com teclado, a capacidade de os leitores de ecrã compreenderem a estrutura da página e a clareza e usabilidade dos formulários.
A parte 2.1 refere-se à versão da norma. A parte AA refere-se ao nível de conformidade. A WCAG tem três níveis: A, AA e AAA. O nível A é o mínimo básico. O nível AA é o nível a que a maioria das organizações procura chegar e o nível mais frequentemente exigido por lei ou por política interna. O nível AAA é mais exigente e, normalmente, não é exigido em todo um website.
Quando se diz que um site está “em conformidade com a WCAG 2.1 AA”, normalmente quer dizer que o site foi concebido e testado para cumprir os critérios de sucesso dos níveis A e AA da WCAG 2.1. Na realidade, a acessibilidade não é um selo que se obtém uma única vez. É um processo contínuo de conceção, gestão de conteúdos, testes e melhoria.
Porque é que a WCAG é importante
A acessibilidade é frequentemente discutida como uma exigência legal, mas é igualmente uma questão de usabilidade básica e de serviço público. Se alguém não consegue preencher um formulário, ler um documento de política, marcar uma consulta ou compreender informação importante devido a barreiras evitáveis, o serviço não está a funcionar corretamente.
A WCAG ajuda as organizações a identificar e reduzir essas barreiras. Fornece um quadro comum que designers, developers, equipas de conteúdos, equipas de contratação e decisores podem utilizar. Isto é especialmente importante no setor público, onde os serviços digitais têm de funcionar para o maior público possível.
As melhorias de acessibilidade costumam beneficiar toda a gente, e não apenas os utilizadores com deficiência. Cabeçalhos claros tornam as páginas mais fáceis de percorrer. Um bom contraste de cores ajuda em ecrãs móveis sob luz solar intensa. As legendas ajudam pessoas em locais ruidosos. Os formulários compatíveis com teclado ajudam utilizadores avançados. A linguagem simples ajuda toda a gente a perceber o que fazer a seguir.
Os quatro princípios da WCAG
A WCAG assenta em quatro princípios fundamentais. O conteúdo deve ser Perceivable, Operable, Understandable and Robust. Em português, são frequentemente resumidos por POUR.
Perceivable
Os utilizadores têm de conseguir perceber a informação apresentada. Isto significa que o conteúdo não deve depender apenas de um sentido, como a visão ou a audição. Exemplos incluem fornecer alternativas em texto para imagens, legendas para vídeos e contraste de cores suficiente entre o texto e o fundo.
Operable
Os utilizadores têm de conseguir operar a interface. Um site não deve exigir movimentos precisos do rato ou gestos que algumas pessoas não consigam realizar. Muitos utilizadores dependem de um teclado, de um dispositivo de comutação ou de controlo por voz. A navegação e os formulários devem, por isso, funcionar sem rato.
Understandable
Os utilizadores têm de conseguir compreender tanto a informação como o modo de funcionamento da interface. As páginas devem ser previsíveis, as instruções devem ser claras e os formulários devem explicar os erros de forma útil. Uma redação complicada pode, por si só, constituir um problema de acessibilidade.
Robust
O conteúdo deve funcionar de forma fiável com diferentes browsers, dispositivos e tecnologias de apoio, como leitores de ecrã. Isto depende da utilização de uma estrutura e de um código adequados, para que a tecnologia possa interpretar corretamente o conteúdo.
O que a WCAG 2.1 AA costuma abranger
Embora a norma seja detalhada, muitos dos seus requisitos podem ser compreendidos em termos simples. Ao nível WCAG 2.1 AA, espera-se normalmente que as organizações tratem questões como:
- Alternativas em texto: imagens com significado devem ter texto alternativo, para que os utilizadores de leitores de ecrã possam compreender a sua finalidade.
- Legendas e transcrições: vídeos pré-gravados devem incluir legendas e, quando apropriado, o conteúdo áudio deve ter transcrições.
- Contraste de cores: o texto e os principais elementos da interface devem destacar-se claramente do fundo.
- Acesso por teclado: os utilizadores devem poder navegar em menus, ligações, botões e formulários usando apenas o teclado.
- Foco visível: deve existir um indicador visual claro que mostre qual o elemento atualmente selecionado quando se navega por teclado.
- Cabeçalhos e estrutura claros: as páginas devem usar corretamente cabeçalhos, listas e etiquetas, para que o conteúdo seja fácil de seguir.
- Acessibilidade de formulários: os campos devem ter etiquetas, as instruções devem ser claras e os erros devem ser explicados de forma que os utilizadores possam compreender e corrigir.
- Texto redimensionável e layout responsivo: o conteúdo deve continuar utilizável quando os utilizadores aumentam o zoom ou o visualizam em ecrãs mais pequenos.
- Finalidade das ligações: as ligações devem fazer sentido, especialmente fora de contexto. “Leia mais” por si só muitas vezes não é suficiente.
- Navegação consistente: os elementos repetidos devem comportar-se de forma previsível em todo o site.
- Compatibilidade com leitores de ecrã: o código e a estrutura subjacentes devem permitir que as tecnologias de apoio interpretem corretamente o conteúdo.
- Sem barreiras desnecessárias: o conteúdo não deve piscar de forma que possa desencadear crises epilépticas, e as interações não devem depender apenas de gestos complexos.
A WCAG 2.1 introduziu requisitos adicionais especialmente relevantes para a utilização em dispositivos móveis e para utilizadores com baixa visão ou incapacidades cognitivas. Entre estes contam-se a orientação, o reflow, os métodos de introdução de dados e a identificação da finalidade da introdução.
Quem tem de cumprir a WCAG 2.1 AA
A resposta depende do país, do setor e do enquadramento legal, mas, em termos gerais, os organismos do setor público são muito frequentemente obrigados a cumprir a WCAG 2.1 AA nos websites e aplicações móveis. Em toda a UE, as entidades públicas estiveram sujeitas a requisitos de acessibilidade ao abrigo da Web Accessibility Directive, o que levou muitas organizações a adotar a WCAG 2.1 AA como referência prática.
Isto inclui, normalmente, a administração central, as autarquias, o SNS e entidades de saúde, universidades, escolas, reguladores e outras instituições públicas, embora o âmbito exato e as exceções variem consoante o país.
As organizações do setor privado também podem ter de cumprir, sobretudo quando prestam serviços essenciais ao consumidor ou operam em setores regulados. Mesmo quando não existe uma obrigação legal direta, a WCAG 2.1 AA é amplamente utilizada em contratação pública, contratos, políticas internas e gestão de risco.
Também é comum as organizações exigirem que os fornecedores cumpram a WCAG 2.1 AA quando adquirem websites, intranets, portais, sistemas de marcação ou plataformas de documentos. Na prática, isto significa que a acessibilidade não é apenas uma questão legal para a organização que publica o conteúdo, mas também para as agências e fornecedores de software que a apoiam.
A ligação com o European Accessibility Act
O European Accessibility Act, ou EAA, é distinto da Web Accessibility Directive, mas ambos têm finalidades muito próximas. Os dois visam melhorar a acessibilidade, mas aplicam-se a áreas diferentes.
A Web Accessibility Directive centra-se sobretudo nos websites e aplicações móveis dos organismos do setor público. O EAA alarga os requisitos de acessibilidade a partes do setor privado, abrangendo determinados produtos e serviços colocados no mercado da UE, como serviços de comércio eletrónico, serviços bancários, e-books, máquinas de venda de bilhetes, terminais bancários para consumidores e alguns serviços digitais relacionados com transportes.
Para leitores não técnicos, o ponto importante é este: o EAA aumenta a pressão sobre as organizações para levarem a acessibilidade digital a sério. Mesmo que uma equipa conheça apenas as regras do setor público, a direção europeia mais ampla é clara. A acessibilidade está a tornar-se uma expectativa padrão em cada vez mais serviços digitais, e não um requisito de nicho.
A WCAG é frequentemente utilizada como referência prática para conteúdos web e interfaces digitais quando se demonstra acessibilidade, ainda que os textos legais possam referir normas mais amplas ou normas europeias harmonizadas. Por outras palavras, se uma organização se está a preparar para obrigações relacionadas com o EAA, compreender a WCAG 2.1 AA é um ponto de partida sensato.
Cumprir significa que todas as páginas são perfeitas?
Não necessariamente. As grandes organizações têm frequentemente sistemas legados, PDFs antigos, ferramentas de terceiros e conteúdos arquivados que criam desafios. A conformidade é normalmente avaliada face aos requisitos efetivamente abrangidos, e muitas entidades públicas publicam uma declaração de acessibilidade a explicar o que está conforme, o que não está e o que estão a fazer para melhorar.
Dito isto, as declarações de acessibilidade não substituem a ação. Servem para dar transparência, não para encobrir problemas evitáveis. Um programa de acessibilidade realista inclui governação, testes, priorização e revisão regular.
Como testar a WCAG 2.1 AA
Testar a acessibilidade corretamente envolve mais do que executar um verificador automático. As ferramentas automáticas são úteis, mas só conseguem identificar alguns problemas. Muitos problemas importantes de acessibilidade exigem revisão humana.
1. Comece por verificações automáticas
As ferramentas automáticas podem assinalar rapidamente problemas comuns, como texto alternativo em falta, contraste de cores insuficiente, botões vazios, etiquetas de formulário em falta ou problemas na estrutura dos cabeçalhos. São úteis para detetar erros óbvios em grande escala, sobretudo durante o desenvolvimento e a publicação de conteúdos.
No entanto, as ferramentas automáticas não conseguem avaliar de forma fiável se o texto alternativo é significativo, se as instruções são claras, se a ordem de navegação por teclado faz sentido ou se um utilizador consegue concluir uma tarefa sem confusão.
2. Teste com teclado
Um teste simples, mas muito eficaz, é afastar o rato e tentar utilizar o site apenas com o teclado. Consegue percorrer menus, ligações, botões e formulários? Consegue ver onde está o foco? Consegue abrir e fechar elementos interativos? Consegue submeter um formulário e corrigir um erro?
Se a utilização por teclado for difícil, é provável que o site apresente barreiras sérias para muitos utilizadores.
3. Reveja manualmente o conteúdo e o design
A revisão manual deve abranger cabeçalhos, texto das ligações, instruções, mensagens de erro, títulos de página, utilização da cor, estrutura dos documentos e clareza geral. Uma página pode passar numa análise automática e, ainda assim, ser difícil de compreender ou impossível de utilizar na prática.
4. Teste com tecnologia de apoio
Quando possível, teste com leitores de ecrã e outras tecnologias de apoio. Isto ajuda a perceber se a estrutura da página é anunciada corretamente, se os controlos têm os nomes certos e se as atualizações de conteúdo dinâmico são comunicadas adequadamente.
Isto não significa que todas as equipas de projeto tenham de se tornar utilizadoras especialistas de todas as tecnologias de apoio, mas é importante realizar alguns testes práticos, sobretudo nos percursos principais do utilizador.
5. Inclua utilizadores com deficiência nos testes
As informações mais valiosas resultam muitas vezes de testes com pessoas que realmente utilizam tecnologias de apoio ou enfrentam barreiras de acessibilidade no dia a dia. Os testes com utilizadores podem mostrar onde um serviço cumpre tecnicamente alguns critérios, mas continua a criar fricção, confusão ou exclusão.
6. Teste também documentos e sistemas incorporados
Os testes de acessibilidade não devem ficar pela página principal do website. PDFs, documentos Word, formulários online, mapas, sistemas de marcação, ferramentas de pagamento e widgets de terceiros podem todos criar barreiras. Se fizerem parte do percurso do utilizador, têm de ser considerados.
Equívocos comuns sobre a WCAG
- “A acessibilidade é só para pessoas cegas.” Na verdade, a acessibilidade abrange uma vasta gama de necessidades, incluindo diferenças auditivas, de mobilidade, cognitivas e neurológicas.
- “Um overlay ou widget resolve a acessibilidade.” Não resolve. A acessibilidade tem de ser incorporada na conceção, no código e no conteúdo.
- “Se uma ferramenta automática disser que passou, estamos em conformidade.” Os testes automáticos são úteis, mas são apenas uma parte do processo.
- “A acessibilidade torna os websites demasiado simples.” Uma boa acessibilidade apoia uma conceção clara e utilizável. Não impede uma identidade visual forte.
- “Isto só importa para organizações grandes.” As organizações mais pequenas também servem utilizadores com deficiência e podem continuar a enfrentar riscos legais, contratuais ou reputacionais.
O que as organizações devem fazer a seguir
Para equipas que não são altamente técnicas, a abordagem mais prática é tratar a WCAG 2.1 AA como uma norma operacional e não como um tema especializado. Isso significa integrá-la na contratação, nos briefings de design, nos fluxos de trabalho de conteúdos, na garantia de qualidade e na governação.
Um ponto de partida sensato seria:
- auditar os websites, aplicações e documentos atuais
- identificar os percursos do utilizador prioritários, como formulários, pagamentos, marcações e contactos
- corrigir primeiro as barreiras mais graves
- formar editores de conteúdos e equipas de projeto
- definir requisitos de acessibilidade para fornecedores
- introduzir testes regulares, em vez de revisões pontuais
- manter uma declaração de acessibilidade rigorosa, quando exigido
A acessibilidade é mais fácil e mais barata quando é considerada desde o início. Adaptá-la mais tarde é, regra geral, mais lento, mais caro e menos eficaz.
Em resumo
WCAG 2.1 AA é a norma amplamente reconhecida utilizada para tornar websites e serviços digitais mais acessíveis. Para leitores não técnicos, é melhor entendê-la como uma lista de verificação prática e um quadro de referência para remover barreiras que impedem as pessoas de utilizar conteúdos digitais.
É importante porque os serviços digitais devem funcionar para toda a gente, incluindo pessoas com deficiência. Os organismos do setor público são frequentemente obrigados a cumpri-la, e o enquadramento jurídico europeu mais amplo, incluindo o European Accessibility Act, significa que as expectativas de acessibilidade estão a expandir-se para além do setor público.
A conformidade não se resume a passar num teste automático ou a publicar uma declaração. Exige testes adequados, responsabilidade clara, práticas de conteúdo acessível e melhoria contínua. As organizações que compreendem isto estão muito melhor posicionadas para prestar serviços digitais legais, utilizáveis e justos.