Si has escrito alguna vez “haz click aquí”, tranquilo: no eres la primera persona. Lo que sí sería un crimen (con premeditación y alevosía UX) es dejarlo ahí sabiendo que un enlace es mucho más que un trocito subrayado en azul.
En accesibilidad web (a11y) y en contenido y diseño inclusivo, los enlaces son un punto crítico porque funcionan como decisiones en miniatura: cada link le pide al usuario que entienda algo, elija algo y actúe. Y ahí entra una comparación que te va a servir para auditar tu interfaz sin excusas:
- Tiempo de decisión: cuánto tarda alguien en entender “qué hace esto” y decidir si le interesa.
- Carga cognitiva: cuánta energía mental necesita para interpretar el texto, el contexto, el estilo visual, los estados y la promesa del enlace.
Cuando el enlace está mal redactado (“aquí”, “ver más”, “leer”, “clic”), suben ambas: tardas más en decidir y además te cansas antes. Cuando está bien, la interfaz se vuelve más rápida, más clara y más accesible.
Vamos a destriparlo con ejemplos técnicos y de interacción, sin postureo.
Por qué “haz click aquí” falla en accesibilidad (y también en UX)
“Haz click aquí” falla por tres razones muy prácticas:
- No describe el destino (ni la acción).
- No sobrevive fuera de contexto.
- Excluye: no todo el mundo “hace click” (móvil, teclado, voz, lector de pantalla, switch, etc.).
Cómo leen los usuarios visuales: escanean, no leen linealmente
En la vida real, mucha gente no “lee” tu página: escanea. Busca palabras-ancla (nombres, verbos, conceptos) que le permitan decidir rápido.
- “Haz click aquí” no aporta información semántica.
- Obliga a mirar alrededor para entender “¿aquí para qué?”.
- Aumenta tiempo de decisión y carga cognitiva porque el usuario tiene que reconstruir significado.
Micro-ejemplo: el enlace no debe pedir contexto prestado
Mal:
- “Para más información sobre accesibilidad visual, haz click aquí.”
Bien:
- “Más información sobre accesibilidad visual en interfaces.”
En la versión buena, el enlace ya contiene la promesa. El ojo lo detecta y el cerebro decide sin esfuerzo.
Cómo lo leen los lectores de pantalla: listas de enlaces sin el resto del texto
Esto es clave en accesibilidad web: muchos usuarios de lectores de pantalla navegan saltando por enlaces o incluso abriendo una lista de enlaces de la página. En ese escenario, “aquí” se convierte en una colección de nada.
Imagina una lista así:
- aquí
- aquí
- ver más
- ver más
- leer
- leer
Eso no es navegación: es un laberinto.
Lo que queremos que pase
Queremos que, al extraer los links, sigan teniendo sentido:
- Guía de contenido y diseño inclusivo
- Checklist de a11y para desarrollo web
- Descargar Informe de accesibilidad (PDF)
- Ver ejemplos de links accesibles en UI
Aquí baja el tiempo de decisión (se entiende rápido) y baja la carga cognitiva (no hay que deducir).
Qué convierte un enlace en accesible: semántica + contexto + forma
Un enlace accesible no es solo “texto bonito”. Es la suma de:
- Semántica: el texto describe destino/acción.
- Contexto: se entiende incluso fuera del párrafo.
- Interacción: se percibe como link y se puede usar con distintos métodos.
- Diseño: contraste, foco, estados, tamaño y consistencia.
Regla de oro: el texto del enlace debe describir el destino
Piensa en el enlace como un “título de acción”. Debe responder a una de estas preguntas:
- ¿Qué voy a ver?
- ¿Qué voy a hacer?
- ¿Qué se descarga y en qué formato?
- ¿A dónde me lleva?
Plantillas que funcionan (y posicionan mejor)
En SEO y accesibilidad, suele funcionar combinar verbo + objeto o objeto + aclaración:
- Leer: “Cómo auditar accesibilidad web en un proyecto React”
- Ver: “Ejemplos de links accesibles en navegación”
- Descargar: “Descargar guía de a11y (PDF, 1,2 MB)”
- Abrir herramienta: “Abrir validador de contraste”
Fíjate que aquí no solo mejoras accesibilidad visual y cognitiva: también estás metiendo términos significativos que ayudan al posicionamiento y a la comprensión.
Evita “ver más” repetido en cards: patrón típico, problema típico
En grids de artículos o tarjetas, es habitual ver:
- Card 1 → “Ver más”
- Card 2 → “Ver más”
- Card 3 → “Ver más”
Para un lector de pantalla, eso es casi inútil. Para un usuario visual, obliga a fijarse en el título de la tarjeta, generando micro-fricción repetida.
Solución 1: convierte el título en el enlace principal
Recomendación: el título del contenido suele ser el mejor texto de enlace.
<article>
<h3>
<a href="/blog/links-accesibles">Links accesibles: “haz click aquí” es un crimen</a>
</h3>
<p>Cómo reducir carga cognitiva y mejorar a11y con microcopy.</p>
</article>
Solución 2: si necesitas un CTA extra, hazlo específico
- “Leer el artículo sobre a11y y enlaces”
- “Ver ejemplos de contenido inclusivo”
Si por diseño quieres mantener un “Ver más”, entonces enriquece el nombre accesible:
<a href="/blog/links-accesibles" aria-label="Ver más: Links accesibles, haz click aquí es un crimen">
Ver más
</a>
Ojo: aria-label es un parche útil, pero lo ideal es que el texto visible ya sea bueno. Si la UI es ambigua, el problema no se arregla solo con ARIA.
Botón vs enlace: no es estética, es semántica (y comportamiento)
Un error frecuente en desarrollo web: usar <a> para acciones y <button> para navegación, o al revés. Esto afecta accesibilidad, expectativas y hasta analítica.
Cuándo usar enlace
Usa <a> cuando el objetivo sea navegar:
- Ir a otra URL
- Abrir una sección (hash)
- Ir a un recurso externo
Cuándo usar botón
Usa <button> cuando el objetivo sea ejecutar una acción:
- Abrir un modal
- Enviar un formulario
- Filtrar resultados (sin cambiar URL)
- Expandir/contraer contenido
Ejemplo de patrón correcto en filtros
Bien:
- Botones para filtrar
- Enlaces para navegar a detalle
Esto reduce carga cognitiva: el usuario no tiene que adivinar si “parece link” pero actúa como botón.
Interacción accesible: foco, estados, contraste y área clicable
Un enlace accesible también se “lee” con los dedos y con el teclado.
Foco visible: si navegas con teclado, esto es tu mapa
Si el foco no se ve, estás quitando navegación a una parte de usuarios (y generando frustración). La accesibilidad visual aquí es directa.
Recomendaciones:
- Que el foco sea muy evidente (no un cambio sutil de color).
- Que haya estilos en
:focus-visible. - Que no dependan solo del color.
Ejemplo en Tailwind (práctico y limpio)
<a
href="/guia-a11y"
class="underline underline-offset-4 focus-visible:outline focus-visible:outline-2 focus-visible:outline-offset-4"
>
Guía de accesibilidad web (a11y)
</a>
No uses solo color para indicar “esto es un link”
Si tu enlace se distingue solo por color, estás cargando la interfaz de ambigüedad para:
- Personas con baja visión
- Daltonismo
- Pantallas con bajo contraste
- Contextos con brillo alto
La solución clásica y efectiva: subrayado (sí, subrayado). Si lo quitas por estética, entonces debes reemplazarlo por un patrón igual de robusto, no por “ya se intuía”.
Tamaño del objetivo: enlaces pequeños, precisión imposible
En móvil, un link minúsculo es un castigo. Y en accesibilidad, un objetivo pequeño aumenta errores, reintentos y fatiga (hola, carga cognitiva).
Hazlo fácil de tocar:
- Más padding
- Más separación entre links
- Evita “links pegados” en un párrafo sin espacios
Enlaces especiales: nueva pestaña, descargas, externos e iconos
Aquí es donde muchos proyectos se rompen: el usuario hace click y pasan cosas que no esperaba.
Si abre en nueva pestaña, dilo (o al menos indícalo)
Abrir en nueva pestaña sin avisar puede desorientar. Si lo haces, sé transparente:
- “Abrir documentación (se abre en una pestaña nueva)”
- Icono + texto oculto accesible
<a href="https://example.com" target="_blank" rel="noopener noreferrer">
Documentación externa <span class="sr-only">(se abre en una pestaña nueva)</span>
</a>
Si es una descarga, indica formato y peso cuando sea relevante
Esto es contenido inclusivo: ayudas a decidir antes de actuar.
- “Descargar informe de accesibilidad (PDF, 2 MB)”
- “Descargar dataset (CSV, 450 KB)”
Baja el tiempo de decisión y evita sorpresas (baja carga cognitiva y frustración).
Icon-only links: siempre con nombre accesible
Si tienes un icono de GitHub, Twitter o “compartir”, recuerda: el icono no siempre “se lee”.
<a href="https://github.com/tuusuario" aria-label="Ir a GitHub de Marta González">
<!-- svg -->
</a>
Mejor aún: combina icono + texto visible cuando la UI lo permita.
Ejemplos “antes y después” para que puedas aplicarlo hoy
En un párrafo informativo
Antes:
“Si quieres aprender sobre accesibilidad web, haz click aquí.”
Después:
“Aprende sobre accesibilidad web y a11y en desarrollo web con esta guía práctica.”
En una lista de recursos
Antes:
- Click aquí
- Click aquí
- Click aquí
Después:
- Checklist de accesibilidad visual para interfaces
- Guía de contenido y diseño inclusivo
- Buenas prácticas de enlaces accesibles en React
En cards de blog
Antes:
- Título
- Descripción
- “Ver más”
Después (mejor patrón):
- Título (enlace)
- Descripción
- Opcional: “Leer el artículo”
Checklist técnico rápido para auditar links accesibles (sin herramientas)
En 2 minutos, revisa esto
- ¿Cada enlace tiene sentido fuera de contexto?
- ¿Hay “aquí / ver más / leer” repetidos?
- ¿El texto describe destino o acción?
- ¿El foco es visible y claro?
- ¿El link se distingue sin depender solo del color?
- ¿Los iconos tienen nombre accesible?
- ¿Se avisa si abre nueva pestaña o descarga?
- ¿Link y botón están bien usados semánticamente?
Mini-test mental: “lista de enlaces”
Si un usuario escuchara solo tus enlaces, ¿podría navegar sin perderse? Si la respuesta es “no”, ya sabes por dónde empezar.
Preguntas frecuentes (FAQs)
1) ¿Puedo usar “aquí” si el texto alrededor explica el destino?
Poder, puedes. Pero no es buena práctica. En accesibilidad web, el enlace debe ser autosuficiente porque puede ser consumido fuera del contexto (listas de enlaces, escaneo, navegación por teclado). Si quieres mantener un tono natural, integra el enlace en una frase descriptiva.
2) ¿Qué hago si por diseño necesito que el CTA sea corto?
Haz el texto corto, pero significativo. “Ver guía” es mejor que “Ver”. Y si aún así necesitas un genérico por consistencia visual, complementa con un nombre accesible (por ejemplo, aria-label). Aun así, lo recomendable es que el texto visible haga el trabajo principal.
3) ¿Es mejor enlazar una card completa o solo el título?
Depende, pero cuidado: una card entera clicable puede crear problemas de accesibilidad si no está bien implementada (teclado, foco, elementos interactivos anidados). El patrón más robusto suele ser: título enlazado + CTA secundario opcional, evitando zonas “misteriosamente clicables”.
Un enlace es una promesa (y también un acto de respeto)
Un link no es un adorno: es una promesa de navegación y una petición de atención. Cuando escribes “haz click aquí”, estás delegando el significado en el contexto y empujando al usuario a hacer trabajo extra. Eso sube el tiempo de decisión y la carga cognitiva, y en accesibilidad eso se traduce en barreras reales.
En cambio, cuando un enlace es claro, descriptivo y coherente con la interacción, ocurre algo muy potente: la interfaz se vuelve más rápida para quien escanea, más fiable para quien navega con teclado, más comprensible para quien usa lector de pantalla y más amable para quien simplemente está cansado y quiere que la web deje de ponerle trampas.
Si hoy te llevas una sola regla, que sea esta: el texto del enlace debe poder vivir solo. Si puede, tu UI respira. Si no puede, estás a un “aquí” de convertir la navegación en un crimen.