Modifica el orden del DOM con tabindex

Dave Gash
Dave Gash
Meggin Kearney
Meggin Kearney
Alexandra Klepper
Alexandra Klepper

El orden de tabulación predeterminado que proporciona la posición del DOM de los elementos HTML semánticos es conveniente, pero es posible que, en ocasiones, debas modificar el orden de tabulación. Mover elementos en el HTML es ideal, pero puede que no sea factible. En estos casos, puedes usar el atributo HTML tabindex para establecer de forma explícita la posición de pestaña de un elemento.

Navegadores compatibles

  • 1
  • 12
  • 1.5
  • ≤4

Origen

tabindex se puede aplicar a cualquier elemento, aunque no es necesariamente útil para todos los elementos, y toma un rango de valores enteros. Con tabindex, puedes especificar un orden explícito para los elementos de página enfocables, insertar un elemento que de otra manera no podría enfocarse en el orden de tabulación y quitar elementos de ese orden. Por ejemplo:

tabindex="0": Inserta un elemento en el orden natural de pestañas. Para enfocar el elemento, presiona Tab, y el elemento se puede enfocar llamando al método focus().

tabindex="-1": Quita un elemento del orden natural de pestañas, pero el elemento aún puede enfocarse llamando a su método focus().

tabindex="5": Cualquier tabindex superior a 0 coloca ese elemento al principio del orden natural de pestañas. Si hay varios elementos con un índice de tabulación mayor que 0, el orden de tabulación comienza desde el valor más bajo que sea superior a cero y asciende. El uso de un tabindex superior a 0 se considera un antipatrón.

En especial, se aplica a elementos que no son de entrada, como encabezados, imágenes o títulos de artículos. Cuando sea posible, es mejor organizar el código fuente para que la secuencia del DOM proporcione un orden de tabulación lógico. Si usas tabindex, restríngelo a controles interactivos personalizados, como botones, pestañas, menús desplegables y campos de texto, es decir, elementos a los que el usuario podría esperar proporcionar entradas.

Solo agrega tabindex al contenido interactivo. Incluso si el contenido es importante, como una imagen clave, los usuarios de lectores de pantalla pueden entenderlo sin agregarle enfoque.

Administrar el enfoque a nivel de la página

A veces, tabindex es necesario para brindar una experiencia del usuario fluida. Por ejemplo, si creas una sola página sólida con diferentes secciones de contenido, en la que no todo el contenido es visible de forma simultánea. Esto podría significar que los vínculos de navegación cambien el contenido visible sin que se actualice la página.

En este caso, identifica el área de contenido seleccionada, asígnale un elemento tabindex de -1 y llama a su método focus. Esto garantiza que el contenido no aparezca en el orden natural de pestañas. Esta técnica, llamada administración de foco, mantiene el contexto percibido del usuario en sincronización con el contenido visual del sitio.

Cómo administrar el enfoque en los componentes

En algunos casos, también debes administrar el enfoque a nivel de control, por ejemplo, con los componentes personalizados.

Por ejemplo, el elemento select puede recibir un enfoque básico, pero una vez allí, puedes usar las teclas de flecha para exponer opciones adicionales que se pueden seleccionar. Si compilas un elemento select personalizado, es importante replicar ese comportamiento para que los usuarios del teclado aún puedan interactuar con tu control.

Saber qué comportamientos del teclado implementar puede ser difícil. En la guía Prácticas de creación de aplicaciones de Internet enriquecidas accesibles (ARIA), se enumeran los tipos de componentes y las acciones de teclado que admiten.

Tal vez estás trabajando en elementos personalizados, que se asemejan a un conjunto de botones de selección, pero con tu apariencia y comportamiento únicos.

<radio-group>
    <radio-button>Water</radio-button>
    <radio-button>Coffee</radio-button>
    <radio-button>Tea</radio-button>
    <radio-button>Cola</radio-button>
    <radio-button>Ginger Ale</radio-button>
</radio-group>

Para determinar qué compatibilidad con el teclado se necesita, consulta la guía de prácticas de creación de ARIA. La sección 2 contiene una lista de patrones de diseño, incluida la tabla de características para grupos de botones de selección, el componente existente que más coincide con tu elemento nuevo.

Uno de los comportamientos comunes del teclado que debería admitirse son las teclas de flecha hacia arriba, abajo, izquierda y derecha. Para agregar este comportamiento al componente nuevo, usamos una técnica llamada tabindex itinerante.

El tabindex itinerante funciona configurando tabindex en -1 para todos los elementos secundarios, excepto el que está activo en ese momento.

<radio-group>
  <radio-button tabindex="0">Water</radio-button>
  <radio-button tabindex="-1">Coffee</radio-button>
  <radio-button tabindex="-1">Tea</radio-button>
  <radio-button tabindex="-1">Cola</radio-button>
  <radio-button tabindex="-1">Ginger Ale</radio-button>
</radio-group>

El componente usa un objeto de escucha de eventos del teclado para determinar qué tecla presiona el usuario. Cuando esto sucede, establece el tabindex del elemento secundario enfocado anteriormente en -1, establece el tabindex del elemento secundario que se debe enfocar en 0 y llama al método de enfoque en él.

<radio-group>
    <!-- Assuming the user pressed the down arrow, we'll focus the next available child -->
    <radio-button tabindex="-1">Water</radio-button>
    <radio-button tabindex="0">Coffee</radio-button> // call .focus() on this element
    <radio-button tabindex="-1">Tea</radio-button>
    <radio-button tabindex="-1">Cola</radio-button>
    <radio-button tabindex="-1">Ginger Ale</radio-button>
</radio-group>

Cuando el usuario llega al último elemento secundario (o al primero, según la dirección en la que mueva el foco), el enfoque se repite indefinidamente hasta el primer elemento secundario (o el último).

Prueba el siguiente ejemplo. Inspecciona el elemento en Herramientas para desarrolladores para observar cómo el tabindex se mueve de un botón de selección al siguiente.

Trampas de teclado y modales

Es mejor evitar administrar el enfoque de forma manual, ya que puede conducir a situaciones complicadas. Por ejemplo, un widget de Autocomplete que intenta administrar el enfoque y captura el comportamiento de la pestaña, pero evita que el usuario lo abandone hasta que se complete. Esto se denomina trampa de teclado y puede ser muy frustrante para el usuario.

La sección 2.1.2 de las WCAG establece que el foco del teclado nunca debe bloquearse ni capturarse en un elemento de página en particular. El usuario debe poder navegar hacia todos los elementos de página y desde todos ellos con solo usar el teclado.

La excepción a esta regla son los modales. Sin embargo, debes evitar el uso de tabindex cuando crees una ventana modal. Con inert, puedes asegurarte de que los usuarios no puedan interactuar accidentalmente con un elemento (una trampa de teclado intencional). Usa el elemento <dialog>, que está inerte de forma predeterminada, para crear una ventana modal para los usuarios y, a la vez, bloquear los clics y las pestañas fuera de la ventana modal. Esto permite que el usuario se enfoque en una selección necesaria.