Atributo Tabindex y su efecto en la accesibilidad

El atributo tabindex forma parte de HTML y permite modificar la forma en la que un elemento recibe el foco del teclado. Su uso puede mejorar la accesibilidad de una interfaz, pero también puede empeorarla si se utiliza para corregir problemas que deberían resolverse con una estructura HTML adecuada.
La navegación con teclado es una parte esencial de la accesibilidad web. Muchas personas no utilizan ratón, bien porque trabajan con lector de pantalla, porque emplean otros productos de apoyo o porque simplemente prefieren desplazarse por la interfaz mediante la tecla de tabulación y otros comandos del teclado. En esos casos el foco indica en qué elemento se encuentra la interacción en cada momento.
Los elementos de HTML ya forman parte del orden de tabulación por defecto. Un enlace con href, un botón, un campo de formulario o un control nativo pueden recibir el foco sin necesidad de añadir atributos adicionales. Esto es importante porque HTML ya incorpora mucho comportamiento accesible cuando se utiliza correctamente.
El problema aparece cuando se intenta forzar el comportamiento de una página mediante tabindex sin tener en cuenta las expectativas de las personas que navegan con teclado.

Qué hace tabindex

El atributo tabindex permite alterar el orden natural del foco. Puede hacer que un elemento no interactivo pueda recibir el foco, puede retirar un elemento interactivo del orden de tabulación y también puede reorganizar el orden en el que se recorren los elementos de la página.
Su valor es numérico. Cuando se utiliza tabindex=»-1″, el elemento puede recibir el foco mediante JavaScript, pero no queda incluido en la navegación secuencial con la tecla Tab. Cuando se utiliza tabindex=»0″, el elemento entra en el orden de tabulación respetando la posición que ocupa en el código HTML. Cuando se utiliza un valor positivo, como tabindex=»1″ o tabindex=»2″, se fuerza un orden de navegación distinto al orden natural del documento.
En la práctica, los valores positivos suelen ser una mala señal. Si el orden de foco no coincide con el orden visual o lógico de la página, lo correcto normalmente no es añadir números para reconstruir artificialmente la navegación. Lo adecuado es revisar la estructura del HTML y utilizar CSS para ajustar la presentación visual cuando sea necesario.

<a href="/inicio">Inicio</a>
<div tabindex="0">Contenido desplazable</div>
<a href="/contacto">Contacto</a>

En este ejemplo, el div entra en el orden de tabulación en el lugar que ocupa dentro del documento. Esto puede ser correcto si ese contenedor tiene algún comportamiento interactivo real. Pero si se trata solo de un bloque de texto, añadirlo al foco puede introducir ruido innecesario en la navegación.

El foco no debe sustituir a la semántica

Una regla sencilla para evaluar el uso de tabindex consiste en preguntarse si el elemento debería ser interactivo. Si se necesita un botón, se debe utilizar un elemento button. Si se necesita un enlace, se debe utilizar un enlace. Si se necesita un campo de formulario, se debe utilizar el control correspondiente.

Crear un botón con un div y añadirle tabindex=»0″ no convierte ese elemento en un botón completo. Puede recibir el foco, pero no incorpora automáticamente el comportamiento esperado con teclado, la semántica adecuada ni la comunicación correcta con los productos de apoyo. En muchos casos, ese tipo de solución obliga a reproducir manualmente características que HTML ya ofrece de forma nativa.

La accesibilidad no consiste solo en que algo pueda recibir el foco. También importa qué anuncia el lector de pantalla, qué teclas activan el componente, cómo se informa del estado, cómo se integra en el flujo del documento y si la interacción coincide con lo que la persona usuaria espera.

Cuándo puede ser útil tabindex=”-1”

El valor -1 resulta útil cuando un elemento no debe aparecer en la navegación normal con Tab, pero necesita recibir el foco en una situación concreta. Un caso habitual es un mensaje de error después de enviar un formulario.

Si una persona envía un formulario y existen errores, mover el foco al resumen de errores puede ayudar a comprender qué ha ocurrido. Para una persona que navega con teclado, evita tener que volver a recorrer toda la página hasta localizar el problema. Para una persona que utiliza lector de pantalla, permite que el mensaje sea anunciado en el momento adecuado.

<div id="errores" tabindex="-1">
Hay errores en el formulario. Revisa los campos indicados.
</div>

Después, mediante JavaScript, se puede enviar el foco a ese elemento cuando se detecten errores.

document.getElementById('errores').focus();

Este patrón también puede ser útil en ventanas modales, paneles que se abren dinámicamente o zonas de la interfaz que aparecen como consecuencia de una acción de la persona usuaria. El objetivo no es añadir más paradas al teclado, sino colocar el foco en un punto lógico cuando cambia el contexto de interacción.

Cuándo puede ser útil tabindex=“0”

El valor 0 debe utilizarse con más cuidado. Su función es incorporar un elemento al orden natural de tabulación. Esto puede tener sentido cuando existe una zona que debe poder recibir interacción con teclado, pero que por defecto no forma parte del orden de foco.

Un ejemplo frecuente son los contenedores con desplazamiento interno creados con CSS mediante overflow.

Si un bloque tiene contenido desplazable y una persona solo utiliza el teclado, necesita poder situar el foco en esa región para desplazarse por ella. En ese caso, tabindex=»0″ puede hacer que el contenedor sea alcanzable saltando con la tecla de tabulador.

<section aria-labelledby="condiciones" tabindex="0" style="overflow: auto; max-height: 12rem;">
<h2 id="condiciones">Condiciones de uso</h2>
<p>Texto de las condiciones de uso...</p>
</section>

En este tipo de componentes no es suficiente con hacer que el contenedor reciba el foco. También conviene proporcionar una etiqueta accesible y una estructura semántica clara. Una persona que usa lector de pantalla debe poder entender qué contiene esa región y por qué ha llegado hasta ella.

Los valores positivos rompen expectativas

Los valores positivos de tabindex permiten definir un orden de tabulación independiente del orden del documento.

Esta práctica debe realizarse con mucho cuidado ya que es muy sencillo romper el orden coherente y comprensible del orden de tabulación.

Cuando el foco salta de una parte a otra de la página en un orden inesperado, la interfaz se vuelve más difícil de comprender. La persona que navega con teclado puede perder la relación entre la posición visual, la estructura del contenido y el punto real de interacción. Para quien utiliza lector de pantalla, esa separación entre orden del código, orden visual y orden de foco puede resultar especialmente confusa.

<div tabindex="3">Tercer elemento</div>
<div tabindex="1">Primer elemento</div>
<div tabindex="2">Segundo elemento</div>

Este código fuerza una secuencia que no coincide con el orden del documento. Si el diseño necesita mostrar visualmente los elementos de otra manera, CSS debería encargarse de la presentación. El HTML debe conservar un orden lógico, comprensible y coherente.

Componentes personalizados

Existen componentes interactivos que no tienen una equivalencia directa en HTML nativo. Un sistema de pestañas, determinados widgets complejos o algunos controles de aplicación pueden requerir una gestión específica del foco.

En estos casos, tabindex puede formar parte de la solución, pero no debe utilizarse de forma aislada. Un patrón de pestañas accesible, por ejemplo, puede necesitar que la pestaña activa tenga tabindex=»0″ y que las pestañas inactivas tengan tabindex=»-1″ para permitir una navegación controlada con flechas y una gestión correcta del foco.

Revisar el uso de tabindex

Una revisión de accesibilidad debería incluir la búsqueda de usos de tabindex en el código. Cada aparición merece una comprobación concreta. Si un elemento nativo interactivo tiene tabindex=»0″, probablemente no lo necesita. Si un elemento no interactivo tiene tabindex=»0″, conviene revisar si realmente debe recibir el foco. Si aparece un valor positivo, normalmente debería corregirse el orden del documento en lugar de mantener ese valor.

También es importante revisar los casos con tabindex=»-1″. No son necesariamente incorrectos, pero deben estar asociados a una gestión del foco clara. Si ningún script envía el foco a ese elemento, puede que el atributo no esté cumpliendo ninguna función.

Las herramientas automáticas pueden localizar estos casos, pero la decisión final requiere criterio humano. Una herramienta puede indicar que existe un tabindex, pero no siempre puede determinar si su uso responde a una necesidad real de interacción.

Una herramienta que debe usarse con criterio

tabindex no es un atributo prohibido. Es una herramienta potente para gestionar el foco en situaciones concretas. Pero precisamente por afectar directamente a la navegación con teclado, debe utilizarse con prudencia.

En una página bien estructurada, la mayor parte del orden de tabulación debería venir dado por el propio HTML. Los enlaces, botones y campos de formulario ya tienen comportamiento accesible cuando se usan correctamente. Añadir tabindex sin una razón clara puede introducir barreras donde antes no las había.

The Color Contrast Checker

El proyecto The Color Contrast Checker es una herramienta web orientada a revisar el contraste entre colores y facilitar el cumplimiento de las pautas de accesibilidad relacionadas con la legibilidad visual. Su objetivo principal es permitir que diseñadores, desarrolladores y responsables de contenido comprueben si una combinación de color de texto y fondo alcanza los niveles exigidos por WCAG para los criterios AA y AAA.

La propia herramienta se presenta como un comprobador gratuito de contraste WCAG con sugerencias para encontrar combinaciones de color accesibles.

El contraste de color es uno de esos aspectos de la accesibilidad que puede parecer sencillo hasta que se analiza con cierta atención. No es suficiente con que dos colores parezcan diferentes en una pantalla concreta, con un brillo concreto y en unas condiciones de iluminación concretas. Una combinación que para una persona resulta aceptable puede ser insuficiente para otra con baja visión, daltonismo, fatiga visual o simplemente utilizando el dispositivo en un entorno poco favorable.

La accesibilidad visual no depende únicamente del tamaño de la letra ni de la calidad tipográfica. También depende de la relación entre el color del primer plano y el color del fondo. Cuando esa relación de contraste de color es baja, el contenido puede seguir estando técnicamente presente, pero deja de ser cómodo, eficiente o incluso posible de leer para gran parte de los usuarios. En esa situación el problema deja de ser estético para convertirse en un problema funcional.

Herramientas como The Color Contrast Checker ayudan a convertir una percepción subjetiva en un dato verificable. El diseñador puede introducir los colores, comprobar la relación de contraste y conocer si la combinación cumple o no los umbrales establecidos. Esta verificación resulta especialmente útil porque evita depender únicamente de la intuición, de la vista del diseñador o de la apariencia en una única pantalla.

WCAG utiliza ratios de contraste para determinar si un texto resulta suficientemente distinguible respecto a su fondo. En el modelo tradicional de WCAG 2, la escala va de 1:1, cuando no hay contraste, hasta 21:1, que corresponde al contraste máximo entre negro y blanco. Otras herramientas actuales también incorporan APCA, un modelo perceptual propuesto en el contexto de WCAG 3, que expresa el contraste mediante valores de luminancia percibida en lugar de utilizar el ratio clásico.

La revisión del contraste no debería considerarse una fase final del proyecto. Debería formar parte del diseño desde el principio. Si una paleta no permite combinaciones suficientes para texto normal, texto grande, componentes interactivos y estados de interfaz, el problema no está en la herramienta que lo detecta. El problema está en la definición de la propia paleta.

También conviene recordar que una buena puntuación de contraste no resuelve por sí sola toda la accesibilidad visual. Un texto puede tener contraste suficiente y seguir siendo difícil de leer por usar un tamaño demasiado pequeño, una fuente poco clara, demasiado espaciado negativo, bloques extensos sin estructura o información transmitida solamente mediante color.

365 Days iOS Accessibility

El proyecto 365 Days iOS Accessibility es una iniciativa orientada a compartir conocimiento práctico sobre accesibilidad en aplicaciones iOS. El proyecto consiste en publicar, durante un año, pequeñas piezas de contenido relacionadas con técnicas, recomendaciones y detalles que pueden ayudar a crear aplicaciones más accesibles.

La accesibilidad en iOS suele asociarse de forma inmediata con VoiceOver, pero el proyecto muestra que el campo es mucho más amplio. En sus publicaciones aparecen temas relacionados con SwiftUI, UIKit, visionOS, accesibilidad en Apple Watch, atajos de teclado, Voice Control, Full Keyboard Access, orientación de pantalla, texto alternativo, prioridades de orden de lectura o adaptación de interfaces a tamaños grandes de texto.

Este enfoque resulta especialmente interesante porque reduce la distancia entre la teoría y la práctica. Muchas veces la accesibilidad se presenta como una obligación general, como una fase de revisión o como una lista de comprobaciones al final del desarrollo. Sin embargo, en el trabajo diario de una aplicación móvil, las barreras suelen aparecer en decisiones pequeñas como un botón sin etiqueta clara, un orden de navegación incorrecto, un gesto sin alternativa, una pantalla que no soporta orientación horizontal, un texto que no crece correctamente o una imagen compartida sin descripción.

El valor de este proyecto está precisamente en señalar esos detalles. No sólo explica que una aplicación debe ser accesible, sino de mostrar cómo se puede mejorar una parte concreta de la interfaz, una interacción concreta o un componente concreto. En una publicación se recuerda, por ejemplo, la importancia de permitir que las imágenes compartidas por los usuarios incluyan texto alternativo para que pueda utilizarse como etiqueta de accesibilidad. En otra se habla de la necesidad de soportar ambas orientaciones cuando sea posible y de evitar obligar al usuario a girar el dispositivo.

Otro aspecto importante es la relación entre distintas herramientas de apoyo. Una aplicación con buen soporte para VoiceOver suele tener una base más sólida para otras formas de interacción, pero eso no significa que todo quede resuelto automáticamente. El proyecto recuerda, por ejemplo, que en Apple Watch puede ser útil implementar acciones rápidas para AssistiveTouch cuando existe una acción principal clara. Este tipo de observaciones ayudan a entender que la accesibilidad no depende de una única tecnología, sino de la capacidad de la interfaz para ofrecer caminos alternativos para la persona usuaria.

GAAD 2026

El próximo 21 de mayo de 2026 se celebrará una nueva edición del Global Accessibility Awareness Day, más conocido como GAAD. Será la decimoquinta edición de una jornada internacional dedicada a hablar, pensar y aprender sobre accesibilidad digital e inclusión. Su objetivo es conseguir que la tecnología digital pueda ser utilizada por todas las personas, incluidas las personas con discapacidad.

La accesibilidad digital afecta a páginas web, aplicaciones móviles, software, documentos, plataformas educativas, servicios públicos, comercio electrónico y cualquier entorno en el que una persona necesite interactuar con tecnología. No es un asunto reservado a especialistas. También involucra a quienes diseñan, desarrollan, prueban, compran, financian, legislan o toman decisiones sobre productos digitales.

El GAAD nació precisamente para reducir esa distancia entre la intención y la práctica. Muchas personas están de acuerdo con la idea de hacer tecnología más accesible, pero no siempre saben por dónde empezar. La propia web del GAAD recuerda que el conocimiento sobre accesibilidad web es un primer paso necesario para que los equipos técnicos puedan revisar, corregir y mejorar sus productos.

Una jornada con muchos eventos

Aunque el día oficial será el 21 de mayo, durante estas semanas se están anunciando diversos eventos, webinars y talleres relacionados con la accesibilidad digital. La página oficial del GAAD mantiene una sección de eventos donde se recogen actividades en distintos países y formatos.

Entre las citas previstas está la Primera Jornada de Accesibilidad Digital de la Universitat de Lleida, que se celebrará el 28 de mayo de 2026 en formato online, con inscripción gratuita y sesiones sobre personas, diseño, desarrollo web, documentos, evaluación e inteligencia artificial.

También se ha anunciado el evento Global Accessibility Awareness Day with Deque, previsto para el 21 de mayo, con actividades virtuales gratuitas orientadas a la sensibilización y al aprendizaje sobre accesibilidad digital.

Otra propuesta internacional es la jornada de Disability:IN para el GAAD, centrada en cómo las organizaciones están incorporando la accesibilidad en el desarrollo de productos, la experiencia de cliente, la tecnología y la innovación. El evento contempla sesiones para distintas regiones, incluyendo EMEA, APAC, LATAM y NORAM.

En el ámbito universitario también se celebrará el UC Global Accessibility Awareness Day 2026 Webinar, bajo el lema From Policy to Practice, con contenidos sobre implementación de políticas de accesibilidad, inteligencia artificial, problemas habituales en PDF y audiodescripción.

Estas actividades muestran que el GAAD ya no es solo una fecha simbólica. Es una oportunidad para compartir experiencias, contrastar criterios, revisar procesos y acercar la accesibilidad a personas que quizá no trabajan directamente en este ámbito, pero cuyas decisiones influyen en la vida diaria de muchas personas.

Plexus Tech y la accesibilidad digital real

Este año participaré como moderador en una mesa dentro del evento de Plexus Tech dedicado al GAAD. Plexus ya celebró en 2025 un encuentro en streaming bajo el lema de seguir trabajando por una accesibilidad digital real, con profesionales de distintos sectores, expertos en normativa, diseño UX/UI y accesibilidad digital.

En la edición de 2025 se abordaron cuestiones como la evolución normativa, la aplicación de estándares, el papel de las administraciones y la necesidad de introducir la accesibilidad desde la base de los proyectos. También se compartieron casos reales de organizaciones como Renfe, Santander, Govern de les Illes Balears y B100.

Ese enfoque resulta especialmente importante. La accesibilidad no puede aparecer al final de un proyecto como una fase de revisión o como una corrección de emergencia. Cuando llega tarde, suele llegar peor. Obliga a rehacer interfaces, reescribir contenidos, corregir componentes, revisar documentos y justificar decisiones que podrían haberse tomado correctamente desde el principio.

Hablar de accesibilidad digital real implica asumir que el cumplimiento normativo es necesario, pero no suficiente. Una interfaz puede superar determinadas comprobaciones automáticas y seguir siendo incómoda, confusa o poco usable. También puede cumplir formalmente con un criterio técnico y, aun así, no ofrecer una experiencia razonable a una persona que navega con lector de pantalla, que usa teclado, que necesita más tiempo para completar una tarea o que requiere contenidos más claros.

Accesibilidad como práctica continua

El GAAD sirve para recordar que la accesibilidad no es una campaña anual. Es una práctica continua. Cada nueva funcionalidad, cada actualización de una aplicación, cada cambio de diseño y cada documento publicado puede abrir o cerrar una puerta.

En los últimos años se ha hablado mucho de inteligencia artificial, automatización y nuevas interfaces. Estas tecnologías pueden ayudar a reducir barreras, pero también pueden crear otras nuevas si no se diseñan con criterios inclusivos. Por eso es importante que los eventos del GAAD no se limiten a explicar qué es la accesibilidad, sino que entren en cómo se aplica, cómo se evalúa, cómo se mantiene y cómo se integra en los equipos.

La accesibilidad digital no pertenece únicamente al departamento de desarrollo. Empieza en la definición del producto, continúa en el diseño, se concreta en el código, se valida en las pruebas, se comunica en los contenidos y se mantiene durante toda la vida del servicio.

El 21 de mayo es una buena excusa para revisar lo que hacemos. Pero la accesibilidad no debería depender de una fecha concreta. El valor del GAAD está en recordarnos que cada barrera digital tiene consecuencias reales y que cada mejora también las tiene.

Permiso de pegar desde otras apps en iOS

En Apple gran parte de la seguridad de sus sistemas operativos se gestiona mediante permisos. Desde iOS 16.1 existe un permiso que permite controlar al usuario que una app pueda acceder al portapapeles sin control alguno. Esto permite saber si una app está accediendo o modificando el contenido del portapapeles sin que el usuario lo sepa.

Esta configuración se puede personalizar, desde iOS 26, para cada aplicación y evitar que una app en concreto moleste al usuario preguntando si puede acceder al portapapeles. Por ejemplo, podemos evitar esa consulta cuando queramos importar un texto como libro en la app Vox libri.

Para ello debemos ir a los ajustes del iPHone, ir al apartado Apps, buscar la app Vox libri en la lista y buscar un botón llamado Pegar desde otras apps, al tocarlo se abrirá un selector y si elegimos la opción permitir ya no aparecerá la pregunta para acceder al contenido del portapapeles sólo para la app de Vox libri.

AraWrite, una herramienta de ayuda a la discapacidad cognitiva

AraWrite es una aplicación de libre distribución presentada en Aragón como herramienta de accesibilidad cognitiva vinculada a ARASAAC. Su función principal consiste en adaptar textos a pictogramas de forma semiautomática, apoyándose en inteligencia artificial y en el ecosistema gráfico de ARASAAC.

Además de traducir texto a pictogramas, esta operación se realiza de forma automática simplificando el proceso para las personas que no se han especializado en la discapacidad cognitiva.

Los beneficios de AraWrite impactan en personas con discapacidad intelectual, con trastornos del lenguaje, con autismo, con dificultades de comprensión lectora, con necesidades de apoyo en contextos educativos o comunitarios. En muchos casos, las soluciones de accesibilidad para los perfiles de discapacidad cognitiva eran insuficientes debido a la falta de profesionales de la accesibilidad especializados en este perfil de discapacidad.