WCAG 2.5.5: Tamaño del objetivo (mejorado)

Qué Significa Esta Regla

WCAG 2.5.5 Target Size (Enhanced) es un criterio de Nivel AAA en WCAG 2.2 que establece un tamaño mínimo estricto para los elementos interactivos. Específicamente, requiere que el tamaño del objetivo, es decir, el área clicable o tocable de cualquier componente de la interfaz de usuario, sea de al menos 44 por 44 píxeles CSS tanto de ancho como de alto. Esto se aplica a todas las interacciones basadas en puntero, incluyendo clics de ratón, toques en pantallas táctiles y entrada con lápiz óptico.

Es importante entender qué constituye exactamente el "objetivo" en este contexto. El objetivo es toda el área activable del control, no solo su representación visual. Un ícono pequeño puede ser visualmente de 16×16 píxeles, pero si el relleno circundante expande la región clicable a 44×44 píxeles, el criterio aún puede cumplirse. Esto significa que las personas desarrolladoras pueden usar el relleno de forma estratégica para cumplir el requisito sin alterar drásticamente el diseño visual.

El criterio define un aprobado como cualquier elemento interactivo cuyo área objetivo mida al menos 44×44 píxeles CSS. Se produce un fallo cuando el área activable de un elemento interactivo está por debajo de este umbral en cualquiera de las dimensiones; por ejemplo, un enlace que tenga 44 píxeles de ancho pero solo 20 píxeles de alto seguiría fallando.

WCAG 2.5.5 proporciona varias excepciones oficiales en las que el requisito de 44×44 no se aplica. Estas son:

• Espaciado: Los objetivos de tamaño insuficiente son aceptables si un espaciado de separación suficiente los separa de todos los demás objetivos. El objetivo debe estar posicionado de tal manera que, si se centrara sobre él un círculo de 44×44 píxeles CSS, ese círculo no intersectaría ningún otro objetivo ni la caja delimitadora del círculo de 44×44 de ningún otro objetivo. Esta excepción evita que la regla exija cambios de diseño cuando los controles adyacentes son inherentemente pequeños pero están bien separados.
• Equivalente: Un control alternativo en la misma página realiza la misma función y cumple el requisito de tamaño mínimo.
• En línea: El objetivo está en una oración o su tamaño está restringido de otro modo por el interlineado del texto que no es objetivo. Los hipervínculos dentro de un párrafo de texto principal, por ejemplo, están exentos porque redimensionarlos interrumpiría el flujo del texto.
• Control del agente de usuario: El tamaño está determinado completamente por el navegador o el sistema operativo y no puede ser modificado por la persona autora. Los controles de formulario nativos del navegador en su estado sin estilos pueden entrar en esta categoría.
• Esencial: Una presentación particular del objetivo es esencial para la información que se transmite. Esta es una excepción limitada para casos en los que cambiar el tamaño del objetivo alteraría de forma fundamental el significado o la funcionalidad.

Este criterio se introdujo en WCAG 2.2 y sustituye la orientación anterior, menos estricta, sobre objetivos de puntero. Su criterio complementario, WCAG 2.5.8 Target Size (Minimum) en Nivel AA, establece un umbral más bajo de 24×24 píxeles CSS con un cálculo basado en el espaciado, pero 2.5.5 sigue siendo el estándar de referencia para una accesibilidad mejorada.

Por Qué Importa

Las discapacidades motoras y de destreza afectan a una parte sustancial de la población mundial. Según la Organización Mundial de la Salud, aproximadamente 1,3 mil millones de personas — o el 16% de la población mundial — viven con algún tipo de discapacidad significativa, siendo las afecciones motoras y musculoesqueléticas de las más prevalentes. Afecciones como la enfermedad de Parkinson, el temblor esencial, la parálisis cerebral, la esclerosis múltiple, la hemiplejía relacionada con accidentes cerebrovasculares y las lesiones por esfuerzo repetitivo reducen la capacidad de una persona para realizar movimientos precisos con el puntero. En dispositivos móviles, incluso las personas sin discapacidad pueden tener dificultades con objetivos pequeños cuando usan guantes, cuando tienen las manos mojadas o simplemente cuando usan el teléfono con una sola mano.

Considere un escenario concreto del mundo real: una persona con artritis reumatoide navega por una plataforma de comercio electrónico turca en una tableta táctil para comprar medicación. El flujo de pago incluye pequeños botones de opción, menús desplegables estrechos y un botón de "Confirmar pedido" de 24×18 píxeles. Cada toque erróneo selecciona la opción incorrecta o no hace nada, obligando a la persona usuaria a reintentar varias veces. La frustración no es simplemente una molestia: puede hacer que abandone la compra por completo, convirtiendo un fallo de accesibilidad en una pérdida directa de ingresos para la empresa.

Más allá de las discapacidades motoras, los objetivos de tamaño adecuado benefician a una amplia gama de personas usuarias. Las personas mayores suelen experimentar una reducción del control motor fino y una disminución de la agudeza visual de forma simultánea, lo que hace que los objetivos pequeños sean doblemente difíciles. Las personas con discapacidades cognitivas pueden tardar más en posicionar un puntero y tienen más probabilidades de activar controles adyacentes si los objetivos están abarrotados. Incluso las personas videntes y sin discapacidad física se benefician de objetivos más grandes en dispositivos móviles, una realidad que ha impulsado las convenciones de diseño en las principales empresas tecnológicas durante años. Las Human Interface Guidelines de Apple recomiendan un objetivo mínimo de toque de 44×44 puntos, y las directrices de Material Design de Google recomiendan al menos 48×48 píxeles independientes de la densidad por las mismas razones.

Desde la perspectiva del SEO y la usabilidad, la métrica "Interaction to Next Paint" (INP) de Core Web Vitals de Google recompensa las interfaces en las que las interacciones de las personas usuarias se registran de forma rápida y correcta. Los toques erróneos causados por objetivos de tamaño insuficiente inflan las tasas de fallo de interacción, aumentan el tiempo dedicado a la tarea e incrementan las tasas de rebote, todas señales que pueden afectar indirectamente a la clasificación en los resultados de búsqueda. Las mejoras de accesibilidad a nivel de puntero, por lo tanto, tienen consecuencias empresariales medibles más allá del cumplimiento normativo.

Reglas Relacionadas de Axe-core

WCAG 2.5.5 requiere pruebas manuales. No existe una regla de axe-core totalmente automatizada que señale de forma fiable todas las infracciones de tamaño de objetivo para este criterio mejorado. La razón por la que las herramientas automatizadas tienen dificultades aquí es multifacética: el tamaño efectivo del objetivo depende del diseño CSS calculado, incluyendo relleno, margen y dimensiones de pseudo-elementos que varían según el viewport, la relación de píxeles del dispositivo y el renderizado dinámico. Además, la excepción de espaciado requiere calcular el desplazamiento geométrico entre objetivos adyacentes, un cálculo que requiere el árbol de diseño renderizado completo y un análisis de proximidad que las herramientas automatizadas de análisis del DOM no pueden realizar con precisión en todos los casos. Asimismo, determinar si un elemento cumple los requisitos de la excepción "en línea" o "equivalente" requiere una comprensión semántica y contextual que está más allá de las capacidades de los motores de reglas automatizadas.

• target-size (axe-core experimental): Axe-core incluye una regla experimental llamada target-size que verifica los elementos interactivos frente al umbral de Nivel AA de WCAG 2.5.8 de 24×24 píxeles CSS con compensaciones de espaciado. Aunque esta regla puede sacar a la luz algunas infracciones menores, no aplica el umbral más estricto de 44×44 requerido por 2.5.5 y puede pasar por alto infracciones en las que el relleno o los pseudo-elementos afectan al área de impacto renderizada de formas que la instantánea del DOM no captura. Considere cualquier resultado de esta regla como un punto de partida, no como una auditoría completa.
• Inspección visual manual: Dado que ninguna regla automatizada cubre completamente 2.5.5, las personas evaluadoras deben inspeccionar y medir visualmente los objetivos interactivos utilizando las herramientas de desarrollo del navegador, reglas de píxeles CSS o extensiones de navegador de accesibilidad. Esto incluye comprobar que el relleno está incluido en el área de impacto y que las excepciones de espaciado se cumplen realmente, y no simplemente se asumen.

Cómo Probar

1. Ejecutar un análisis automatizado como línea base: Abra axe DevTools o Lighthouse en Chrome DevTools en la página que se va a probar. En axe DevTools, filtre los resultados por "target-size" si está disponible en las reglas experimentales. Tome nota de cualquier elemento señalado, pero entienda que este análisis no detectará todas las infracciones de 2.5.5 y puede hacer referencia al umbral 2.5.8 en lugar de a los 44×44 píxeles. Use la auditoría de accesibilidad de Lighthouse para buscar advertencias relacionadas con objetivos de puntero.
2. Medir los tamaños de los objetivos con las DevTools del navegador: Abra las DevTools de Chrome o Firefox y use el panel Elements para inspeccionar cada elemento interactivo: botones, enlaces, campos de formulario, casillas de verificación, botones de opción, controles personalizados y controles solo de ícono. En el panel de estilos Computed, verifique el ancho y el alto renderizados. Recuerde que el relleno se incluye en el objetivo de clic para los elementos de nivel de bloque, pero puede no incluirse para los elementos en línea. Verifique que el área de impacto calculada sea de al menos 44×44 píxeles CSS.
3. Usar las herramientas de accesibilidad integradas del navegador: En Chrome DevTools, abra la pestaña Rendering y habilite "Emulate a focused page" o use el Accessibility Tree para inspeccionar elementos. En Firefox, use el Accessibility Inspector para identificar elementos interactivos y cruzar sus dimensiones de caja delimitadora.
4. Probar en dispositivos táctiles reales: Conecte un dispositivo físico iOS y pruebe con VoiceOver activado (presione tres veces el botón lateral para activarlo). Navegue tocando y use el rotor para moverse entre elementos interactivos. Intente activar objetivos pequeños y observe con qué frecuencia se activan accidentalmente elementos adyacentes. Repita en un dispositivo Android usando TalkBack (deslice a la derecha para navegar, toque dos veces para activar). Preste especial atención a los widgets personalizados construidos a partir de elementos <div> o <span>.
5. Probar manualmente las excepciones de espaciado: Para cualquier objetivo más pequeño que 44×44 píxeles que invoque la excepción de espaciado, dibuje una caja delimitadora imaginaria de 44×44 píxeles centrada en ese objetivo y confirme visualmente que ningún otro elemento interactivo cae dentro de esa caja. Las extensiones de navegador o herramientas de superposición que dibujan cajas delimitadoras pueden ayudar en esta tarea.
6. Verificación con teclado y lector de pantalla: Pruebe con NVDA + Firefox y JAWS + Chrome desplazándose con la tecla Tab por todos los elementos interactivos. Aunque el enfoque mediante teclado no prueba directamente el tamaño del objetivo del puntero, ayuda a identificar si todos los controles son alcanzables y confirma el inventario de elementos con el que cruzará los tamaños de los objetivos de puntero. VoiceOver + Safari en macOS puede usarse para verificar que los controles personalizados se anuncian correctamente y tienen áreas de activación adecuadas cuando se hace clic con el puntero.
7. Probar en múltiples tamaños de viewport: Los tamaños de los objetivos pueden variar entre diseños de escritorio y móviles. Pruebe con anchos de viewport de 320px, 768px y 1280px para confirmar que los diseños responsivos mantienen el mínimo de 44×44 en todos los puntos de corte, particularmente en menús tipo hamburguesa, carruseles y columnas de acciones en tablas de datos.

Cómo Corregir

Botón solo de ícono con tamaño insuficiente — Incorrecto

<!-- A close button rendered as a small SVG icon with no padding.
     The rendered size is approximately 16x16 CSS pixels, far below the 44x44 minimum. -->
<button class='close-btn'>
  <svg width='16' height='16' aria-hidden='true'>
    <use href='#icon-close'></use>
  </svg>
  <span class='sr-only'>Close dialog</span>
</button>

<style>
.close-btn {
  background: none;
  border: none;
  padding: 0;
  cursor: pointer;
}
</style>

Botón solo de ícono con tamaño insuficiente — Correcto

<!-- Padding is added to expand the hit area to at least 44x44 CSS pixels
     while preserving the visual icon size. The button itself has explicit
     min-width and min-height to guarantee compliance across browsers. -->
<button class='close-btn'>
  <svg width='16' height='16' aria-hidden='true'>
    <use href='#icon-close'></use>
  </svg>
  <span class='sr-only'>Close dialog</span>
</button>

<style>
.close-btn {
  background: none;
  border: none;
  padding: 14px; /* 16px icon + 14px * 2 padding = 44px total hit area */
  min-width: 44px;
  min-height: 44px;
  cursor: pointer;
  display: inline-flex;
  align-items: center;
  justify-content: center;
}
</style>

Casilla de verificación personalizada construida a partir de un div — Incorrecto

<!-- A visually styled custom checkbox that is too small to meet the target size
     requirement. The div has no padding and renders at 20x20 pixels. -->
<div role='checkbox' aria-checked='false' tabindex='0' class='custom-check'></div>

<style>
.custom-check {
  width: 20px;
  height: 20px;
  border: 2px solid #333;
  border-radius: 3px;
  cursor: pointer;
}
</style>

Casilla de verificación personalizada construida a partir de un div — Correcto

<!-- The visual box remains 20x20 pixels but is wrapped in a label element
     whose total clickable area is expanded to 44x44 via padding.
     Using a native input element is strongly preferred over role=checkbox
     because it provides built-in keyboard and pointer behavior. -->
<label class='check-wrapper'>
  <input type='checkbox' class='sr-only'>
  <span class='custom-check' aria-hidden='true'></span>
  Subscribe to newsletter
</label>

<style>
.check-wrapper {
  display: inline-flex;
  align-items: center;
  gap: 8px;
  min-height: 44px; /* entire label row is at least 44px tall */
  cursor: pointer;
  padding: 12px 0; /* vertical padding expands the hit area */
}
.custom-check {
  width: 20px;
  height: 20px;
  border: 2px solid #333;
  border-radius: 3px;
  flex-shrink: 0;
}
.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0,0,0,0);
  white-space: nowrap;
  border: 0;
}
</style>

Enlaces de navegación en una barra de herramientas con espaciado abarrotado — Incorrecto

<!-- Toolbar links rendered as small inline elements.
     Each link is approximately 32px wide and 24px tall,
     and they are spaced only 4px apart — failing both size and spacing exceptions. -->
<nav aria-label='Secondary navigation'>
  <a href='/help' class='nav-link'>Help</a>
  <a href='/settings' class='nav-link'>Settings</a>
  <a href='/logout' class='nav-link'>Logout</a>
</nav>

<style>
.nav-link {
  font-size: 12px;
  padding: 2px 4px;
  margin: 0 2px;
}
</style>

Enlaces de navegación en una barra de herramientas con espaciado abarrotado — Correcto

<!-- Each link now has padding that expands its hit area to at least 44x44 px.
     The gap between links is also increased so the spacing exception would
     apply even if sizing were relaxed in future. -->
<nav aria-label='Secondary navigation'>
  <a href='/help' class='nav-link'>Help</a>
  <a href='/settings' class='nav-link'>Settings</a>
  <a href='/logout' class='nav-link'>Logout</a>
</nav>

<style>
.nav-link {
  font-size: 14px;
  display: inline-flex;
  align-items: center;
  min-height: 44px;
  padding: 0 16px; /* horizontal padding extends width well past 44px */
  margin: 0 4px;
  text-decoration: underline;
}
</style>

Errores Comunes

• Suponer que la caja delimitadora visual equivale al área de impacto: Establecer width: 44px; height: 44px en la imagen del ícono dentro de un botón no hace que el botón mida 44×44; solo añadir esas dimensiones o un relleno equivalente al propio elemento <button> crea el área de impacto correcta.
• Usar padding: 0 para restablecer los estilos del navegador sin un tamaño mínimo compensatorio: Los resets de CSS a menudo eliminan todo el relleno de los botones y campos de entrada. Después de un reset, vuelva a aplicar siempre un relleno suficiente o valores explícitos de min-width y min-height para restaurar el área de activación.
• Confiar solo en line-height para aumentar la altura del objetivo: Aumentar line-height afecta al espaciado del texto, pero no siempre expande el área clicable de un enlace o botón. Use padding-top y padding-bottom en su lugar.
• Colocar varios botones pequeños de ícono uno al lado del otro sin suficiente espaciado: Una fila de íconos de redes sociales para compartir de 24×24 con márgenes de solo 2px incumple tanto el requisito de tamaño como la excepción de espaciado, ya que los círculos de 44px centrados en cada ícono se superpondrían con sus vecinos.
• Aplicar incorrectamente la excepción de texto en línea a enlaces de navegación: La excepción se aplica a enlaces dentro de una oración o párrafo de texto fluido. Los menús de navegación, barras de herramientas y listas de enlaces no son texto en línea y no califican para esta excepción, incluso si usan display: inline.
• Construir controles personalizados con role='button' en un <span> y olvidar dimensionar el span: Los lectores de pantalla anunciarán el span como un botón, pero su tamaño renderizado por defecto estará determinado solo por su contenido de texto, que normalmente está muy por debajo de 44×44 píxeles. Añada siempre display: inline-flex, min-width, min-height y padding.
• No probar en dispositivos táctiles reales al tamaño de viewport real: Medir píxeles en las DevTools de escritorio no es suficiente. La densidad de píxeles CSS y el comportamiento de detección de objetivos táctiles a nivel del sistema operativo pueden diferir entre entornos simulados y dispositivos físicos.
• Pasar por alto controles renderizados dinámicamente: Los tooltips, las celdas de días en selectores de fecha, los elementos de sugerencias en autocompletar y los botones de cierre de modales suelen ser inyectados por bibliotecas de JavaScript con tamaños pequeños codificados. Audite la salida de los widgets de terceros y sobrescriba sus estilos si es necesario.
• Alegar la excepción de espaciado sin medirla: La excepción de espaciado es geométrica y precisa. Suponer visualmente que los controles parecen estar lo suficientemente separados no es suficiente: la prueba del círculo de 44px debe aplicarse a cada objetivo de tamaño insuficiente para confirmar que no existe superposición.
• Olvidar verificar después de cambios en los puntos de corte responsivos: Un botón que mide 44×44 en escritorio puede reducirse a 30×30 en un viewport móvil de 375px debido a anchos porcentuales o a la contracción de flexbox. Vuelva a probar siempre los tamaños de los objetivos en cada punto de corte importante.

Relación con las Normativas de Accesibilidad de Turquía

La Circular Presidencial n.º 2025/10 de Turquía, publicada en el Boletín Oficial n.º 32933 el 21 de junio de 2025, establece requisitos obligatorios de accesibilidad web y móvil basados en el estándar WCAG 2.2. La circular se aplica a un conjunto definido de entidades que operan en Turquía y establece obligaciones legales para la conformidad con niveles específicos de WCAG.

Los tipos de entidades cubiertas por la circular incluyen: instituciones y organismos públicos tanto a nivel de gobierno central como local; bancos e instituciones financieras regulados por la Banking Regulation and Supervision Agency (BDDK); hospitales y proveedores de servicios de salud, tanto públicos como privados; operadores de telecomunicaciones con 200,000 o más suscriptores; plataformas de comercio electrónico por encima de determinados umbrales de ingresos o transacciones; agencias de viajes que operan servicios de reserva en línea; empresas de transporte privado que ofrecen emisión de billetes o reservas digitales; y escuelas privadas e instituciones educativas autorizadas por el Ministry of National Education (MoNE).

WCAG 2.5.5 Target Size (Enhanced) es un criterio de Nivel AAA y no se encuentra entre los requisitos mínimos obligatorios establecidos por la circular, que se centra principalmente en el cumplimiento de los niveles A y AA. Sin embargo, la circular anima explícitamente a las entidades cubiertas —en particular a aquellas que prestan servicios al público, pacientes de salud y estudiantes— a buscar la conformidad AAA cuando sea viable, reconociendo que representa una práctica de accesibilidad de primer nivel.

Para las organizaciones en Turquía, implementar WCAG 2.5.5 tiene un valor estratégico particular en varios contextos. Los portales gubernamentales que atienden a personas mayores, los sistemas de programación de citas médicas utilizados por pacientes con enfermedades crónicas y las aplicaciones bancarias a las que acceden personas con discapacidades motoras se benefician sustancialmente de objetivos de 44×44 píxeles. Turquía tiene una población que envejece rápidamente, y el Turkish Statistical Institute (TÜİK) proyecta que las personas ciudadanas de 65 años o más constituirán más del 16% de la población para 2040, una franja demográfica para la cual el tamaño del objetivo del puntero es un factor crítico de usabilidad.

Aun cuando el Nivel AAA no sea un requisito legal, las organizaciones que cumplen voluntariamente con WCAG 2.5.5 demuestran un compromiso que puede reducir el riesgo de litigios, fortalecer la elegibilidad en procesos de contratación pública que requieren documentación de accesibilidad y mejorar las métricas de satisfacción de las personas usuarias en mercados competitivos como el comercio electrónico y las fintech. El SDK de Accsible proporciona funciones configurables de mejora de objetivos táctiles que pueden ayudar a las organizaciones a cumplir o acercarse a este criterio, y la documentación de dichos esfuerzos puede formar parte de un Accessibility Conformance Report (ACR) o de una presentación VPAT requerida por los procesos de contratación institucional.