Acessibilidade de widgets pelo teclado

Um widget de novidades pode abrir perfeitamente com o mouse e atrapalhar quem navega pelo teclado. O painel aparece, mas a tecla Tab continua percorrendo a página atrás dele. Ao fechar, a pessoa perde o ponto em que estava no sistema. A novidade estava legível; o problema foi conseguir voltar ao trabalho.

Para a equipe de produto ou desenvolvimento, vale transformar acessibilidade em uma pergunta concreta: a pessoa consegue abrir uma atualização, acompanhar seu conteúdo e retomar a tarefa que interrompeu? Vamos percorrer uma tela hipotética de cobrança para decidir e testar esse comportamento. O exemplo não é uma auditoria do Sinalio nem de outro fornecedor.

Acompanhe uma interrupção até o fim

Imagine alguém do financeiro preparando a cobrança de um cliente. Ao lado da navegação há um botão Novidades. Uma atualização explica uma nova opção de exportação. A pessoa quer ler a explicação e continuar a cobrança, sem perder os dados que já preencheu.

Na primeira versão, o botão é um ícone clicável sem funcionamento pelo teclado. A equipe corrige essa parte, mas abrir o painel ainda deixa o foco no botão de abertura. O próximo Tab chega ao seletor de cliente, escondido atrás da sobreposição. Escape não faz nada. Quando finalmente encontra o ícone de fechar, a pessoa consegue sair, mas precisa descobrir onde estava.

São falhas diferentes no mesmo percurso. Trocar apenas o botão não resolve as demais. Use um botão HTML para a ação de abertura, com nome compreensível, como Novidades. O padrão de botão prevê ativação por Enter e pela barra de espaço. Se a intenção for somente levar a outra página, comece com um link comum. [1]

O artigo sobre adicionar um changelog ao SaaS parte dessa alternativa simples de página com link. As decisões a seguir entram em cena quando um painel realmente ajuda a consultar uma mudança sem abandonar a tarefa atual. [2]

Decida se a tela de cobrança continua disponível

Um modal torna a aplicação de fundo temporariamente indisponível. No nosso exemplo, a pessoa termina a leitura ou fecha a novidade antes de voltar a interagir com a cobrança. Um painel não modal permite continuar usando a cobrança enquanto a atualização fica aberta. Estar desenhado na lateral direita não determina qual desses comportamentos o painel tem.

Escolha um modal quando a interrupção curta for intencional e o restante da tela deva aguardar. Prefira um painel não modal quando for útil comparar a explicação com os controles do sistema. A segunda opção precisa de espaço e de uma ordem de leitura coerente. Um painel apertado, que cobre a cobrança mas permite navegar por trás dele, reúne dificuldades dos dois modelos.

No padrão modal da WAI ARIA, o foco entra no diálogo, Tab e Shift+Tab circulam dentro dele, Escape fecha e o foco normalmente retorna ao botão de abertura. Associe o nome acessível do diálogo ao seu título visível. Só indique modalidade quando a interface de fundo estiver realmente indisponível. [3]

Uma alternativa não modal simples é a expansão de conteúdo, chamada disclosure: o botão mostra uma área da página e informa seu estado expandido ou recolhido. Neste exemplo, coloque o conteúdo revelado logo depois do botão na ordem do documento. O foco pode permanecer no botão; o próximo Tab chega ao primeiro controle do painel. Essa é uma solução por expansão, não uma regra para todo diálogo não modal. [4]

Descreva como deve ficar o percurso corrigido

Na versão modal do exemplo, abrir Novidades leva o foco ao título da atualização. O título precisa aceitar foco programático, por exemplo com tabindex="-1", sem virar uma parada extra de Tab. Há vários parágrafos antes dos links. A pessoa lê a explicação, usa Tab para chegar à documentação da exportação e encontra um botão Fechar visível. Ao fechar, volta ao botão Novidades. Os dados da cobrança continuam preenchidos. Esse é um cenário de aceitação proposto, não o resultado de um teste realizado.

O elemento HTML nativo dialog é um ponto de partida útil: showModal abre um diálogo modal, enquanto show abre um não modal. O modal tem fechamento por Escape como comportamento padrão; o não modal não recebe esse mesmo padrão. Nos dois casos, ainda é preciso oferecer uma forma clara de fechar e escolher o foco inicial de propósito. [5]

A incorporação exige atenção a um limite importante. A documentação MDN explica que um modal dentro de um iframe torna inerte o documento daquele frame, não o documento ao redor. Se o widget usa iframe, teste a página hospedeira inteira. Abrir um diálogo dentro do frame não significa que todos os controles da cobrança fora dele ficaram bloqueados. [6]

Na versão por expansão, a pessoa abre Novidades, consulta a atualização e pode continuar usando Tab até chegar à cobrança, com o painel ainda aberto. Não existe o ciclo de foco de um modal. Se houver um botão Fechar dentro do painel, ao acioná-lo leve o foco a um ponto coerente, como o botão de abertura que continua visível. Evite deixá-lo no conteúdo que acabou de desaparecer. A ordem precisa preservar o sentido da navegação. [7]

Observe também o que acontece ao redor

O funcionamento pelo teclado inclui a tarefa completa: abrir links e operar os controles da atualização. Não basta alcançar o botão inicial se o formulário de feedback no mesmo widget exige mouse para enviar. O critério Keyboard das WCAG trata da funcionalidade equivalente por uma interface de teclado, considerando a exceção prevista no próprio critério. [8]

O indicador de foco mostra qual controle responderá à próxima ação. Ele deve ser perceptível no botão de abertura, dentro do painel e no sistema hospedeiro. Uma captura de tela do painel aberto não demonstra isso: percorra a interface pelo teclado e observe cada parada. [9]

Com o painel não modal aberto, inspecione também a tela de cobrança. Uma lateral fixa ou um rodapé preso à janela não deve esconder completamente o componente que recebeu foco, conforme o critério mínimo Focus Not Obscured. Experimente uma janela estreita e ampliação da página: a sobreposição pode surgir apenas quando o layout muda. Para conteúdo aberto pela pessoa, o critério também admite uma forma de revelar o componente sem avançar o foco do teclado. [10]

Conter o foco dentro de um modal intencional é compatível com o uso do teclado quando existe uma saída por teclado. O problema é entrar em um componente e não conseguir sair dessa forma. Teste a saída de verdade, em vez de considerar todo limite de foco uma falha ou todo ciclo de foco aceitável. [11]

Faça um experimento com resultado observável

Use uma cobrança de teste, sem dados de clientes, e uma atualização longa o suficiente para exigir rolagem. Peça a alguém da equipe que chegue a Novidades sem usar o mouse, abra a atualização, encontre o link sobre exportação, feche o painel e continue preenchendo a cobrança. Não explique antes o caminho esperado. Anote onde a pessoa hesita, qual controle recebe foco a cada transição e se os campos continuam preenchidos.

Repita com Shift+Tab. No modal, teste Escape e o botão Fechar. Na expansão, teste o botão que mostra e recolhe o conteúdo e o botão Fechar interno, se existir. Na versão não modal, peça que a pessoa alterne entre a atualização aberta e a cobrança. Depois, repita após navegar para outra tela do sistema. Se o botão original desaparecer durante a mudança de rota, defina um destino coerente para o foco em vez de tentar devolvê-lo a um elemento removido. Registre navegador, tamanho da janela e passos para reproduzir.

Um relato útil diz: abrir a novidade na tela de cobrança deixa o foco no campo de cliente atrás do painel. A equipe recebe um estado inicial e um resultado observável. Depois da correção, refaça a mesma tarefa e o fluxo de cobrança ao redor; olhar somente a animação de abertura não basta.

Inclua testes com leitor de tela e pessoas com necessidades de acesso relevantes em uma avaliação mais ampla. A WAI apresenta suas verificações rápidas como um começo que pode deixar barreiras importantes passar. Concluir este experimento não demonstra acessibilidade completa, conformidade com as WCAG nem conformidade legal. [12]

O objetivo é um percurso curto e previsível: chegar à novidade, entender onde está, sair e continuar trabalhando. Decida esse comportamento antes de refinar o visual do painel e mantenha o percurso funcionando conforme o widget e a aplicação evoluem.