O seu relatório de auditoria diz que o 2.1.1 falha em todos os elementos. Como saber se é verdade.

Alguém lhe envia uma auditoria de acessibilidade. Em 2.1.1 Teclado, todos os elementos da página levam o mesmo veredicto: não há alternativa ao uso exclusivo do rato. Desliga o rato, percorre a página com o tabulador e funciona tudo — o foco desloca-se, o anel vê-se, Enter ativa o que deve.

Um dos dois está enganado. Descobrir qual não é questão de opinião, e a resposta é mais interessante do que «o fornecedor está a inflacionar o relatório».

Primeiro: o 2.1.1 não significa o que o relatório provavelmente pressupõe

O critério diz:

Toda a funcionalidade do conteúdo é operável através de uma interface de teclado sem exigir temporizações específicas para as teclas individuais, exceto quando a função subjacente exige uma entrada que depende do percurso do movimento do utilizador e não apenas dos pontos inicial e final.

Nível A. Repare no que falta: qualquer menção a uma tecla concreta.

O documento Understanding é explícito:

os botões que têm o foco podem geralmente ser ativados tanto com a tecla Enter como com a barra de espaços. Se um controlo de botão personalizado numa aplicação web reagir apenas a Enter (ou até a uma tecla ou combinação totalmente personalizada), isto continua a satisfazer os requisitos deste critério de sucesso.

Portanto «o Enter não fez nada, logo 2.1.1» não é uma constatação. Nem «este controlo quer uma tecla que não adivinhei». A pergunta que o 2.1.1 faz é se a função pode ser executada a partir do teclado — não se pode ser executada da forma que esperava.

E corta nos dois sentidos. Elimina uma classe de falsos positivos, mas também significa que um controlo pode cumprir o 2.1.1 sendo na prática inutilizável, porque ninguém adivinha a tecla. É um problema real, mas pertence a outros critérios e à simples usabilidade, não a este.

Segundo: três coisas arquivadas sob 2.1.1 que são critérios distintos

Importa, porque se o relatório mete tudo sob um único número, isso já diz alguma coisa sobre como foi produzido.

Ficar preso é 2.1.2 Sem bloqueio de teclado (A). Entra com o tabulador e não consegue sair. Critério diferente.

Ver onde está é 2.4.7 Foco visível (AA). Aquele anel grosso que observou é prova para o 2.4.7. Não é prova nem a favor nem contra o 2.1.1 — uma página pode ter um indicador de foco perfeito em todos os controlos e ainda assim falhar o 2.1.1, e pode cumprir o 2.1.1 sem qualquer foco visível.

O foco tapado por um cabeçalho fixo é 2.4.11 Foco não obscurecido (mínimo) (AA), novo nas WCAG 2.2. Também não é 2.1.1.

Se o seu teste consistiu em «carreguei no tabulador, via o foco e o Enter funcionava», reuniu boas provas sobre o 2.4.7 e provas apenas parciais sobre o 2.1.1.

Que aspeto tem uma constatação 2.1.1 a sério

Uma falha deste critério tem de nomear uma função que não pode ser executada. Não um elemento que existe. Portanto uma constatação utilizável contém:

• o elemento, e o que estava a tentar fazer com ele
• os passos para reproduzir
• resultado esperado contra resultado obtido
• navegador, sistema operativo, e que tecnologia de apoio em que versão

Não é uma fasquia alta. É o que quem testou anotou enquanto testava, porque precisou disso para saber que falhava. Qualquer auditoria que valha o que custa já o tem.

Se todos os elementos levam um veredicto idêntico, isso não é um resultado: é um modelo. Uma lista de verificação preenchida uma vez e copiada coluna abaixo tem exatamente este aspeto. E também um relatório onde «não testado» foi exportado como «falha».

Volte atrás e peça passos de reprodução para dois ou três dos pontos assinalados. É um pedido factual que podem satisfazer ou não, e encerra a discussão sem que ninguém tenha de debater a redação de um critério.

Mas não conclua que o seu teste absolveu a página

É aqui que quem tem razão sobre o relatório acaba muitas vezes por estar errado sobre o seu próprio sítio.

Desligar o rato e carregar no tabulador é um teste a sério, e falha a maioria das avarias que realmente aparecem nas auditorias:

• Conteúdo que só aparece ao passar o ponteiro. O seu ponteiro desapareceu, portanto nunca o vê, e quem usa o teclado também não. (Relacionado: 1.4.13 Conteúdo ao passar o ponteiro ou com foco, AA.)
• Tudo o que exige arrastar. Deslizadores, listas reordenáveis, deslocar mapas. As WCAG 2.2 acrescentaram 2.5.7 Movimentos de arrastamento (AA) precisamente porque isto continuava a acontecer.
• Widgets compostos em que o tabulador chega ao componente mas as setas lá dentro nunca foram ligadas. Uma listbox ou um conjunto de separadores personalizados em que se entra e não se navega.
• Modais que abrem lindamente e não fecham sem ponteiro. Isso é 2.1.2, e é o defeito grave de teclado mais comum que vejo.
• Tudo o que fica depois de um bloqueio de teclado, que nunca alcançará, e cuja ausência das suas notas parece uma aprovação.

Porque podem ter razão os dois

Aqui está a explicação que normalmente se aplica, e que quase ninguém verifica: só teclado e teclado com um leitor de ecrã a correr são dois testes diferentes.

O NVDA e o JAWS em modo de navegação intercetam as teclas antes de a página as receber. Um elemento alcançável com o tabulador e o leitor desligado pode ser inalcançável em modo de navegação, e ocasionalmente o contrário. Quem testa com NVDA e quem desenvolve sem nada observam mesmo comportamentos diferentes na mesma página.

Portanto, se o fornecedor testou com tecnologia de apoio ligada e você com ela desligada, nenhum dos dois está a mentir e nenhum tem o quadro completo. É também por isso que a linha do ambiente numa constatação não é burocracia: sem ela, a constatação não pode ser reproduzida nem refutada.

O que fazer, por ordem

1. Peça passos de reprodução para dois ou três pontos assinalados.
2. Experimente esses mesmos com o NVDA a correr, em modo de navegação, no Windows. Firefox ou Chrome, aquele que indicaram.
3. Se se reproduzirem, aprendeu algo real sobre o seu sítio.
4. Se não se reproduzirem e o fornecedor não souber dar os passos, tem motivos para rejeitar a coluna — e para perguntar o que mais no relatório foi gerado da mesma maneira.

Um scanner automático, o meu incluído, não lhe resolve isto. A operabilidade por teclado não é detetável de forma fiável por uma máquina: uma ferramenta pode assinalar um tabindex positivo, um elemento escondido das tecnologias de apoio mas ainda focável, ou um controlo sem nome acessível, e vale a pena ter isso. Se uma pessoa consegue mesmo concluir a sua finalização de compra sem rato continua a ser uma pergunta que exige uma pessoa.

A ressalva

Estou a descrever como avaliar um relatório, não a dizer-lhe que o seu sítio passa. Se a auditoria tem razão, estar mal escrita não a torna errada: torna-a mal escrita. Peça os passos, e depois leve a sério o que voltar.

Fontes: Understanding SC 2.1.1 Keyboard · WebAIM: Keyboard Accessibility