Por Reinaldo Ferraz*
Em março de 2021 escrevi um artigo aqui sobre um dos primeiros rascunhos da nova documentação de acessibilidade, a WCAG 2.2. Dois anos depois, a documentação finalmente se tornou uma recomendação do W3C, o que significa que agora é um documento estável e que já pode ser utilizado no desenvolvimento de aplicações acessíveis.
As novidades dessa documentação não são tão novas assim. Já existem diversos artigos e documentos que explicam bem as novas diretrizes (recomendo a leitura do artigo do Bruno Pulis e a atualização do Guia WCAG, do Marcelo Sales). Nesse artigo quero contemplar as mudanças da versão de 2021 para a mais recente e apresentar as técnicas e documentos de apoio das novas orientações que ajudam a atender as diretrizes.
É importante reforçar que até o momento não existem ferramentas de verificação automática que detectam os novos critérios de sucesso do WCAG 2.2. Por isso é importante se familiarizar com testes manuais de acessibilidade para checar a conformidade com as novas orientações.
Critérios 2.4.11 – Foco não obscurecido (mínimo) (AA) e 2.4.12 – Foco não obscurecido (aprimorado) (AAA)
Esses dois critérios apontam para o conteúdo quando recebem foco de teclado que não deixa o componente escondido. Para cumprir o 2.4.11, o componente não pode estar completamente escondido (o critério permite que esteja parcialmente escondido). Já para cumprir o 2.4.12, nenhuma parte do componente pode estar escondida.
O objetivo dos dois critérios é manter o foco sempre visível, ou seja, impedir que algo sobreponha o componente que recebe foco para que a pessoa não se perca na navegação. A navegação por teclado é muito utilizada por quem usa leitores de tela, mas também beneficia pessoas com mobilidade reduzida que necessitam ver onde o foco de teclado está posicionado na aplicação.
A documentação do W3C que detalha esses critérios dá exemplos de páginas com cabeçalhos e rodapés flutuantes – que, conforme a pessoa navega pela página, podem sobrepor parte do conteúdo interativo. A documentação também tolera componentes que podem ser movidos para evitar cobrir o foco da navegação. Por exemplo, um modal que permite mover ou fechar cumpre o critério 2.4.11; já para cumprir ambos (conformidade com AAA), a documentação sugere o uso de notificações que não exigem uma ação da pessoa para fechar quando tirar o foco.
O critério 2.4.11 da documentação anterior (aquela de 2021) estava relacionado com a aparência do foco. Esse apenas mudou o número para 2.4.13 e não tem mais diferença entre mínimo e aprimorado.
Critério 2.4.13 – Aparência do foco (AAA)
Recomenda que quando um elemento receber foco por teclado ele cumpra com dois requisitos:
- Ter pelo menos uma área de 2 píxels CSS delimitada para os estados de elemento com e sem foco;
- Ter uma taxa de contraste de pelo menos 3:1 entre os píxels dos elementos com foco e sem foco.
Esse critério tem como objetivo permitir que a pessoa perceba o componente que recebe foco com uma referência visual, também muito útil para quem possui mobilidade reduzida que faz uso da navegação pelo teclado.
A conformidade pode ser contemplada fazendo apenas pequenos ajustes de CSS na aplicação. Claro que botões que não possuem espaçamento suficiente ou uma borda definida podem exigir mais ajustes.
A documentação do W3C mostra uma série de possibilidades para cumprir esse critério de sucesso que vão além de colocar uma borda de 2 píxels nos botões. Nela há exemplos de botões que somente as bordas laterais têm mudança de contraste e até componentes que mudam a cor de todo o elemento para atender esse critério (até sombreado está contemplado nos exemplos da documentação).
Na documentação de 2021 havia dois critérios para a aparência de foco, um de nível AA e outro AAA. O primeiro exigia uma borda de pelo menos 1 píxel CSS e taxa de contraste de 3:1. Já o de nível AAA exigia 2 píxels CSS e contraste de 4,5:1. No fim das contas, a versão final foi uma combinação de ambos para criar um único critério nível AAA.
Critério 2.5.7 – Movimentos de arrastar (AA)
O objetivo desse critério é permitir que pessoas que não conseguem fazer movimentos de arrastar e soltar tenham uma alternativa de “ponteiro único” ou navegação por teclado como opção. Isso permite que quem possui limitações motoras ou visuais perceba para onde o componente deve ser posicionado e consiga operar a aplicação.
O conceito de ponteiro único permite que a pessoa selecione a posição inicial e a posição final para operar o componente. Isso não inviabiliza o movimento de arrastar e soltar, mas dá uma alternativa para quem possui dificuldades com o movimento.
A documentação de apoio do W3C tem uma série de exemplos de aplicação, como um mapa que pode ser arrastado para exibir outras áreas mas que permite a navegação por setas também.
Esse critério sofreu poucas mudanças com relação à versão de 2021 – apenas uma frase com algumas exceções.
2.5.8 Tamanho do alvo (mínimo) (AA)
No documento WCAG 2.1 já existia um critério de tamanho do alvo. Esse critério é de nível AAA e define o tamanho do alvo em 44×44 pixels CSS. O novo critério do WCAG 2.2 permite botões um pouco menores para atingir um critério de nível AA.
Esse critério diz que os elementos interativos, como botões e ícones, devem ter pelo menos 24×24 pixels CSS. Isso evita que pessoas acionem botões por engano. Hoje temos resoluções de tela cada vez maiores e botões pequenos podem ser difíceis para pessoas com mobilidade reduzida e baixa visão.
Existem algumas exceções para esse critério, como links em uma sentença de texto ou botões menores, mas com tolerância para um espaçamento. A documentação de apoio desse critério é muito rica e dá diversos exemplos de uso e exceções (botões de 20×20 pixels CSS que têm espaçamento de 4 píxels entre si, por exemplo, cumprem este critério).
3.2.6 Ajuda consistente (A)
Já existe uma orientação no WCAG referente à ajuda (3.3.5), que diz que deve existir alguma forma de ajuda para quem navega. O novo critério do WCAG 2.2 orienta sobre o posicionamento dessa ajuda na página.
Se há uma forma de entrar em contato (por e-mail, telefone ou outra maneira), “Perguntas e Respostas” (Frequently Asked Questions – FAQ) ou chat (humano ou automatizado), esse componente deve estar posicionado no mesmo local do site em todas as páginas.
Esse tipo de orientação visa garantir que as pessoas memorizem onde estão posicionados os componentes de ajuda conforme navegam pela página ou aplicação. Pessoas com limitações cognitivas ou de memória são muito beneficiadas com essa recomendação. A documentação de apoio aponta algumas exceções, como quando a pessoa faz modificação nesses componentes (como uma janela de chat que aparece na tela e é possível mudar sua posição ou fechar).
Esse critério tem pequenas diferenças para a versão de 2021, como o nome, que antes era “ajuda localizável”, e alguns ajustes no texto. Mas sua essência permanece: que é permitir que a ajuda esteja no mesmo local em todas as páginas.
3.3.7 Entrada redundante (A)
Essa orientação serve para ajudar as pessoas a preencher dados já inseridos em formulários complexos ou de múltiplas etapas. O objetivo é evitar que se tenha que inserir novamente dados previamente preenchidos.
Podemos usar como exemplo um formulário de várias etapas para um cadastro. Os primeiros campos exigem a entrada de nome e endereço da pessoa. Mais adiante, para confirmar dados de entrega, existe uma forma de selecionar os mesmos dados já preenchidos previamente, seja exibindo essas informações nos campos de nome e endereço de entrega, ou permitindo a seleção desses dados a preencher. O documento de apoio do WCAG dá exemplos como um “select” que permite selecionar os dados preenchidos nas etapas anteriores.
Esse critério torna mais simples o preenchimento de formulários de múltiplas etapas, facilitando a compreensão de pessoas com limitações cognitivas ou de memória.
Com relação à versão anterior, foram acrescentadas algumas exceções ao critério, como questões relacionadas à segurança e o preenchimento dos dados.
3.3.8 Autenticação acessível (mínimo) (AA) e 3.3.9 Autenticação acessível (aprimorada) (AAA)
Esses critérios estão relacionados com o uso de testes de funções cognitivas para autenticação na Web. Segundo o W3C, testes de funções cognitivas são definidos como:
Uma tarefa que exige que a pessoa lembre, manipule ou transcreva informações. Os exemplos incluem, mas não estão limitados a:
- Memorização, como lembrar um nome de usuário, senha, conjunto de caracteres, imagens ou padrões. Os identificadores comuns nome, e-mail e número de telefone não são considerados testes de função cognitiva, pois são pessoais e consistentes em todos os sites;
- Transcrição, como digitação de caracteres;
- Uso de grafia correta;
- Realização de cálculos;
- Resolução de quebra-cabeças.
A diferença entre o critério mínimo (nível AA) e aprimorado (nível AAA) está relacionada às exceções do critério. Para atingir o critério mínimo, caso a autenticação exija um teste de função cognitiva, pelo menos um dos quatro itens abaixo deve ser verdadeiro:
Alternativa
Outro método de autenticação que não depende de um teste de função cognitiva.
Mecanismo
Um mecanismo está disponível para auxiliar a pessoa na conclusão do teste de função cognitiva.
Reconhecimento de objeto
O teste de função cognitiva consiste em reconhecer objetos.
Conteúdo pessoal
O teste de função cognitiva visa identificar o conteúdo não textual que a pessoa forneceu ao site.
Já para o critério aprimorado (mais restritivo), a autenticação que faz uso de um teste cognitivo deve contemplar pelo menos um dos dois primeiros itens descritos anteriormente (alternativa e mecanismo).
Os documentos de apoio desses critérios apontam uma série de situações. Ambos dão exemplos de formas de conformidade, como permitir copiar e colar a senha e o uso de autenticação em dois fatores. Com relação às restrições, o documento do critério mínimo é tolerante aos desafios de CAPTCHA de seleção de imagens, mas pede que não vá além do reconhecimento dos objetos (por exemplo, adicionar cálculos além da identificação de imagens). Já o documento do critério aprimorado é mais restritivo e não permite desafios de identificação de imagens.
Com relação à versão anterior, esses dois critérios eram apenas um (referente à autenticação acessível), de critério de nível A e sem exceções (ou seja, muito difícil de ser cumprido).
O que foi retirado da versão anterior?
Ficaram fora da versão final (comparada com a versão de 2021) as orientações referentes a “controles escondidos”, “pontos de referência fixos” e “espaçamento de alvo de ponteiro”. Parte do conteúdo dessas orientações foi aproveitada em outros trechos do documento.
Além dos critérios que estavam em rascunho, uma orientação que existia desde a WCAG 2.0 também foi removida e está relacionada com a verificação da marcação HTML da página. Explico a seguir.
4.1.1 Análise (Parsing) – Removido
Além dos 9 novos critérios, o W3C retirou um da documentação. Esse critério exigia que a aplicação tivesse a marcação HTML sem erros, com tags completas, sem atributos duplicados e outros erros de marcação que pudessem comprometer a navegação de quem navega com leitores de tela.
Segundo o W3C, “este critério foi originalmente adotado para resolver problemas que a tecnologia assistiva tinha ao analisar diretamente o HTML. A tecnologia assistiva não precisa mais analisar HTML diretamente. Consequentemente, estes problemas já não existem ou são resolvidos por outros critérios. Este critério não tem mais utilidade e é removido.”
Sendo assim, não é mais necessário ter um HTML sem erros de marcação para cumprir esse critério, porém o uso de elementos apropriados ainda é importante para diversos critérios, como o 1.3.1.
Apesar desse critério não ser mais necessário, ainda recomendo o uso do validador de markup do W3C. A ferramenta consegue detectar erros que podem comprometer a acessibilidade, como imagens sem texto alternativo.
O que esperar das próximas versões?
O W3C está trabalhando no WCAG 3, que em julho de 2023 ainda estava em “working draft”. Isso significa que ainda é uma versão muito preliminar do documento.
Mesmo assim, esse documento traz uma série de novidades sobre as diretrizes, inclusive com novos níveis de conformidade e técnicas. Ainda precisamos esperar essa documentação amadurecer para escrever mais detalhadamente sobre ela, mas vale a pena acompanhar todo o trabalho que está sendo feito pelo grupo para tornar as diretrizes mais fáceis de serem compreendidas e verificadas.
*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”.