Esse artigo foi inspirado no post da WebAim Four Reasons to Give WCAG AAA a Second Look que aborda muito bem quatro critérios de sucesso AAA que podem ser adotados no nosso dia a dia no desenvolvimento de aplicações acessíveis.
Os requisitos de acessibilidade na Web costumam apontar principalmente para os níveis de conformidade nível A e AA. Isso vai desde legislação americana, como a Section 508 até a própria documentação do W3C que diz ser difícil satisfazer todos os critérios de sucesso nível AAA.
Mesmo assim, alguns critérios são razoavelmente simples de serem implementados. Alguns deles até já usamos e nem percebemos (ou gostariamos de usar). O objetivo deste artigo é apresentar alguns desses critérios e como eles podem ser utilizados no nosso dia a dia.
Critérios de sucesso nível AAA
O documento WCAG define três níveis de conformidade:
- Nível A – O mínimo exigido para a conformidade coma documentação. Beneficia um grande grupo de pessoas e tipos de deficiência
- Nível AA – Todos os critérios de nível A mais os de nível AA. É o nível intermediário e beneficia um grupo maior de pessoas e tipos de deficiência. É normalmente usado para conformidade legal.
- Nível AAA – Todos os critérios de nível A, AA e AAA. É o maior nível de conformidade e beneficia um grupo maior de pessoas e tipos de deficiência, porém é mais difícil de ser atingido.
O documento WCAG 2.2 conta com 32 critérios de sucesso de nível AAA. São eles:
- 1.2.6 Língua de sinais (Pré-gravada)
- 1.2.7 Audiodescrição Estendida (Pré-gravada)
- 1.2.8 Mídia Alternativa (Pré-gravada)
- 1.2.9 Apenas Áudio (Ao Vivo)
- 1.3.6 Identificar o Objetivo
- 1.4.6 Contraste (Melhorado)
- 1.4.7 Áudio de fundo baixo ou sem Áudio de fundo
- 1.4.8 Apresentação Visual
- 1.4.9 Imagens de Texto sem exceção
- 2.1.3 Teclado Sem Exceção
- 2.2.3 Sem Temporização
- 2.2.4 Interrupções
- 2.2.5 Nova Autenticação
- 2.2.6 Limites de Tempo
- 2.3.2 Três Flashes
- 2.3.3 Animação de Interações
- 2.4.8 Localização
- 2.4.9 Finalidade do Link (Apenas o Link)
- 2.4.10 Cabeçalhos da Sessão
- 2.4.12 Foco não Obscurecido (Melhorado)
- 2.4.13 Aparência do Foco
- 2.5.5 Tamanho do Alvo (Melhorado)
- 2.5.6 Mecanismos de Entrada Simultâneos
- 2.5.7 Movimento de Arrastar
- 3.1.3 Palavras Incomuns
- 3.1.4 Abreviaturas
- 3.1.5 Nível de Leitura
- 3.1.6 Pronúncia
- 3.2.5 Alteração Mediante Solicitação
- 3.3.5 Ajuda
- 3.3.6 Prevenção de Erros (Todos)
- 3.3.9 Autenticação Acessível (Melhorado)
Cada um dos critérios tem um link para os documentos com mais detalhes sobre cada um deles. Recomendo fortemente a leitura deles, pois lá existem detalhes, exemplos e os motivos que tornam esses critérios relevantes para a acessibilidade. Alguns deles podem ser complexos para implementação, como o de audiodescrição estendida, mas alguns deles são mais simples. A seguir vou apresentar alguns critérios de nível AAA fáceis de implementar e que vão melhorar a acessibilidade das nossas aplicações.
1.4.9 – Imagens de texto sem exceção
Para a conformidade com os níveis anteriores, imagens com texto tem que ter um texto alternativo com o conteúdo. Para atingir o critério AAA não devemos ter imagens de texto na aplicação.
Entendo que esse critério é mais complicado, principalmente para banners, chamadas em sites e e-commerce. O problema é que em vários sites de compras online encontrei imagens de texto sem o texto alternativo adequado. O exemplo abaixo foi capturado de um grande site no dia 04/01/2024:
alt="Seleção de Luminárias e Acessórios com até 30%"Evitar imagens de texto reduz a chance de um texto alternativo equivocado ser inserido na figura, já que o texto será visível também para quem está desenvolvendo.
2.3.2 Três Flashes
O critério de três flashes facilita a conformidade com o critério anterior 2.3.1 Três Flashes ou Abaixo do Limite (nível A). Isso porque para estar em conformidade com o 2.3.1 é necessário não ter conteúdo que pisca mais de três vezes no período de um segundo ou é necessário entender os limites de flash universal e flash vermelho. Mas você sabe o que significa flash universal e flash vermelho? Segundo o W3C, as definições são as seguintes:
- Um flash universal é definido como um par de alterações opostas na luminescência relativa de 10% ou superior da luminescência relativa máxima em que a luminescência relativa da imagem mais escura está abaixo dos 0.80; e em que “o par de alterações opostas” aumenta seguido por um decréscimo, ou diminui seguido por um acréscimo, e
- Um flash vermelho é definido como qualquer par de transições opostas envolvendo uma saturação de vermelho
Para entender luminiscência relativa é necessário considerar as seguintes definições de cores:
Para o espaço de cor sRGB, a luminescência relativa de uma cor é definida como L = 0,2126 * R + 0.7152 * G + 0.0722 * B em que R, G e B são definidos da seguinte forma:
- se RsRGB <= 0.03928 então R = RsRGB/12.92 senão R = ((RsRGB+0.055)/1.055) ^ 2.4
- se GsRGB <= 0.03928 então G = GsRGB/12.92 senão G = ((GsRGB+0.055)/1.055) ^ 2.4
- se BsRGB <= 0.03928 então B = BsRGB/12.92 senão B = ((BsRGB+0.055)/1.055) ^ 2.4
e RsRGB, GsRGB, e BsRGB são definidos da seguinte forma:
- RsRGB = R8bit/255
- GsRGB = G8bit/255
- BsRGB = B8bit/255
Depois de ler tudo isso, não é mais fácil considerar “não ter conteúdo que pisca mais de três vezes no intervalo de um segundo”?
2.4.9 Finalidade do Link (Apenas o Link)
A imagem próxima a esse texto representa bloco no meio de um site de notícias. Em um container há um título de notícia, um breve resumo e na sequência um link com “leia mais”. Por mais incômodo que seja, isso está em conformidade com o critério 2.2.4, sobre finalidade do link em contexto. Esse critério diz que a finalidade do link pode ser determinada pelo contexto em torno dele. No exemplo da imagem o link também está no título da matéria, então o usuário de leitor de tela vai ler o título e “leia mais” em todos os destaques do site.
Porém, o critério 2.4.9 diz que o destino do link deve ser determinado pelo texto dele. Sendo assim, usar “leia mais” não está em conformidade com esse critério AAA. Esse é um bom exercício para definir onde vão os links da sua aplicação e se eles são compreendidos isoladamente. Esse é um critério que gosto de seguir nas minhas publicações.
2.4.10 Cabeçalhos da Sessão
Já é uma boa prática de acessibilidade utilizar os cabeçalhos para a organização de sessões da página, principalmente porque essa é uma técnica que está relacionada com um critério muito importante de nível A, o 1.3.1 – Informações e Relações.
Estruturar os cabeçalhos da aplicação reforçam a semântica da página e é um ótimo recurso para navegação por usuários de leitores de tela.
3.3.6 Prevenção de Erros (Todos)
O critério 3.3.4 está relacionado a prevenção de erros que envolvem responsabilidades jurídicas ou transações financeiras para o usuário, que modificam ou eliminam dados controláveis pelo usuário em sistemas de armazenamento de dados. Se não for nenhum desses casos não é necessário cumprir esse critério.
Já o 3.3.6 diz que qualquer sistema que exige que o usuário envie dados ele deve conseguir reverter a submissão, verificar antes de submeter ou confirmar. As mesmas ações do critério 3.3.4.
Isso significa que seguir o 3.3.6 serve para todos os sistemas de envios de dados, desde aqueles utilizados para criação de contas em banco até os mais simples, como um sistema de publicação de cartões de natal. Por que não permitir que uma pessoa possa revisar seus dados antes de submeter os dados em qualquer sistema?
Conclusão
O que acabei de mostrar nesse post são boas práticas que não demandam um grande esforço para a conformidade de alguns critérios AAA. Tenho certeza que existem outros, então fiquem a vontade para enviar sugestões de práticas de conformidade para esses critérios.
Garantir a acessibilidade de uma aplicação vai muito além da definição de um nível de conformidade ou uma nota de verificador automático. Acessibilidade significa aplicar recursos que vão beneficiar o usuário.
Sei que é muito fácil justificar que “não precisamos de conformidade AAA”, mas talvez o grande desafio seja nos perguntarmos “por que ainda não incluímos conformidade AAA?”
