Artigo por Reinaldo Ferraz*
O documento WCAG (Web Content Accessibility Guidelines, traduzido para o português como Diretrizes de Acessibilidade para Conteúdo na Web) é uma das principais diretrizes elaboradas pelo W3C (Consórcio World Wide Web) para a construção de sites e aplicações acessíveis. Desde sua primeira versão, em 1999, ele vem orientando desenvolvedores e gestores sobre técnicas relacionadas à acessibilidade na Web e eliminação de barreiras de acesso.
Um breve histórico:
- 1999: O W3C criou o grupo de trabalho Web Accessibility Initiative (WAI, traduzido para o português como Iniciativa de Acessibilidade na Web), cuja função é elaborar diretrizes para que a Web seja acessível para as pessoas com deficiências ou em condições especiais de acesso.
- 1999: o grupo WAI publicou, em 1999, a primeira versão das Web Content Accessibility Guidelines (WCAG 1.0), documento com um conjunto de 14 diretrizes para a acessibilidade.
- 2008: Sai a primeira grande atualização, chamada WCAG 2.0. Ela traz muitas novidades em comparação com a primeira.
- 2018: Chega a versão 2.1, introduzindo técnicas importantes como interação em interfaces táteis e dispositivos móveis.
- Para 2020, um novo passo será dado: o W3C está trabalhando em uma nova atualização do documento. É sobre essa novidade e possíveis novos recursos que falarei a partir de agora.
Versão 2.2
O documento preliminar do WCAG 2.2 foi publicado no dia 11 de agosto de 2020 e ainda está com o status “W3C Working Draft”. Isso significa que ele ainda pode sofrer ajustes e mudanças.
Anteriormente, ainda com status W3C Editor’s Draft (que é a base para a construção e ajustes do documento), já aparecem novos critérios de sucesso, que poderão ou não fazer parte da documentação final. Segundo o blog do W3C de fevereiro de 2020, o documento deveria passar para o status Candidate Recommendation em junho de 2020 e, finalmente, para W3C Recommendation quando o documento se tornaria padrão nos meses seguintes (o processo está atrasado devido à pandemia e deve se tornar uma recomendação em julho de 2021, segundo o W3C).
Apresento a seguir os novos critérios com breve explicação sobre cada um. Mas não esqueça: por estar em fase de revisão, o documento pode sofrer mudanças após a publicação deste artigo.
Critério de Sucesso 2.4.11 Foco Visível (Mínimo) – Nível AA
Esse critério refere-se ao foco, o destaque que é dado a um elemento quando o usuário navega sem o uso de mouse, pela tecla “tab” do teclado ou por movimento de “swipe” no dispositivo móvel, usando tecnologia assistiva. Quando o foco está posicionado em um elemento interativo (como um link ou botão) esse elemento recebe destaque, facilitando a percepção do usuário.
A documentação aponta qual o tamanho da área que indica o foco do elemento em uma página ou aplicação, a taxa de contraste adequada nos elementos que recebem foco, espessura da borda e cores do elemento.
Enxergar o foco é muito importante para acessibilidade. Pessoas com baixa visão e que navegam sem o uso de mouse precisam saber onde o foco está posicionado para acionar os elementos interativos, como links ou campos de formulário. Por essa razão, temos que garantir que o foco em todos os elementos interativos estejam visíveis.
Critério de Sucesso 2.4.12 Foco Visível (Aprimorado) – Nível AAA
Define valores de tamanho e contraste em elementos em foco maiores que os do critério 2.4.11 (por exemplo, o critério de foco visível mínimo define a taxa de contraste de 3:1. Já o critério de foco visível aprimorado define essa taxa em 4,5:1). Esses valores mais altos permitem que pessoas com limitações visuais e motoras mais severas consigam usar a aplicação de forma mais confortável.
Critério de Sucesso 2.4.13 Pontos de Referência Fixos – Nível A
Quando você lê um livro em papel é muito comum encontrar referências no texto como “veja o exemplo na página 12” ou “conforme o gráfico nessa mesma página”. Porém, em uma publicação digital o conceito de página pode ser diferente. As referências podem não estar na mesma página ou posição, dependendo da aplicação, dispositivo e até tamanho das fontes utilizadas pelo leitor.
Se a página Web for uma publicação eletrônica, como um ePub, ela deve ter localizadores para permitir a navegação pelo seu conteúdo e permitir que o localizador se mantenha fixo na publicação, mesmo que a formatação mude. Quando uma publicação faz referência a algo “nesta mesma página” o usuário deve ser capaz de localizar a referência com base no localizador aplicado. Essa técnica permite que qualquer pessoa, independente do dispositivo utilizado, acompanhe o conteúdo da mesma forma.
O objetivo deste critério de sucesso é permitir que usuários com deficiência encontrem as referências no conteúdo com base nos localizadores fixos.
Critério de Sucesso 2.5.7 Arrastando – Nível AA
Aborda o uso de técnicas para garantir que interações que envolvam arrastar o ponteiro na tela também sejam acessíveis. Esse critério diz que toda funcionalidade que faz uso de movimento de arrastar ponteiro também pode ser operada por toque ou clique sem arrastar, a menos que o movimento de arrastar seja essencial.
Para algumas pessoas a ação de arrastar um elemento em uma interface digital não é uma tarefa simples, seja por falta de força, destreza ou mesmo por estarem impossibilitadas de executar esse tipo de tarefa. Quando adicionamos uma possibilidade de ação por toque único, não é necessário arrastar os elementos pela tela. Basta que o usuário toque no destino final para que o cursor se mova e a ação seja efetivada.
Critério de Sucesso 2.5.8 Espaçamento de Alvo do Ponteiro – Nível AA
Define um tamanho mínimo de 44 pixels (de altura e largura) em qualquer elemento interativo que aciona um link ou dispara uma ação. Esse critério define esse tamanho para evitar que elementos interativos sejam acionados acidentalmente, como um botão ou link para uma nova página. Ele não se aplica em alguns casos, quando o usuário controla o tamanho da área interativa ou esse elemento é uma sentença em um bloco de texto.
Pessoas com limitações motoras, como tremores e dificuldades em executar pequenos movimentos, são beneficiadas com a técnica.
Critério de Sucesso 3.2.6 Ajuda Localizável – Nível A
Algumas pessoas podem não conseguir localizar informações ou executar ações em páginas ou aplicações na Web mais complexas e podem precisar de ajuda. Por isso, esse critério serve para recomendar formas de disponibilizar ajuda para os usuários, como opções de mecanismos de contato automatizado até formas de contatar uma ajuda humana.
Critério de Sucesso 3.2.7 Controles Escondidos – Nível AA
É muito comum que aplicações escondam certos controles do usuário e que sejam exibidos conforme necessário. Esse critério determina que os controles essenciais para interação ou progresso do usuário devem estar visíveis, sem precisar passar o cursor ou foco do teclado, ou deve ser oferecido um mecanismo para torná-los visíveis quando o usuário tiver que usá-los.
A intenção deste Critério de Sucesso é garantir que os controles necessários para progredir ou concluir um processo possam ser facilmente encontrados por pessoas com deficiências cognitivas.
Critério de Sucesso 3.3.7 Autenticação Acessível – Nível A
A memorização de um nome de usuário e uma senha (ou a transcrição manual) para a maioria dos sites impõe um ônus muito alto ou torna a ação impossível às pessoas com certas deficiências cognitivas. Adicionar tarefas mais complexas para login pode dificultar o acesso de alguns usuários. O foco é facilitar a autenticação do usuário.
Critério de Sucesso 3.3.8 Entrada Redundante – Nível A
O objetivo deste critério de sucesso é garantir que o preenchimento de formulários com diversas etapas seja um processo fácil. Isto é, reduzir a solicitação de dados que podem ser previamente preenchidos pode ser útil para pessoas com limitações cognitivas.
A orientação para este critério, então, é que, caso o usuário já tenha preenchido algo previamente em um formulário, o sistema deve preencher automaticamente ou permitir que o usuário selecione os dados previamente disponibilizados.
Esse critério não se aplica em verificações de segurança, como senhas, por exemplo.
Diretrizes de acessibilidade em português
O WCAG 2.0 foi o primeiro documento a ter tradução autorizada pelo W3C internacional para português do Brasil. Sua tradução foi feita pelo professor Everaldo Bechara e a revisão pelo Grupo de Especialistas em Acessibilidade na Web do W3C Brasil, coordenada pelo Ceweb.br. Esse processo foi feito em conjunto com a versão em português de Portugal, para aproximar as documentações, respeitando as características individuais de cada idioma.
A versão 2.1 do documento também está disponível em português, mas ainda não é uma tradução autorizada pelo W3C (está em processo). Por enquanto, ela continua com status de tradução livre. A tradução do WCAG 2.2 deve acontecer quando ele se tornar uma Recomendação do W3C, o que significa que seu conteúdo está estável e não deve sofrer mudanças.
WCAG 3
O W3C continua trabalhando na evolução das diretrizes de acessibilidade e já disponibilizou a primeira versão do WCAG 3, em 21 de janeiro de 2021, ainda em fase muito preliminar em Working Draft. O documento propõe uma nova abordagem da acessibilidade, bem diferente das anteriores. Mas isso será tema para um próximo artigo.
*Reinaldo Ferraz é especialista em Desenvolvimento Web do W3C Brasil e do Ceweb.br/NIC.br e autor do livro “Acessibilidade na web: boas práticas para construir sites e aplicações acessíveis”.