Foco de gestión e inertes | Programar Plus

Muchas formas de tecnología de asistencia utilizan la navegación por teclado para comprender y actuar sobre el contenido de la pantalla. Una forma de navegar es a través de la tecla Tabulador. Es posible que ya esté familiarizado con esta forma de navegar si la usa para saltar rápidamente de una entrada a otra en un formulario sin tener que alcanzar su mouse o trackpad.

La pestaña saltará a los elementos interactivos en el orden en que aparecen en el DOM. Esta es una de las razones por las que es tan importante que el orden de su código fuente coincida con la jerarquía visual de su diseño.

La lista de elementos interactivos que se pueden tabular es:

  • Anclas, cuando el href el atributo está presente,
  • <button>,
  • <input> y <textarea>, con una etiqueta adjunta,
  • <select>,
  • <details>,
  • <audio> y <video> cuando los controles están presentes,
  • <object>, dependiendo de cómo se use,
  • cualquier elemento con desbordamiento de desplazamiento en Firefox,
  • cualquier elemento con el contenteditable atributo que se le aplica, y
  • cualquier elemento con el tabindex atributo aplicado a él (más sobre esto en un momento).

Un elemento interactivo gana atención cuando:

  • Se ha navegado a través de la tecla Tabulador,
  • se hace clic en él, siguiendo un ancla que se vincula a otro elemento enfocable,
  • o el foco se establece programáticamente a través de element.focus() en JavaScript.

El enfoque es similar a pasar el cursor del mouse sobre un elemento, en el sentido de que está identificando lo que desea activar. También es por eso que los estilos de enfoque visualmente obvios son tan importantes.

Indicación de enfoque moviéndose a través de una estructura alámbrica de la página de inicio. Comienza en el logotipo, pasa a productos, luego a servicios, luego a carreras, blog, contacto y se detiene en un botón Más información.

Gestión de foco

La gestión de enfoque es la práctica de coordinar lo que puede y no puede recibir eventos de enfoque. Es una de las cosas más difíciles de hacer en el desarrollo front-end, pero es importante para hacer que los sitios web y las aplicaciones web sean accesibles.

Buenas prácticas para la gestión del foco

El 99% de las veces, desea dejar el orden de enfoque solo. No puedo enfatizar esto lo suficiente.

Focus simplemente funcionará para usted sin necesidad de un esfuerzo adicional, siempre que esté utilizando el <button> elemento para botones, el elemento ancla para enlaces, el <input> elemento para la entrada del usuario, etc.

Hay casos excepcionales en los que es posible que desee aplicar el enfoque a algo fuera del orden de enfoque, o hacer que algo que normalmente no puede recibir eventos de enfoque sea enfocable. Aquí hay algunas pautas sobre cómo hacerlo de una manera accesible e intuitiva para navegar:

Hacer: aprender sobre el tabindex atributo

tabindex permite enfocar un elemento. Acepta un número entero como valor. Su comportamiento cambia según el número entero que se utilice.

No: Aplicar tabindex="0" a cosas que no lo necesitan

Elementos interactivos que pueden recibir el foco del teclado (como el <button> elemento) no necesita tener el tabindex atributo que se les aplica.

Además, no necesita declarar tabindex en elementos no interactivos para garantizar que puedan ser leídos por la tecnología de asistencia (de hecho, esto es una falla de WCAG si no hay un rol y un nombre accesible). Hacerlo en realidad crea una experiencia inesperada y difícil de navegar para una persona que usa tecnología de asistencia: tienen otras formas esperadas de leer este contenido.

✅ Hacer: Usar tabindex="-1" para enfocar con JavaScript

tabindex="-1" se utiliza para crear widgets interactivos accesibles con JavaScript.

una declaración de tabindex="-1" hará que un elemento sea enfocable a través de JavaScript o haga clic/toque. Sin embargo, no permitirá que se navegue a través de la tecla Tabulador.

❌ No: use un número entero positivo como tabindex valor

Este es un serio antipatrón. El uso de un número entero positivo anulará el orden de tabulación esperado y creará una experiencia confusa y desorientadora para la persona que intenta navegar por su contenido.

Un ejemplo de esto es bastante malo. Múltiples declaraciones es una pesadilla total. En serio: no lo hagas.

❌ No: crear una orden de enfoque manual

Los elementos interactivos se pueden tabular solo en virtud de su uso. No es necesario establecer una serie de tabindex atributos con valores crecientes en cada elemento interactivo en el orden que cree que debería usar la persona que navega por su sitio. Dejarás que el orden de los elementos en el DOM haga esto por ti.

Trampa de enfoque

Puede haber momentos en los que necesite evitar que las cosas se enfoquen. Un buen ejemplo de esto es la captura de foco, que es el acto de restringir condicionalmente los eventos de foco a un elemento y sus elementos secundarios.

La captura de foco no debe confundirse con las trampas de teclado (a veces denominadas trampas de foco). Las trampas de teclado son situaciones en las que alguien que navega a través del teclado no puede escapar de un widget o componente debido a un bucle desagradable de lógica mal escrita.

Un ejemplo práctico de para qué usaría el reventado de enfoque sería para un modal:

Indicación de enfoque moviéndose a través de una estructura alámbrica de la página de inicio y abriendo un modal para demostrar el reventado de enfoque. Dentro del modal hay tabulaciones para el contenedor modal, un botón de reproducción de video, un botón de cancelación, un botón de compra y un botón de cierre. Una vez que se cierra el modal, el enfoque vuelve al botón que activó el modal.

¿Por qué es importante?

Mantener el enfoque dentro de un modal comunica sus límites y ayuda a informar qué es y qué no es contenido modal: es análogo a cómo una persona vidente puede ver cómo un modal “flota” sobre otro sitio web o contenido de aplicación web. Esta es información importante si:

  • Tiene poca o ninguna visión y confía en los anuncios del lector de pantalla para ayudar a comunicar el cambio en el modo de interacción.
  • Tiene baja visión y una pantalla ampliada, donde enfocarse fuera de los límites del modal puede ser confuso y desorientador.
  • Navega únicamente a través del teclado y, de lo contrario, podría salir del modal y perderse en la página subyacente o ver tratando de volver al modal.

¿Cómo lo haces?

La gestión fiable del enfoque es un asunto complicado. Necesita usar JavaScript para:

  1. Determine los elementos contenedores de todos los elementos enfocables en la página o vista actual.
  2. Identifique los límites del contenido interceptado, incluido el primer y el último elemento enfocable.
  3. Elimine tanto la interactividad como la capacidad de descubrimiento de cualquier cosa identificada como enfocable que no esté dentro de ese conjunto de contenido atrapado.
  4. Mueva el foco hacia el contenido atrapado.
  5. Escuche los eventos que indican el descarte del contenido atrapado (guardar, cancelar, descartar/presionar la tecla Esc, etc.).
  6. Descartar el área de contenido atrapada cuando se activa por un evento pertinente.
  7. Restaura la interactividad previamente eliminada.
  8. Vuelva a centrar el foco en el elemento interactivo que activó el contenido interceptado.

¿Por qué lo hacemos?

No voy a mentir: todo esto es complicado y requiere mucho tiempo. Sin embargo, la gestión del enfoque y un orden de enfoque sensato y utilizable es una pauta de accesibilidad al contenido web. Es lo suficientemente importante como para que se considere parte de un estándar internacional legalmente vinculante sobre usabilidad.

Tabulado y detectable

Hay un pequeño truco para eliminar tanto la capacidad de descubrimiento como la interactividad.

Los lectores de pantalla tienen un modo de interacción que les permite explorar la página o verla a través de un cursor virtual. El cursor virtual también permite que la persona que usa el lector de pantalla descubra partes no interactivas de la página (encabezados, listas, etc.). A diferencia de los estilos de tabulación y enfoque, el cursor virtual solo está disponible para las personas que usan un lector de pantalla.

Cuando administra el enfoque, es posible que desee restringir la capacidad del cursor virtual para descubrir contenido. Para nuestro ejemplo modal, esto significa evitar que alguien se “salte” accidentalmente de los límites del modal cuando lo esté leyendo.

La detectabilidad se puede suprimir a través de una aplicación juiciosa de aria-hidden="true". Sin embargo, la interactividad es un poco más matizada.

Ingresar inert

El inert El atributo es un atributo HTML global que facilitaría mucho la eliminación y luego la restauración de la capacidad de los elementos interactivos para ser descubiertos y enfocados. He aquí un ejemplo de cómo funcionaría:

<body>
  <div 
    aria-labelledby="modal-title"
    class="c-modal" 
    id="modal" 
    role="dialog" 
    tabindex="-1">
    <div role="document">
      <h2 id="modal-title">Save changes?</h2>
      <p>The changes you have made will be lost if you do not save them.<p>
      <button type="button">Save</button>
      <button type="button">Discard</button>
    </div>
  </div>
  <main inert>
    <!-- ... -->
  </main>
</body>

Estoy evitando deliberadamente usar el <dialog> elemento para el modal debido a sus muchos problemas de soporte de tecnología de asistencia.

inert ha sido declarado en el <main> elemento que sigue a un modal de confirmación de guardado. Lo que esto significa que todo el contenido contenido dentro <main> no puede recibir el foco ni se puede hacer clic.

El foco está restringido al interior del modal. Cuando se descarta el modal, inert se puede quitar de la <main> elemento. Esta forma de manejar la captura de foco es mucho más fácil en comparación con las técnicas existentes.

Recordar: Un evento de despido puede ser causado por los dos botones dentro de nuestro ejemplo modal, pero también presionando Esc en su teclado. Algunos modales también le permiten hacer clic fuera del área modal para descartar también.

Soporte para inertes

Las últimas versiones de Edge, Chrome y Opera son compatibles inert cuando las características de la plataforma web experimental están habilitadas. ¡La compatibilidad con Firefox también llegará pronto! El único caso atípico son las versiones de escritorio y móvil de Safari.

Me encantaría ver a Apple implementar soporte nativo para inert. Si bien hay un polyfill disponible, tiene problemas de soporte no triviales para todos los principales lectores de pantalla. ¡No es bueno!

Además, me gustaría llamar la atención sobre esta nota del inert LÉAME del proyecto polyfill:

El polyfill será costoso, en términos de rendimiento, en comparación con un nativo inert implementación, porque requiere una buena cantidad de caminatas por los árboles.

Tree-walking significa que JavaScript en el polyfill requerirá potencialmente mucha potencia computacional para funcionar y, por lo tanto, ralentizará la experiencia del usuario final.

Para los dispositivos de menor potencia, como los teléfonos inteligentes Android económicos, las computadoras portátiles más antiguas y los dispositivos más potentes que realizan tareas de computación intensiva (como ejecutar varias aplicaciones de Electron), esto podría significar que se congelan o fallan. El soporte nativo del navegador significa que este tipo de comportamiento es mucho menos exigente para el dispositivo, ya que tiene acceso a partes del navegador que JavaScript no tiene.

Safari

Personalmente, estoy decepcionado por la falta de soporte de Apple para inert. Si bien entiendo que agregar nuevas funciones a un navegador es un trabajo increíblemente complicado y difícil, inert parece una función que Apple habría admitido mucho antes.

Históricamente, macOS e iOS han tenido un gran soporte para la accesibilidad, y las características amigables con la tecnología de asistencia son una parte común de sus campañas de marketing. Secundario inert parece una extensión natural de la misión de Apple, ya que la característica en sí haría mucho para hacer que las experiencias web accesibles sean más fáciles de desarrollar.

Frustrantemente, Apple también tiene los labios apretados sobre en qué está trabajando y cuándo podemos esperar verlo en general. Por eso, el futuro de inert es una pregunta abierta.

igalia

Igalia es una empresa que trabaja sobre las funcionalidades del navegador. Actualmente tienen un experimento en el que el público puede votar qué características les gustaría ver. El razonamiento de esta iniciativa está fuera del alcance de este artículo, pero puedes leer más al respecto en Smashing Magazine.

Una característica que Igalia está considerando es agregar compatibilidad con WebKit para inert. Si ha estado buscando una manera de ayudar a mejorar la accesibilidad en la web, pero no está seguro de cómo empezar, le animo a que se comprometa. $5, $10, $25. No tiene que ser una gran cantidad, cada poquito suma.

Comprométase ahora

Desafortunadamente, inert no ganó el experimento de Priorización Abierta. Esto significa que volvemos a no saber si Apple está trabajando en ello o cuándo podemos esperar verlo aparecer en Safari Technology Preview.

Terminando

Manejar el enfoque requiere cierta habilidad y cuidado, pero vale mucho la pena hacerlo. El inert El atributo puede contribuir en gran medida a que esto sea más fácil de hacer.

Tecnologías como inert también representa una de las mayores fortalezas de la plataforma web: la capacidad de allanar los caminos del comportamiento emergente y codificarlo en algo fácil y efectivo.

Otras lecturas

  • Control de foco con tabindex (A11ycasts, Episodio 04)
  • Usando el atributo tabindex (The Paciello Group)
  • Uso de JavaScript para atrapar el foco en un elemento (Hidde de Vries)

Gracias a Adrian Roselli y Sarah Higley por sus comentarios.

(Visited 6 times, 1 visits today)