Eu separei isso de # 2164. Essa questão é realmente sobre o fato de que os leitores de tela não podem ler o conteúdo do editor. Quero falar sobre um problema de acessibilidade mais simples:
Se você tiver o Ace em um formulário e estiver percorrendo o formulário de campo para campo, uma vez que entrar no Ace, você está preso, porque o Tab recua a linha de código atual (o que é muito natural). Isso é um problema para nós, e a melhor solução que consegui encontrar é esta:
Apresentamos dois modos para cada instância do editor:
Diante disso, o comportamento é o seguinte:
Devido a 1), você pode simplesmente percorrer todo o formulário sem travar, como seria de esperar. Devido a 2), uma vez que você está digitando o código, Tab recua a linha atual, como seria de esperar. 3) e 4. Torne possível a fuga.
Isso não é perfeito. Vejo alguns problemas: isso pode ser descoberto por novos usuários? Deve haver uma indicação visível (ou auditiva) de qual modo você está? Acho que uma indicação pode ser boa. Por outro lado, ocupar qualquer espaço da tela ou fazer com que o leitor de tela fale qualquer coisa (quando você deseja se concentrar no que está digitando ou onde está no formulário) parece indesejável. Se o comportamento fosse natural o suficiente, não importaria.
Se as pessoas gostarem dessa sugestão, terei prazer em tentar codificá-la.
Esta ideia parece interessante e será útil como uma extensão opcional, não tenho certeza sobre habilitá-la por padrão, pois muitos sites têm sua própria forma de navegação entre os elementos, por exemplo, no Cloud9 existem atalhos para enfocar elementos específicos como árvore de arquivos ou terminal e ctrl-cmd-arrow para alternar o foco entre os painéis do editor.
Obrigado pelo feedback.
Parece uma boa solução.
@timhunt , você acabou codificando isso? Nós o usaríamos diretamente em nosso garfo ou como uma extensão. Fico feliz em fazer nossa própria extração de código se estiver aberto em algum lugar e você não tiver tempo para limpá-lo.
Desculpe, não - pelo menos não dentro do Ace. Estávamos usando o Ace dentro do tipo de questão CodeRunner para Moodle e ficou mais fácil implementar o que queríamos na camada de cola: https://github.com/trampgeek/moodle-qtype_coderunner/blob/master/amd/src /aceinterface.js.
No entanto, você pode copiar qualquer um desses códigos.
Estou tendo o mesmo problema com o Ace, e esta é a solução alternativa que eu inventei.
Use a função setCommandEnabled de https://stackoverflow.com/questions/24963246/ace-editor-simply-re-enable-command-after-disabled-it
Em seguida, configure o editor desta forma:
editor.on('focus', function() {
setCommandEnabled(editor, "indent", true)
setCommandEnabled(editor, "outdent", true)
})
editor.commands.addCommand({
name: "escape",
bindKey: {win: "Esc", mac: "Esc"},
exec: function() {
setCommandEnabled(editor, "indent", false)
setCommandEnabled(editor, "outdent", false)
}
});
Funciona razoavelmente bem. Pressione Escape e Tab / Shift + Tab para escapar do editor Ace e o próximo / anterior elemento focalizável obtém o foco.
Usar Ctrl + [em vez de Shift + Tab e Ctrl +] em vez de Tab funciona no editor ace, então apenas removi o comando tab e nenhuma armadilha agora
aceEditor.commands.removeCommand (aceEditor.commands.byName.indent);
aceEditor.commands.removeCommand (aceEditor.commands.byName.outdent);
No Mac, consegui usar Option + Tab para escapar
Comentários muito úteis
Esta ideia parece interessante e será útil como uma extensão opcional, não tenho certeza sobre habilitá-la por padrão, pois muitos sites têm sua própria forma de navegação entre os elementos, por exemplo, no Cloud9 existem atalhos para enfocar elementos específicos como árvore de arquivos ou terminal e ctrl-cmd-arrow para alternar o foco entre os painéis do editor.