Links y botones que no dicen 'click acá': cómo nombrarlos con sentido

Una persona que usa lector de pantalla muchas veces no lee la página de arriba a abajo: salta de link en link para orientarse rápido. El software le lee una lista de todos los enlaces, fuera de contexto. Si tenés seis links que dicen "click acá", esa persona escucha "click acá, click acá, click acá" y no tiene idea de adónde va ninguno. El texto del enlace es su mapa. Nombrarlo bien es la diferencia entre navegar y adivinar.

La regla central: el link se tiene que entender solo

WCAG 2.4.4 lo pide directo: el propósito de cada enlace tiene que entenderse por su propio texto, sin depender de lo que hay alrededor. Preguntate: si leo solo esta frase-link, ¿sé adónde me lleva?

• Malo: Para ver los precios, hacé click acá. → el link es "acá".
• Bueno: Mirá nuestra lista de precios. → el link es "lista de precios".

El truco práctico: que el texto del enlace sea el destino, no la orden. Nombrás la página a la que vas, no la acción de hacer clic.

Lo que nunca debería ser un texto de enlace

• "Click acá" / "Hacé click". No dice nada del destino.
• "Acá" / "Este link". Igual de vacío.
• "Leer más" / "Ver más" repetido. Si tenés diez "leer más" en la misma página, son diez links idénticos hacia lugares distintos. Diferencialos: "Leer más sobre contraste".
• La URL cruda pegada. https://sitio.com/productos/2024/… el lector la deletrea entera, carácter por carácter. Ilegible.

Botones vs. enlaces: no son lo mismo

Parece detalle técnico, pero cambia cómo funciona la navegación por teclado y qué anuncia el lector de pantalla:

• Enlace (<a>): te lleva a otro lugar (otra página, otra sección). El lector dice "enlace".
• Botón (<button>): ejecuta una acción acá mismo (enviar, abrir un menú, reproducir). El lector dice "botón".

Usar el elemento correcto no es cosmético: un div estilizado como botón no responde a la tecla Enter ni se anuncia como interactivo. Si algo es clickeable, tiene que ser un <a> o un <button> de verdad (WCAG 4.1.2, nombre/rol/valor).

Nombres accesibles cuando no hay texto visible

Un botón que es solo un ícono (una lupa, un tacho de basura, una X) no tiene texto para que el lector lea. Ahí va un nombre accesible por código:

• aria-label="Buscar" en el ícono de lupa.
• aria-label="Cerrar" en la X.
• aria-label="Eliminar comentario" en el tacho.

Que el nombre describa la acción, no el dibujo: "Buscar", no "lupa".

Cómo lo escucha un lector de pantalla

Un ejemplo concreto de por qué esto importa:

• Elemento: link de texto con copy "Hacé click acá para conocer más".
• Estado: no accesible — WCAG 2.4.4 (Nivel A). Enlace ambiguo, sin autonomía contextual.
• Cómo lo escucha: "Enlace: Hacé click acá para conocer más. Sin información de destino."

Cómo arreglarlo:

• Opción 1: "Ver artículos sobre accesibilidad".
• Opción 2: "Descargar la guía de legibilidad (PDF)".

Fijate que la segunda además avisa el formato: quien lo escucha sabe que va a bajar un PDF antes de tocarlo.

Detalles que suman

• Avisá lo inesperado. Si el link abre en una pestaña nueva o descarga un archivo, decilo en el texto: "(PDF)", "(abre en pestaña nueva)".
• Que se vea que es un link. No lo distingas solo por color; sumá subrayado (esto se cruza con la guía de contraste).
• Foco visible. Al navegar con Tab, el link tiene que mostrar claramente que está seleccionado.

Checklist rápido antes de publicar

1. ¿Cada link se entiende leyendo solo su texto, sin el contexto?
2. ¿Eliminaste los "click acá", "acá" y "leer más" sueltos?
3. ¿Los "leer más" repetidos están diferenciados por su destino?
4. ¿Usaste <a> para navegar y <button> para acciones?
5. ¿Los botones-ícono tienen aria-label con la acción?
6. ¿Avisás cuando algo abre pestaña nueva o descarga un archivo?
7. ¿El link se distingue por algo más que el color y tiene foco visible?