He separado esto del # 2164. Ese problema se trata realmente del hecho de que los lectores de pantalla no pueden leer el contenido del editor. Quiero hablar sobre un problema de accesibilidad más simple:
Si tiene Ace en un formulario y está tabulando el formulario de un campo a otro, una vez que ingrese a Ace, se atascará, porque Tab sangra la línea de código actual (lo cual es muy natural). Este es un problema para nosotros, y la mejor solución que he podido encontrar es la siguiente:
Introducimos dos modos para cada instancia del editor:
Dado eso, el comportamiento es el siguiente:
Debido a 1), puede abrir paso a través de todo el formulario sin quedarse atascado, como es de esperar. Debido a 2), una vez que está escribiendo el código, Tab sangra la línea actual, como es de esperar. 3) y 4. Hacer posible la fuga.
Esto no es perfecto. Veo algunos problemas: ¿Es esto detectable para nuevos usuarios? ¿Debería haber una indicación visible (o auditiva) de en qué modo se encuentra? Siento que una indicación podría ser buena. Por otro lado, ocupar espacio en la pantalla o hacer que el lector de pantalla hable algo (cuando desea concentrarse en lo que está escribiendo o en dónde se encuentra en el formulario) parece indeseable. Si el comportamiento fuera lo suficientemente natural, no importaría.
Si a la gente le gusta esta sugerencia, estoy feliz de intentar codificarla.
Esta idea suena interesante y será útil como una extensión opcional, no estoy seguro de habilitarla por defecto ya que muchos sitios tienen su propia forma de navegación entre elementos, por ejemplo, en Cloud9 hay atajos para enfocar elementos específicos como árbol de archivos o terminal. y ctrl-cmd-arrow para cambiar el enfoque entre los paneles del editor.
Gracias por la respuesta.
Suena como una buena solución.
@timhunt , ¿terminaste codificando esto? Lo usaríamos directamente en nuestra bifurcación o como una extensión. Feliz de hacer nuestra propia extracción de código si está abierto en algún lugar y no tienes tiempo para limpiarlo.
Lo siento, no, al menos no dentro de Ace. Estábamos usando Ace dentro del tipo de pregunta CodeRunner para Moodle, y resultó ser más fácil implementar lo que queríamos en la capa de pegamento: https://github.com/trampgeek/moodle-qtype_coderunner/blob/master/amd/src /aceinterface.js.
Sin embargo, puede copiar cualquier parte de ese código.
Me encuentro con el mismo problema con Ace, y esta es la solución que se me ocurrió.
Utilice la función setCommandEnabled de https://stackoverflow.com/questions/24963246/ace-editor-simply-re-enable-command-after-disabled-it
Luego configure el editor de esta manera:
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 bastante bien. Presione Escape y Tab / Shift + Tab, y escapa del editor Ace y el elemento enfocable siguiente / anterior se enfoca.
Usar Ctrl + [en lugar de Shift + Tab y Ctrl +] en lugar de Tab funciona en el editor ace, así que simplemente eliminó el comando de tabulación y no hay trampa ahora
aceEditor.commands.removeCommand (aceEditor.commands.byName.indent);
aceEditor.commands.removeCommand (aceEditor.commands.byName.outdent);
En Mac pude usar Opción + Tab para escapar
Comentario más útil
Esta idea suena interesante y será útil como una extensión opcional, no estoy seguro de habilitarla por defecto ya que muchos sitios tienen su propia forma de navegación entre elementos, por ejemplo, en Cloud9 hay atajos para enfocar elementos específicos como árbol de archivos o terminal. y ctrl-cmd-arrow para cambiar el enfoque entre los paneles del editor.