Una de las formas más rápidas de identificar a un desarrollador front-end sin experiencia es observar cómo maneja los enlaces y los botones.
Parece algo trivial.
No lo es.
Muchos problemas de accesibilidad comienzan cuando los desarrolladores eligen el elemento HTML incorrecto y luego intentan obligarlo a comportarse como otra cosa.
Un enlace es para la navegación.
Un botón es para las acciones.
Estas dos cosas no son intercambiables.
Sin embargo, los sitios web modernos están llenos de enlaces que actúan como botones, botones que actúan como enlaces y elementos <div> clicables que pretenden ser ambas cosas.
La página puede verse bien.
La experiencia de accesibilidad suele ser un desastre.
La regla es simple
Si al hacer clic en un elemento el usuario es llevado a otro lugar, utilice un enlace.
<a href="/productos/rampa-para-silla-de-ruedas">
Ver detalles del producto
</a>
Algunos ejemplos incluyen:
- Abrir la página de un producto
- Leer un artículo de blog
- Descargar un PDF
- Navegar a otra página
- Saltar a otra sección de la misma página
- Abrir un sitio web externo
Si al hacer clic en un elemento se realiza una acción en la página actual, utilice un botón.
<button type="button">
Abrir menú
</button>
Algunos ejemplos incluyen:
- Abrir una ventana modal
- Enviar un formulario
- Expandir un acordeón
- Mostrar u ocultar un menú
- Aplicar un filtro
- Agregar un artículo al carrito de compras
Ese es todo el proceso de decisión.
Sin embargo, muchos sitios web lo hacen mal.
Por qué les importa a los usuarios de tecnologías de asistencia
La mayoría de los usuarios nunca piensa en la diferencia entre un enlace y un botón porque interactúan visualmente con la página.
Los usuarios de lectores de pantalla sí lo hacen.
Las tecnologías de asistencia presentan los enlaces y los botones de manera diferente porque cumplen funciones distintas.
Cuando un lector de pantalla anuncia "enlace", los usuarios esperan navegación.
Cuando anuncia "botón", esperan una acción.
Esas expectativas se forman después de años utilizando sitios web.
Cuando un desarrollador crea un enlace que abre una ventana modal en lugar de navegar a otra página, el usuario recibe un mensaje y experimenta algo completamente diferente.
El resultado es confusión.
Los problemas de accesibilidad suelen ser consecuencia de expectativas incumplidas más que de funcionalidades rotas.
El comportamiento con el teclado es diferente
Los enlaces y los botones también responden de forma diferente al teclado.
Un botón estándar puede activarse tanto con la tecla Enter como con la barra espaciadora.
Un enlace estándar normalmente se activa con Enter.
Muchos desarrolladores descubren esto solamente después de reemplazar controles nativos por componentes personalizados en JavaScript.
Crean un elemento <div> clicable, agregan un detector de eventos y asumen que el trabajo está terminado.
No lo está.
Ahora deben recrear:
- Compatibilidad con teclado
- Gestión del foco
- Semántica para lectores de pantalla
- Estados deshabilitados
- Nombres accesibles
- Comportamiento esperado del navegador
HTML nativo ya proporciona todo eso.
Descartarlo genera trabajo adicional y normalmente introduce errores de accesibilidad.
El problema de los enlaces falsos
Uno de los errores de accesibilidad más comunes es utilizar una etiqueta de anclaje sin un atributo href.
Por ejemplo:
<a onclick="openModal()">
Abrir diálogo
</a>
Visualmente, esto puede parecer un enlace.
Semánticamente, muchas veces no lo es.
Muchas tecnologías de asistencia no tratarán el elemento como un enlace real porque carece de un destino válido.
El desarrollador ve un enlace.
El usuario del lector de pantalla puede no verlo así.
Esto crea experiencias inconsistentes entre navegadores y tecnologías de asistencia.
Un botón habría sido la solución correcta desde el principio.
El problema de los botones falsos
El error opuesto es igual de común.
Un desarrollador crea un botón y utiliza JavaScript para redirigir al usuario a otra página.
<button onclick="window.location='/contacto'">
Contáctenos
</button>
El resultado visual funciona.
El significado semántico es incorrecto.
A los usuarios se les informa que están activando un botón. Sin embargo, son enviados a otra página.
Esa desconexión puede parecer menor para un desarrollador que prueba el sitio con un ratón, pero genera fricción innecesaria para los usuarios que dependen de comportamientos predecibles.
Si el propósito es navegar, utilice un enlace.
Los botones pueden hacer cosas que los enlaces no pueden
Otra razón por la que esta distinción es importante es que los botones y los enlaces tienen capacidades diferentes.
Los botones pueden deshabilitarse.
<button disabled>
Enviar
</button>
Los enlaces no pueden.
Los botones participan de forma natural en los formularios.
Los enlaces no.
Los botones están diseñados para acciones del usuario.
Los enlaces están diseñados para destinos.
Intentar obligar a un elemento a comportarse como el otro suele generar código adicional y más problemas de accesibilidad.
Cómo navegan los usuarios de lectores de pantalla
Muchos desarrolladores se sorprenden al descubrir que los usuarios de lectores de pantalla suelen navegar por las páginas consultando listas de enlaces o listas de botones.
En lugar de leer cada palabra de una página, pueden saltar directamente entre elementos interactivos.
Imagine que un usuario abre una lista de enlaces y escucha:
- Abrir menú
- Expandir sección
- Mostrar filtros
- Cerrar diálogo
Esas son acciones, no destinos.
Deberían haber sido botones.
La estructura de la página ya no refleja la realidad.
El usuario debe dedicar tiempo adicional a descubrir qué hace realmente cada control.
Un ejemplo del mundo real
Recientemente, el sitio web de un bufete de abogados utilizaba etiquetas de anclaje para cada sección desplegable de su página de preguntas frecuentes.
Cada pregunta estaba programada como un enlace.
Al hacer clic en el enlace no se navegaba a ninguna parte. Simplemente se mostraba contenido oculto debajo de la pregunta.
El diseño funcionaba visualmente.
La experiencia de accesibilidad no.
Los lectores de pantalla anunciaban cada pregunta como un enlace. Los usuarios de teclado esperaban navegación. El código no proporcionaba ninguna de las dos cosas.
Reemplazar los enlaces por botones nativos requirió solo unos minutos de desarrollo y corrigió inmediatamente el problema semántico.
No fue necesario rediseñar nada.
No fue necesario instalar ningún widget de accesibilidad.
Solo fue necesario utilizar mejor HTML.
Lista práctica de verificación
Utilice un enlace cuando:
- El usuario navega a otra página
- El usuario abre un sitio web externo
- El usuario descarga un archivo
- El usuario salta a otra sección de una página
- El usuario abre un documento o recurso
Utilice un botón cuando:
- El usuario envía un formulario
- El usuario abre o cierra una ventana modal
- El usuario expande o contrae contenido
- El usuario muestra u oculta un menú
- El usuario cambia una configuración
- El usuario filtra resultados de búsqueda
- El usuario realiza una acción sin abandonar la página
La buena accesibilidad comienza con HTML
Muchas auditorías de accesibilidad se centran en atributos ARIA, contraste de color, indicadores de foco y herramientas automatizadas de prueba.
Esos aspectos son importantes.
Sin embargo, un número sorprendente de incumplimientos relacionados con la ADA tiene su origen en algo mucho más simple: elegir el elemento HTML equivocado.
Los desarrolladores suelen pasar horas escribiendo JavaScript para que controles personalizados se comporten correctamente cuando el navegador ya proporciona controles accesibles de forma gratuita.
Un enlace no es un botón.
Un botón no es un enlace.
El navegador conoce la diferencia. Los lectores de pantalla conocen la diferencia. Los usuarios de teclado conocen la diferencia.
Su HTML también debería conocerla.
Comments (0)
No comments yet.