Orientação Direta, Sem Complicações
Muitas vezes, as diretrizes da WCAG parecem abstratas ou difíceis de interpretar. Este guia interativo foi criado para eliminar a incerteza: ele traduz os critérios técnicos em ações concretas, separando o que compete a cada perfil profissional.
A acessibilidade digital garante que produtos e serviços podem ser utilizados por todas as pessoas, independentemente de limitações visuais, auditivas, motoras, cognitivas ou circunstanciais. Este guia consolidado reúne todas as guidelines e success criteria da WCAG 2.2, organizados de forma prática e orientada para equipas multidisciplinares.
Quem deve fazer o quê?
A acessibilidade não é responsabilidade de uma única função mas sim um esforço coletivo. Cada papel tem impacto direto na experiência final do utilizador e na conformidade com a WCAG. Ela começa na definição do produto, continua no design, é implementada no desenvolvimento, ganha clareza no conteúdo e é validada por QA.
Para que a acessibilidade aconteça, cada papel tem tarefas únicas. Selecione o seu perfil para filtrar as suas responsabilidades específicas e entender como o seu trabalho se encaixa no esforço coletivo:
Este guia permite filtrar responsabilidades por papel: Product, Design, Development, Content e QA.
Product & Management: Responsável pelo planeamento e definição dos requisitos de negócio.
Exemplo de responsabilidades principais:
- Garantir que os requisitos estão de acordo com as necessidades de acessibilidade.
- Escreve user stories com critérios de aceitação que garantam a acessibilidade.
Exemplo:
- User story incorreta: “Adicionar vídeo na página.”
User story correta: “Adicionar vídeo demonstrativo página. Este vídeo deve incluir legendas e controlo de reprodução visiveis que permitam ao utilizador pausar, parar ou ocultar qualquer movimento, animação.”
Design & UX: Define como o utilizador vê, entende e interage com o produto.
Exemplo de responsabilidades principais:
- Cria layouts acessíveis.
- Garante contraste, hierarquia visual, espaçamento e navegação.
- Documenta estados, foco e interações.
Exemplos:
- Garante que o esquema de cores é acessivel em todas as interações.
- Certifica-se de que existe um estilo definido para o foco quando o utilizador navega com o teclado.
- Assegura que a navegação é clara e consistente.
Development: Implementa acessibilidade no código. Foca-se em semântica HTML, suporte a teclado, ARIA e robustez de código.
Exemplo de responsabilidades principais:
- Usa elementos HTML semânticos.
- Garante navegação correta por teclado.
- Implementa atributos ARIA quando necessário.
Exemplos:
- <button><i class="icon icon-download"></i></button> sem texto alternativo → inacessível.
- Modal sem focus trap permite que um utilizador sai fora de contexto, especialmente um utilizador invisual.
- Modal deve permitir que o utilizador possa fechar a modal usando o teclado. Ex: Usando a tecla ESC.
Content Writer / UX Writter: Foca-se na clareza do texto, nomes descritivos e labels.
Exemplo de responsabilidades principais:
- Cria labels descritivos.
- Escreve mensagens de erro úteis.
- Mantém headings coerentes.
Exemplos:
- Label “Nome” → ambíguo. Melhor: “Nome completo”.
- Erro “Campo Inválido” → inútil. Melhor: “O email deve ter o formato nome@domínio.com”.
QA (Quality Assurance): Foca-se na validação final de fluxos, testes com leitores de ecrã e conformidade técnica.
Exemplo de responsabilidades principais:
- Testa navegação por teclado.
- Valida foco, ordem e comportamento.
- Usa ferramentas de teste automáticas de forma a complementar os testes manuais e não ao contrário.
Exemplos:
- Botão invisível ao tab.
- Foco perdido após fechar modal.
- Imagem sem descrição alternativa.
As WCAG organizam-se em quatro princípios (POUR), 13 guidelines e 78 success criteria. As guidelines são orientações gerais; os success criteria são requisitos testáveis que determinam conformidade nos níveis A, AA ou AAA.
Percecionável
O conteúdo deve ser visível ou audível para todos, sem exceções.
Operável
A interface deve ser navegável, independentemente do dispositivo usado.
Umpreensível
O funcionamento e o texto devem ser claros e fáceis de seguir.
Robusto
O código deve ser limpo e compatível com tecnologias assistivas.