Botones, enlaces y controles personalizados

Botones y enlaces son los dos controles más abundantes de cualquier web y, paradójicamente, los que más se confunden entre sí. Para una persona que ve la pantalla la diferencia es cosmética; para quien usa lector de pantalla o control por voz la diferencia es funcional: un enlace «va a un sitio», un botón «hace algo», y cada uno se opera con teclas distintas y aparece en listas distintas. Esta lección fija cuándo usar cada uno, cómo nombrarlos y qué hay que reconstruir cuando, excepcionalmente, se construye un control desde cero.

Botón o enlace: la decisión

Las consecuencias de equivocarse son concretas. Un enlace con href="#" que abre un modal aparece en la lista de enlaces del lector de pantalla, ofrece «abrir en pestaña nueva» en el menú contextual (lo que abre una página vacía), no responde a Espacio y, si JavaScript falla, hace saltar la página arriba. Un <button> que navega con onclick="location.href=…" no se puede abrir en otra pestaña, no muestra la URL de destino y no aparece en la lista de enlaces.

<a href="#" onclick="abrirCarrito()">Ver carrito</a>
<a href="javascript:void(0)" class="btn">Aceptar</a>
<a class="btn">Continuar</a>

Si por restricciones del framework o del CMS no puedes cambiar el elemento, aplica el parche completo: role="button", manejador de Espacio (porque un enlace no lo tiene) y href válido. Pero es un parche, no la solución.

Nombres que funcionan fuera de contexto

Las personas usuarias de lectores de pantalla navegan a menudo con la lista de enlaces o de botones, donde cada nombre aparece sin el texto que lo rodea. El criterio 2.4.4 Propósito de los enlaces (en contexto) (A) permite que el propósito se deduzca del contexto programático (la frase o el elemento de lista que lo contiene), pero la práctica recomendable, y lo que exige el AAA 2.4.9, es que el texto baste por sí solo.

• «Leer más» repetido diez veces no sirve. Mejor: «Leer más sobre las tasas 2025», aunque parte del texto quede visualmente oculto con una clase de ocultación accesible, o un aria-labelledby que combine el texto del enlace con el título de la tarjeta.
• «Pulse aquí» o «este enlace» no describen nada.
• En enlaces que abren en una nueva pestaña o descargan un archivo, indica el comportamiento y el formato: «Memoria 2024 (PDF, 2 MB)», «Portal de transparencia (se abre en una ventana nueva)».
• En botones con icono, el nombre describe la acción («Cerrar», «Buscar», «Eliminar la fila de Ana García»), no el dibujo («Equis», «Lupa», «Papelera»).

<article>
  <h3 id="n-42">Nuevas ayudas al alquiler para menores de 35 años</h3>
  <p>…</p>
  <a href="/noticias/42" aria-labelledby="leer-42 n-42" id="leer-42">Leer más</a>
</article>

Estados de los botones

• Deshabilitado: disabled quita el botón del orden de tabulación y lo anuncia como «no disponible». Es correcto para acciones imposibles en ese momento, pero tiene un coste: la persona no puede llegar a él para saber que existe ni por qué está deshabilitado. Para el botón de envío de un formulario, muchas guías recomiendan dejarlo habilitado y mostrar los errores al pulsarlo, en lugar de deshabilitarlo hasta que todo sea válido. Si necesitas que siga siendo enfocable, usa aria-disabled="true" e ignora el clic en JavaScript.
• Conmutador (activado/desactivado): aria-pressed="true|false". El nombre no cambia («Negrita»); cambia el estado. No pongas «Activar negrita» y «Desactivar negrita» alternando el texto y además aria-pressed: el lector dirá «Desactivar negrita, pulsado», que es confuso.
• Despliega algo: aria-expanded y, si lo que despliega no es el siguiente elemento, aria-controls.
• Abre un menú o diálogo: aria-haspopup="menu", aria-haspopup="dialog" (opcional, pero informativo).
• En curso: mientras se procesa, cambia el texto a «Enviando…» y usa aria-disabled o una región de estado; evita el spinner mudo.

Controles personalizados: la lista de reconstrucción

Cuando un control no tiene equivalente nativo (un botón de «me gusta» con animación compleja, un selector de color, una ficha arrastrable), hay que reconstruir manualmente lo que el navegador daría. La lista de comprobación mínima:

1. Elemento contenedor con el role correcto de la APG (se abre en una ventana nueva).
2. tabindex="0" (o roving tabindex si forma parte de un grupo).
3. Nombre accesible visible o con aria-labelledby/aria-label.
4. Estados ARIA actualizados por JavaScript en cada cambio.
5. Manejador keydown para Intro y Espacio (y flechas si el patrón las usa), con preventDefault() en Espacio.
6. Indicador de foco visible con :focus-visible.
7. Tamaño mínimo del objetivo de 24 por 24 píxeles CSS (2.5.8 Tamaño del objetivo (mínimo)), salvo que haya suficiente separación, un equivalente mayor, o esté dentro de una línea de texto.
8. Eventos de puntero que no dependan de gestos complejos (2.5.1) y que puedan cancelarse soltando fuera (2.5.2 Cancelación del puntero): activa en click o pointerup, no en pointerdown.

Cómo comprobarlo

• Abre la lista de enlaces y la de botones con el lector de pantalla: cada nombre debe entenderse solo y estar en la lista correcta.
• Pulsa Espacio sobre cada cosa que parece un botón: si navega o no hace nada, no es un botón.
• Haz clic con el botón derecho sobre lo que parece un enlace: debe ofrecer «abrir en pestaña nueva».
• Mide los objetivos pequeños con las herramientas del navegador: 24 por 24 píxeles CSS como mínimo.

Resumen

• Enlace para navegar, botón para actuar; nunca href="#" con un onclick ni <a> sin href.
• Los nombres deben funcionar fuera de contexto e incluir el texto visible; en iconos, describen la acción.
• Los estados se expresan con disabled/aria-disabled, aria-pressed, aria-expanded y aria-haspopup, actualizados por JavaScript.
• Un control personalizado exige rol, tabindex, nombre, estados, teclado, foco visible, tamaño mínimo y cancelación del puntero.
• Estilizar el elemento nativo casi siempre es más barato y más robusto que reconstruirlo.