Contents

Cuando alguien pregunta qué es una pill en diseño web, generalmente se refiere a un elemento pequeño y completamente redondeado en una página o aplicación. Esa forma es lo que describe la palabra “pill”.
Es un estilo visual, no un componente fijo que siempre funciona igual.
La misma forma puede cumplir distintas funciones. A veces una pill solo muestra información, como una etiqueta de estado.
Otras veces se puede hacer clic en ella, como un filtro que un usuario puede activar y desactivar, o una selección que puede eliminar. La forma por sí sola no indica cuál es el caso, por eso los sistemas de diseño la nombran de manera diferente.

Un sistema de diseño es el conjunto de reglas y componentes prediseñados que una empresa comparte para construir sitios o aplicaciones de forma consistente. No todos los sistemas usan la palabra “pill”.
Dos fuentes usan “pill” directamente:
| Fuente | Término usado | Qué hace |
|---|---|---|
| Bootstrap | Pill badge | Un estilo de badge completamente redondeado, con la clase .rounded-pill |
| Refinitiv Element Framework | Pill | Un elemento pequeño tipo botón para mostrar elementos seleccionados, con opciones de alternancia y eliminación |
Otras fuentes usan términos distintos para etiquetas similares pero diferentes:
| Fuente | Término usado | Qué hace |
|---|---|---|
| Fluent 2 | Tag | Muestra un valor seleccionado, como un destinatario de correo, y puede eliminarse |
| GOV.UK Design System | Tag | Muestra un estado, como activo o completado |
| USWDS | Tag | Resalta contenido nuevo o categorizado, o filtra resultados |
| Atlassian Design System | Tag | Una etiqueta compacta para categorizar contenido |
| Android Jetpack Compose | Chip | Cuatro tipos de chip interactivos (assist, filter, input, suggestion) para apps de Android |
Estos tags y chips no se llaman pills en su propia documentación, y los chips de Android son un ejemplo móvil, no un estándar web.
Revisa cómo se comporta un elemento redondeado en lugar de asumirlo por su nombre.

La pregunta más útil que el nombre es si una pill es estática o interactiva. Una pill estática muestra información y no está pensada para que se haga clic en ella.
Una pill interactiva invita a una acción: selección, alternancia o eliminación.
El ef-pill de Refinitiv muestra el tipo interactivo. Admite un modo de alternancia con un estado activo, un botón para eliminar la pill y un valor que representa lo que significa.
El mismo componente también puede ser una etiqueta simple; la documentación de Refinitiv señala que un desarrollador puede asignarle un rol de presentación para ese caso, de modo que los lectores de pantalla la traten como texto en lugar de anunciarla como un elemento en el que se puede hacer clic.
Mezclar ambos tipos genera problemas. Una pill estática con estilo de interactiva puede invitar a clics que no hacen nada.
Una pill interactiva con estilo de etiqueta simple puede ocultar el hecho de que se puede usar. Mantener ambos tipos visualmente distintos, y consistentes con elementos similares en la página, reduce ese riesgo.
Resolver estos detalles durante la construcción es el tipo de trabajo que ocurre en el desarrollo front-end hecho a mano y probado.

No toda pill seleccionable necesita comportamiento completo de botón, pero una que activa una acción, como un filtro o un cierre, debe funcionar también para usuarios de teclado y lectores de pantalla.
Una etiqueta accesible es el nombre que un lector de pantalla anuncia para un elemento, generalmente tomado de su texto visible. Elegir un componente específico no hace esto automático; la etiqueta aún debe describir qué hace la pill.
El ef-pill de Refinitiv calcula esta etiqueta a partir del texto de la pill automáticamente y usa un rol de botón por defecto. En modo de alternancia, es decir, cuando cambia entre dos estados como encendido y apagado, también gestiona automáticamente un atributo aria-pressed para exponer ese estado.
Ese requisito de aria-pressed aplica específicamente a los botones de alternancia. Un botón de acción ordinario, que realiza una sola acción sin cambiar de estado, no necesita un estado presionado.
Cualquier pill construida para actuar como botón también debe responder a Enter y Espacio, según el patrón de botón del W3C. La guía de Bootstrap agrega que el color por sí solo no debe transmitir significado, ya que los lectores de pantalla no lo comunican.

Una pill generalmente cumple uno de cuatro roles. Una etiqueta estática solo muestra información.
Un enlace de navegación lleva a otra página, y los enlaces estándar ya son compatibles con el uso de teclado. Un botón de acción ordinario realiza una sola acción sin estado presionado.
Un botón de alternancia cambia entre dos estados y necesita que ese estado se exponga mediante aria-pressed.
Definir qué rol debe cumplir una pill antes de construirla da a diseño y desarrollo el mismo entendimiento de lo que debe hacer.
No necesariamente. Fluent 2 describe el reflow como el paso de los tags a la siguiente línea cuando un grupo no cabe, no como un ajuste de texto dentro de un tag.
Eso resuelve una fila saturada, no una etiqueta más ancha que la pantalla. Mantén las etiquetas cortas y prueba el comportamiento real en pantallas pequeñas.
El atributo clears de Refinitiv agrega un botón de eliminación visible y permite que la pill responda a la tecla Suprimir, para que los usuarios de teclado también puedan eliminarla. Confirma ambas opciones al especificar una pill similar.
El filter chip de Android combina un estado seleccionado con una marca de verificación, en lugar de depender solo del color. Combinar un ícono visible con un estado a nivel de código como aria-pressed da a los usuarios más de una señal.
Las propiedades documentadas de Refinitiv, active, clears, disabled, readonly, toggles y value, son una lista útil para describir estados y no solo apariencia.
El patrón de botón del W3C señala que botones y enlaces cumplen propósitos distintos, y la apariencia debe coincidir con la función. Una pill que activa una acción debe ser un botón.
Una que navega a otro lugar debe usar comportamiento de enlace.
USWDS recomienda probar tu implementación específica directamente, en lugar de asumir accesibilidad solo porque se basa en un sistema de diseño ya probado.
Have any questions or comments? Write them below!