Cuándo usar user-select: none (y cuándo es una trampa de UX/Accesibilidad)

Probablemente hayas recurrido a user-select: none para evitar que el texto se resalte cuando alguien hace clic en un botón. Parece un pequeño detalle inofensivo de pulido. Pero aplícalo en el lugar equivocado y habrás roto silenciosamente la experiencia para una porción significativa de tus usuarios. Aquí te explicamos cómo usarlo bien.

Qué hace realmente la propiedad CSS user-select

La propiedad CSS user-select controla si un usuario puede seleccionar texto en un elemento. Los valores más comunes que encontrarás:

• none — evita completamente la selección de texto
• text — permite explícitamente la selección (útil para anular un none heredado)
• all — un clic selecciona todo el contenido del elemento
• auto — el valor predeterminado, que se resuelve según el contexto del elemento y el valor calculado de su padre

Cuando aplicas user-select: none a un elemento padre, efectivamente evita la selección en los descendientes a menos que los anules explícitamente con user-select: text. Ese comportamiento es fácil de olvidar y fácil de romper cosas con él.

Cuándo tiene sentido deshabilitar la selección de texto con CSS

Hay razones genuinamente buenas para recurrir a user-select: none. La clave es mantenerlo limitado.

Botones y enlaces con apariencia de botón. Los elementos nativos <button> no son seleccionables por defecto. Pero las etiquetas <a> estilizadas como botones sí lo son, y la selección accidental de texto durante un clic-arrastre es un punto de fricción real. Aplicar user-select: none aquí es razonable.

.btn {
  user-select: none;
  cursor: pointer;
}

Interfaces de arrastrar y soltar y controles deslizantes. Cuando los usuarios interactúan arrastrando, la selección de texto compite directamente con el gesto. Deshabilitarla en el elemento arrastrable evita que el navegador secuestre la interacción.

Barras de pestañas, barras de herramientas y elementos de interfaz interactivos. Las etiquetas en pestañas o botones de iconos no necesitan ser seleccionables. Aplicar user-select: none a estos componentes mantiene las interacciones limpias.

Excluir elementos decorativos o no contenido de las copias del portapapeles. Si un emoji, unidad publicitaria o elemento aside contaminaría la copia de un usuario, envolverlo en user-select: none mantiene la selección limpia sin deshabilitarla ampliamente.

Dónde user-select: none se convierte en una trampa de UX y accesibilidad

Aquí es donde la mayoría de los artículos se quedan cortos. Deshabilitar la selección de texto en el contexto equivocado causa daño real.

Áreas de contenido. Los artículos, documentación, mensajes de error, resultados de formularios y fragmentos de código siempre deben ser seleccionables. Los usuarios copian texto para buscarlo, traducirlo, pegarlo en herramientas o compartirlo. Bloquearlo es fricción sin ninguna ventaja.

Herramientas de traducción y texto a voz. Las extensiones de navegador como Google Translate y herramientas independientes de texto a voz operan sobre texto seleccionado. Los usuarios con discapacidades cognitivas, dislexia o dominio limitado del idioma dependen de estos flujos de trabajo. user-select: none los rompe silenciosamente.

Personas que leen resaltando. Muchos usuarios, incluidos aquellos con TDAH o desafíos de memoria de trabajo, siguen su posición de lectura seleccionando texto a medida que avanzan. Eliminar esa capacidad en páginas con mucho contenido es una barrera de accesibilidad genuina.

Comportamiento de buscar en página. Aunque Ctrl+F / Cmd+F sigue funcionando independientemente de user-select, algunos entornos de navegador y herramientas de asistencia interactúan con el estado de selección de formas que no son completamente consistentes entre implementaciones.

Importante: Los lectores de pantalla como JAWS y NVDA analizan el DOM directamente y no dependen de la selección de texto, por lo que user-select: none no los afecta. Los riesgos de accesibilidad están con los usuarios videntes que dependen de flujos de trabajo basados en selección.

user-select: none no es un mecanismo de protección de contenido

Vale la pena decirlo claramente: user-select: none no protege tu contenido. Cualquiera puede abrir DevTools, deshabilitar el CSS y copiar libremente en segundos. Tratarlo como una medida de seguridad intercambia daño real al usuario por cero protección real.

Una regla práctica para la accesibilidad de user-select

Aplica user-select: none solo a controles interactivos, no a contenido. Si el propósito de un elemento es ser leído, copiado o referenciado, deja la selección en paz.

/* Seguro: elementos de interfaz interactivos */
button,
[role="tab"],
.drag-handle {
  user-select: none;
}

/* Nunca hagas esto con contenido */
article,
p,
code,
.error-message {
  /* user-select: none — no lo hagas. */
}

Una nota más sobre compatibilidad de navegadores: las implementaciones antiguas requerían prefijos de proveedor (-webkit-user-select, -moz-user-select). Los navegadores modernos manejan bien la propiedad sin prefijo, pero el comportamiento no es perfectamente uniforme en todos los entornos, así que prueba en lugar de asumir. Las versiones con prefijo de proveedor como -webkit-user-select solo deben agregarse al soportar entornos antiguos, ya que el comportamiento con prefijo puede diferir de la propiedad estándar.

Conclusión

user-select: none es una herramienta útil para componentes de interfaz interactivos donde la selección accidental crea fricción. Se convierte en una trampa cuando se aplica a cualquier cosa que los usuarios necesiten leer, copiar o referenciar. Mantén el alcance limitado, nunca lo uses como un bloqueo de contenido, y evitarás los errores más comunes.

Preguntas Frecuentes

Truly understand users experience

See every user interaction, feel every frustration and track all hesitations with OpenReplay — the open-source digital experience platform. It can be self-hosted in minutes, giving you complete control over your customer data. . Check our GitHub repo and join the thousands of developers in our community..