Desde a atualização recente para a versão 2.8.0.beta2, o botão do menu de administrador está destacado em amarelo.
Pensei que o Discourse quisesse me avisar de algo, mas mesmo após pesquisar na web e neste fórum, não tenho ideia do que possa ser.
Alguém pode, por favor, me esclarecer?
Acho que isso está indicando que o foco do teclado está naquele item. Essa foi uma mudança recente de #acessibilidade:
Depois de exibir o menu, tente pressionar Tab para navegar entre os itens do menu.
Sim, correto. Como @simonk observou, uma das formas pelas quais estávamos cometendo erros era não mudar o foco para as sobreposições. O foco precisa estar em um local adequado enquanto você navega pela aplicação.
Então, considera-se que está “funcionando conforme o previsto” quando vejo isso (passando o mouse sobre “Medalhas”)?
Hmm, não tenho certeza; precisamos de um estado de hover ali, @awesomerobot?
Acho que podemos querer mudar de :focus para :focus-visible no nosso CSS. Ele ainda não é suportado no Safari, mas é fácil fazer um fallback para :focus nesse caso.
Se o elemento ativo corresponder a :focus-visible e um script fizer o foco mudar para outro lugar, o elemento recém-focado deve corresponder a :focus-visible.
Isso significa que, se você abrir o menu hambúrguer usando a tecla Tab (o que ativa o estilo :focus-visible), ao abrir o menu, o estilo :focus-visible aparecerá. Se você abrir o menu com um dispositivo apontador, o estilo :focus-visible não aparecerá:
Há uma desvantagem: em um cenário misto de entrada, onde você abre o hambúrguer com um dispositivo apontador e depois tenta navegar com a tecla Tab… o estilo :focus-visible não aparece no primeiro link (mesmo que ele esteja tecnicamente focado), então parece que ele foi pulado. Não sei se existe alguma solução alternativa para isso…
Como sou (na maioria das vezes) um usuário de mouse, exatamente isso é o que eu esperaria do comportamento.
Por outro lado, às vezes uso meu smartphone com tela sensível ao toque: o mesmo problema ocorre lá. “Admin” fica destacado, indicando que pode haver algo importante na seção de administração que precisa de atenção.
A partir do tópico relacionado sobre leitores de tela, vejo que parece haver a necessidade de definir o foco de alguma forma.
Já ficaria satisfeito com o comportamento mencionado acima para ponteiros.
Tenho o mesmo problema.
Acho que este elemento atualmente não tem o valor de UX que vocês pretendiam — recebemos imediatamente relatórios de bugs sobre isso em nosso fórum. O foco desaparece quando você clica com o botão direito em qualquer lugar da janela e há um foco duplo ao passar o mouse sobre os botões. No geral, parece bugado para os usuários, especialmente porque o Discourse não impõe essa seleção em nenhuma outra visualização.
Seria melhor mostrar o foco do teclado apenas quando o usuário pressionar pela primeira vez Tab, ou apenas quando o usuário navegar para abrir o menu hambúrguer com uma ação de teclado.
pode postar uma captura de tela disso? não estou ciente desse problema
Vejo o mesmo no Safari e no Firefox (macOS); isso também é mencionado na postagem acima:
Se entendi corretamente esse recurso, deveria ser possível abrir o menu clicando ou pressionando = e, em seguida, navegar com algo (setas?) e pressionar algo (Enter?) para ir ao item destacado.
No Safari e no Firefox no macOS, seja abrindo o menu com um clique ou com =, não consigo navegar dentro dele. As setas para cima/baixo movem a página para cima e para baixo, e as setas para esquerda/direita não parecem fazer nada visível.
A tecla Tab muda o foco para outra coisa, como um botão de curtir em uma postagem, e remove o destaque amarelo do menu. No Firefox, ao pressionar Tab, o foco chegava a passar pelos itens do menu antes de eu começar a escrever esta resposta, mas agora não passa mais; uma janela anônima foi fechada entre essas tentativas.
Observo esses comportamentos aqui no Meta e na minha própria instância atualizada para efbc2481d8 (exceto que, no Firefox, o Tab funciona com sucesso, algo que só vi aqui).
As setas não devem fazer nada, mas tab e enter devem!
Então, quando você abre o menu com = e pressiona tab, você não está percorrendo os itens do menu? Estou no macOS e funciona como esperado no Safari, Firefox e Chrome, então isso é um pouco intrigante!
Analisei mais de perto o que está acontecendo aqui em geral e a ideia de usar focus-visible que mencionei acima não funcionará.
O problema é que o menu hambúrguer aparece no nosso HTML fora do container do botão do menu (o container que contém os botões de pesquisa, hambúrguer e usuário). Isso significa que o menu não está no próximo lugar na ordem natural de tabulação. Para compensar, definimos focus no primeiro item do menu usando JavaScript. Isso tem o efeito colateral de destacar o item (porque também precisamos ter estilos :focus).
Acho que não podemos necessariamente confiar em detectar uma pressão de tab, pois não é a única tecla que os leitores de tela usam para navegar, e interferiríamos em outros atalhos se capturássemos todas as pressões de tecla…
Consigo pensar em duas possíveis correções:
Mover o menu no HTML para que ele apareça imediatamente após o botão que o aciona. Isso pode ter alguns efeitos colaterais no layout.
Prender o foco dentro do menu quando ele estiver aberto, mas não definir o foco em nenhum item específico. Isso significa que, quando o menu estiver aberto, você só pode navegar pelo seu conteúdo e por nada mais na página. Acho que essa é provavelmente a solução preferível…
Correto. Para maior especificidade, estou usando macOS 11.4 e Safari 14.1.1. Estou acessando o meta em uma janela anônima e minha própria instância em uma janela não anônima.
Devo ter errado no meu teste inicial do Firefox; ele funciona da maneira que você descreveu se a preferência do sistema para Usar navegação por teclado para mover o foco entre controles estiver ativada, e navega até um botão de curtir da maneira que descrevi anteriormente se estiver desativada.
Posso alternar de forma confiável entre os comportamentos ativando ou desativando essa preferência do sistema, sem precisar recarregar a página no Firefox.
No Safari, vejo que ele navega até um botão de curtir independentemente dessa preferência do sistema, mesmo após recarregar a página. Ainda não testei reiniciar o Safari após ativá-la.
Agora também verifiquei o Chrome, que funciona da maneira que você descreveu, independentemente da preferência do sistema.
Encontrei a causa do meu problema no Safari. Percebi que, ao contrário do Chrome e do Firefox, se eu clicasse em algum lugar na barra de cabeçalho e pressionasse Tab, nenhum dos elementos do cabeçalho seria selecionado.
Isso levou à descoberta dessa preferência no Safari, em Avançado:
Tenho 99% de certeza de que essa é a configuração padrão em uma instalação limpa do Big Sur; não acredito que eu tenha alterado isso. Com essa preferência ativada, o comportamento começa a funcionar como você descreveu. Como o texto acima sugere, também funciona dessa maneira ao usar Option-Tab com a preferência desativada.
