Gutenberg: Permitir que os usuários personalizem atalhos de teclado

O Gmail, por exemplo, usa atalhos Cmd / Ctrl + Shift, mas também usa atalhos de tecla única ou combinações de teclas de caracteres:

Conforme mencionado em # 3084, os atalhos de tecla única funcionam quando não estão dentro de um campo editável. Os leitores de tela usam atalhos de tecla única, mas já têm seus próprios mecanismos para pular por regiões de referência.

Comentando de carro aqui, mas estamos principalmente preocupados apenas com as línguas latinas ou ocidentais?

Nesse caso, pode ser possível encontrar uma chave compartilhada (se for difícil). Caso contrário, a experiência anterior com i18n sugere que diferentes idiomas / conjuntos de idiomas precisarão ter diferentes mapeamentos de teclas _e_ ainda precisaremos permitir que os usuários personalizem de qualquer maneira.

Citando ATAG A.3.1.5 https://www.w3.org/TR/2015/REC-ATAG20-20150924/#sc_a315

Personalize o acesso do teclado: Se a ferramenta de criação incluir comandos de teclado, esses comandos de teclado podem ser personalizados.

A intenção deste critério de sucesso é garantir que os autores que usam uma interface de teclado em plataformas que suportam comandos de teclado tenham a capacidade de remapear os atalhos de teclado padrão da ferramenta de autoria para evitar conflitos de pressionamento de tecla, usar combinações familiares de pressionamento de tecla e otimizar o layout do teclado (por exemplo, para uso com uma mão).

Investigando em # 5847 / # 6144 Eu li alguma documentação da Ratoeira (a ferramenta usada por Gutenberg para implementar atalhos de teclado). Referência:
https://craig.is/killing/mice
https://github.com/ccampbell/mousetrap

É importante notar que também as sequências de pressionamentos de tecla funcionam, consulte https://craig.is/killing/mice#api.bind.sequence e também atalhos que incluem sequências e combinações. Por exemplo, pressionar Command (ou Ctrl ) duas vezes funcionaria. Isso abre novas possibilidades e talvez seja algo mais fácil de implementar do que atalhos personalizáveis. Quaisquer pensamentos mais do que bem-vindos. / cc @aardrian @rianrietveld @joedolson @samikeijonen etc.

Não sei onde colocar isso, mas tenha cuidado ao aplicar atalhos de teclado, especialmente ao usar o Slack como exemplo. O Slack tornou sua acessibilidade _pobre_ para usuários de leitores de tela que dependem de navegação por teclado. Esta troca de Twitter entre um usuário SR habilidoso e o cara do Slack responsável pela acessibilidade demonstra essa desconexão: https://twitter.com/LeonieWatson/status/974615133044359168

Além disso, muitos usuários de leitores de tela e muitos usuários apenas de teclado têm deficiências motoras que tornam possíveis combinações complexas (ou mesmo simples). Os atalhos podem ser um ótimo complemento para muitos usuários, mas não são uma correção de acessibilidade garantida (portanto, não há problema em tê-los, mas não os torne o único meio de interação para um recurso).

@afercia

Investigando em # 5847 / # 6144 Eu li alguma documentação da Ratoeira (a ferramenta usada por Gutenberg para implementar atalhos de teclado). Referência:
https://craig.is/killing/mice
https://github.com/ccampbell/mousetrap

Iniciou com o NVDA. O primeiro exemplo na página é pressionar a tecla 4 para destacar a primeira linha do código. Sem o NVDA funciona bem. Com o NVDA, como o NVDA (corretamente) captura as teclas digitadas, ele me leva para o primeiro <h4> da página.

Para passar a chave para o sistema operacional, ignorando o NVDA, preciso usar NVDA Key + F2 e então posso bater 4 . (observe que NVDA Key será Caps Lock ou Insert dependendo da configuração do usuário).

Em minha experiência, poucos usuários de leitores de tela sabem qual é sua combinação de teclas de passagem, muito menos quando ou como usá-la.

Dito isso, em uma rápida olhada na biblioteca, não vi nenhuma declaração sobre como implementá-la e contabilizar leitores de tela. A resposta do desenvolvedor pode ser "Meh", que deve ser documentado se essa for a abordagem.

@aardrian thanks. Sim, estou ciente de que a chave de passagem não é tão usada e diria que não é aceitável pedir aos usuários que a usem. Não olhei os exemplos da Ratoeira, porém a parte boa é que a Ratoeira é "agnóstica" e permite realmente usar qualquer atalho. Cabe à implementação fazê-los funcionar com AT, por exemplo, fazer o SR entrar no modo de formulários ou no modo de aplicação quando apropriado.

Os atalhos são provavelmente mais úteis para usuários profissionais de teclado (não usuários de leitores de tela). Não vale a pena o atalho Ctrl + backtick mencionado aqui basicamente corresponder aos marcos ARIA, de modo que os usuários de leitores de tela podem simplesmente usar seu leitor de tela para pular através dos marcos.

Ah, entendi. As coisas que você deseja designar como alvos para Ctrl + backtick correspondem a regiões / pontos de referência nomeados. Eu gosto disso.

Sim, é uma tentativa de emular pontos de referência para usuários que não usam leitores de tela 😆

Apenas para confirmar que o atalho "Ctrl + backtick" não funciona em vários teclados de layout diferente do inglês e, portanto, a capacidade de pular pelas seções principais do editor não está disponível para todos os usuários (consulte também # 1182):

• não disponível em um layout de teclado italiano (@afercia)
• não disponível em um layout de teclado holandês (@rianrietveld)
• não disponível em um layout de teclado finlandês (@samikeijonen)
• não disponível em um layout de teclado francês (@audrasjb)
• provavelmente muito mais

Sim, é uma tentativa de emular pontos de referência para usuários que não usam leitores de tela

O Facebook tem uma abordagem interessante para navegação em pontos de referência. Um menu de pontos de referência como uma parada de tabulação inicial na página, onde você costuma encontrar um link pular para o principal. Acho que é notável, porque presumo que muitos usuários de teclado já o tenham encontrado. Não sou um usuário do Facebook, mas ele é usado na tela de inscrição também, então brinquei com ele lá.

Descrição aqui: https://a11ywins.tumblr.com/post/170270963528/facebook-ax-navbar

Essa é uma abordagem interessante. Na verdade, eu entrei no Facebook para testar, funcionou conforme descrito.

@fuzzbomb interessante. Vejo que eles usam Alt + / para invocar o menu, então o problema com o atalho de teclado ainda permanece. No meu teclado italiano, por exemplo, eu precisaria pressionar Shift + 7 para obter uma barra / . Não tenho certeza sobre outros layouts de teclado, mas provavelmente ainda precisaria de algum tipo de mecanismo de personalização. ( @samikeijonen onde está a barra / no seu teclado finlandês?)

No entanto, você me fez pensar em um tíquete principal do Trac que pedia para tornar o link Skip existente acessível aos desenvolvedores (consulte https://core.trac.wordpress.org/ticket/36644). Embora a proposta não seja exatamente a mesma coisa, agora estou pensando: e se tentarmos tornar o link Skip existente extensível, ou seja, mais links skip podem ser adicionados lá por meio de um filtro ou algo assim?

Então, ele deve ser alterado para um menu ARIA com navegação por setas e seria ótimo ter um atalho personalizável para invocá-lo.

@afercia O mesmo aqui com / , não consegui acessar com Alt + / . Mas pelo menos foi a primeira parada de tabulação.

@samikeijonen obrigado. Esse é o ponto, precisamos de uma ferramenta que os usuários possam acessar quando o foco estiver na IU do Gutenberg 🙂

precisamos de uma ferramenta que os usuários possam acessar quando o foco estiver na IU do Gutenberg 🙂

Para fins de argumentação e fingimento que seria a coisa mais fácil do mundo: e se adicionássemos regiões a toda a IU do WordPress, não apenas a Gutenberg - isso seria um benefício real?

Claro, a navegação de referência do Facebook pode ser acessada por meio de um atalho de teclado, mas você também pode acessá-la rapidamente clicando em Tab após carregar uma página. O ALT + barra seria apenas outro atalho personalizável.

O que me interessa na abordagem do Facebook é que ele inclui links para suas páginas de ajuda de acessibilidade também, mas mantém toda a região em uma única tabulação. A região não é apenas uma alternativa sofisticada para ignorar link, é uma região para todas as ferramentas em geral.

Agora, você pode adicionar outras coisas lá também, como uma lista suspensa de navegação de títulos ou ... links para personalizar as configurações de acessibilidade por usuário. Então é aí que um mecanismo para personalizar os atalhos do teclado poderia ficar - em uma região de ferramentas a11y, apenas uma tecla TAB (e algumas setas) de distância do início da página. Se ALT + / não for adequado para você, um usuário apenas com teclado ainda poderá encontrar uma maneira de personalizá-lo sem muito esforço.

Um botão sempre visível para revelar a região de "ferramentas de acessibilidade" pode residir na barra de ferramentas principal, de forma bastante discreta. Assim, a região de ferramentas a11y é facilmente alcançada por um único TAB após carregar a página, ou vários Shift-TABs se formam em algum lugar no meio da página, ou um clique do mouse, Dragon ou qualquer atalho de teclado que ele tenha.

Não sei quantos atalhos estão sendo propostos, mas acho que algo na escala do Gmail é demais. Uma maneira de evitar excessos seria um sistema onde muitas ações _podem_ ter um atalho de teclado, mas a maioria delas não são atribuídas por padrão (uma configuração vazia). A área de trabalho KDE Plasma e a área de trabalho GNOME fazem isso dessa maneira.

(Pelo que vale a pena, Ctrl + crase é usado pelo desktop Ubuntu Unity para "percorrer as janelas no aplicativo atual", enquanto o KDE Plasma usa Alt + crase, e GNOME usa Win + crase, e o macOS usa Splat + crase para o mesmo tarefa. E assim por diante.)

Indo ainda mais longe, os atalhos de teclado poderiam ser completamente desativados por padrão - os usuários teriam que optar, mas haveria muito menos risco de frustrar os usuários de tecnologia assistiva com conflitos de teclas. Para os usuários que os desejam, eu confio no manual e em todos aqueles artigos sobre "10 coisas a fazer depois de instalar o WordPress" para divulgar a mensagem. Imagine se todos fossem instruídos a verificar o link de configurações de acessibilidade ....

PS: Sou um mantenedor do Drupal a11y, em vez de um contribuidor do WordPress. Encontrei esse problema porque sigo as notícias do WP-a11y. Ainda não temos nenhum atalho de teclado, preferimos controles de teclado sequenciais básicos. Acho que é uma questão de tempo antes de precisarmos olhar para esse problema na iniciativa de ferramentas de autoria do Drupal também.

precisamos de uma ferramenta que os usuários possam acessar quando o foco está na IU do Gutenberg ligeiramente_smiling_face

Para fins de argumentação e fingimento que seria a coisa mais fácil do mundo: e se adicionássemos regiões a toda a IU do WordPress, não apenas a Gutenberg - isso seria um benefício real?

Espere aí, a intenção é restringir o foco dentro de um formulário de edição? Parece que a barra de ferramentas superior (e / ou barra lateral do painel) deve ser uma região disponível, pelo menos. Não estou certo sobre a terminologia do WP, aliás.

É totalmente capaz de ter regiões de referência em todas as áreas da IU. A parte difícil é decidir quantos.

Agora estou me perguntando: e se tentarmos tornar o link Ignorar existente extensível, ou seja, mais links ignorar podem ser adicionados lá por meio de um filtro ou algo assim?

Sim, alguma API para adicionar links de salto seria factível. Acho que o do Facebook apresenta regiões de referência, não tenho certeza se as descobre dinamicamente no navegador ou no lado do servidor gerenciado. Há uma implementação de descoberta de marco JS em matatk / landmarks .

Para recapitular: Gutenberg já usa 3 regiões de referência ARIA. Elas são as marcadas com role="region" :

• a barra superior
• a área do editor principal
• a barra lateral

Os usuários de tecnologia assistiva já possuem ferramentas para usar os marcos ARIA: os leitores de tela fornecem ferramentas específicas para navegar por eles.

Em vez disso, os usuários de teclado que não usam um leitor de tela não podem tirar proveito dos marcos ARIA (sim, existem algumas extensões de navegadores que os habilitam). Portanto, o atalho Ctrl+backtick foi implementado para permitir aos usuários saltar através das 3 principais áreas do editor que correspondem aos marcos ARIA.

A questão é que os usuários do teclado precisam ser capazes de pular de um bloco para a barra superior ou lateral a qualquer momento.

Claro, a navegação de referência do Facebook pode ser acessada por meio de um atalho de teclado, mas você também pode acessá-la rapidamente clicando em Tab após carregar uma página. O ALT + barra seria apenas outro atalho personalizável.

Não podemos pedir aos usuários que percorram toda a interface para fazer, por exemplo, uma capitulação em um parágrafo. Eu diria que o mais importante nesta edição é como implementar corretamente atalhos que funcionem para todos os usuários, portanto, precisamos de personalização. Então, podemos discutir uma ferramenta adicional como um "menu a11y".

(Pelo que vale a pena, Ctrl + crase é usado pelo desktop Ubuntu Unity para "percorrer as janelas no aplicativo atual", enquanto o KDE Plasma usa Alt + crase, e GNOME usa Win + crase, e o macOS usa Splat + crase para o mesmo tarefa. E assim por diante.)

Interessante, mas acho que isso muda dependendo do layout do teclado definido no SO 🙂 WordPress é um projeto global, não devemos codificar apenas para o layout do teclado em inglês.

Portanto, a região do ponto de referência da barra superior é a única coisa com "+ novo" e "ver postagem", e um usuário apenas com teclado ainda pode alcançá-la por muito tempo com shift-tab, caso não tenha descoberto o atalho de teclado dos pontos de referência? Meu ponto é que os usuários que usam apenas o teclado às vezes ficam muito felizes em usar a navegação sequencial básica, porque aprender atalhos é uma tarefa árdua.

Isto é. Também precisamos de uma maneira de "pular" do bloco selecionado para a barra lateral para resolver um problema interessante: quando um bloco tem foco, Gutenberg considera aquele bloco "selecionado" e a barra lateral é contextual. Então, por exemplo, você está em um bloco e deseja aplicar uma capitulação ou alterar as cores ou o tamanho da fonte: você precisa ir para a barra lateral.
Ao usar apenas o teclado: assim que você pressionar Tab e iniciar sua jornada na esperança de chegar à barra lateral, poderá pousar em outro bloco (se houver muitos blocos). Nesse ponto, o bloco recém-focalizado é o "selecionado". Continue tabulando e o último bloco será o "selecionado". Finalmente, você está na barra lateral, mas agora tudo o que você fizer na barra lateral se aplica ao último bloco (o "selecionado") 😬

Basicamente, ao usar o teclado e percorrer a interface, o bloco "selecionado" será sempre o último. Ou o primeiro se for tabulado para trás.

Neste ponto, o atalho para pular para a barra lateral é essencial. Eu também sugiro considerar qualquer outra alternativa que possa tornar a vida mais fácil para os usuários do teclado, por exemplo, um link "pular para a barra lateral" colocado dentro dos blocos. / Cc @jasmussen

Neste ponto, o atalho para pular para a barra lateral é essencial. Eu também sugiro considerar qualquer outra alternativa que possa tornar a vida mais fácil para os usuários do teclado, por exemplo, um link "pular para a barra lateral" colocado dentro dos blocos.

Isso pode se beneficiar do modo de navegação PR em que o Riad está trabalhando?

por exemplo, um link "pular para a barra lateral" colocado dentro dos blocos

Com Graham conversamos sobre isso em Londres. Definitivamente, é necessário haver o link "pular para a barra lateral". Poderia ser o primeiro elemento no menu Configurações de bloco / Mais opções?

Com Graham conversamos sobre isso em Londres. Definitivamente, é necessário haver o link "pular para a barra lateral". Poderia ser o primeiro elemento no menu Configurações de bloco / Mais opções?

Não foi por isso que criamos o link "Mostrar configurações de bloqueio"? Isso pode funcionar como um link para pular?

Não foi por isso que criamos o link "Mostrar configurações de bloqueio"? Isso pode funcionar como um link para pular?

Onde fica isso? Estou no último branch master.

Edit: Desculpe, é isso. Mas ele apenas alterna as configurações de Mostrar / Ocultar bloco. Ele não move o foco nas configurações de bloco.

ele apenas alterna as configurações de Mostrar / Ocultar bloco. Ele não move o foco nas configurações de bloco.

Certo, mas não poderia mostrar / ocultar configurações de bloco _e_ mover o foco para lá?

Pode, então o texto pode precisar ser alterado.

Edit: Ou talvez não seja uma boa ideia tê-lo no mesmo link.

1. Digamos que as configurações de bloqueio estejam abertas. O usuário clica em _Ocultar configurações de bloqueio_, o foco não deve se mover para lugar nenhum.
2. Digamos que as configurações de bloqueio estejam próximas. O usuário clica em _Mostrar configurações de bloqueio_, não tenho certeza se quero mudar o foco em qualquer lugar.

_Editar configuração de bloco_ ou algo faria mais sentido para mim.

Bem, um link "pular para" (na verdade, não um link) não precisa necessariamente estar visível na IU. Ele precisa ser revelado no foco. Veja, por exemplo, ao clicar no final da barra lateral de configurações do bloco # 5856

Você está certo, não precisa ser visível. Ambos estão bem por mim. Nesse caso, acho que deveria ser visível. Já existem muitas coisas acontecendo ou desligadas.

Mas como já temos essa opção no menu - precisamos de outra, visível ou não? O que está no menu não pode ser duplicado?

Então _Mostrar configurações de bloqueio_ deve ser renomeado para _Mostrar e mover para configurações de bloqueio_ ou algo assim. Mas, como eu disse, pode ser estranho ser forçado a mover meu foco para lá se eu realmente quiser apenas abrir o painel de configurações de bloqueio.

Certo, mas não poderia mostrar / ocultar configurações de bloco e mover o foco para lá?

Hm, acho que isso seria uma suposição. As duas coisas devem ser separadas. Como usuário, posso querer abrir as configurações de bloco apenas para dar uma olhada nelas, não necessariamente para ir para lá. Um segundo controle específico para pular para lá tornaria as coisas mais claras e respeitaria a intenção dos usuários.

Justo. Parece que a próxima etapa pode ser um RP para testar como é a solução em que mais acreditamos.

Algum desenvolvedor na casa que tem tempo para fazer isso e escrever um PR?

Para se inspirar, o Slack também usa F6 para navegar pelos pontos de referência (acho que eles adicionaram F6 há um tempo). Nota: F6 é um dos atalhos de teclado padrão

Percorrer os elementos da tela em uma janela ou área de trabalho

Que significa:

• quando há um aplicativo aberto em uma janela, percorre os elementos definidos pelo aplicativo dentro da janela e ignora a IU do sistema operacional
• quando o foco está na área de trabalho, percorre as principais seções da IU do sistema operacional

Como o aplicativo principal em uma janela é o navegador, isso significa que no Windows, na maioria dos navegadores, o F6 percorrerá a barra de endereços do navegador e o documento. Na verdade, o Slack usa F6 no mac e Ctrl+F6 no Windows:

No Mac:

No Windows:

Parece-me que isso é melhor do que backtick, como F6 deve estar disponível em todos os layouts de teclado? (a menos que esteja faltando alguma coisa)

Eu cavo. A chave, pelo menos para mim pessoalmente e não sou especialista nisso, é que _se podemos reutilizar um atalho que é usado em outros aplicativos, vamos adiar isso. Nesse caso, há uma precedência clara no Slack que vale a pena imitar.

Vale a pena notar que o atalho do Slack acima funciona _além_ ao botão ctrl + (tecla abaixo de escape). Eu adoraria se pudéssemos manter esse outro atalho também, mesmo que não esteja listado em nenhum dos arquivos de ajuda.

Uma coisa que é curiosa - os Macs costumam usar alguns comandos personalizados nas teclas F, como brilho e volume. Embora você possa alterar esse padrão, suspeito que ninguém o faz, o que significa que normalmente você precisa manter pressionada a tecla Fn para invocar a verdadeira ação F6. No entanto, no Slack está funcionando para mim, com e sem segurar Fn. Não sei se é porque F6 não está mapeado para uma função do sistema (nem F5), ou se Slack está fazendo algo especial aqui para interceptar o comando F6 e o ​​comando Fn + F6. Vale a pena testar.

Teste muito rápido, mas preciso de Fn+F6 no Slack. Mas +1, já que todo (a maioria) teclado deve ter essas teclas.

OK, tentei o F6, mas infelizmente não funciona bem em navegadores e plataformas.

• macOS chrome e safari: F6 funciona
• macOS firefox: F6 não funciona, ctrl + F6 não funciona
• windows chrome: ctrl + F6 funciona
• windows firefox e IE 11: ctrl + F6 não funciona

Portanto, experimentei alt+F6 no Windows e parece que funciona no Chrome e no Firefox. Não funciona no IE 11 :( Esquisito, mas a única maneira de fazer funcionar no IE 11 é focalizar primeiro a barra de endereços do navegador e depois ela funciona. Claro, tabular a partir daí perderá o foco ...

Não tenho certeza do que fazer. Alguma ideia melhor ?? :)

Isso é uma chatice. Acho que precisamos de conselhos de @iseulde , ela é uma

Apenas para recapitular e reler isso , a razão pela qual queremos uma alternativa para Ctrl + [tecla abaixo de escape] é porque é muito difícil para nós descobrir _que_ tecla que está em teclados internacionais, correto? Esta combinação de teclas estaria correta se pudéssemos solicitar ajuda para descobrir isso? Queríamos uma matriz que listasse qual era o código-chave, bem como qual caractere mostrar na folha de atalho.

Aqui estão algumas outras opções.

• O Google Chrome quando navegado no Android usando Talkback e teclado externo usa Alt + D para a próxima região, Alt + Shift + D para a região anterior.
• Esta extensão do navegador rando usa Alt + Shift + N e Alt + Shift + P.
• O NVDA usa D e Shift D. Posso criar um atalho que só funcione quando você não estiver editando texto?
• j / k geralmente são os atalhos de teclado para o próximo e o anterior. Devemos usar Ctrl + j e Ctrl + k para a próxima região e a anterior?

Faltando algum contexto aqui, desculpe se já foi discutido.

O que nos impede de usar algum modificador + setas / guia para percorrer as regiões? Já estão todos usados? Algo como alt + tab talvez ainda esteja disponível.

E se os blocos funcionassem como uma lista em que você os percorre com as teclas de seta, não muito diferente de um editor normal, e funcionassem como um campo ao navegar?

Não sou fã de usar letras para navegação. Além disso, as teclas F # são difíceis de descobrir e lembrar. Idealmente, teríamos algo como o movimento do cursor funciona. Seta = mover por um, opção + seta = mover por palavra, etc. Seria legal se tab = mover por um elemento tubbable e opção + tab = mover por região.

Algo como alt + tab talvez ainda esteja disponível.

Isso alterna entre janelas abertas no Windows, certo?

E se os blocos funcionassem como uma lista em que você os percorre com as teclas de seta, não muito diferente de um editor normal, e funcionassem como um campo ao navegar?

Desculpe, eu deveria ter esclarecido. Isso é para navegar entre regiões. Quando você pressiona ctrl + [a tecla abaixo de Escape], você navega por regiões como esta:

Isso já funciona, mas estamos procurando um atalho de teclado alternativo porque não temos certeza se ele funciona em todos os teclados e não temos certeza de como descobrir se funciona.

No entanto, seu ponto é bom em relação à navegação na lista de bloqueio e discutimos algo nesse sentido aqui: https://github.com/WordPress/gutenberg/pull/5709#issuecomment -393791220

opção + tab = mover por região.

Eu concordo, a guia parece uma chave superior a ser usada para navegar nas regiões aqui, uma vez que a guia é inerentemente sobre a seleção de elementos na página. No entanto, também é um desafio, pois a maioria das combinações de modificadores de guia são usadas:

• Ctrl + Tab e Ctrl + Shift + Tab alternam as guias nos navegadores
• Alt + Tab no Mac não parece fazer nada, mas no Windows alterna entre as janelas, o que também nos bloqueia do ⌘ + Tab no mac.
• Ctrl + Alt + Tab para avançar com tabulação e Ctrl + Shift + Alt + Tab podem funcionar, mas é um pouco complicado, e Ctrl + Alt são mapeados para a lupa em Macs, se isso estiver ativado.

Em outras palavras, por mais que eu queira usar a guia aqui, não tenho certeza se podemos :(

Além disso, as teclas F # são difíceis de descobrir e lembrar.

Quase todas as combinações são difíceis de lembrar. Precisa de uma boa documentação de qualquer maneira.

Isso já funciona, mas estamos procurando um atalho de teclado alternativo porque não temos certeza de que funcione em todos os teclados.

Não tem, temos certeza :)

OK, tentei o F6, mas infelizmente não funciona bem em navegadores e plataformas.

@afercia Já havia um PR para teste?

Conforme comentado em parte acima:

• backtick não está disponível em pelo menos 4 layouts de teclado, provavelmente mais. Consulte https://github.com/WordPress/gutenberg/issues/3218#issuecomment -381651232
• leitores de tela Alt + D ou D funcionam apenas com um leitor de tela em execução, precisamos de um atalho que funcione para usuários de teclado que não usam um leitor de tela.
  Por exemplo, Ald + D no Windows entra em conflito com o atalho nativo para enfocar a barra de endereço do navegador.
• alt + tab é usado no Windows
• as setas não funcionarão dentro do fluxo de escrita? e acho que não funcionarão de dentro de um campo de entrada (ou não queremos que funcionem de dentro de um campo de entrada, para preservar a interação nativa); precisamos de um atalho "global" que funcione de qualquer lugar, a qualquer momento

@samikeijonen não, não há PR. Acabei de adicionar os atalhos em components/higher-order/navigate-regions/index.js , é muito fácil tentar.

Então, depois da grande ilusão de que F6 era uma opção, acho que estamos novamente no problema inicial.

Na reunião de acessibilidade, decidimos testar uma dessas combinações de teclas:

Próximo ponto de referência: Alt + Shift + N
Marco anterior: Alt + Shift + P

Ou

Próximo ponto de referência: Ctrl + Alt + N
Ponto de referência anterior: Ctrl + Alt + P

Concluímos que é necessário que haja três combinações de teclas, mesmo que seja difícil de lembrar. Mais uma vez, a documentação é a _chave_ aqui.

Também observando que há uma extensão de Marcos que usa esses atalhos de teclado.

Agora existe um PR pendente https://github.com/WordPress/gutenberg/pull/8005 para testar os atalhos:

Próximo ponto de referência: Alt + Shift + N
Marco anterior: Alt + Shift + P

/ Cc @samikeijonen @rianrietveld @audrasjb (pingando você como um usuário sortudo de layouts de teclado sem tecla de fundo)

layouts de teclado sem tecla de fundo

Esses parecem bons atalhos de teclado!

Não tenho a intenção de objetar, esta é uma área em que me refiro aos especialistas. No entanto, gostaria de esclarecer que também não tenho uma chave de crase:

Mas o atalho do teclado ainda funciona. Ou seja, pressiono Ctrl + [a tecla abaixo de escape] e ele navega entre as regiões perfeitamente. Esta foi a sugestão a que me referi anteriormente - que usemos a mesma área do teclado para todas as regiões, mesmo que a tecla real varie de região para região - pode ser backtick nos EUA e $ em teclados dinamarqueses. Esta é uma opção adicional aos outros atalhos?

Mas o atalho do teclado ainda funciona. Ou seja, eu pressiono Ctrl + [a tecla abaixo de escape]

Bem, maldito seja, isso também funciona para mim! Mesmo que a tecla pareça diferente no meu teclado. Acho que podemos ter os dois.

Mas o atalho do teclado ainda funciona. Ou seja, eu pressiono Ctrl + [a tecla abaixo de escape],

Não, não 🙂Só para esclarecer novamente, em meu laptop Windows alternando entre idiomas e layouts de teclado:

• Inglês com teclado americano: funciona
• Italiano com teclado americano: funciona
• Italiano com teclado italiano: não funciona

Lamento, mas não ajuda eu não estar sendo claro. O que venho tentando dizer, e claramente falhando, é que parece que deveria ser possível usar _a chave geograficamente localizada abaixo da tecla de escape_ em todo o mundo. Este é um bom local _geográfico_ porque está próximo à guia, que é freqüentemente usada para navegação relacionada, e é um local conveniente para um recurso tão poderoso.

Acontece que funciona nos EUA e na Dinamarca, e talvez também na Finlândia? Precisaríamos de uma série de combinações de teclas para cada idioma. Com base nesta imagem (corrija-me se estiver errado), gostaríamos de oferecer suporte a Ctrl+~ para que funcione em teclados italianos.

Sei que é um trabalho extra fazer com que funcione em todos os locais e, de fato, pode não valer a pena. Mas eu queria ter certeza de que meu ponto foi entendido.

Quando eu mudo para o layout do teclado italiano, essa tecla se torna a tecla de barra invertida \ . https://it.wikipedia.org/wiki/File : Italian_Keyboard_layout.svg

Minha opinião pessoal é que dada a variedade de layouts de teclado e também o fato de que às vezes os fornecedores implementam layouts fora do padrão, isso vai ser um inferno

Você pode verificar como essa chave difere nos vários layouts QWERTY aqui: https://en.wikipedia.org/wiki/QWERTY
Existe uma grande variedade. Além disso, o espanhol é diferente do espanhol latino-americano, o português é diferente do brasileiro, etc. Os layouts do idiomas com alfabetos não latinos .

Atalhos de teclado adicionais para o componente "navegar por regiões" foram adicionados em # 8005. Isso resolve o problema imediato com a tecla backtick não presente em todos os layouts de teclado. Introduzir um mecanismo para personalizar atalhos ainda é uma boa ideia para o futuro difícil. Passando para o projeto de ideias.

Atualização rápida: acabei de notar que o atalho Ctrl + backtick não funciona no Opera (mac) porque é usado pelo navegador:

Mais uma prova de que os conflitos de atalhos são muito prováveis ​​e não há uma maneira confiável de ter atalhos "livres de conflito".

Relacionado: https://wordpress.org/support/topic/modifying-shortcuts-in-gutenberg/

Estou repassando todo o tópico, mas já verifiquei e:

• Ctrl + crase não funciona para o idioma búlgaro / inglês;
• Alt + Shift + 1/2/3/4 também não funciona para o idioma búlgaro / inglês;

Eu definitivamente preciso encontrar uma maneira de usar a combinação Alt + Shift + número, porque usar o mouse para escolher cada título é um desastre.
Chrome @ Windows
Wordpress 5.1.1.

Eu realmente não entendo onde exatamente foi parar meu comentário.
Vou fazer upload de uma captura de tela do problema que desejo abordar. Eu só preciso ter a opção de usar o atalho para os títulos novamente, sem clicar com o mouse para cada título em cada postagem do blog ou etc.

Já tentei usar Ctrl + crase para o idioma búlgaro - não funciona.
O mesmo para Alt + Shift + qualquer número.
Chrome @ Windows

Devemos começar a discutir algumas idéias de qual IU usar para personalizar os atalhos - deve estar dentro do editor? Separadamente? Deve ser extensível? (Eu poderia imaginar um plug-in ou um conjunto de configurações que as pessoas poderiam extrair do repositório para, digamos, um bom conjunto de atalhos para um layout de teclado espanhol no Mac e assim por diante.)

Acho uma ótima ideia possibilitar a alteração de atalhos de teclado. (Eu também encontro problemas com o teclado alemão ...).

Eu gostaria de levantar a questão, como os usuários podem sincronizar suas configurações pessoais entre diferentes instâncias do WordPress? Exportar e importar JSON? Sincronizá-los adicionalmente com o armazenamento local? (Mas o armazenamento local pode ser acessado de domínios diferentes? Acho que não.)

(Claro, em WordPress.com/with Jetpack ele pode ser armazenado na conta do WordPress.com.
<vision_mode> Talvez uma "Gutenberg-Cloud-Account" neutra e compatível com GPDR possa ajudar, o que salva configurações como as configurações do teclado, modo de tela inteira, configurações da barra lateral etc. e pode até mesmo ser usado no Drupal etc. ) Depois de abrir o Gutenberg em uma instância do WP pela primeira vez, ele poderia solicitar a conta diretamente. Mas isso está definitivamente fora do escopo deste problema ... </vision_mode> )

Salvar as configurações do usuário no armazenamento local não é o ideal e mostra cada vez mais seus limites. Acho que há um projeto em algum lugar para abandonar esse padrão e salvar as configurações do usuário no banco de dados, como deveria ser desde o início. Não tenho certeza sobre o progresso lá, mas acho que deve ser priorizado.

Aqui está um protótipo de um fluxo que visa abordar a personalização de atalhos de teclado em sua forma mais básica.

Estou usando propositalmente as iterações de design mais recentes em que @karmatosed está trabalhando para o # 24965 como moldura para esse novo recurso, pois acho que o novo modal de Opções ou Preferências será um bom lugar para a IU de atalhos de teclado viver. Dito isso, por favor, não preste muita atenção ao menu à esquerda, por enquanto vamos nos concentrar apenas nos atalhos de teclado.

O fluxo abrange algumas ações básicas:

1. Exibir todos os atalhos de teclado
2. Editar / personalizar um atalho de teclado
3. Desativar um atalho de teclado
4. Restaurar padrões

Também estou considerando que este será um recurso importante para usuários de teclado e tecnologia assistiva, então quero ter certeza de que o manteremos simples e óbvio.

Adoraria ouvir seus comentários:

• Este fluxo é intuitivo?
• Estou perdendo uma ação ou recurso?
• De uma perspectiva a11y, estamos tornando mais fácil para os usuários de teclado e tecnologia assistiva personalizar seus atalhos de teclado?

Além do fluxo acima, também explorei um layout diferente para exibir a lista de atalhos de teclado:

| Rótulos à esquerda, atalhos à direita | Atalhos à esquerda, rótulos à direita |
| ------------ | -------------- |
| | |

Eu me inclino para rótulos à esquerda, atalhos à direita, já que esse é um padrão comum e bem estabelecido, mas também gostaria de ouvir seus pensamentos. Qual você acha mais fácil de ler e escanear?

@enriquesanchez

Eu me inclino para rótulos à esquerda, atalhos à direita, já que esse é um padrão comum e bem estabelecido, mas também gostaria de ouvir seus pensamentos. Qual você acha mais fácil de ler e escanear?

Layout perfeito. A questão é: como os atalhos serão exibidos? Por exemplo, à direita, onde você seleciona um atalho, será uma caixa de seleção, rádio ou campo de seleção?

Obrigado.

Obrigado, @alexstine!

A questão é: como os atalhos serão exibidos?

Estou propondo que os atalhos do teclado sejam exibidos de maneira muito semelhante à forma como eles aparecem atualmente no menu 'Opções' do editor de blocos, mas tenho alguns elementos adicionais no protótipo.

Há um título na parte superior que diz "Atalhos de teclado" seguido por um breve texto de descrição. Este texto diz: "Você pode editar atalhos e personalizá-los de acordo com suas necessidades ou deixá-los em branco para desativá-los."

Em seguida, há um botão de texto que diz "Restaurar padrões". A intenção dessa opção é que, se você fizer algumas alterações em seus atalhos de teclado e precisar ou quiser restaurá-los de volta ao estado inicial, basta clicar neste botão e todos os atalhos serão restaurados ao valor padrão.

Em seguida, os atalhos aparecem como uma lista, com o rótulo / descrição à esquerda, seguido pela combinação de teclas de atalho à direita, na mesma linha. Minha proposta também adiciona um botão de ícone de lápis à direita ao lado das teclas de atalho. Clicar no botão do ícone de lápis exibe um campo de entrada de texto que vem pré-preenchido com a combinação de atalho. A combinação de atalhos também está pré-selecionada para que você possa começar a digitar e substituí-la facilmente.

Conforme você digita a nova combinação de teclas de atalho desejada, os caracteres aparecem no campo de entrada. Ao lado do campo de entrada, há um botão de texto 'Salvar' e um botão de ícone 'Cancelar'. Se você selecionar 'Salvar', a nova combinação de teclas de atalho será gravada e aparecerá no lugar da anterior.

Também estou propondo que, além de alterar a combinação de teclas de atalho, você também pode deixar o campo vazio e selecionar 'Salvar' para desativar uma tecla de atalho. Se você fizer isso, a combinação de teclas de atalho que exibimos é substituída por um rótulo de texto que diz 'Desativado'.

Como é esse fluxo para você? É intuitivo o suficiente? Há alguma opção ou recurso ausente neste fluxo?

@enriquesanchez Acho que o fluxo é perfeito. Obrigado por explicar isso.

Eu gosto mais de como você consegue se concentrar em um atalho por vez, em vez de ter uma grande lista de atalhos com campos de texto. Você precisa intencionalmente clicar no botão Editar primeiro por atalho.

Como os conflitos podem ser tratados? Por exemplo, definir o atalho 1 para X e o atalho 2 para X. Haverá algum tipo de alerta?

Obrigado.

Muito obrigado pela proposta e por ajudar este assunto finalmente a avançar.

Primeiras observações:

• Além do botão global "Restaurar padrões", acho que é necessário um botão para cada atalho. Como usuário, posso querer redefinir um atalho de teclado único e específico para seus padrões e não perder todos os outros atalhos personalizados que defini anteriormente. Em vez disso, a IU atual permite apenas redefini-los todos ou nenhum.
• Devemos evitar botões apenas com ícones e usar botões com texto visível. Os controles apenas de ícone são um antipadrão de acessibilidade e não devemos usá-lo, pelo menos aqui, visto que esta é uma interface de usuário voltada principalmente para usuários com necessidades de acessibilidade. O ícone "editar", por exemplo, deve ser substituído por texto simples e visível: "Editar".
• Em relação a "À medida que você digita a nova combinação de teclas de atalho desejada, os caracteres aparecem no campo de entrada", devemos considerar que no Windows as teclas modificadoras não usam caracteres únicos. Eles são texto simples para "Ctrl", "Shift", "Alt" ... então isso precisaria de um mecanismo técnico diferente, mas também o design deveria levar isso em consideração. Captura de tela da lista de atalhos de teclado atual no Windows:

Tenho algumas reservas sobre os seguintes itens:

• O campo de entrada para inserir um atalho personalizado aparece _e substitui_ parte da IU: a equipe de acessibilidade já apontou que este não é um bom padrão (veja por exemplo a discussão nas barras de ferramentas). Em vez disso, valeria a pena considerar um padrão de divulgação: clique no botão Editar, um campo de entrada é revelado após o botão Editar _além_ aos outros elementos da IU.
• Os botões "Salvar" e "Cancelar" exibidos dentro do campo de entrada parecem estranhos para mim e são potencialmente confusos para os usuários. Além dos detalhes de implementação técnica, não vejo a necessidade de exibi-los dessa forma e encorajo um posicionamento mais padrão, esperado, desses botões.
• O botão "Cancelar" é outro botão apenas de ícone que usa um "X". Além do "X" sugerir a ideia de "fechar" em vez de "cancelar", também este botão deve usar texto simples em vez de um ícone.

Re: preocupação de @alexstine com conflitos: sim, deve haver um mecanismo para detectar conflitos e avisar os usuários que um atalho de teclado já está em uso. Acho que isso é tecnicamente factível, mas sim, trata-se de detalhes de implementação enquanto ainda estamos na fase inicial de design 🙂

Obrigado pelo feedback, @alexstine e @afercia! Aqui está uma iteração do design que abordou alguns dos pontos que você fez.

Como gostaríamos de ter as opções para Editar, Desativar e Restaurar para cada atalho de teclado individual, estou vendo essas opções aparecerem em um menu popover:

_A imagem acima mostra uma lista de atalhos de teclado. Para cada item, há um rótulo / descrição à esquerda seguido pelas teclas de atalho à direita na mesma linha. Ao lado dele, há um botão de menu de reticências, semelhante ao que é encontrado no editor e barras de ferramentas de bloco. Em um desses atalhos de teclado, o botão de menu de reticências é ativado e um popover com três itens de menu aparece abaixo dele: 'Editar atalho,' Desativar atalho 'e' Restaurar para o padrão '. O último, 'Restaurar para o padrão', só deve aparecer quando / se o atalho de teclado tiver sido personalizado._

Se eu clicar em 'Editar atalho', aparecerá uma caixa de diálogo. Eu concordo com você @afercia , que esta caixa de diálogo não deve substituir nenhum conteúdo. O que estou propondo é que o diálogo fique no topo e alinhado com a linha de atalho do teclado para maior clareza e proximidade. O que eu gosto nessa solução é que o rótulo / descrição do atalho é mantido visível, então é mais fácil correlacionar os dois.

_A imagem acima mostra uma caixa de diálogo da IU que contém um campo de entrada com a combinação de atalhos do teclado e os botões Salvar e Cancelar à direita dela._

Quanto aos conflitos, acho que precisamos mostrar uma mensagem de erro no local, perto do campo de entrada. Aqui está o que estou propondo:

_A imagem acima mostra a caixa de diálogo da IU anterior que aparece ao editar um atalho. O campo de entrada tem uma borda vermelha em torno dele para indicar um estado de erro e, abaixo dele, há uma mensagem de erro que diz "Este atalho já está sendo usado.". O botão 'Salvar' está em um estado desabilitado porque a ação não pode ser realizada._

O que você acha desta iteração? Eu acredito que atendeu ao feedback que você trouxe.

@enriquesanchez Desculpe, agora vou ser difícil.

Como gostaríamos de ter as opções para Editar, Desativar e Restaurar para cada atalho de teclado individual, estou vendo essas opções aparecerem em um menu popover:

Do meu ponto de vista, acho que um menu dentro de uma caixa de diálogo não é uma boa ideia. Ele adiciona outra seleção necessária para entrar no menu e, em seguida, localizar, editar, excluir ou restaurar. De qualquer forma, não colocá-los em um menu?

Eu posso ver os dois lados ... Provavelmente não vai caber bem em telas menores, mas apenas algo para se pensar.

Obrigado.

Desculpe, agora vou ser difícil.

De forma alguma @alexstine , eu realmente aprecio seus comentários e entendo seu ponto.

Meu raciocínio para ter essas três opções dentro de um menu era que tê-las expostas e repetidas em todas as linhas, em uma lista de dezenas de atalhos, iria adicionar muita confusão e ruído visual. Isso pode tornar essa IU difícil de analisar para algumas pessoas.

Definitivamente, vou procurar alternativas. Uma ideia que tive inicialmente, mas não explorei totalmente, é expor essas opções assim que você clicar no botão 'Editar' do atalho. Precisaremos de um diálogo maior para caber tudo, mas acho que vale a pena tentar.

A última iteração parece próxima. Alguns detalhes a serem considerados, mas não são bloqueadores:

• Popovers / modais geralmente têm o botão CTA (Salvar) à direita.
• A mensagem de erro embutida pode ser uma interação um pouco estranha, pois o contêiner precisa ser redimensionado para ser exibido. Pode valer a pena explorar algumas outras opções aqui. Algumas idéias que vêm à mente: ter um texto auxiliar / instrutivo em seu lugar que seja substituído pela mensagem de erro, fazer com que o erro seja mostrado como um erro de banner na tentativa de salvar ou algo mais.

• Popovers / modais geralmente têm o botão CTA (Salvar) à direita.

@kellychoffman Para focar nas configurações do teclado nesta edição, escrevi uma resposta mais geral aqui: https://github.com/WordPress/gutenberg/issues/24965#issuecomment -706520051

Resumindo: acho que os botões Salvar podem ser usados ​​contextualmente em relação à categoria de preferência. Talvez as configurações do teclado possam lucrar com um botão Salvar geral. O que é mais acessível? Um único botão Salvar ou um botão Salvar para cada atalho? (Talvez isso esteja relacionado à questão de quando e onde os erros de conflito devem aparecer.)

@mariohamann Este é um ótimo feedback, Mario. Obrigado!

Talvez as configurações do teclado possam lucrar com um botão Salvar geral. O que é mais acessível?

Eu acho que depende. Se vou alterar apenas um atalho de teclado, ter o botão de confirmação bem ao lado do campo de atalho é definitivamente mais fácil para a maioria das pessoas. Eu não teria que navegar para encontrar o botão Salvar em outro lugar abaixo da lista.

Se eu fosse alterar muitos desses atalhos, talvez fosse mais fácil ter apenas um botão Salvar. Dito isso, suspeito que o último será o caso menos comum aqui e devemos otimizar para ações de edição única.

• Popovers / modais geralmente têm o botão CTA (Salvar) à direita.
• A mensagem de erro embutida pode ser uma interação um pouco estranha, pois o contêiner precisa ser redimensionado para ser exibido. Pode valer a pena explorar algumas outras opções aqui

Obrigado! Aqui estão algumas iterações que abordam seu feedback, @kellychoffman

Eu gosto da direção de usar o banner de avisos padrão que usamos em outros lugares. O aviso fica em destaque e por aparecer dentro do modal, fica próximo ao local onde ocorre o erro. Há também a vantagem de que esses avisos sejam comunicados adequadamente às tecnologias assistivas com wp.a11y.speak() .

Também explorei alternativas de como acessar as opções de edição (Personalizar, Desativar e Restaurar). Na exploração anterior, observei um menu suspenso ao lado de cada atalho com as três opções:

_A imagem acima mostra uma lista de atalhos de teclado. Para cada item, há um rótulo / descrição à esquerda seguido pelas teclas de atalho à direita na mesma linha. Ao lado dele, há um botão de menu de reticências, semelhante ao que é encontrado no editor e barras de ferramentas de bloco. Em um desses atalhos de teclado, o botão de menu de reticências é ativado e um popover com três itens de menu aparece abaixo dele: 'Editar atalho,' Desativar atalho 'e' Restaurar para o padrão '._

Desta vez, observei como podemos condensar todas as três ações em um único diálogo:

_A imagem acima mostra uma lista de atalhos de teclado. Para cada item, há um rótulo / descrição à esquerda seguido pelas teclas de atalho à direita na mesma linha. Ao lado dele, há um botão de menu Editar. Em um desses atalhos de teclado, o botão Editar é ativado e uma caixa de diálogo fica logo abaixo dele. A caixa de diálogo possui um campo de texto com a tecla de atalho. É aqui que o usuário poderá personalizar o atalho. Abaixo deste campo de texto, há um controle de alternância com o rótulo 'Desativar atalho'. Este é o controle que os usuários ativarão se quiserem desativar o atalho de teclado. Abaixo segue uma linha de três botões. O primeiro é 'Restaurar para o padrão', que só deve aparecer se o atalho tiver sido personalizado. Em seguida, siga 'Cancelar' e 'Salvar' ._

Estou dividido entre esses dois. Por um lado, gosto da clareza de escolhas na versão anterior e como ela mantém o mínimo de diálogo de edição. Mas, por outro lado, gosto de como esta última exploração simplifica o fluxo, oferecendo apenas uma escolha para fazer de antemão.

Eu adoraria ouvir seus comentários ou sugestões.

Realmente gosto dessas explorações. Eu gostaria de adicionar algumas idéias sobre o visual, espero que esteja tudo bem:

• Banner de avisos: Pessoalmente tenho a sensação de que o aviso poderia merecer um pouco mais de margem, especialmente para cima. Parece um pouco "estimulado". Talvez usar a mesma margem do título (como "Atalhos de teclado") funcionaria, então visualmente "substitui" o título?
• Realmente amo o último. Eu preferiria que o campo de diálogo aparecesse ACIMA do botão de edição se houver espaço suficiente. Como o atalho é definitivamente alterado com o teclado, a próxima interação possível com o mouse seria clicar no botão "Salvar". Portanto, se a caixa de diálogo aparecer acima, o caminho com o mouse para o botão "Salvar" é muito mais curto.
• Outra coisa que me pergunto: apoiaria o processo, se o atalho que está sendo editado no momento fosse mais enfatizado (ou os demais sendo mais reduzidos?). Acho que o "azul" atual pode ser muito decente para indicar o estado atual - especialmente em termos de a11y. A próxima imagem mostra duas ideias: a primeira tornando os outros itens não selecionados mais transparentes, a segunda invertendo o botão clicado. Este último é melhor para mim. Você pode experimentar aqui na Figma: https://www.figma.com/proto/WwbLC4uG5BGW38ZlCRh9uz/Preferences?node-id=8%3A66&viewport=-1374%2C108%2C0.36925479769706726&scaling=scale-down

Maquete de todas as três sugestões abaixo.

Aqui está uma última atualização minha sobre esse problema.

Fiz algumas pequenas atualizações no fluxo:

• Reduziu a quantidade de IU: não estou mais usando um popover dentro do modal (obrigado @alexstine pelo feedback sobre isso!)
• Simplificou algumas ações, como restaurar e desabilitar atalhos: removeu os botões e alternadores que eu estava usando anteriormente. Adicionados alguns esclarecimentos à descrição da seção sobre estes: _ "Estes são os atalhos de teclado disponíveis no editor de bloco. Você pode personalizá-los de acordo com suas necessidades ou deixar o campo vazio para desativá-los." _
• Agora estou usando os atalhos modais atuais no editor de bloco para ter uma imagem mais clara de onde eles ficarão.

Aqui está um GIF do protótipo atualizado:

E alguns modelos estáticos para uma visão geral mais detalhada:

_Descrição: A imagem acima mostra os atalhos de teclado modais abertos no editor de blocos. O modal contém uma lista de todos os atalhos disponíveis e ao lado de cada um um botão de edição (um ícone de lápis) ._

_Descrição: clicar no botão editar para qualquer um dos atalhos exibirá um campo de texto embutido com o atalho atualmente atribuído. Os usuários podem inserir um atalho diferente, se necessário. Há um botão Salvar próximo ao campo._

_Descrição: Se o usuário inserir um atalho que já está sendo usado, exibimos uma mensagem de erro "Atalho já em uso." abaixo do campo e realce o campo em vermelho. Esta mensagem de erro também precisa ser comunicada às tecnologias assistivas._

_Descrição: se um campo for deixado em branco, o atalho será desabilitado e um rótulo "Nenhum" aparecerá no lugar do atalho. Depois que um atalho foi editado / modificado, exibimos um pequeno ponto indicando que o atalho foi personalizado. Isso deve ajudar os usuários a rastrear quais atalhos eles modificaram. O ponto deve incluir uma dica de ferramenta para maior clareza e essa mudança de estado também deve ser comunicada às tecnologias assistivas._

Se descobrirmos que o ponto não funciona aqui, também podemos optar por um asterisco:

_Descrição: um atalho que já foi modificado mostrará um botão "Restaurar" adicional ao editá-lo. Este botão de restauração aparecerá próximo ao botão Salvar. Clicar em restaurar retorna o atalho ao valor padrão e fecha o campo de edição._

Eu acho que o acima é um bom lugar para tentar uma v1 deste recurso. Não gastei muito tempo nisso, mas para um esforço de acompanhamento, será ótimo considerar a sugestão de @mtias :

Deve ser extensível? (Eu poderia imaginar um plug-in ou um conjunto de configurações que as pessoas poderiam extrair do repositório para, digamos, um bom conjunto de atalhos para um layout de teclado espanhol no Mac e assim por diante.)

Isso pode ser tão simples quanto adicionar uma opção para importar uma configuração de atalhos de teclado:

_Descrição: a imagem acima mostra o mesmo modal de atalhos de teclado desta proposta com um botão adicional que diz "Importar configuração" logo abaixo da descrição do modal._

Se dermos essa opção aos usuários, devemos também oferecer uma maneira para que eles restaurem e voltem aos padrões.

E, por último, também fiz uma simulação de como será o fluxo do teclado para este recurso. Considerando que este será um recurso que beneficiará enormemente os usuários de teclado e usuários de tecnologias assistivas, pensei que seria importante considerar como o fluxo funcionará nesse cenário:

_Descrição: o gif acima mostra o fluxo de foco do teclado do mesmo modal de atalhos descrito acima. É um fluxo passo a passo de cada parada de foco necessária para personalizar um campo de atalho.

Realmente gosto dessas explorações!
Em um ponto do seu
último GIF, fiquei um pouco irritado: depois de "escrever" um novo atalho, esperava usar a tecla Enter para salvá-lo. Em seu GIF, você está usando a guia para obter o botão Salvar. Eu acho que você precisava disso para tornar possível chegar ao botão para reverter uma configuração? Caso contrário, eu definitivamente esperaria pressionar "voltar" para salvar o atalho e "escapar" para esquecer o novo atalho.

O que você acha de usar diretamente um ícone "Desfazer" para indicar alterações e torná-las reversíveis? (Aumentou um pouco o espaço entre os ícones "Desfazer" e "Editar" na imagem a seguir.)

Isso até tornaria o fluxo de "Editar" mais limpo, já que o "Desfazer" não seria mais necessário. (Na minha opinião, clicar fora da área de edição ou pressionar esc reverteria as alterações _atuais_ também.