Criterios de éxito de las WCAG · Level A
WCAG 2.4.4: Propósito del enlace (en contexto)
WCAG 2.4.4 requiere que el propósito de cada enlace pueda determinarse solo a partir del texto del enlace, o a partir del texto del enlace junto con su contexto circundante. Esto garantiza que las personas usuarias de lectores de pantalla, las personas que solo usan el teclado y las personas con discapacidades cognitivas puedan entender adónde lleva un enlace sin necesidad de seguirlo.
Qué significa esta regla
WCAG 2.4.4 — Propósito del enlace (en contexto) — es un criterio de éxito de Nivel A bajo el principio de Operable. Establece que el propósito de cada enlace debe poder determinarse a partir del texto del enlace por sí solo, o del texto del enlace combinado con su contexto del enlace determinado de forma programática. Si ninguno de los dos es suficiente, el enlace no cumple este criterio.
La expresión "contexto del enlace determinado de forma programática" está definida cuidadosamente por WCAG. Se refiere a la información que puede derivarse de la misma oración, párrafo, elemento de lista o celda de tabla que el enlace, o del encabezado que precede a una sección que contiene el enlace. También incluye el contexto expuesto mediante relaciones ARIA como aria-labelledby o aria-describedby. De forma crítica, este contexto debe estar disponible de forma programática — lo que significa que las tecnologías de asistencia pueden leerlo automáticamente — y no simplemente estar implícito visualmente para las personas videntes.
En términos prácticos, los siguientes elementos y atributos HTML se ven directamente afectados por este criterio: elementos de anclaje <a href>, elementos <area> en mapas de imagen, elementos <button> que desencadenan navegación, elementos con estilos o scripts para comportarse como enlaces usando roles ARIA como role='link', y elementos SVG <a>. El nombre accesible del enlace — calculado a partir de su texto interno, aria-label, aria-labelledby o un atributo alt en una imagen hija — es el vehículo principal para comunicar su propósito.
Qué se considera un cumplimiento: Un enlace cumple si una persona usuaria puede determinar su destino o función sin contexto adicional (por ejemplo, "Descargar el Informe Anual 2024 en PDF"), o si el contexto programático circundante hace que el propósito sea claro (por ejemplo, un enlace "Leer más" dentro de un <li> que comienza con el título del artículo). El texto del enlace no necesita ser globalmente único en toda la página; solo necesita ser inequívoco dentro de su contexto.
Qué se considera un incumplimiento: Textos de enlace genéricos como "haz clic aquí", "leer más", "aquí", "más" o "enlace" no cumplen cuando el contexto programático circundante no desambigua el destino. Un enlace de imagen con un atributo alt ausente o vacío también incumple porque el nombre accesible está completamente ausente.
Excepción oficial: WCAG reconoce una excepción. Cuando el propósito del enlace es intencionalmente ambiguo — es decir, cuando hacer que el propósito se conozca de antemano destruiría su utilidad o la del contenido circundante — el criterio no se aplica. Esta excepción es extremadamente limitada y rara vez aplicable en escenarios del mundo real.
Por qué es importante
Aproximadamente 2,2 mil millones de personas en todo el mundo tienen algún tipo de discapacidad visual, según la Organización Mundial de la Salud. Entre ellas, las personas ciegas que dependen de lectores de pantalla son las más afectadas por textos de enlace ambiguos. El software de lector de pantalla como NVDA, JAWS y VoiceOver permite navegar por una página generando una lista de todos los enlaces extraídos de su contexto. Cuando esa lista contiene decenas de entradas que todas dicen "leer más" o "haz clic aquí", las personas ciegas no pueden determinar a dónde lleva cada enlace sin volver a cada uno y leer el contenido circundante, un proceso que consume tiempo y resulta desorientador.
Las personas con discapacidad motora que navegan usando solo el teclado, controles por interruptor o dispositivos de seguimiento ocular también se benefician sustancialmente. Estas personas a menudo avanzan con la tecla Tab a través de los elementos interactivos de forma secuencial y dependen de la etiqueta del elemento enfocado para decidir si lo activan. El texto de enlace ambiguo obliga a realizar pasos de navegación adicionales que aumentan la fatiga y las tasas de error.
Las personas con discapacidades cognitivas — incluidas aquellas con trastornos de atención, problemas de memoria o baja alfabetización — se benefician de textos de enlace claros y descriptivos porque reducen la carga cognitiva necesaria para comprender la estructura de una página. No necesitan mantener la información contextual en la memoria de trabajo mientras examinan los enlaces.
Un escenario concreto del mundo real: Considere una página de listado de productos de comercio electrónico que muestra diez productos, cada uno con un botón "Comprar ahora" y un enlace "Más información" representados de forma idéntica. Una persona ciega que navega por la lista de enlaces escucha diez instancias consecutivas de "Más información" sin indicación de a qué producto se refiere cada enlace. Para comprar el producto correcto, debe leer todo el contexto circundante de cada enlace, un proceso que puede llevar minutos en lugar de segundos. Con un texto de enlace descriptivo como "Más información sobre los auriculares Sony WH-1000XM5", la misma tarea requiere un solo gesto de navegación.
Más allá de la accesibilidad, el texto de enlace descriptivo proporciona beneficios de SEO medibles. Los rastreadores de motores de búsqueda usan el texto de anclaje como una señal para entender el contenido de la página enlazada. El texto de enlace descriptivo y rico en palabras clave mejora la capacidad de rastreo e indexación de los recursos enlazados, contribuyendo positivamente a las clasificaciones de búsqueda. Además, el texto de enlace claro reduce las tasas de rebote y las solicitudes de soporte al establecer expectativas precisas de la persona usuaria antes de que se produzca la navegación.
Reglas relacionadas de Axe-core
- link-name: Esta regla comprueba que cada elemento
<a>con un atributohref, cada elemento conrole='link'y cada elemento<area>tenga un nombre accesible no vacío. El nombre accesible se calcula mediante el cálculo estándar de nombre accesible ARIA: contenido de texto interno,aria-label,aria-labelledbyo el atributoaltde una<img>hija. Axe marca una infracción cuando el nombre accesible calculado está vacío, contiene solo espacios en blanco o está completamente ausente. Esta regla detecta la forma más grave de incumplimiento de 2.4.4 — enlaces completamente sin nombre — pero no puede detectar enlaces cuyos nombres están técnicamente presentes pero son semánticamente carentes de significado (por ejemplo, "haz clic aquí" o "leer más"), porque las herramientas automatizadas no pueden determinar la intención a partir de cadenas genéricas. - duplicate-id-aria: Esta regla comprueba que no haya dos elementos en la página que compartan el mismo atributo
idcuando eseides referenciado por un atributo ARIA comoaria-labelledbyoaria-describedby. Los IDs duplicados usados en relaciones ARIA hacen que el navegador resuelva la referencia de forma impredecible — normalmente al primer elemento coincidente en el orden del DOM — lo que puede provocar que el nombre accesible de un enlace se calcule a partir del elemento equivocado. Por ejemplo, si dos enlaces usanaria-labelledby='product-title'y dos elementos comparten ese ID, los lectores de pantalla pueden anunciar el nombre de producto equivocado para uno o ambos enlaces, violando directamente 2.4.4. Axe marca esto como un problema crítico porque el nombre accesible resultante no es fiable.
Es importante entender los límites de las pruebas automatizadas para este criterio. Herramientas como axe-core pueden verificar que un enlace tenga un nombre accesible, pero no pueden verificar que el nombre sea significativo. Un enlace llamado "aquí" cumple automáticamente la regla link-name porque la cadena no está vacía. Se requiere juicio humano para evaluar si el texto de enlace genérico incumple 2.4.4. Esto hace que las pruebas manuales sean un complemento esencial al escaneo automatizado para este criterio.
Cómo probar
- Escaneo automatizado con axe DevTools o Lighthouse: Instale la extensión de navegador axe DevTools (Chrome o Firefox) o ejecute una auditoría de accesibilidad de Lighthouse en Chrome DevTools. Ejecute un escaneo de página completa y filtre los resultados por las reglas
link-nameyduplicate-id-aria. Revise cada elemento marcado: confirme que el nombre accesible calculado está ausente o vacío en las infracciones delink-name, y verifique que los IDs duplicados estén rompiendo las referencias de etiquetas ARIA en las infracciones deduplicate-id-aria. Tenga en cuenta que superar estas comprobaciones automatizadas no garantiza el cumplimiento completo de 2.4.4; continúe con los pasos manuales. - Revisión manual de la lista de enlaces: En NVDA con Firefox, presione la combinación de teclas
Insert+F7para abrir el cuadro de diálogo Lista de elementos y seleccione "Enlaces". Revise cada entrada de la lista de forma aislada, sin contexto visual. Pregúntese: ¿puede determinar a dónde lleva cada enlace solo por su texto? Repita en JAWS con Chrome usandoInsert+F7para abrir la Lista de enlaces. En VoiceOver con Safari en macOS, presioneControl+Option+Upara abrir el Rotor de ítems web y seleccione "Enlaces". Cualquier enlace cuyo propósito sea ambiguo de forma aislada debe examinarse en relación con su contexto programático. - Prueba de navegación con teclado: Usando solo la tecla
Tab, navegue por todos los elementos interactivos de la página. Cada vez que el foco se sitúe en un enlace, lea solo el texto anunciado (no el contenido visual circundante). Si no puede determinar el destino del enlace a partir de lo que se anuncia, es probable que el enlace incumpla 2.4.4. Preste especial atención a los enlaces compuestos solo por iconos (iconos de redes sociales, botones de flecha) y a los enlaces de imagen. - Verificación de contexto: Para los enlaces que dependen del contexto circundante (por ejemplo, "Leer más" dentro de un elemento de lista), inspeccione el DOM para confirmar que el texto contextual está en la misma oración, párrafo, elemento de lista o celda de tabla que el enlace. El contexto que solo es visualmente adyacente pero no está asociado de forma programática no satisface el criterio. Use las DevTools del navegador para inspeccionar el árbol de accesibilidad calculado y confirmar la relación.
- Auditoría de etiquetas ARIA: Busque en el código fuente de la página todos los usos de
aria-labelledbyyaria-describedbyen elementos de enlace. Verifique que cada ID referenciado exista exactamente una vez en el documento y que el elemento referenciado contenga el texto descriptivo previsto. Use el panel del árbol de accesibilidad del navegador (disponible en Chrome DevTools en la pestaña Accessibility) para confirmar el nombre calculado de cada enlace.
Cómo corregir
Enlace solo con icono y sin nombre accesible — Incorrecto
<!-- An icon link with no text and no aria-label -->
<a href='https://twitter.com/accsible'>
<svg viewBox='0 0 24 24' width='24' height='24'>
<path d='M23 3a10.9 10.9...' />
</svg>
</a>
Enlace solo con icono y sin nombre accesible — Correcto
<!-- aria-label provides a descriptive accessible name for screen readers -->
<a href='https://twitter.com/accsible' aria-label='Accsible on Twitter'>
<svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>
<path d='M23 3a10.9 10.9...' />
</svg>
</a>
Enlaces genéricos "Read more" en una lista de tarjetas — Incorrecto
<!-- Multiple identical link texts with no distinguishing context -->
<ul>
<li>
<h3>Istanbul Accessibility Summit 2024</h3>
<p>Join us for the annual summit on digital inclusion.</p>
<a href='/events/istanbul-2024'>Read more</a>
</li>
<li>
<h3>New WCAG 2.2 Guidelines Released</h3>
<p>W3C has published the updated guidelines.</p>
<a href='/news/wcag-22'>Read more</a>
</li>
</ul>
Enlaces genéricos "Read more" en una lista de tarjetas — Correcto
<!-- Option 1: Visually hidden text appended to the link -->
<ul>
<li>
<h3>Istanbul Accessibility Summit 2024</h3>
<p>Join us for the annual summit on digital inclusion.</p>
<a href='/events/istanbul-2024'>
Read more
<span class='sr-only'>about the Istanbul Accessibility Summit 2024</span>
</a>
</li>
<li>
<h3>New WCAG 2.2 Guidelines Released</h3>
<p>W3C has published the updated guidelines.</p>
<a href='/news/wcag-22'>
Read more
<span class='sr-only'>about the New WCAG 2.2 Guidelines</span>
</a>
</li>
</ul>
<!-- Option 2: Use aria-label to override the visible text entirely -->
<a href='/events/istanbul-2024' aria-label='Read more about the Istanbul Accessibility Summit 2024'>
Read more
</a>
Enlace de imagen con atributo alt vacío — Incorrecto
<!-- The image has an empty alt, making the link completely unnamed -->
<a href='/products/overlay-widget'>
<img src='widget-logo.png' alt='' />
</a>
Enlace de imagen con atributo alt vacío — Correcto
<!-- The alt attribute on the image provides the link's accessible name -->
<a href='/products/overlay-widget'>
<img src='widget-logo.png' alt='Accsible Overlay Widget — product details' />
</a>
aria-labelledby que hace referencia a un ID duplicado — Incorrecto
<!-- Two elements share the same ID; the second link resolves to the wrong label -->
<div>
<span id='card-title'>Accsible SDK Documentation</span>
<a href='/docs' aria-labelledby='card-title'>View</a>
</div>
<div>
<span id='card-title'>Accsible Pricing Plans</span>
<a href='/pricing' aria-labelledby='card-title'>View</a>
</div>
aria-labelledby que hace referencia a un ID duplicado — Correcto
<!-- Each ID is unique; each link resolves to the correct label -->
<div>
<span id='card-title-docs'>Accsible SDK Documentation</span>
<a href='/docs' aria-labelledby='card-title-docs'>View</a>
</div>
<div>
<span id='card-title-pricing'>Accsible Pricing Plans</span>
<a href='/pricing' aria-labelledby='card-title-pricing'>View</a>
</div>
Errores comunes
- Usar "haz clic aquí", "aquí", "más" o "leer más" como texto de enlace sin ningún nombre accesible complementario mediante
aria-label,aria-labelledbyo elementos<span>visualmente ocultos; estas cadenas carecen de significado cuando un lector de pantalla las extrae de su contexto visual. - Agregar un
aria-labela un enlace que contiene un texto visible diferente sin asegurarse de que la etiqueta comience con la cadena de texto visible; esto viola WCAG 2.5.3 (Etiqueta en el nombre) y causa confusión a las personas usuarias de control por voz que intentan activar el enlace pronunciando su nombre visible. - Establecer
alt=''en una imagen que es el único contenido de un enlace, lo que hace que el nombre accesible calculado del enlace esté vacío y provoque una infracción delink-name; un alt vacío es correcto para imágenes decorativas pero no cuando la imagen es el único contenido de un elemento interactivo. - Aplicar
aria-hidden='true'al único nodo de texto dentro de un enlace, lo que elimina el nombre accesible del árbol de accesibilidad y deja el enlace sin nombre para las personas usuarias de lectores de pantalla. - Reutilizar el mismo valor de
iden varios elementos que son referenciados poraria-labelledbyen distintos enlaces, lo que hace que los lectores de pantalla calculen el nombre accesible equivocado para uno o más enlaces debido a una resolución de IDs impredecible. - Envolver un componente de tarjeta completo (encabezado, imagen, párrafo y botón) en una sola etiqueta
<a>, lo que hace que los lectores de pantalla lean todo el contenido de la tarjeta como el nombre accesible del enlace — una experiencia prolija y desorientadora — en lugar de usar una etiqueta breve y descriptiva. - Confiar únicamente en un tooltip del atributo CSS
titleo en una pseudoclase:hoverpara proporcionar contexto al enlace; el atributotitlese expone de forma inconsistente por los lectores de pantalla y es completamente inaccesible para las personas que solo usan teclado y no pueden activar estados hover. - Usar la propia URL como texto de enlace (por ejemplo,
<a href='https://example.com/p?id=12345'>https://example.com/p?id=12345</a>), lo cual es impronunciable por los lectores de pantalla y carece de significado para las personas con discapacidades cognitivas. - Generar IDs de enlaces o valores de atributos ARIA dinámicamente con frameworks de JavaScript sin garantizar su unicidad; los componentes de React, Vue y Angular renderizados en listas con frecuencia producen IDs duplicados a menos que se implementen estrategias explícitas de claves.
- Olvidar agregar
focusable='false'a los iconos SVG en línea dentro de enlaces en Internet Explorer y versiones antiguas de Edge, lo que hace que el SVG reciba su propio punto de tabulación y que los lectores de pantalla anuncien el SVG por separado del texto del enlace, dividiendo el cálculo del nombre accesible.
Relación con la normativa de accesibilidad de Turquía
La Circular Presidencial 2025/10 de Turquía, publicada en el Boletín Oficial n.º 32933 el 21 de junio de 2025, establece requisitos obligatorios de accesibilidad digital alineados con WCAG 2.2. WCAG 2.4.4 Propósito del enlace (en contexto) es un criterio de Nivel A, lo que significa que forma parte de la base obligatoria que todas las entidades cubiertas deben alcanzar.
La circular se aplica a un conjunto definido de tipos de entidades tanto del sector público como del privado. Las instituciones públicas — incluidos ministerios, organismos estatales, municipios y universidades públicas — deben lograr la conformidad completa de Nivel A en el plazo de un año desde la publicación de la circular. Las entidades del sector privado cubiertas por la circular tienen un plazo de cumplimiento de dos años. El alcance del sector privado es amplio e incluye explícitamente plataformas de comercio electrónico, bancos e instituciones financieras, hospitales privados y proveedores de atención sanitaria, operadores de telecomunicaciones con 200.000 o más abonados, agencias de viajes, empresas de transporte privado y escuelas privadas autorizadas por el Ministerio de Educación Nacional.
Para todas estas entidades, el texto de enlace no conforme representa una infracción normativa directa. Considere una plataforma turca de comercio electrónico que muestra páginas de listado de productos con enlaces repetidos "Satın Al" (Comprar ahora) o "Devamını Oku" (Leer más) sin ningún contexto programático. Una persona ciega que dependa de TalkBack, NVDA o VoiceOver no podría determinar a qué producto se refiere cada enlace, lo que constituye un incumplimiento de 2.4.4 y una violación de los requisitos de la circular. De manera similar, el portal de reserva de citas de un hospital público que use enlaces de navegación compuestos solo por iconos y sin nombres accesibles incumpliría tanto la regla link-name de axe como el mandato de la circular.
El cumplimiento de 2.4.4 no es simplemente una casilla técnica que marcar. La circular señala un compromiso gubernamental más amplio con la inclusión digital de los aproximadamente 8,5 millones de ciudadanos con discapacidad de Turquía. Para las entidades dentro del alcance, abordar de forma proactiva los fallos en el propósito de los enlaces — mediante estándares de sistemas de diseño, formación de desarrolladores y escaneo automatizado en CI/CD — es tanto una obligación legal como una inversión sólida en usabilidad y rendimiento en búsquedas. El incumplimiento dentro de los plazos establecidos puede dar lugar a acciones regulatorias por parte de las autoridades supervisoras pertinentes designadas en la circular.
